跨部门项目测试负责人全流程把控，我是这样做的！

1.背景

最近几个月，我负责一系列大项目上线，特点：跨多个部门、时间跨度长、涉及角色多，有部分重叠并行。跨部门大项目中，你遇到过这样的坑吗？

需求阶段

• 参与需求评审时，没有提前给出需求文档，导致需求评审变成没有结论的需求讨论，还需要下一轮评审

• 有的项目跨度时间大，由于QA资源冲突，可能最终的QA会发生变化，会出现拉进测试沟通群的QA并不是最终负责对接的QA

技术评审阶段

• RD在技术评审时，没有给出时序图，QA在编写case时需要和RD不断沟通，增加沟通成本

• RD从技术设计开始概括性罗列要清洗的点，但未明确具体，无法让人check是否真正完整清洗，导致清洗数据遗漏

测试方案设计阶段

• 各方测试排期拉不齐

• 与外部进行测试方案评审时，没有考虑到外部QA是新人，评估的需要外部提供的数据构造流程与最终实际的不一致

联调阶段

• 涉及第三方的流程的节点阻塞，QA尝试去帮助RD解决，但是对方配合不积极

• 联调不顺利时，与RD的共同diff代码的时间被占用

• 联调不顺利时，冒烟时间被占用，提测质量如何保证？

测试阶段

• 依赖的第三方配置不生效

• 对于大项目普遍周期很长，从设计测试方案到真正上线之前，可能会有别的新的业务功能上线，合并代码后，需要check当前的业务逻辑能否兼容新功能，没有预留开发和测试工作量

• 测试期发现第三方需求点遗漏，评估时不需要开发，但实际需要开发才能支持

• 沙箱测试配置不全，导致错误数据

• 沙箱测试期运营提供的配置和约定的配置结构不一样，导致重新修改开发

上线后

• 一线使用人员操作和需求约定不一致，系统不支持。

2.一套可行的全流程质量把控需要做什么？怎么做？

基于跨部门项目的特点：跨多个部门、时间跨度大、涉及角色多，在项目的各个环节，各角色，都有可能遇到坑，每一个小细节处理不好，都可能影响项目的顺利推进，为项目的质量埋下隐患。作为测试负责人，要在项目全局的角度，提前警觉和预防。那么在各个环节，应该怎么做呢？

2.1.需求阶段

提前了解需求，分析需求

正式需求评审前，要求拿到完整需求文档，一个跨部门的项目大概率需求量很大，如果不进行提前了解，仅凭PM现场的讲解，可能会跟不上，无法提出疑问和建议。在正式评审前，可以提前列出自己的疑问

带着问题参与需求评审

需求评审中，先听取PM的讲解，提出自己的疑问，并将结论记录下来；确认运营配置是最终确定的版本；提醒PM更新最新的需求文档

创建测试沟通群

人员：测试负责人、各方实际参与测试的QA、新人QA需要同步拉能够帮助把关的QA

目标：为了便于项目重要节点信息同步，以及测试过程中相互配合、问题讨论、进度和风险收集。

关注其他方需求评审完毕的时间

关注这个时间的目的是为了方便了解各方信息是否对齐，避免业务发起方很了解需求，但和第三方沟通时对方还没开始熟悉需求，沟通时出现误解和偏差.

2.2.方案设计&开发阶段

参与技术设计评审

• 参与外部评审

  一般是与第三方技术一起确认系统间的交互及依赖，需要关注与第三方的交互边界；关注历史数据清洗；关注灰度计划

• 参与内部评审

  关注与第三方交互的时序图，要求拿到时序图，评审时如果还不能确认时序图细节，至少在联调节点前补上

确定排期并周知

1）评估内部的测试耗时

基于需求分析和技术设计，首先针对自己负责的业务的测试耗时进行评估，需要确定出测试环境测试时间段、沙箱测试时间段

• 时间：设计评审后

• 方法：需要拆分功能模块，对每个模块进行耗时评估，大项目一般产品&UI&UE验收耗时较长，需要额外留出配合的时间

  

 

2）评估整体测试排期

收集各方QA的测试排期，需要考虑其他方的测试人日、沙箱测试人日，看各方介入测试的排期是否需要拉齐，能否拉齐

如果需要拉齐但又资源不足，可以考虑如下几种解决思路

• 看能否请求到QA资源，缩短测试期跨度；

• 需要根据依赖关系，来考虑自己介入的时间；

• 根据依赖，确认一部分独立的功能是否可以开发自测提前上线

• 部分功能开发或产品自测

• 部分功能下次迭代

方式：建立共享文档，收集排期,例如：

3）周知整体测试排期及上线时间

周知各方QA在项目管理表中及时填写具体测试排期，并将项目整体测试排期同步在项目大群中；大项目上线时间最好单独预留一天上线时间

测试方案设计与评审

1）内部测试方案设计

除了针对需求的常规测试方案外，还需要考虑多个QA分工协作的问题，因此需要提前规划每个人每日的测试内容划分，沟通确认达成一致后，分别在tapd上拆分任务。如：

此处依赖前面按照模块的估时，在进入case编写阶段后可能会再调整，直到提测前会确定好

2）与外部测试方案设计与评审

整体测试方案设计时主要是确认如下几点：

• 涉及的各方项目人员与排期

• 关键时间节点

• 配置

• 数据构造

• 测试边界划分

对于配置，需要明确配置提供的人员，要求能够确保配置的正确性；尽可能地使用和线上一致的配置

对于数据构造，需要各方QA提前梳理并列出自己能提供的数据构造工具，需要新开发的给出预计提供时间；有大量数据依赖但无法提供数据构造工具的需要提前帮助对方QA学会如何造数据，可以采用文档教学、组织会议现场教学等方式；仅有少量数据依赖的可以考虑测试期辅助配合造数据或者共用数据即可

设计时间：写case阶段就可以开始

评审时间：需要考虑其他方QA介入的时间，最好是他们case编写完成之后，RD执行冒烟前完成评审；若时间太早，有些QA对需求细节梳理还不是太完整透彻，不能真正理解交互边界

评审参会人员：需要考虑项目的QA是否是新人，如果是新人还需要拉上leader或者能帮助把关的人；如果边界还不是太确定还需要拉上双方的技术，避免出现遗漏或者偏差。

2.3.联调冒烟阶段

1)数据构造新工具开发

进入联调阶段后RD提供的接口相对稳定，因此在此阶段进行数据构造工具开发是最合适的时机;开发完成后录入到数据构造平台，串联成流程

2)跟进开发联调进度

有必要可以参与开发的联调站会，了解开发联调进度。对于长流程项目可以提前介入进行流程测试，确保提测前核心流程无卡；积极跟进联调阶段严重问题，督促开发推动合作方进行解决。

3)接口测试

开发在进入冒烟阶段，QA可以同步开始核心接口的接口测试，提前暴露问题

4)diff代码

提测前进行代码diff，特殊情况至少在上沙箱前一定要保证能够diff完成。如果提测后才完成代码diff，会有一定风险，RD会有代码优化，需要RD给出优化的影响范围，再进行回归测试。

2.4.测试阶段

1)提供统一的测试环境

申请一个统一的测试环境，确保测试环境在项目前不会因为到期而被提前回收。正式介入测试的前一天，通知各方部署测试代码到统一的测试环境，通知各方产品完成配置。考虑到测试环境有时需要debug定位关键问题，最好维护有一个备用的测试环境

2)提供统一的沙箱环境

正式进入沙箱测试的前一天，确保各方在沙箱环境部署新分支及配置同步到沙箱。沙箱测试期第一天，再次在大群中艾特各方开发或者QA负责人确认各方的所有分支是否已全部部署，艾特各方PM负责人确认配置是否已全部生效；收到反馈确认无误后才可以正式开始测试，否则可能会出现一些错误数据

3)执行内部测试

按照测试用例及模块分工进行测试，如实际的测试模块与计划不同了，应及时修改计划并周知协作的QA,避免重复测试或者漏测；关注代码覆盖率，测试完成后找RDcheck还有哪些未覆盖的，及时补充测试

4)组织联合测试

联合测试的目的是为了用一条数据将涉及多方的完整流程串起来，避免各自测各自的没问题，但是串起来就有问题的情况；如果时间来不及可以到沙箱环境再进行联合测试

5)问题跟进

• 发现外部bug需要在测试群中和对方QA反馈，要求提bug

• 本期不解决的问题形成todo，跟进解决排期

• 对于大项目普遍周期很长，从设计测试方案到真正上线之前，可能会有别的新业务功能上线，需要确认当前的业务逻辑能否兼容新功能

• 对于推不动或者难以解决的问题，若问题长时间未解决可将问题上升

6)每日进度收集&进度同步

对于整体项目，可以每日采用站会的方式或者测试沟通群内沟通的方式收集各方进度，重点关注进度异常及原因，解决方案是否需要协助，再在技术大群内同步结论

对于内部进度周知，则需要周知更详细的细节。关注bug趋势，评估项目风险，尽量做到bug日清，如果没有日清，根据bug的个数和严重程度来评估是否一定日清及可能带来的质量和进度风险

7)参与上线计划评审

关注上线顺序、是否有回滚方案、灰度计划、产品配置。有必要时可拉其他方QA一起参加。对于上线计划评审的结论，尤其是上线的具体时间点，需要在QA群内再次通知以确保每个QA都能为之做好准备

8)组织产品&UI验收

需求提测后即可以让UI找FE同学进行UI验收；测试功能稳定后可组织产品和UE验收

2.5.上线阶段

1)上线

确认各方测试完成后，同步技术负责人可以开始上线；如果实际可以上线的时间与计划不同，需要和各方再次确认是否当日上线

2)线上验证

需要先向各方确认线上配置是否已全部配置完成，再开始线上测试，否则会造成脏数据；对于参与灰度或者线上验证的用户名单，最好确认是内部人员的

2.6.上线后

1)跟进线上问题

由于跨多个部门，大神文档和tapd给所有人开通权限比较麻烦，可以建立线上问题记录的共享表格，包括：

• 问题描述

• 期望结果

• 反馈人

• 处理状态

• 处理人

• 解决时间

• 问题类型

  

2)组织复盘

在项目大群中收集项目过程中的问题，收集各方意见，形成todo，定期跟进todo进度；有争议的共性问题可以提前沟通得出结论，复盘会上同步结论，提高会议效率

3.写在最后

在跨部门项目的全流程质量把控中，测试负责人承担着测试策划、管理、执行和分析的责任，以确保软件质量和项目顺利进展。通过参与全流程，可以及早发现各个环节潜在的缺陷或问题，从而能够及时解决和修复，减少问题在后续阶段的累积、扩大和影响。全流程的质量把控，可以确保软件或系统在各个阶段和整个生命周期中具备高质量，并提供持续的改进和优化机会；同时，通过全流程的质量把控，QA能够提升在团队中的价值和影响力。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

 ​​​​软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。