1 | 写在前面:之前和大家一起回顾了大规模敏捷测试的基础,良好的迭代内敏捷实践以及团队协作的一些小tips。既然说到大规模,一定要说到集成测试。对于0-1实现的系统,如何组织多个团队,多个服务甚至多个产品之间的进行有效的大规模集成测试,是我们这趟测试之旅中要经历的重点。 |
大规模敏捷测试的必经之路:SIT集成测试
大规模敏捷测试的分层策略
随着分布式架构的流行,使得大规模的产品开发更加灵活和便捷,但这同时也为质量保障活动带来了挑战。为了更高效地进行测试,往往采用测试分层的策略。从关注每个服务的测试,到关注某个模块的多个服务集成,再包括一个产品内不同模块间的基础测试,最后再到整个端到端多个产品间的集成测试。
迭代内测试
迭代内测试主要关注两个方面的测试:
每个服务的功能测试
每个模块内的服务集成,比如订单模块的测试。
上一个基础篇中,我们已经针对迭代内测试进行了详细阐述,这里不再赘述。
SIT集成测试
系统集成测试我又称为SIT集成测试,分成了两个阶段:
第一个阶段是SIT产品内的集成测试,又叫SIT产品自测,主要关注产品内不同服务间的集成测试,和第三方产品的接口暂时使用mock。
第二个阶段是SIT产品间的集成测试,又叫SIT拉通测试,主要关注不同产品间的接口集成。由于产品众多,又分为几条主线。将十几个甚至几十个产品一起拉通,那场面有点壮观。
该项目中的SIT集成测试有两个重要的特征:
产品是0到1的数字化转型,所有的集成基础都从0开始。
端到端的场景涉及多个产品集成,涉及组织复杂,参与人员众多。
两种集成测试的组织方式
大规模产品的集成测试一般有两种组织方式。
虚拟的SIT测试团队
组织方式:
每个Scrum团队出一个SIT接口人,作为整体SIT测试和各个团队之间的桥梁。SIT Lead负责SIT整体的组织,协调,策略,规范,机制等。各个Scrum团队负责SIT的测试执行。优势:
这种组织方式相对灵活,SIT接口人可以统筹小组内SIT的任务与团队内的迭代任务。一般来说SIT任务优先级更高。如果SIT任务集中时,可以牺牲迭代内的任务来支持SIT。如果SIT相对任务较少时,可以支持更多迭代内的任务。
同时这种组织方式信息更加透明,知识能够及时共享。接口人可以将SIT发现的问题更快地分享给团队内,团队内可以针对问题及时调整。同时接口人也可以及时获得迭代内开发新功能的信息,支持后续SIT测试。缺点:
SIT任务和迭代内容易发生资源冲突,迭代内需要留一定buffer给SIT。人员切换频繁会导致SIT测试效率低。
独立的SIT测试团队
组织方式:
独立的SIT集成测试团队,团队成员专门负责系统集成测试执行,与Scrum团队是弱连接。SIT
Lead负责SIT整体的组织,协调,策略,规范,机制等,并负责SIT团队成员的培养以及与各个Scrum团队之间的协作和知识传递。优势:
这种组织方式执行力强,SIT团队专门负责集成测试,可以快速沉淀集成测试经验,资源专项专用,执行力更强。
同时还可以隔离对迭代内的影响,迭代内的测试比较容易计划和控制,不受SIT太多影响。缺点:
但是这种组织方式协作成本很高。SIT团队和迭代内团队是两个独立的组织,容易形成谷仓效应。SIT团队成员需要和每个团队对接学习业务及架构的知识,并高效及时地与Scrum团队沟通发现的问题,沟通成本高。
而且资源独占,不够灵活,对于人员的要求也很高。SIT团队的成员需要在短时间内对整体的业务理解透彻,不断地学习新功能,才能更有效的发现集成问题。
在这个项目中,我们采用了第一种虚拟SIT测试团队的方式。但是对于不同的子团队,还采用了不同的协作方式。有的团队更独立,能过很好的协调团队内部SIT测试和迭代内测试,那么SIT接口人只需了解总体的策略,原则,机制和规范,做到定时沟通即可。而有些团队希望有专门的人来负责SIT测试,甚至SIT问题的修复,从而屏蔽对迭代内的过多影响。但是即使是相对固定的人参与SIT,他仍旧参与迭代内站会,及时同步SIT信息。如果SIT需要团队更多的支持,则阶段性地协商支持方式。如果SIT工作量较小时,则成员还可以及时支持迭代内工作。
无论哪种方式,都要有统一的原则,测试策略,问题响应机制和测试管理规范,才能有效地协调一致,共同完成集成测试。
SIT集成测试节奏
在大规模项目中,集成测试的节奏取决于项目的迭代节奏和产品的复杂度。一般来说较为成熟的产品建议每个迭代都进行集成测试,或者每个功能发布前进行快速集成。然而对于0-1的大规模数字化转型项目来说,初期很难做到频繁集成。那么多长时间进行一次集成测试是一个比较好的节奏呢?
在该项目上,由于业务和产品的复杂性,我们采用了滚动式逐步加速的方式来进行集成。逐步加速是采用前松后紧的方式来进行的。我们知道越是频繁的集成对于质量保障是越有利的,但是我们也要考虑到产品的复杂性,0-1的初始阶段等多种因素。集成的频率分为了四个阶段:
阶段一:MVP集成。第一次基础是基于0-1MVP来集成的。
经过初期调研,产品设计,架构设计,多个迭代的开发(当前项目是6个迭代),产品核心雏形基本完成。除了前期Showcase时进行的轻量级集成,P0级别需求(MVP)完成的节点是第一次系统的正式的集成测试。阶段二:大需求集成。 第二次集成是P1级别需求完成后进行。由于P1中仍有些大的需求,难以拆分,所以中间可以采用稍微长一点的时间(e.g.2个迭代)之后再集成。
阶段三:按迭代集成。 后续需求相对较小,可以更容易拆分,就可以按照每个迭代的频率来进行。
阶段四:按需集成。 而在做集成测试的过程中,还会陆续的识别到一些新的小需求,为了赶上集成以及拉通的窗口,我们会安排一些按需集成。可以每周,或者每个需求完成就部署到集成环境。
由于业务的复杂性,一个端到端的场景往往涉及到多个模块,甚至多个产品线,SIT的自测和拉通测试,以及UAT验收都需要并行滚动进行,每次迭代内工作完成后都要经历SIT自测,SIT拉通,UAT产品验收,UAT拉通验收四个步骤。有可能第一阶段的拉通还没有完成,就要进行第二阶段的SIT自测,需要规划不同环境的升级计划,拉出不同的分支,平衡资源等,为整个质量保障工作带来了非常大的挑战。
逐步加速的集成测试节奏能够帮助我们在前期做好准备,带领团队熟悉集成的工作流程,培养团队对集成测试的认知,形成良好的工作习惯,这样才能在后续多个并行工作的复杂环境中保持快速集成的节奏。
SIT集成测试启动会
集成测试一般可以分为三步走,测试计划与准备,测试执行与监控,测试收尾与总结。每个步骤都有相应的实施活动。
所有的集成中,第一次的集成测试最为重要,有三个主要目标:
PO完成对于迭代内工作的验收:他们会参与集成测试,并集中在场景的测试上。
完成各模块间的集成测试:验证各模块之间的接口是否工作正常,满足需求。这个主要由QA来承担,除了PO场景的测试外,要更关注在边界,异常情况上。
培养团队习惯:还有一个更为重要的目标是培养团队习惯,让所有相关的团队成员能够熟悉集成测试概念,目标,原则,策略,流程规范等,并不断地持续改进,为后续的快节奏集成打下坚实的基础。
第一次集成一切都是从0开始,无论是从具体的流程,规范,环境,工具,还是人员意识,职责划分上大家都带有着自己以前的认知。为了统一认识,对齐目标,在集成测试之前举行SIT测试启动会是一个非常必要的环节。
启动会的目的
普及集成测试的概念
各角色对齐集成测试的目标
宣贯集成测试的策略,原则,流程规范,管理机制,度量指标等
澄清各角色在集成测试中的职责
启动会的参会范围
集成测试涉及到的关键角色,包括:Scrum团队的PO, BA,PM,TL,QA。集成测试不仅仅是QA的事情,即使你采用独立的SIT团队,也需要和其他角色紧密合作才能完成集成测试。
Tips-1:在实际项目中,依据人员认知能力,可能在启动会前后需要多次和不同角色进行单独的沟通。有的项目成员可能没有经历过大规模复杂项目,往往会用小的scrum团队认知来衡量大规模集成的工作,造成认知偏差。
Tips-2: 需要注意要用各个角色能够理解的语言解释集成测试中的各种原则和策略,尤其是分支策略,升级计划等。人们容易掉进知识诅咒的陷阱,互相假设对方理解,结果造成实施中的偏差。
启动会的内容
启动会上要把各个角色为更好完成SIT集成测试所需要的信息都对齐,一般来说包含以下的内容:
集成测试目标和策略
集成测试的整体计划(时间,人员,范围)
集成测试的准入准出标准及度量指标
集成测试的问题响应机制
分支策略和问题修复流程
缺陷管理流程及规范
环境升级策略及规范
工具平台使用规范
对迭代内开发的影响
可能存在的风险及举措
各个相关负责人
沟通计划及问题升级流程
各角色职责及分工
其他问题
如果你是SIT
Lead,你需要在启动会之前做好线下调研,和各个关键角色对齐相关内容。启动会只是一个宣贯和所有角色对齐的动作,真正的对齐要发生在线下。否则启动会将变成一个争吵大会。如果不幸第一次变成这样的一个大会,你还需要准备第二次启动会直到对齐。尤其对于各个角色的职责与分工,一定要在会议上进行澄清,以免发生不同理解导致后续协作困难。
比如:PM要规划SIT测试支持与迭代内工作量的平衡;开发人员要完善服务配置工作,环境配置工作,理解缺陷修复规范,理解分支策略和问题修复策略,理解响应优先级等;BA要留出时间支持SIT过程中遇到的业务方案争议,做出决策;QA要做好测试用例设计,环境验证,数据初始化,问题响应,对PO进行支持等工作;而公共模块负责人和运维人员也要相应的提前准备,测试环境基础设施,部署流水线,做好部署升级准备,做好问题响应,修复准备等。
集成测试用例的设计与规划
测试用例的设计与编写是集成测试成功的关键,它决定了测试的方向和深入程度。而对于SIT自测和SIT拉通测试,显然测试用例的设计是不同的。SIT自测更注重本产品内的功能,而SIT拉通测试更注重端到端的场景衔接。
SIT自测的用例编写
前面我们讲到,SIT自测有两个主要目标,一个是为PO验收迭代内实现的功能,一个是验证模块和模块间的接口集成。所以SIT自测阶段的测试用例也分为两个部分:
一是由系统的用户(业务)联合PO从用户视角进行编写。由QA和IT PO审核修改完成的,进行测试的时候会根据业务场景和用例执行。
优点是用例的场景更能贴近实际的业务,同时在编写用例的过程中可以让用户更加了解系统逻辑,是一个交流对齐的过程。
缺点一是存在重复测试,描述不足以及期望结果和系统内的实现可能不一致(业务期望全集而不只是一个一期的MVP)。二是耗时耗力,用例编写涉及人员众多,工程庞大,花费比较多的精力去组织协调。但是为了0-1转型打好基础,并节省后面UAT验收的成本,采用了这种方式。
二是QA基于接口进行一些边界及异常场景的测试。这部分并没有以正式的测试用例形式出现,而是采用脑图的方式节约设计成本。
SIT拉通的用例编写
SIT拉通测试和SIT自测的侧重点不同,它更关注从上游到下游整个贯通的场景。测试用例如何设计也是非常有挑战的事情。每个产品都在SIT自测时设计了自己的测试用例,如果用笛卡尔集拼接,数量将指数级增长,估计得测上几个月也测不完。但是按照一个产品,又有缺失场景的风险。最后是将整个产品集分成若干个主线,以主线场景为主,从自测用例中挑选合适的用例,组成端到端的测试场景。
最后我们产品所在的主线,大约挑选出250多个场景。在做测试计划时,为这些场景进行编号xxx-001,xxx-002,并基于编号进行测试规划。测试计划中依据每个场景在不同产品中的流转,规划每一天开始场景号,结束场景号,从而把几十个系统的集成,几百号人的集成拉通测试组织起来。下图就是整个SIT拉通测试组织计划图。分为5个主线,N个产品。不过这样拉通的成本也是非常高的,如果不是0-1的数字化转型,一般也无法组织起这么大规模的拉通测试。
img
分支策略及SIT问题修复机制
Scrum中针对每个服务的开发,一般我们都推荐采用主干开发的策略来管理代码,这更符合我们敏捷中尽早持续集成的理念。然而对于大规模的复杂产品来讲,如果我们有较长的集成测试阶段,集成期间就需要保持一定的代码稳定性,那么集成中发现问题的修复和新功能的开发之间就会产生冲突,这时候就不得不考虑更好的分支策略。
这个项目中我们就遇到了这个问题,滚动式集成策略使得同时可能最多会有三条线并行。也就是我们除了主干之外,需要有两个分支。第一个分支可能还在做SIT拉通集成,另一个分支在做SIT自测,主干进行迭代内开发。那么当集成测试中发现了问题后,该在哪个上面进行修复,如何保障几条线同步呢?我们采用了哪里发现问题,哪里修复的原则,之后再Cherry
Pick到其他线。
这里如果某个集成分支发现的问题,就在这个集成分支上进行修复,之后再Cherry Pick到主干。如果还有另外一个分支并行,也要再Cherry
Pick到另一个分支。 这里如果代码差异很大,Cherry Pick可能不行,就需要手动修改代码。
- 分支策略的优势
要说这种分支策略的优势,其实就是满足了大规模敏捷测试中滚动式并行集成的复杂需求。这样使得我们可以阶段性的尽早地进行集成活动,尽早发现问题,一定程度的测试左移。
否则是无法进行这种复杂场景下的集成测试的。然而这种方式也是有成本的。
- 分支策略的成本和风险
这种方式的成本是显而易见的,开发同学必须一个问题进行多个分支的代码修改或者merge动作,测试同学必须在多个环境上进行验证。这无疑是带来了很大的工作量。
风险也同样明显,如果开发同学忘记merge到主干或者其他分支,这个问题会被遗漏,在将来再次出现,带来质量风险。
风险应对策略
从流程规范上定义清晰,规避风险。
包括问题筛选分级,在缺陷中写入明确Comments,甚至duplicate一个缺陷或者task来track其他分支上的merge动作,把这个流程写进代码规范,
最后消除分支时再次进行检查等等。 这里有一个问题修复机制的流程示例。
前期Monitor执行情况,及时纠正,养成习惯。
即使这样有规范流程,在前期还是会出现很多遗漏和错误,测试Lead和TL需要在前期进行更细致的Monitor,来帮助团队养成习惯。
SIT测试环境的准备与升级策略
测试环境是集成测试中非常重要的基础。在迭代内测试中,我们主要使用Dev环境和Test环境来进行开发自测和QA测试。在集成测试中,我们需要准备集成测试的环境。由于该项目把集成测试分成了两个阶段,还需要准备两个环境SIT自测环境,SIT拉通环境。而环境的升级也分为两种,一种是统一升级,迭代测试结束后,要进入到集成测试阶段,这时要做整个迭代开发代码的统一升级。另一种是测试过程中发现的bug修复后进行的升级,我们叫它日常发版。无论是那种升级都需要很多的准备工作,也有可能踩很多坑。
统一升级
由于我们采用的滚动式逐步加速的集成节奏,从一开始0-1搭建环境,到后期频繁升级,都有着很多痛苦的经历。最开始从0到1的环境搭建花费了近一周的时间,从基础设施搭建,公共服务部署,各服务部署与配置,到环境验证和主场景冒烟测试,真的是问题百出,险象环生,负责部署的同学一直熬了几个晚上。
最突出的问题有以下几个方面:
- 计划不明晰,信息不透明;
最开始的时候,虽然也有环境升级的计划环节,但是并没有通知到所有的角色和执行人,导致在搭建和部署过程中发现问题时,才现抓人解决。有的人找不到,有的人找到也不明白上下文,感觉上一片混乱。
显然环境搭建和部署并不是某一个人的事情,它涉及到各个角色的协作,包括运维、TL、各模块的开发、QA,甚至需要验证的PO。不同的角色要协同一致,各司其职,才能保障环境的顺利升级。
改进方案:
经过一轮的问题分析和讨论,决定三个手段来保障信息透明。
1 | - 升级启动会:每次升级前一两天开一个环境升级启动会,邀请所有相关人员,对齐升级的时间,环境,版本等信息。10到20分钟快速信息对齐。 |
- 配置问题频繁出现;
虽然有配置中心,虽然也有环境配置管理,但是总还是有很多需要手工去记录,更改的地方。在前期升级过程中,频繁出现配置问题,无论是服务的配置参数丢失,配错,还是环境配置参数忘记修改,都导致非常多的问题。排查问题也造成了很多的资源浪费。
这里有流程问题,技术问题,也有意识问题。有很多团队成员觉得配置问题不算是问题,只有代码的问题才是真正的bug。然而配置问题带来的危害一点不比真正的代码问题小。
改进方案:
为此我们对所有的环境和配置问题进行了根因分析归类,找出共性问题,通过下列手段解决:
1 | - 创建升级检查checklist :要求每个团队为自己负责的模块和服务都创建服务配置及环境配置检查单,TL评审后,升级期间由负责人员对照检查。同时还记录每次部署完成,验证完成具体时长,以便后续提升。 |
- 单独升级某个服务,却由于模块间的互相依赖导致回滚;
协调所有模块一起升级是最安全的一个做法,但是它也是有成本的。尤其到后期更频繁的集成时,升级频率也非常的高。一起升级有时显得很笨拙。也曾有过单个模块单独升级的时候,然而大规模产品的共性问题就是有互相的依赖摆脱不开。虽然采用了微服务方式,但是一方面对于公共模块有依赖,尤其是前端公共基座的修改。另一方面集成测试有些场景涉及几个模块,需要进度对齐,一起升级。
改进方案:
1 | 对一些关键需求依赖提前识别,协调不同团队的开发资源和进度,尽量能够节奏一致。但是也开放exception的流程,提出由关键角色评审后,可以不跟随大节奏,单独或者几个服务一起升级。 |
日常发版
日常发版主要是缺陷修复后的升级。这个升级要简单很多,但是也会存在一定的风险,尤其是拉通测试时,一个服务出现问题,可能会导致整体的场景被阻塞,那影响的范围将是上百人,所以不能随意进行升级。要从几个方面去限制:
规定可升级的时间段: 比如上午9:00之前,中午12:00-2:00,下午6:00-7:00,晚上9:30之后。如果存在一些紧急升级,需要PMO和测试Lead同意才能破例升级。
控制可升级的人群: 基本上每个模块分配一个QA能够升级,而限制其他人的权限,避免一些因信息缺失导致的错误升级。
每次升级留痕:每次升级都要留下记录,以备后续发现问题回溯查找。
SIT集成测试准入准出标准
前面我们提到过,每个需求都要经历迭代内测试,SIT自测,SIT拉通,UAT产品验收,UAT拉通验收几个阶段之后才符合上线标准。那么每个测试阶段都有准入准出的标准。每个公司或者项目都可以依据自己不同的实际情况制定准入准出标准,主要包括几个方面:需求代码完成情况,上一阶段测试完成情况,以及缺陷修复完成情况。基本比较雷同,这里仅给出一个样例。
SIT准入标准:
开发编码完成,单元测试通过
迭代内测试100%完成并通过
缺陷修复率
阻塞/严重缺陷 100%修复
普通/优化缺陷>95%修复
遗留问题都已评审并在系统中标注解决方案
SIT准出标准:
计划的测试100%完成并通过
缺陷修复率
阻塞/严重缺陷 100%修复
普通/优化缺陷>95%修复
遗留问题都已评审并在系统中标注解决方案
集成测试中接口变更之殇
SIT自测时关注的是产品内不同模块间的接口,一个产品内的团队至少联调机会多,有很多时候在test环境就已经放开mock,大胆集成了。所以接口问题没有那么突出,顶多是长链条涉及模块多的一些场景会有一些偏差,导致少量接口变更。
然而在SIT拉通测试中,接口变更确成为最痛的痛点。
我们的产品处在上游,接口一般由下游消费方来提出需求。虽然前期也有约定,甚至接口集成平台上写得明明白白,但是由于这种0-1大规模的赶工产品交付,在前期必然思考的不那么周密,联调时的约定,也按不住后期方案的变更,需求的增多,理解的偏差,代码的混乱。于是乎,拉通测试中接口问题频频暴露,而接口的定义在这个项目环境下非常灵活。上游和下游总是会争得面红耳赤,都想在这场变与不变中处于有利位置。整个拉通现场堪比热闹的菜市场,争执声此起彼伏,一天下来不仅嗓子哑了,耳朵也接近聋了。参数不对,类型不对,必填非必填等等各种接口变更的问题,更离谱的甚至还有一个因为下游系统都对某个字段理解错误,按照错误的来实现,为了整体节约成本,也要上游来改接口。别人犯错,你来买单。
这大大超出了我们对于接口变更带来的工作量的预期。
如果没有合适的接口变更处理机制,这些对第三方来说几乎无成本的变更会无穷无尽地扑面而来。于是为了控制变更膨胀,制定接口变更机制成为当务之急。作为供应商,更得把新需求和缺陷定义清晰。所以接口变更的流程和机制就呼之欲出。
- 接口变更机制
出现问题后首先由QA,BA和PO共同协商判断,如果确定之前定义接口清晰明了,现在需要变更,就由PO起草新需求,按照新需求进入迭代内处理。如果之前有清晰定义,实现有误,就按缺陷处理。如果无法达成一致,就上报决策小组,最终决策小组形成决定。
但是集成测试中如果出现阻塞问题,需要立刻处理,否则会影响整个集成的进度。所以又把问题分为两种类型:
阻塞场景:先响应,再记录。
由于拉通测试的特殊性,当存在阻塞场景拉通的问题出现时,不管该问题最终被定义为缺陷还是需求变更,都需要第一优先级进行修复。为了处理这样的情况,即使是新需求,或者无法达成一致,团队也会立刻响应处理,随后再记录。
普通场景:按照一般流程处理。
这么大规模的E2E拉通测试真的很像一场战争,对于整个团队都是一个巨大的考验,QA更是这里的漩涡,如果不能提前做好规划和快速推动决策调整,任何一环节出现问题都会导致整个测试阻塞,耽误的就是几百号人的时间和精力。
QA在集成测试中职责的转变
QA在迭代内主要是进行故事卡的测试,最多是负责一些Showcase的准备和演示工作。但是在SIT测试中,QA的作用和职责发生了很大的变化。由于参与SIT测试的人员众多,尤其在后期拉通测试中,还要和其他产品团队一起测试。QA的职责从单一的测试执行转变为一专多能。首先转变为一个测试Coach,赋能IT
PO来进行测试;其次转变为一个Agent,问题解决的引擎。对每个问题进行分析,澄清,分发,驱动PO,开发,BA,甚至运维共同协作,快速解决问题;最后还是一个价值守护者,不仅守护着产品的质量,更要守护业务的价值,对拉通中产生的不断变化业务方案,接口定义,从用户角度,从ROI角度,据理力争,并基于问题不断调整测试策略。
作为测试Coach对ITPO赋能
IT PO第一次参与到测试中来,他们摩拳擦掌想要看到自己产品的样子是否满足自己的方案,同时还要对这些功能进行验收,为未来业务的验收做准备。为了帮助IT
PO尽快掌握的测试能力,QA变身为一个测试Coach,一对一的为IT
PO进行赋能。首先用业务的语言讲解系统实现的功能,方便其理解系统的交互逻辑以及一些简单的后端处理逻辑。其次用技术的手段帮助他们能够快速上手,将系统需要的配置以及跳过第三方依赖所需要的mock使用方法文档化,可以及时查阅。最后变为支持者,帮助他们定位问题,确定缺陷严重级别,建立与团队的沟通,将问题尽量描述清晰等等。在后续的各种集成测试,
UAT测试中,经过赋能的ITPO都发挥了重要的作用。
作为团队引擎驱动问题解决
当PO或者其他产品人员在集成测试中发现问题时,QA首先要进行一个基础判断,是否是配置问题,数据问题,环境问题,那么马上就可以解决。如果确实是缺陷,则在缺陷上补充自己的分析和判断,流转给开发同学及时修复。如果是新的需求或者业务方案问题,则引入BA一起讨论澄清。QA在集成测试中是最关键的角色,像一个引擎,驱动整个团队来快速解决问题,使得集成测试能够顺利进行。
QA同学也作为Scrum团队的一个屏障,将非代码问题都屏蔽在团队之外,减轻团队的工作量,有效地保障迭代内的交付。
作为价值守护者
QA是质量的守护者,同时也是价值的守护者。在集成测试中,除了代码的问题,更多时候会有接口的问题,业务方案的问题。在与业务,PO,BA以及其他产品的人员讨论中,QA作为业务和技术的结合点,需要提出自己的认知,从用户的使用角度,从技术的成本角度,统一考虑,以最优的成本守护价值。
同时要根据迭代内的测试反馈,不断地调整测试策略,制定重点的测试场景,对迭代内测试不充分,SIT发现问题较多和风险较高的功能进行回归测试。
一点感悟:
大规模的系统总是要经历这样的SIT集成测试阶段,当然这次这个规模大得有点离谱,但是也让我们从中深刻体会到前期质量内建工作的重要性以及集成准备工作的必要性。在这样大规模的集成中,如果没有每个小团队很好的敏捷实践作为基础,实现了良好的质量内建,预防了很多问题,单是在集成中爆发这些问题,那后果不敢想象。很多其他产品(非TW涉及的产品)都深陷于其中,当初接口设计随意,业务逻辑没有理顺,一集成发现接口完全不能满足业务需要。当初没有持续集成,当前一大堆功能集成,改一个问题引入一大堆问题,这样高强度,大规模的集成,任何闪失都会暴露在聚光灯下,导致几百人工作的延迟,可想而知后果是什么。这里我要感谢我们的那些可靠实践IKM,开卡结卡,流水线,单元测试,Showcase等等。也许你觉得司空见惯,也许我们还有很多可以提升的地方,但是它们确实帮助我们在人员交替,新人无数的困难情况下顺利渡过了这场没有硝烟的战争。
1 | 写在后面: |
转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 350394277@qq.com