原文地址:https://www.sohu.com/a/315434322_672569
作者:中国工商银行业务研发中心 郝毅 霍嘉 肖烨 金石乔
本文笔者着重介绍了金融行业软件自动化测试的相关实践与思考。
近两年来,多家金融机构和专业测试组织开展了大量自动化测试技术的应用研究与工作实践,自动化测试被普遍认为可以有效提高测试效率、节省人力成本,但从实际取得的效果来,似乎并没有达到大家的期望,这让我们不得不重新审视自动化测试,需要基于不同的研发模式进行重现思考和认识。
金融行业主要软件研发模式
目前,金融行业主要有两类软件研发模式,其对应着不同的组织形态。一类是以传统商业银行为代表的规范的、稳定的、质量保障的瀑布式或类瀑布式研发模式,对应的是需求、研发、测试角色相互分离、彼此独立的组织形态;另一类是以互联网公司为代表的灵活的、迭代的、效率优先的敏捷研发模式,对应的是需求、研发、测试角色相互融合、团队协作的组织形态。这两类研发模式各有优势,传统研发模式注重质量,需要严格控制风险,确保安全生产;敏捷研发模式更看重效率,对线上问题有一定的容忍度。质量和效率在天平的两端,选择哪类研发模式取决于企业对于风险的接受程度和市场需求的响应要求。
在整个IT行业敏捷化转型的大趋势下,传统金融行业也在核心稳定的基础上探索适合自身的敏捷化研发模式,大型商业银行一般采用“双模IT”研发管理模式。一方面通过传统研发模式保障核心基础业务的稳定性,另一方面通过敏捷研发模式开展互联网创新业务需求的落地。
不同软件研发模式下的自动化测试实践
不同软件研发模式对应的自动化测试技术体系和工作实践是存在差异的。自动化测试技术只有跟组织形态、环境条件、测试阶段相匹配才能发挥效果,并且在缺陷发现(质量)、风险覆盖(范围)、效率提升(时间)和资源节约(成本)方面产生的作用各有侧重,需要区别的认识和看待。
1.传统瀑布式研发模式。
最佳实践:在传统瀑布式研发模式下,单元测试、系统集成测试(SIT)由开发部门人员完成,版本交付后有独立的测试部门团队进行用户验收测试(UAT)。自动化测试在两阶段分别开展,其中UAT作为质量保障的最后一道关卡,基于用户视角端到端的真实业务流程模拟。UAT开展自动化测试主要使用UI页面自动化测试工具,成熟的实践一般是将核心稳定的功能做成脚本,通过执行自动化测试脚本辅助对重点交易功能进行回归验证,从而起到增强质量信心的作用。当期版本改造内容的验收测试,因脚本开发投入的成本无法得到合理的回报,自动化测试一般不会被考虑。
前提条件: UAT自动化测试技术难点在于前端页面控件识别和业务逻辑核对,自动化测试实施很依赖页面控件开发的规范性,规范的程序和界面设计会显著降低自动化测试脚本开发和维护的成本,被测系统具备良好的可测性是UAT自动化测试有效开展的前提。此外,高可用的测试环境,完备的数据基础,成熟的平台工具,丰富的业务资产,标准化的案例步骤也是UAT自动化测试高效开展的必要条件。虽然UAT对于测试人员自动化测试技能水平要求不高,但对于研发规范性、环境可用性、工具容错性、数据完整性、资产成熟度、业务稳定性等外部条件依赖程度较高,在这些条件没有达成时,UAT推进自动化测试的效果会比较缓慢。
作用效果: 反复执行、流程繁琐的测试内容是UAT自动化测试实施的重点,脚本维护和保鲜是自动化测试实施的难点。通过选择成熟稳定的业务交易流程开展例行化和回归测试的自动化执行,可以提升测试工作的全面性,拓宽当期版本改造内容之外的测试范围,保障核心业务和交易流程的稳定性,从而整体提振版本上线的信心。从缺陷发现、风险覆盖、效率提升和资源节省四个维度上看,UAT自动化测试开展对于项目测试的贡献主要是通过扩大风险覆盖范围达到质量保障的作用,对于例行化和回归测试的执行效率和人力投入节省方面也实现了优化提升,但对于测试主要关注的当期版本改造内容缺陷发现、测试效率提升和人力成本节约方面并未发挥明显作用。
2.敏捷研发模式。
最佳实践:在敏捷研发模式下,研发测试都在一个团队,研发测试人员共同开展工作,人员沟通效率高,资源共享程度高。测试主要集中在接口级的功能和系统集成测试(SIT),用户验收测试(UAT)一般由业务部门开展,不承担质量把关的职责。业界成熟的实践是通过接口自动化测试工具开展自动化测试工作,接口自动化测试脚本的稳定性和可复用度比UI自动化测试脚本更好。很多金融机构测试部门基于接口开展自动化测试,并搭建了持续集成、持续构建的自动化测试流水线。被测系统集成新的接口后就自动跑一遍全量接口测试案例,保证新的接口对存量功能不会产生影响。接口自动化测试既是对当期新功能、新接口的验证,同时也是存量自动化测试脚本库的构建,其良好的特性被敏捷化研发模式所推崇,在自动化测试中发挥的效用被业界广泛认可并大力发展。
前提条件: 敏捷研发模式下测试对象是一个个独立的接口,测试人员验证的是接口功能实现的准确性,无需考虑业务本身的稳定性,测试数据直接根据接口定义进行配置,测试环境只需满足被测接口正常联通即可开展自动化测试,自动化测试对于外界条件依赖程度低。敏捷研发模式下自动化测试实施的前提是清晰的接口定义和接口暴露程度,接口只有在测试环境中能够容易获得,案例可通过简单数据配置生成才能方便地开展自动化测试;同时,接口自动化测试对于测试人员技能水平和工具框架灵活性要求更高,测试人员需要具备编码能力,能够设计良好的接口测试案例。自动化测试工具框架要灵活地支撑持续集成、持续构建的接口组装和批量测试流程,被测应用系统接口要能够被自动化测试工具很容易的集成和调用。商业工具一般难以满足需求,需要自动化测试工具研发团队具备较强的研发能力,支持敏捷研发模式下自动化测试工具灵活的需求。
作用效果: 敏捷研发模式下自动化测试案例可以继承和复用,在后续版本中反复执行,为自动化测试提供了便利的条件。从缺陷发现、风险覆盖、效率提升和资源节省四个维度上看,这种自动化测试实践可以在当期版本功能测试中发现缺陷。对于存量接口回归验证,通过积累复用接口自动化测试案例,实现存量风险的覆盖,提升存量案例执行的效率,通过机器统一调度执行节省了执行人员,整体看来在四个方面都能发挥效果。自动化测试案例一次设计反复使用使得自动化资产积累变得更加顺畅,高并发高响应的执行反馈使得全量功能回归在短时间内迅速完成,在敏捷研发模式下实现持续迭代、反复验证,一天内就可以跑几遍全量测试,自动化测试案例开发成本和执行成本都更加低廉,反复应用使得自动化测试投入回报很高,是一种经济效益良好的自动化实践。
以上两种自动化测试实践是金融行业的主要形式,两种实践模式对应着不同的测试阶段,在效率和质量平衡下,根据项目测试的需求可以在软件研发生命周期中独立或同时使用,合理取舍达到相互补充效果。正确、合理地实施自动化测试,能够快速、全面地对软件进行测试;通过自动化增强测试的全面性和充分性,在单位时间内提升测试效能,从而提振各个测试阶段的质量信心。
关于自动化测试的一些思考
科学地看待自动化测试,就是要了解自动化测试技术的优势和局限性。开展自动化测试可以带来收益,但也要认识到现阶段的自动化测试技术并不是万能的,不能解决全部问题,有一些在认识上的误区需要被澄清。
1.效益。自动化测试的优势如下。
可靠: 自动化测试每次运行时都会准确执行相同的操作,而人工测试则会受到精力、智力、知识、经验等方面的影响,很难做到像工具一样精确、可靠,因此自动化测试可以消除人为的错误,排除人工测试的不确定性,使测试结果更加客观。
快速: 自动化测试的脚本运行速度比人工执行要快得多,很多由于时间限制的问题无法完成的测试内容,通过自动化即可快速实现,同时和手工测试相比,计算机还可以不知疲倦的进行测试。
可重复: 自动化测试可以通过重复执行相同的操作来测试软件的反应,尤其对于跨版本、周期性进行的例行化测试内容,自动化测试的优势更加明显,一个工具或者一个脚本编写完毕,即可多次反复使用,使测试效率可以得到极大的提升,避免人工测试的倦怠感。
覆盖全: 自动化测试工具和脚本由于具有可编程性,可以通过编写复杂的测试脚本来模拟测试过程中重现的场景,找出隐藏的信息,这是手工测试很难达到的一点。
2.误区。
在推进自动化测试的过程中也容易走向另一个极端,尤其是陷入一些常见的误区,主要包括如下几个方面。
一是自动化测试是一种比人工测试更先进,更高级的测试手段。 假设一个项目的需求并不明确,或者对于某个产品来说,它的界面经常会发生变动,类似于这些软件的测试就不适合使用自动化进行测试。如果为了推进自动化而把这些不适合进行自动化测试的产品也通过自动化来进行测试,那么不仅不会产生正的收益,相反可能会增加测试的成本,如不断维护自动化脚本的成本。自动化测试与手工测试的关系应该是相辅相成的,互相弥补各自的局限性,以此来相互促进。
二是所有的手工测试都应该被100%的自动化。 一味片面地去追求高自动化覆盖率,不仅软件的质量得不到提高,而且还会让测试人员疲于奔命,投入巨大的精力去编写或者维护自动化测试工具和脚本,它们产出的性价比却很低。自动化测试并不是万能的,它需要根据实际情况引入并有的放矢地设定其覆盖率。
三是自动化测试能够发现大量的缺陷,它比手工测试更有效。 这个误区如果不单独提出来,可能很多人都会这样认为。然而实际情况却是,自动化测试只能发现很少的软件缺陷,手工测试反而能发现更广泛且更深层次的问题。这是因为测试发现缺陷的能力取决于案例设计而非执行频度,自动化测试的优势在于高效的执行,案例设计仍旧依靠人工,自动化测试在回归测试时大有可为,但这并不意味着其发现问题的能力就一定比手工测试更强,这也是为什么自动化测试不能完全替代手工测试的一个原因。
四是自动化测试只是测试工程师的事情,与开发人员没有关系。 在软件开发过程中,首先需要考虑的就是软件本身的可测试性。但是开发人员如果和测试人员是分离开来的,尤其是开发人员完全隔离于测试过程,那么开发人员就很有可能在一开始的时候就不把软件的可测试性考虑进来,导致其开发的软件对于测试人员来说难以进行测试,更别提还要实现自动化测试了。
五是商业自动化测试工具比开源自动化测试工具更靠谱。 就自动化测试工具而言,测试团队应该根据自身实际情况来选择。商业自动化测试工具固然有它对应的优点,比如有技术团队进行支持,遇到问题也能尽快得到解决。但是如果有特殊需求,这类软件往往就没有自由的可定制功能了。而开源自动化测试工具由于源代码都是开放的,如果团队有特殊的定制需求,可以由测试团队自行修改开源自动化测试工具来满足团队的需要。当然这就需要测试团队具有一定的开发能力,对于测试人员的综合素质又提出了很高的要求。因此要根据测试类别和人员能力实际情况来选择合适的自动化测试工具。