在《质量保障体系从 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 公众号上发表的文章：大规模敏捷测试怎么做（集成篇）。