前言
在这个千变万化的时代,作为一名互联网的人,业务调整似乎成了家常便饭。快速的学习能力与适应能力就显得额外重要,本文章以一名质量保障人员的角度出发,浅谈如何快速接手新业务的质量保障工作。
步骤
明确业务的背景
这一点非常重要,作为测试人员,需要对被测业务有深入的理解才能未雨绸缪,定制合适的测试计划,编写完整的测试用例。对于新接手的一个业务,主要明确以下几点:
- 业务为什么会存在?存在的价值是什么?业务目标是什么?
- 业务面向的用户是谁?tob或者toc?
- 梳理明确业务功能模块,哪些是重点功能模块?
- 业务流程是怎么样的,用户是怎么使用产品的?
- 明确业务处在什么阶段?起步阶段,发展阶段还是稳定阶段?
- 客户或者用户对于业务产品的质量要求是什么样的?
- 如果存在上下游,业务的上下游是什么,这个业务处在大业务的什么环节?
- 业务的发版节奏是什么样的?
- 明确业务产品以及研发负责人。
这些东西基本靠和产品聊天或者产品文档获取信息。
弄清楚了以上这些点,基本对业务的理解算入门了。
梳理业务架构
这就需要与研发人员沟通,从以下方面了解业务架构。
- 业务后台架构,单体还是微服务,服务间调用关系是什么,各个服务的作用是什么?每个服务都有哪些接口?
- 后台数据库地址是什么,数据库库表结构是什么样的?每个字段有什么含义?
- 服务的部署流程,如何分环境部署?部署的机器在哪里?
- 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也罢,接口测试也好,压测也罢,只是用的工具不同,输入不同,数据构造不同,操作步骤不同,断言内容不同,套路都是一样的。