大规模敏捷测试怎么做（集成篇）

对于大规模的产品来说，即使采用敏捷的方式来做，也依然避免不了多个服务集成以及和其他产品集成的过程，这一篇就和大家一起讨论一下在大规模敏捷测试中如何进行SIT（System Integration Testing）集成测试。

1. 大规模敏捷测试的分层策略

随着分布式架构的流行，大规模的产品开发更加灵活和便捷，但这同时也为质量保障活动带来了挑战。为了更高效地进行测试，我们往往采用测试分层的策略。从关注每个服务的测试，到关注某个模块的多个服务集成，再包括一个产品内不同模块间的基础测试，最后再到整个端到端多个产品间的集成测试。如图：

1）迭代内测试

迭代内测试主要关注两个方面的测试：

• 服务的功能测试
• 模块内的服务集成

迭代内的测试如何进行，可以参考上一篇博客：大规模敏捷测试怎么做？——基础篇

2）SIT集成测试

SIT系统集成测试分成了两个阶段：

• 第一个阶段是SIT产品内的集成测试，又叫SIT产品自测，主要关注产品内不同服务间的集成，不考虑第三方产品的影响，此时是产品的初步集成，使用mock server屏蔽掉第三方系统的依赖并保证测试充分很重要。
• 第二个阶段是SIT产品间的集成测试，又叫SIT拉通测试，主要关注不同产品间的接口集成。端到端的场景可能会涉及多个产品，多个组织，以及庞杂的参与人员都会增加拉通测试的难度。所以如何更好地组织和实施集成测试是大规模敏捷测试成功的关键。

2. 两种集成测试的组织方式

大规模产品的集成测试一般有两种组织方式。如图:

1） 虚拟的SIT测试团队

• 组织方式

每个Scrum团队有一个SIT接口人，作为整体SIT测试和各个团队之间的桥梁。SIT Lead负责SIT整体的组织，协调，策略，规范，机制等。各个Scrum团队负责SIT的测试执行。

• 优势

这种组织方式相对灵活，SIT接口人可以统筹小组内SIT的任务与团队内的迭代任务。一般来说SIT任务优先级更高。当SIT任务集中时，可以牺牲迭代内的任务来支持SIT。当SIT相对任务较少时，可以支持更多迭代内的任务。

同时这种组织方式信息更加透明，知识能够及时共享。接口人可以将SIT发现的问题更快地分享给团队内，团队内可以针对问题及时调整迭代。同时迭代内开发新功能的信息可以及时共享为后续SIT测试打下基础。

• 缺点

SIT任务和迭代内容易发生资源冲突，迭代内需要留一定buffer给SIT。人员切换频繁会导致SIT测试效率低。

2） 独立的SIT测试团队

• 组织方式

独立的SIT集成测试团队，团队成员专门负责系统集成测试执行，与Scrum团队是弱连接。SIT Lead负责SIT整体的组织，协调，策略，规范，机制等，并负责SIT团队成员的培养以及与各个Scrum团队之间的协作和知识传递。

• 优势

这种组织方式执行力强，SIT团队专门负责集成测试，可以快速沉淀集成测试经验，资源专项专用，工作效率更高。同时还可以隔离对迭代内的影响，迭代内的测试比较容易计划和控制。

• 缺点

这种组织方式协作成本很高。SIT团队和迭代内团队是两个独立的组织，容易形成筒仓效应。SIT团队成员需要和每个团队对接学习业务及架构的知识，并高效及时地与Scrum团队沟通发现的问题，导致沟通成本增加。而且资源独占，不够灵活，对于人员的要求也很高。SIT团队的成员需要在短时间内对整体的业务理解透彻，不断地学习新功能，才能更有效的发现集成问题。

实际项目中的选择

在实际项目中，根据实际情况可以采用两种不同的模式来进行SIT测试。对于团队协作熟练且有足够带宽处理临时任务的团队，可以采用虚拟SIT测试团队的方式。这种方式不会对既有的组织结构造成很大的破坏，也不会增加过多的沟通成本和知识传递成本。

而对于集成问题影响高，产品尚在初期，对迭代内质量不够有信心的组织，可以先采用独立测试团队来负责SIT测试和问题修复的团队。这种方式可以屏蔽对迭代内的影响，降低迭代内的管理成本。独立的SIT团队成员也应该参加其负责模块Scrum团队的关键活动，了解迭代内的进度，同步SIT测试情况。在有带宽的情况下，也随时支持迭代内的测试工作。

无论哪种方式，都要有统一的原则，测试策略，问题响应机制和测试管理规范，才能有效地协调一致，共同完成集成测试。

3. SIT集成测试节奏

在大规模项目中，集成测试的节奏取决于项目的迭代节奏和产品的复杂度。对于较为成熟的产品，建议在每个迭代周期或每个功能发布前进行集成测试。然而，对于从无到有（0-1）的大规模数字化转型项目，由于业务尚不成熟，频繁集成可能较为困难。

因此，可以采用滚动式逐步加速的方式进行集成，该方式采用前松后紧的策略。虽然频繁集成有利于质量保障，但考虑到产品复杂性和初始阶段等多种因素，将集成分为四个阶段会更加合适。

• 阶段一：MVP集成。第一次集成测试基于项目的MVP，即核心功能进行，经过初期调研、产品设计、架构设计和多次迭代开发，产品核心雏形已基本完成。除了轻量级集成，第一次正式的系统集成测试是在完成最高优先级P0级别需求（MVP）后进行的。
• 阶段二：大需求集成。第二次集成测试在完成次优先级P1级别需求后进行。由于P1中仍存在一些难以拆分的大需求，因此需要等需求功能完整后再进行集成测试。
• 阶段三：按迭代集成。后续需求相对较小，可以更容易拆分，因此可以按照每个迭代的频率进行集成测试。
• 阶段四：按需集成。在集成测试过程中，可能会陆续发现一些新的小需求。为了及时进行集成测试和测试拉通，可以按需进行集成。

如图：

由于业务的复杂性，一个端到端的场景往往涉及到多个模块，甚至多个产品线，SIT的自测和拉通测试，以及UAT验收都需要并行滚动进行，每次迭代内工作完成后都要经历SIT自测，SIT拉通，UAT产品验收，UAT拉通验收四个步骤。

经常会遇到第一阶段的拉通还没有完成，就要进行第二阶段的SIT自测的情况，所以需要规划好不同环境的升级计划，拉出不同的分支，平衡资源等，只有这样充足的准备才能更高的保障项目的质量。

逐步加速的集成测试节奏能够帮助我们在前期做好准备，带领团队熟悉集成的工作流程，培养团队对集成测试的认知，形成良好的工作习惯，这样才能在后续多个并行工作的复杂环境中保持快速集成的节奏。

4. SIT集成测试规划

集成测试一般可以分为三步走，测试计划与准备，测试执行与监控，测试收尾与总结。每个步骤都有相应的实施活动。

所有的集成中，初次的集成测试最为重要，有三个主要目标：

• PO（Product Owner）完成对于迭代内工作的验收：他们会参与集成测试，并集中在场景的测试上。
• 完成各模块间的集成测试：验证各模块之间的接口是否工作正常，满足需求。QA需要关注除了PO负责测试场景外的边界和异常场景的测试。
• 培养团队习惯：还有一个更为重要的目标是培养团队习惯，让所有相关的团队成员能够熟悉集成测试概念，目标，原则，策略，流程规范等，并不断地持续改进，为后续的快节奏集成打下坚实的基础。

第一次集成一切都是从0开始，由于每个人对具体的流程、规范、环境、工具，以及人员意识和职责划分等方面都带有自己以前的认知。为了达到统一认识和目标，SIT测试启动会是一个非常必要的环节。

5. 集成测试用例的设计

测试用例的设计与编写是集成测试成功的关键，它决定了测试的方向和深入程度。而对于SIT自测和SIT拉通测试，显然测试用例的设计是不同的。SIT自测更注重本产品内的功能，而SIT拉通测试更注重端到端的场景衔接。

1）SIT自测的用例编写

SIT自测有两个主要目标，一个是为PO验收迭代内实现的功能，一个是验证模块和模块间的接口集成。所以SIT自测阶段的测试用例也分为两个部分：

• 一是由系统的终端用户从用户视角进行编写，由QA和PO审核修改完成的，这样编写出来的用例场景更能贴近实际的业务，同时在编写用例的过程中可以让用户更加了解系统逻辑，是一个交流对齐的过程。
• 二是QA基于接口进行一些边界及异常场景的测试。

2）SIT拉通的用例编写

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

6. 分支策略及SIT问题修复机制

一般推荐采用主干开发的策略来管理代码，这更符合我们敏捷中尽早持续集成的理念。但是如果集成的战线拉得比较长，集成期间需要保持一定的代码稳定性，那么集成中发现问题的修复和新功能的开发之间就会产生冲突，这时候就不得不考虑更好的分支策略。

滚动式集成策略使得同时可能最多会有三条线并行。也就是我们除了主干之外，需要有两个分支。一个分支做SIT拉通集成，另一个分支做SIT自测，主干进行迭代内开发。测试过程中在哪里发现问题，就哪里修复，验证通过后再统一Cherry Pick到其他分支。

如图:

• 分支策略的优势

要说这种分支策略的优势，其实就是满足了大规模敏捷测试中滚动式并行集成的复杂需求。这样使得我们可以阶段性的尽早地进行集成活动，尽早发现问题，一定程度的测试左移。否则是无法进行这种复杂场景下的集成测试的。然而这种方式也是有成本的。

• 分支策略的成本和风险

这种方式的成本是显而易见的，开发同学必须一个问题进行多个分支的代码修改或者merge动作，测试同学必须在多个环境上进行验证。这无疑是带来了很大的工作量。风险也同样明显，如果开发同学忘记merge到主干或者其他分支，这个问题会被遗漏，在将来再次出现，带来质量风险。

7. 集成测试中接口变更之殇

SIT自测时关注的是产品内不同模块间的接口，一个产品内的团队联调机会多，所以接口问题没有那么突出。但是产品之间都是开发了很多功能后才开始初步进行集成测试的，开发过程中都是各自使用mock的方式屏蔽第三方依赖的，这时候就会导致很多接口变更问题。

如果没有合适的接口变更处理机制，接口变更会无穷无尽地扑面而来。为了控制变更膨胀，接口变更的流程和机制就呼之欲出。

接口变更机制

在开发过程中涉及到和第三方系统交互的接口，在定义清晰后需要留存接口文档和邮件记录。这样在SIT拉通测试的过程中发现问题后就有迹可循，能够更合理的定义接口变更的合理性。多个产品集成测试需要站在整个产品成功的角度考虑问题，如果集成测试中出现阻塞问题，需要立刻处理，否则会影响整个集成的进度。所以又把问题分为两种类型：

• 阻塞场景：先响应，再更新记录。

由于拉通测试的特殊性，当存在阻塞场景拉通的问题出现时，不管该问题最终被定义为缺陷还是需求变更，都需要第一优先级进行修复。为了处理这样的情况，即使是新需求，或者无法达成一致，团队也会立刻响应处理，随后再更新相应记录。

• 普通场景：按照一般流程处理。

如果是普通场景，就按照先记录，判定优先级，再根据迭代安排处理。

大规模的E2E拉通测试很像一场战争，需要整个团队齐心协力，提前做好规划并快速推动决策调整，任何一环节出现问题都会导致整个阻塞，耽误的就是几百号人的时间和精力。

8. QA测试人员在集成测试中职责的转变

QA在迭代内主要是职责是进行故事卡的测试，有时负责一些Showcase的准备和演示工作。但是在SIT测试中，QA的作用和职责发生了很大的变化。由于参与SIT测试的人员众多，尤其在后期拉通测试中，需要和其他产品团队共同合作完成测试。QA的职责从单一的测试执行转变为一专多能。

首先转变为一个测试Coach，赋能其他角色，尤其PO来进行测试；其次转变为一个Agent，问题解决的引擎。对每个问题进行分析，澄清，分发，驱动PO，开发，BA共同协作，快速解决问题；最后还是一个价值守护者，不仅守护着产品的质量，更要守护业务的价值，对拉通中产生的不断变化业务方案，接口定义，能够从用户角度，从ROI角度，据理力争，并基于问题不断调整测试策略。

1）作为测试Coach对PO赋能

PO第一次参与到测试中来，虽然对场景熟悉，但是对测试理解尚浅。为了帮助PO尽快掌握测试能力，QA需要转变身份成为一个测试Coach，为PO进行赋能。首先用业务的语言讲解系统实现的功能，方便其理解以及要关注的测试点。

其次用技术的手段帮助他们能够快速上手，将系统需要的配置以及跳过依赖所需要的mock使用方法文档化，可以及时查阅。

最后作为PO测试的支持者，帮助他们定位问题，确定缺陷严重级别，建立与团队的沟通，将问题尽量描述清晰等等。在后续的各种集成测试， UAT测试中，经过赋能的PO都可以发挥重要的作用。

2）作为团队引擎驱动问题解决

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

QA在集成测试中是最关键的角色，就像一个引擎，驱动整个团队来快速解决问题，使得集成测试能够顺利进行。

QA同学也是迭代内交付团队的一个屏障，将非代码问题都屏蔽在团队之外，减轻团队的工作量，有效地保障迭代内的交付。

3）作为价值守护者

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