在《质量保障体系从 1 到 N 的思考》中,落地实践了迭代内的质量保障体系构建,但是在日常的工作中,个人还涉及到了端到端的大规模集成测试,这个活动主要是在项目的前两个版本需要集中做,那么如何开展这类测试活动呢?笔者结合自己在多个大型项目中的实践,做了整理。

1. 什么是端到端集成测试

端到端集成测试,又叫 SIT 拉通测试,主要关注不同产品间的接口集成。端到端的场景可能会涉及多个产品,多个组织,以及庞杂的参与人员都会增加拉通测试的难度。就像搭乐高,迭代测试,就像各个小零件间的配合,更多的是关注上下游依赖的系统,而端到端集成测试,就是把所有零件按照图纸(场景),组合成一个完整的玩具(实际上完整的业务流程)的过程。

集成测试有如下特点:

规模大:端到端集成测试涉及业务的全链路流程,需要配合的系统一般比较多,规模大;

系统多:实际的业务场景相对复杂,需要多系统配合,不论哪个环节出问题,对业务而言,就是失败的;

涉及人员多:由于前面两个原因,涉及到人员就会很多,需要做好沟通和协调,对组织的软技能要求高;

关注数据的流向而不是单系统的异常:到了端到端集成测试,测试人员需要关注的是完整的业务场景是否能走通,异常业务流是否能回退或者有解决方案,而不需要过于关注某个节点系统内部的异常;

2. 团队组织形态

基于端到端集成测试的基本要求,又需要经常开展类似的活动(在项目上线前期,如果需要多系统协同上线,就需要做一次完整的拉通测试)。为了满足这种活动需要,我们选择了如下图所示的组织架构:

端到端集成测试的人员,需要从各系统团队中抽取出来(角色包含测试和产品,必须有产品加入),这些人即参与日常的迭代测试,了解当前迭代系统的业务需求,同时在开展端到端测试的时候,抽出来负责端到端测试,由各团队负责人统筹安排,一般来说 SIT 任务优先级更高。当 SIT 任务集中时,可以牺牲迭代内的任务来支持 SIT。当 SIT 相对任务较少时,可以支持更多迭代内的任务。

同时这种组织方式信息更加透明,知识能够及时共享。接口人可以将 SIT 发现的问题更快地分享给团队内,团队内可以针对问题及时调整迭代。同时迭代内开发新功能的信息可以及时共享为后续 SIT 测试打下基础。但缺点也比较明显,端到端集成测试任务和迭代内容易发生资源冲突,迭代内需要留一定 buffer 给端到端集成测试。

3. 开展端到端集成测试的前期准备

因为涉及人员多,规模大,为了更好地开展端到端集成测试,需要做好充分的事先准备,才能更好地开展活动,应对变化。所以,在开展端到端测试之前,需要梳理好准入条件,以便评估风险。一般会包含如下准入条件:

迭代需求研发完成度:由于平时大家关注的点都在各自的迭代中,对于哪些需求是否研发完成,未完成的 Story 对整体的业务影响是什么并不清晰,所以需要在端到端集成测试前,明确迭代任务是否都已开发完成,如果有未完成的,需要在这里明确出来,让团队知道并评估影响。

迭代测试报告:各子项目需要出具各自迭代的测试报告,以便团队整体评估风险;

端到端测试人员名单:方便后续做沟通和协调,也有利于整体产能和人力资源的评估。

端到端测试用例:在开展端到端测试之前,需要完成对应端到端测试用例的评审(具体的形式下文再阐述)。

环境对齐:由于涉及的系统多,各系统又有各自的环境,所以需要在开展端到端集成测试前,确认各系统对接的环境是正确的(这里可以另开一个文档来记录,明确各系统对应的 IP、端口、中间件地址等,也方便后续排查问题能够快速对应的服务器)

基础数据准备:根据业务场景和测试用例,需要各团队准备好对应的基础测试数据,避免在测试过程中因为缺少基础数据而导致测试阻塞(根据经验,这里是最容易出问题的地方,需要认真对待)

4. 测试用例输出与评审

首先,需要和产品、业务一起确认端到端集成测试的业务场景。与迭代测试用例不同,端到端测试的用例更关注从上游到下游整个贯通的场景。测试用例如何设计也是非常有挑战的事情。每个产品都在 SIT 自测时设计了自己的测试用例,如果用笛卡尔集拼接,数量将指数级增长。所以需要按照端到端的业务场景编写用例,以关键性的核心业务展开辐射到各个产品上,保证业务场景测试充分。

根据上图的场景路线图,输出测试用例。对于测试用例的组织形式,也与迭代测试不同,因为阅读和执行测试人员的对象不同(在迭代测试中,测试用例的阅读对象是测试人员,所以不需要很细致,甚至只需要功能点就可以了。但是在端到端测试中,测试用例的阅读对象是产品或者业务,还有可能是一线业务人员,所以需要把测试用例写得更明确些)。我们采用的测试用例模板如下图所示:

5. 端到端测试过程实践

在端到端测试开展的期间,需要关注以下内容:

人员集中办公:由于这个活动涉及的人员较多,所以需要一个集中办公,降低沟通成员,让相关人员更专注地开展测试活动,也更有利于问题的推动解决。

明确每日的执行目标:没有目标就无法跟进度。一般开展端到端测试的时间会比较长(多轮次,多场景,至少 1 星期的时间),所以需要明确每天的测试进展,大家往同一个目标去努力。

可视化:在这么多人场景下,如果无法做到可视化,那问题的跟进就会非常麻烦,所以需要一个大看板来随时反馈进度和阻塞点,我们利用 Excel 的强大函数功能,做了如下实时看板:

同时,对测试过程中发现的问题进行实时的跟踪记录,确保发现的问题都被记录在册,以便后期做复盘时,提供有效的数据支撑。

在整个端到端集成测试的执行过程中,需要测试负责人实时推进和解决随时发现的问题,除了代码的问题,更多时候会有接口的问题,业务方案的问题。在与业务,PO,BA 以及其他产品的人员讨论中,测试人员作为信息交汇点,需要具备业务和技术的结合智慧,提出自己的认知,从用户的使用角度,从技术的成本角度,统一考虑,以最优的成本守护价值。同时要根据迭代内的测试反馈,不断地调整测试策略,制定重点的测试场景,对迭代内测试不充分,对于端到商发现问题较多和风险较高的功能进行回归测试

6. 测试问题复盘

因为整体的测试执行过程场景复杂,人员多,遇到的问题也会比较多,所以需要在每日完成测试执行任务后,做及时的复盘,发现并解决过程问题,并根据当天实际的执行情况,对第二天的任务做出针对性的调整,提高测试执行效率。

具体问题具体分析,这里就不放相关的案例了。

7. 测试人员的思维转换

在整体的端到端测试过程中,不管是总体的负责人,还是各业务系统的测试人员,都面临着与迭代测试完全不同角色。在迭代测试中,测试人员更关注的是局部功能的业务验证和风险识别,但是在端到端测试中,测试人员需要做出至少以下几点的思维转换:

a. 作为团队引擎驱动问题的解决:

当 PO 或者其他产品人员在集成测试中发现问题时,测试人员首先要进行一个基础判断,是否是配置问题,数据问题,环境问题。如果确实是缺陷,则在缺陷上补充自己的分析和判断,流转给开发同学及时修复。如果是新的需求或者业务方案问题,则引入 BA 一起讨论澄清。

测试人员在集成测试中是最关键的角色,就像一个引擎,驱动整个团队来快速解决问题,使得集成测试能够顺利进行。测试人员也是迭代内交付团队的一个屏障,将非代码问题都屏蔽在团队之外,减轻团队的工作量,有效地保障迭代内的交付。

b. 作为价值守护者

测试人员是质量的守护者,同时也是价值的守护者。在集成测试中,除了代码的问题,更多时候会有接口的问题,业务方案的问题。在与业务,PO,BA 以及其他产品的人员讨论中,测试人员作为信息交汇点,具备业务和技术的结合智慧,提出自己的认知,从用户的使用角度,从技术的成本角度,统一考虑,以最优的成本守护价值。同时要根据迭代内的测试反馈,不断地调整测试策略,制定重点的测试场景,对迭代内测试不充分,SIT 发现问题较多和风险较高的功能进行回归测试。

8. 挑战点

在主持过多场次不同业务的端到端场景后,个人感觉对于这类测试活动,对负责人最大的挑战不在于对业务的熟悉程度(当然需要对整体的业务有相对完整的了解,也做不到对各系统都相当了解),而在于出现问题时,如何高效地沟通并推动问题的解决。所以在开展端到端测试之前,负责人需要对每个系统的对接人要有相当的熟悉,出现问题时,需要快速找到对应的人员,组织小团队讨论解决方案,并推动问题的解决,这就需要有非常好的沟通和协调能力,并要有高度的责任心,才能把这件事做好。

9. 小结

文章篇幅较长,基本上完整的介绍了大规模集成测试的实践,脑图整理如下:

注:在编写本文的过程中,关于理论的部分,参考了张海云老师在 TW 公众号上发表的文章:大规模敏捷测试怎么做(集成篇)。


↙↙↙阅读原文可查看相关链接,并与作者交流