通用技术 如何开展大规模集成测试

CKL的思考 · 2024年06月06日 · 最后由 开普敦人 回复于 2024年06月11日 · 3332 次阅读

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

共收到 6 条回复 时间 点赞

很好的文章

端到端的测试成本(包括场景用例梳理、多团队甚至多公司协同)非常的高;在端到端测试之前,非常有必要约定各系统各板块对于集成接口的质量保障策略:
1、各系统集成接口要做充分测试,保障提供接口的健壮性及正确性(确保别人调我不出错)
2、所有场景数据往下游流转的通畅性,因为你的下游接口提供者不清楚上游会有多少场景(确保我调别人不出错)

管好自己、做好咬合约定,能够让端到端测试成本和效率有大幅改善

能做到这个其实是很好的,但是在实际的过程中,因为业务进度或者时间的关系,还是会有很多问题遗留到端到端测试。

另外,端到端测试还有个很重点要的点在于要验证业务的完整的性和正确性,毕竟在系统开发出来之前,产品也无法确认系统是否能够完全满足业务需求。

“毕竟在系统开发出来之前,产品也无法确认系统是否能够完全满足业务需求。” 不满足怎么办?做完了再改吗😂 ,感觉应该是有更成熟的需求贯彻方案的吧,Scrum 结合快速原型之类的,或者采用 TDD,在最开始就确定测试用例和验收标准,似乎都是可行的方式(但也对团队要求比较高)

小狄子 回复

我们是有产品线采用 DDD 的方式做系统,然后由测试人员在开发写业务代码之前,就先编写 TDD 的用例,开发需要编写刚好让这些用例通过的代码

难道是半导体公司?

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册