测试“集中作战室”探索与实施

(一)      银行业IT测试发展

软件测试作为整个软件生命周期中的重要一环，是软件产品的质量保证。近些年来，随着“互联网+金融”的高速发展，移动APP，微信公众号，网上银行等已经成为了银行用户办理业务的主要入口，如何开发和运营高质量软件，成为了银行业务发展的一个关键。银行业的软件测试也经历了一个很长的发展周期。

起步阶段

银行软件测试的起步阶段始于开发与测试一体化管理，一般通过科技外包的方式完成产品开发与测试流程。测试人员的管理被纳入软件开发人员的一体化管理，从事测试工作的人员或是从开发队伍中分离出来的技术人员，或是一些测试新手，导致测试的流程不够独立完善，无法有效的区分单元测试，集成测试，验收测试。

发展阶段

软件测试进入发展阶段，开始生成专门的测试团体，通过初步制定测试流程和目标，明确软件测试各个阶段的任务，形成测试的流程化管理。但是由于软件外包测试人员处于流动状态，决定了测试管理是一种松散型的管理模式：有组织机构和职责，但是权责不明确；有人员管理，但是管理的重心是如何在规定时间内完成工作任务，换言之，测试的管理是—种任务驱动型的管理模式。

成熟阶段

进入软件测试成熟阶段的典型特征是有专职的测试队伍，测试范围涵盖了功能测试、兼容性测试、安全测试、性能测试、验收测试等，对测试人员和测试任务的管理呈现持续开展的特征。具体体现为制定详细的软件测试流程和规范，对软件测试的各个阶段有准入准出标准，更加合理安排测试人员和时间。

(二)      我行IT测试阶段划分

目前银行业测试各个阶段一般分为：单元测试-系统/集成测试（SIT）-验收测试（UAT）-生产验收测试（PAT）四个阶段。其中单元测试一般由开发人员设计单元测试的脚本并完成测试，该阶段针对系统的单元模块，无法全局验证产品质量。系统测试由专职的测试技术人员完成，这个阶段还会包含一部分的集成测试，测试技术员会进行需求分析，制定测试计划与策略，编写并执行测试案例。一般系统测试完成后才会进入用户验收测试（UAT），这个阶段是产品上线前的最后一道关卡，由银行业务人员完成。但是银行的业务人员往往更善于业务分析，对于软件测试的技能掌握不到位，此时需要专职的软件测试工程师来辅助。银行的项目多数为迭代型项目，即整个产品已经完成并上线，但是根据业务创新需求持续不断对系统功能做出优化或增加。一个业务系统往往会对接多个业务团队，同时每个迭代周期中又可能接收到不同业务团队的需求，需要软件工程师针对每次不同的团队或者不同的业务人员，做好辅助工作。

(三)      业务验收测试痛点

纵观整个测试流程，不难发现验收测试阶段属于监管的一大盲区。回顾以往验收测试工作，总结出过程中以下几个痛点：

1.       由于业务验收人员相对分散，且仅提供验收结果，对于业务人员验收过程，缺失监控手段，易导致陷入监控盲区；

2.       测试质量监控团队对业务测试质量的验收仅仅依赖其提供的测试文档，故；

a)      无法排除业务人员以测试文档繁重，减少测试时间、降低测试质量为代价，以此满足测试文件形式要求的风险；

b)      测试质量监控团队对于业务的验收仅以测试文档为依据，以此作为测试质量监控的最终手段本身就存在较大风险，此外测试文档的检验亦存在人为主观性风险。

3.       UAT测试时间预留时间不充分，SIT/UAT并行时间过长，UAT缺陷较多，可能导致业务投诉反馈SIT测试质量不高。

4.       质控团队不能有效掌握业务人员对兼容测试进行覆盖情况；

(四)      测试“集中作战室”方法探索

为快速响应多样化的业务需求，针对以上痛点我们总结并提出了测试“集中作战室”的概念：即规定时间地点，统筹和监督业务、开发和测试人员三方集中开展业务验收测试，实现时间空间高度集中、各项目资源共享。此方法主要通过整合业务、开发、测试全体成员、测试资源于一体，以高效沟通、快速响应、集中作战方式开展测试实施工作，从功能测试、兼容性测试、回归测试、业务验收测试等各个方向，切实做到对业务验收过程质量的严格监控。实施过程由质控各项目SIT测试负责人组织协调测试具体事项（包括安排：测试时间、测试地点、测试实施人、测试数据、建议测试范围、兼容性测试矩阵规划等测试准备事项、测试执行过程监督、测试总结会议召开、后期计划跟进等）；UAT测试人员根据时间、地点进行具体实施，开发到场进行配合。

实施原则

Ø  场地方面，可以是事先预置的作战室，也可以是虚拟作战室。原则上空间、时间上都要尽量集中；

Ø  时间方面，既可运用于SIT、UAT分开执行，也可用于平行执行；

Ø  人员方面，在人力许可的前提下，适当调动其他项目测试资源，以确保测试开展的探索性、兼容性；同时要协调好开发人员，及时对验证过程中遇到的问题给与支持。

实施维度

1.       项目性质：新项目、维护型项目；

2.       项目类型：项目制、人力资源型；

3.       实施阶段：UAT验证阶段、PAT验证阶段。

4.       实施时间：工作日、周六周日

5.       参与人员：业务、开发、测试

6.       实施发起人：质量部-测试经理/test leader。

实施步骤

1.       提前准备白名单、测试数据、测试手机、验证清单、测试案例等，同时请业务负责人作为本次验证问题集中受理处。并且所有发现的Bug同步记录至禅道进行处理；

2.       提前安排开发、测试人员准时到场，同时准备测试数据、测试手机等。且组织安排好前端以及管理台等相关测试工作；

3.       提前组织开发人员，随时配合PAT验证工作；

4.       提前准备测试数据、测试手机等。同时组织好前端页面、管理台等相关测试工作；

5.       提前准备测试手机。负责人负责测试协调工作（包括APP、微信）；且做好随机测试、探索性测试工作；

实施目标

1.       同时节省SIT/UAT测试时间；

2.       节约开发、测试、业务之间沟通成本；

3.       提升SIT/UAT测试资源使用效率以及兼容性测试覆盖面；

4.       通过高效沟通、快速响应，快速解决问题等方式，提高了工作效率；

5.       简化业务验收测试报告编写内容，减少质控团队对于业务验收依赖；

6.       切实做到UAT、PAT测试过程、测试质量进行严格监控；

实施难点及推广

在整个模式的推行过程中，也会遇到一些困难点和风险点，主要体现为沟通统筹难。参与集中测试的人员包含测试，开发，业务三方面的人员。统筹安排时间地点要符合各个参与成员的需要，从而导致前期安排统筹需投入较多时间和精力。再者就是业务人员对测试技能掌握不足，对于测试的案例设计也仅仅局限于业务流程的设计，而且偏向于正向流程，对于反向流程、具体的实现方案带来的影响会考虑不足。因此，在“集中测试”模式推广的前期，采用集合人力，固定地点的方式，先要求各方人员到指定地点参与测试。在测试工程师配合业务验收测试过程中，促进业务人员熟悉平台设计方案、提升业务人员测试技能、养成良好测试习惯。打破物理地点局限，形成“虚拟集中作战室”的模式，通过电话会议或者组建讨论群方式，确保各方人员时间统一的基础上完成测试。

在“集中测试”模式不断的实施和探索中，通过总结、提炼、优化集中作战室经验，进行全面推广。首先各个项目组内实行集中测试的模式，增强各个项目业务和测试工程师的合作力度，其次打通各个项目组的测试资源瓶颈，打造“一个平台测试，多个平台用户”，通过以点覆面，最终现全面众测。

(五)      小结

在“互联网+”大环境、大发展、以及严格的市场淘汰环境下，互联网金融如雨后春笋，而银行互联网金融业务“零售”思维也得到了蓬勃发展。“落后就要挨打”在当前的社会环境不仅仅指技术落后，同时也包含“思想的落后”。在测试管理理念先试先行的原则下，我团队通过不断创新，不断探索新的测试管理体系建立测试“集中作战室”。由此不仅规避了业务验收过程中的风险，并且节省了测试周期，同时充分结合用户体验测试，将测试贯穿于软件生命周期的整个过程，即符合IT质量对安全性、可靠性、高效高质量保证的瀑布型开发模型，亦适应于以快捷为核心驱动的互联网金融思维模式。