集成篇 大规模矫捷测试怎样做

作者 |

关于大规模的产品来说，即使驳回矫捷的形式来做，也依然防止不了多个服务集成以及和其余产品集成的环节，这一篇就和大家一同探讨一下在大规模矫捷测试中如何启动SIT（System Integration Testing）集成测试。

一、大规模矫捷测试的分层战略

随着散布式架构的盛行，大规模的产品开发愈加灵敏和方便，但这同时也为品质保证优惠带来了应战。为了更高效地启动测试，咱们往往驳回测试分层的战略。从关注每个服务的测试，到关注某个模块的多个服务集成，再包含一个产品内不同模块间的基础测试，最后再到整个端到端多个产品间的集成测试。如图：

1.迭代内测试

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

2.SIT集成测试

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

二、两种集成测试的组织形式

大规模产品的集成测试普通有两种组织形式。如图:

1.虚构的SIT测试团队

(1) 组织形式

每个Scrum团队有一个SIT接口人，作为全体SIT测试和各个团队之间的桥梁。SIT Lead担任SIT全体的组织，协调，战略，规范，机制等。各个Scrum团队担任SIT的测试口头。

(2) 好处

这种组织形式相对灵敏，SIT接口人可以兼顾小组内SIT的义务与团队内的迭代义务。普通来说SIT义务优先级更高。当SIT义务集中时，可以就义迭代内的义务来允许SIT。当SIT相对义务较少时，可以允许更多迭代内的义务。

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

(3) 缺陷

SIT义务和迭代内容易出现资源抵触，迭代内须要留必定buffer给SIT。人员切换频繁会造成SIT测试效率低。

2.独立的SIT测试团队

(1) 组织形式

独立的SIT集成测试团队，团队成员专门担任系统集成测试口头，与Scrum团队是弱衔接。SIT Lead担任SIT全体的组织，协调，战略，规范，机制等，并担任SIT团队成员的造就以及与各个Scrum团队之间的协作和常识传递。

(2) 好处

这种组织形式行能源强，SIT团队专门担任集成测试，可以极速积淀集成测试阅历，资源专项公用，上班效率更高。同时还可以隔离对迭代内的影响，迭代内的测试比拟容易方案和控制。

(3) 缺陷

这种组织形式协作老本很高。SIT团队和迭代内团队是两个独立的组织，容易构成筒仓效应。SIT团队成员须要和每个团队对接学习业务及架构的常识，并高效及时地与Scrum团队沟通发现的疑问，造成沟通老本参与。而且资源独占，不够灵敏，关于人员的要求也很高。SIT团队的成员须要在短时期内对全体的业务了解透彻，始终地学习新性能，才干更有效的发现集成疑问。

(4) 实践名目中的选用

在实践名目中，依据实践状况可以驳回两种不同的形式来启动SIT测试。关于团队协作熟练且有足够带宽处置暂时义务的团队，可以驳回虚构SIT测试团队的形式。这种形式不会对既有的组织结构形成很大的破坏，也不会参与过多的沟通老本和常识传递老本。

而关于集成疑问影响高，产品尚在初期，对迭代内品质不够有信念的组织，可以先驳回独立测试团队来担任SIT测试和疑问修复的团队。这种形式可以屏蔽对迭代内的影响，降落迭代内的治理老本。独立的SIT团队成员也应该参与其担任模块Scrum团队的关键优惠，了解迭代内的进展，同步SIT测试状况。在有带宽的状况下，也随时允许迭代内的测试上班。

无论哪种形式，都要有一致的准则，测试战略，疑问照应机制和测试治理规范，才干有效地协调分歧，独特成功集成测试。

三、SIT集成测试节拍

在大规模名目中，集成测试的节拍取决于名目的迭代节拍和产品的复杂度。关于较为成熟的产品，倡导在每个迭代周期或每特性能颁布行启动集成测试。但是，关于从无到有（0-1）的大规模数字化转型名目，由于业务尚不成熟，频繁集成或许较为艰巨。

因此，可以驳回滚动式逐渐减速的形式启动集成，该形式驳回前松后紧的战略。只管频繁集成无利于品质保证，但思索到产品复杂性和初始阶段等多种起因，将集成分为四个阶段会愈加适合。

如图：

由于业务的复杂性，一个端到端的场景往往触及到多个模块，甚至少个产品线，SIT的自测和拉通测试，以及UAT验收都须要并行滚动启动，每次迭代内上班成功后都要阅历SIT自测，SIT拉通，UAT产品验收，UAT拉通验收四个步骤。

经常会遇到第一阶段的拉通还没有成功，就要启动第二阶段的SIT自测的状况，所以须要布局好不同环境的更新方案，拉出不同的分支，平衡资源等，只要这样短缺的预备才干更高的保证名目的品质。

逐渐减速的集成测试节拍能够协助咱们在前期做好预备，率领团队相熟集成的上班流程，造就团队对集成测试的认知，构成良好的上班习气，这样才干在后续多个并行上班的复杂环境中坚持极速集成的节拍。

四、SIT集成测试布局

集成测试普通可以分为三步走，测试方案与预备，测试口头与监控，测试收尾与总结。每个步骤都有相应的实施优惠。

一切的集成中，首次的集成测试最为关键，有三个关键指标：

第一次性集成一切都是从0开局，由于每团体对详细的流程、规范、环境、工具，以及人员看法和职责划分等方面都带有自己以前的认知。为了到达一致看法和指标，SIT测试启动会是一个十分必要的环节。

五、集成测试用例的设计

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

1.SIT自测的用例编写

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

2.SIT拉通的用例编写

SIT拉通测试和SIT自测的并重点不同，它更关注从抢先到下游整个贯串的场景。测试用例如何设计也是十分有应战的事件。每个产品都在SIT自测时设计了自己的测试用例，假设用笛卡尔集拼接，数量将指数级增长。所以须要依照端到端的业务场景编写用例，以关键性的外围业务开展辐射到各个产品上，保证业务场景测试充沛。

六、分支战略及SIT疑问修复机制

普通介绍驳回骨干开发的战略来治理代码，这更合乎咱们矫捷中尽早继续集成的理念。但是假设集成的阵线拉得比拟长，集成时期须要坚持必定的代码稳固性，那么集成中发现疑问的修复和新性能的开发之间就会发生抵触，这时刻就不得不思索更好的分支战略。

滚动式集成战略使得同时或许最多会有三条线并行。也就是咱们除了骨干之外，须要有两个分支。一个分支做SIT拉通集成，另一个分支做SIT自测，骨干启动迭代内开发。测试环节中在哪里发现疑问，就哪里修复，验证经事先再一致Cherry Pick到其余分支。

如图:

(1) 分支战略的好处

要说这种分支战略的好处，其实就是满足了大规模矫捷测试中滚动式并行集成的复杂需求。这样使得咱们可以阶段性的尽早地启动集成优惠，尽早发现疑问，必定水平的测试左移。否则是无法启动这种复杂场景下的集成测试的。但是这种形式也是有老本的。

(2) 分支战略的老本微危险

这种形式的老本是显而易见的，开发同窗必定一个疑问启动多个分支的代码修正或许merge举措，测试同窗必定在多个环境上启动验证。这无疑是带来了很大的上班量。危险也雷同显著，假设开发同窗遗记merge到骨干或许其余分支，这个疑问会被遗漏，在未来再次出现，带来品质危险。

七、集成测试中接口变卦之殇

SIT自测时关注的是产品内不同模块间的接口，一个产品内的团队联调时机多，所以接口疑问没有那么突出。但是产品之间都是开发了很多性能后才开局初步启动集成测试的，开发环节中都是各自经常使用mock的形式屏蔽第三方依赖的，这时刻就会造成很多接口变卦疑问。

假设没有适合的接口变卦处置机制，接口变卦会无量无尽地扑面而来。为了控制变卦收缩，接口变卦的流程和机制就跃然纸上。

接口变卦机制

在开发环节中触及到和第三方系统交互的接口，在定义明晰后须要留存接口文档和邮件记载。这样在SIT拉通测试的环节中发现疑问后就有迹可循，能够更正当的定义接口变卦的正当性。多个产品集成测试须要站在整个产品成功的角度思索疑问，假设集成测试中出现阻塞疑问，须要立刻处置，否则会影响整个集成的进展。所以又把疑问分为两种类型：

(1) 阻塞场景：先照应，再更新记载。

由于拉通测试的不凡性，当存在阻塞场景拉通的疑问出现时，不论该疑问最终被定义为缺陷还是需求变卦，都须要第一优先级启动修复。为了处置这样的状况，即使是新需求，或许无法达成分歧，团队也会立刻照应处置，随后再更新相应记载。

(2) 普通场景：依照普通流程处置。

假设是普通场景，就依照先记载，判定优先级，再依据迭代布置处置。

大规模的E2E拉通测试很像一场抗争，须要整个团队集思广益，提早做好布局并极速推进决策调整，任何一环节出现疑问都会造成整个阻塞，耽误的就是几百号人的时期和精神。

八、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发现疑问较多微危险较高的性能启动回归测试。