• 快捷搜索
  • 全站搜索

银行信息系统非功能测试实践

2019-09-12 16:05:46作者:华夏银行科技开发中心 冯振兴 缪翔宇编辑:金融咨询网
需求分析是测试计划阶段的重要活动,是测试需求转化为测试方案的必须过程。尤其重要的是在抽象测试场景时,要根据被测系统的需求内容和技术特点进行拆解制订,以实现精准测试的目的。

发展现状:面对日益增长的测试需求,不断提升非功能测试效率和质量显得尤为重要,既要快速响应测试需求,按时完成测试任务,又要高效发掘系统问题,充分发挥测试效用。

  充分挖掘测试需求

  系统非功能需求是指系统必须具备的属性或品质,功能测试需求可由业务人员独立提出,而非功能测试需求往往需要业务人员和技术人员共同完成。业务人员了解系统运行基础需求,掌握系统未来用户规模及业务发展趋势,技术人员则对系统高可用保证、数据库实现等技术细节较为了解,两者综合互补才能形成完整的系统非功能测试需求。

  完整具体的测试需求是测试成功的前提条件,非功能测试需要有明确的测试需求来指引。盲目开展测试工作容易事倍功半,达不到测试效果。实际测试时,我们往往首先得到一份需求的半成品,部分技术细节或测试信息缺失,此时应针对测试需求进一步和需求方讨论确认,逐步完善测试需求,明确测试重点,同时要引导需求方提供更多的银行信息系统非功能测试实践技术实现细节,补充测试场景。

  为了更加高效高质地完成测试需求采集工作,我们可以为需求方构建非功能测试需求模板框架,内容包括测试背景、系统架构、业务量规模、测试案例、测试场景、测试环境、测试数据、网络策略和高可用机制等相关需求要素。尤其是针对测试场景和测试案例的选择,需求方可以通过选择系统类型或自由裁剪的方式实现需求采集标准化和自动化。系统根据客户定制类型自动生成必测、选测内容,然后再针对此需求进一步讨论完善,达到提升需求采集效率的目的。

  合理制订测试方案

  需求分析是测试计划阶段的重要活动,是测试需求转化为测试方案的必须过程。测试方案是需求分析的结果产出,完整的测试方案应至少包含测试计划、测试目标、测试案例、监控策略、测试场景设计、测试条件及约束等内容,完善可行的测试方案是测试工作高效执行的前提保证。

  尤其重要的是在抽象测试场景时,要根据被测系统的需求内容和技术特点进行拆解制订,以实现精准测试的目的。比如当前各家银行与互联网公司竞相推出的线上理财抢购活动,当面对集中式抢购的瞬间冲击时,理财系统及后端关联系统能否平稳运行关系重大。针对此类测试需求,除了要涵盖基础的性能测试场景,验证系统的最大处理能力、最大并发用户数和最大在线用户数,还要包括异常测试场景,检查系统通讯超时情况的处理机制;同时要增加限流测试场景,针对系统的限流机制,还需细分到交易限流、渠道限流、系统总量限流等微测试场景。

  总之,要对测试需求进行精准定位、合理分类,制订可行性强的测试方案,不同的业务场景应至少有一个或多个测试场景与之对应,非功能测试场景制订得合理与否决定着测试质量的高低。在测试方案形成后,一般还要根据系统的重要程度,进行相匹配的评审工作,以保证测试方案的严谨性。

  建立科学指标体系

  测试方案的核心是测试场景与测试目标,有了精准的测试场景,还要有明确的测试目标,这依赖于一套科学完整的评价指标体系。以系统性能指标为例,常规指标包括TPS(Transations per Second)、响应时间、资源使用率等。TPS应由业务量估算所得,常用“二八”原则(80%交易量在20%时间内完成)进行推算,也可通过采集生产系统的连续交易量进行数据建模分析,对系统未来业务量和TPS发展进行预测推演。响应时间根据系统类型及测试方法差异而设定不同,如OLTP(On-Line Transaction Processing)类型系统,对响应时间要求较高,应以毫秒级标准要求,而OLAP(On-Line Analytical Processing)类型系统,对响应时间要求略低,则可适当放宽标准。资源使用率可根据系统开发语言类型区别对待,如C语言和Java语言对硬件资源消耗特点差别明显,可根据不同特点制订不同标准要求。

  科学的非功能测试指标规划体系应考虑从业务类型、主机资源、数据库以及中间件等多维度规划,充分考虑系统多样性,将系统分级分类,根据系统特点和测试条件规范测试目标,指导系统优化过程,科学客观地对被测系统测试结果进行评价。

  规范测试执行过程

  与功能测试相比,非功能测试既要验证系统业务逻辑,又要检测系统健壮可靠,是业务与技术综合应用的过程。非功能测试主要包含四个阶段。设计阶段开始需求分析,完善测试方案;开发阶段调试测试脚本,准备测试数据;执行阶段实施测试场景,监控系统状态;分析阶段分析测试结果,验证系统问题。每个阶段过程都有相应的重点任务,都应规范有序开展,忽视每个测试过程都有可能错过发现系统缺陷的机会,规范执行测试过程是测试质量控制的重要手段。

  细节决定成败,注重测试细节是发掘系统缺陷的基础,测试过程的规范离不开测试细节的把控。从每个阶段的输入输出成果到测试过程控制,从每类测试场景的业务比例分配到场景执行时间要求,从每个系统的监控要求到测试问题记录,都应遵循相应的测试规范。比如测试执行阶段需要具备充足的测试数据后才能开展场景执行工作;基准测试场景案例应至少迭代100次才能统计平均响应时间;混合测试场景应至少持续平稳运行1小时;稳定性场景资源监控至少每隔30秒进行打点采集等。这些测试细节都应重视并严格按标准要求执行。

  每一个致命生产问题的爆发都是由一个个细微缺陷堆积迭代所产生的蝴蝶效应。这要求我们在测试过程中,严把测试过程,注重测试细节,不放过任何异常现象。诸如TPS或响应时间波动剧烈、CPU突增、内存无回收等现象,这些细节问题都应引起测试人员的关注,进而深入探究问题成因,不断提升测试质量。

  沉淀积累测试数据

  组织过程资产积累对任何工作都是重要而有意义的事情,测试工作更是如此。测试过程不断积累的测试数据以及生产系统运行数据对于提升测试质量有着重要作用。基于丰富的基础数据,我们可以将系统运行数据和历史问题集中提炼归类并进行大数据分析,评估系统每次测试的性能抖动程度,研究其历史上曾经出现的代表缺陷,寻找内在规律,为发现系统缺陷、性能调优提供有力的参考依据。

  测试和生产数据分析的过程也是测试质量管理的支持过程,我们可以为每个系统建立测试数据档案和测试知识库。每次测试结果都进行跟踪对比,通过与历史数据进行对照分析,评估测试数据差异与系统变更程度是否匹配,描绘系统性能变化曲线,达到提升测试质量,全面掌控系统性能、可靠性和稳定性的目的。

  定期回溯生产问题

  尽管我们不断致力于提升测试质量,但再完善的测试也不能排除所有系统缺陷,这个客观事实无法改变,总有部分系统问题会被遗漏并被带到生产环境后触发。认真分析这些生产问题,我们会发现测试工作的种种不足,例如测试方案不完善,测试环境不一致,测试人员不尽职等。

  定期回溯生产问题的核心内容是根本原因分析,这个过程的重要性不言而喻。通过分析生产问题,我们可以回溯测试过程中问题遗漏的原因,映射测试过程中不规范的执行过程,被忽视的细节问题等。同时,生产问题分析也是完善测试需求的有益过程,将生产环境各类高频问题归类整理后,可以反哺测试需求中的案例库和场景集,重点问题可纳入同类系统常态测试关注点,为系统提供个性化的定制测试服务。生产问题是一面镜子,通过它我们可以发现测试自身的诸多问题,在查漏补缺中不断改进测试方法,丰富测试场景,推动测试管理流程的改善,达到测试工作持续改进的目的。

  总结

  测试工作是对软件系统质量检测的重要手段,非功能测试是对系统可靠性、易用性、效率、可维护性、可移植性的全面检测。提升非功能测试质量对于控制银行信息系统运行风险有着重要意义。随着非功能测试的重要性越来越受认可,非功能测试阶段在整个软件开发周期中所占的比重也日益增大。从质量管理角度来看,提升非功能测试质量可从质量保证、质量控制和质量回溯三个过程着手:质量保证是非功能测试的过程能效保障,质量控制是非功能测试的阶段能效把控,质量回溯是非功能测试的能效提升来源,三者缺一不可。

图片1.jpg

  对于非功能测试工作,完整需求分析、全面测试方案和科学指标规划是质量保证的基础前提,规范测试过程和历史数据分析是质量控制的有效手段(见图1)。生产问题回溯是质量回溯的核心内容,三者构成质量管理闭环,是提升测试工作质量的完整过程,也是推动测试工作不断改进的持续动力。

(文章来源:金融电子化杂志)

扫码即可手机
阅读转发此文

本文评论

相关文章