作者 |
对于大规模的产品来说,即使采用敏捷的方式来做,也依然避免不了多个服务集成以及和其他产品集成的过程,这一篇就和大家一起讨论一下在大规模敏捷测试中如何进行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发现问题较多和风险较高的功能进行回归测试。
本网站的文章部分内容可能来源于网络和网友发布,仅供大家学习与参考,如有侵权,请联系站长进行删除处理,不代表本网站立场,转载者并注明出处:https://jmbhsh.com/qitabaihuo/35542.html