接手新业务质量保障工作的思路

前言

在这个千变万化的时代，作为一名互联网的人，业务调整似乎成了家常便饭。快速的学习能力与适应能力就显得额外重要，本文章以一名质量保障人员的角度出发，浅谈如何快速接手新业务的质量保障工作。

步骤

明确业务的背景

这一点非常重要，作为测试人员，需要对被测业务有深入的理解才能未雨绸缪，定制合适的测试计划，编写完整的测试用例。对于新接手的一个业务，主要明确以下几点：

1. 业务为什么会存在？存在的价值是什么？业务目标是什么？
2. 业务面向的用户是谁？tob或者toc？
3. 梳理明确业务功能模块，哪些是重点功能模块？
4. 业务流程是怎么样的，用户是怎么使用产品的？
5. 明确业务处在什么阶段？起步阶段，发展阶段还是稳定阶段？
6. 客户或者用户对于业务产品的质量要求是什么样的？
7. 如果存在上下游，业务的上下游是什么，这个业务处在大业务的什么环节？
8. 业务的发版节奏是什么样的？
9. 明确业务产品以及研发负责人。

这些东西基本靠和产品聊天或者产品文档获取信息。
弄清楚了以上这些点，基本对业务的理解算入门了。

梳理业务架构

这就需要与研发人员沟通，从以下方面了解业务架构。

1. 业务后台架构，单体还是微服务，服务间调用关系是什么，各个服务的作用是什么？每个服务都有哪些接口？
2. 后台数据库地址是什么，数据库库表结构是什么样的？每个字段有什么含义？
3. 服务的部署流程，如何分环境部署？部署的机器在哪里？
4. git地址，流水线地址，各个环境的地址？

至此，你对该业务又有了新的理解，以上是建立在文档齐全，研发nice的情况，假如项目混乱，上面信息不好收集的话，比较棘手，基本口口相传。不过一般情况下研发小哥哥姐姐都是很nice的。

质量保障方案确定

根据上面信息基本可以确定产品级别的质量保障方案。业务到底处在质量保障的哪个阶段，具体见我另外一篇文章：https://blog.csdn.net/qq_38783257/article/details/117301780

版本测试计划制定

明确版本内每个需求的目标与价值，使用RBT（基于风险的测试）对每个需求进行评估。主要从失效影响和失效可能性进行评估。
失效影响包括：

• 问题伤害程度
• 影响用户量

失效可能性包括：

• 测试人员水平
• 研发人员水平
• 需求复杂度
• 技术实现复杂度
• 用户使用频率

上面这些只是例子，根据以上的因素对需求进行评估，列出哪些需求是高风险，哪些需求低风险，对于高风险需求重点投入测试资源。

明确了这些，就可以进行测试策略的制定了，也就是这个需求到底测到什么程度？除了基础功能是否有性能要求？兼容性要求？对老功能是否有影响？

测试用例编写

测试策略制定后就需要编写用例了，我用什么方法测试？什么方法设计用例？根据测试策略调整测试强度以及用例覆盖程度。

这边就需要用到什么等价类，因果图，边界值，测试建模等方法。看实际情况使用。

测试执行

这边没啥好说的，根据用例和计划，该点点点的点点点，该写脚本的写脚本，该写工具的写工具，该压测的压测，该性能的性能，该回归的回归，回归累了有时间就搞搞自动化…

数字化

在质量体系设计之初，QA就应当特别留意打造“数字化质量”的评价体系。

在项目需求管理阶段，利用项目管理系统（比如Aone）提供的“迭代、版本、模块”这样的属性来管理工作项，帮助你快速分类收集项目进度信息，形成项目报告release notes，避免单独耗费人力去收集项目数据。比如，通过若干个迭代的演练，计算出发布一个版本需要多少时间，能解决多少需求项，从而帮助老板更准确地评估团队的工程能力。在日常CICD，UT回归测试的活动中，有意识地去记录集成、构建、自测活动的频率、执行时间、成功率等数据，并形成质量指标，可以帮助你发现团队的代码工程近实时质量是否存在退化情况，比如某服务在代码提交后导致构建失败，此时应当叫停后续的代码合并，通知owner修复。到了提测、集成测试的阶段，对关键工程建立代码评审、代码门禁卡点，有意识地去收集SUT与集测结果之间的报错关联信息，并形成错误记录报告；或基于制品库和系统版本关联关系，建立起缺陷的血缘关联，使线上问题的发现、回溯、定位到代码层面，都可控可解释。

总之，通过提升每个质量环节的执行效率（这里会有大量琐碎而细致的脏活累活来让规范落实在工具、流程里），收集、分析、整理过程质量数据，那么团队的工程开发能力、质量控制能力都可以量化表达出来。在这个过程中，QA通过自己开发的工具、流程、服务，提升的团队效能（降成本）、预防发现的缺陷可能导致的资损（防资损），就是QA对团队的业务价值贡献。

后记

做测试1.5年了，感觉套路就是这么个套路，测啥都一样。明确需求价值，确立测试目标，编写测试用例，测试执行。
不管是什么平台也好，sdk也罢，接口测试也好，压测也罢，只是用的工具不同，输入不同，数据构造不同，操作步骤不同，断言内容不同，套路都是一样的。