质量保障人员在大厂工作中的一些感悟
- 文章摘要
- 1、需求提出阶段
- 需求评审
- 2、需求开发阶段
- 开发技术方案评审
- 3、测试准备阶段
- 测试用例编写
- 测试评审
- 制定测试方案
- 功能测试
- 数据测试
- 性能测试
- 4、测试阶段
- 功能测试
- 性能测试
- 5、交付阶段
- 6、上线后
- 7、自动化等提效方式
文章摘要
本篇文章主要描述了自己在大厂工作的这段时间,自己对技术、业务、质量的理解,针对做什么、怎么做才能提升产品质量发表自己的看法,以项目为周期,谈一下在项目的不同阶段,测试需要做什么事。
1、需求提出阶段
需求评审
- 评估需求的合理性、指出需求的漏洞,有问题提前交流,把不合理的需求或者实现起来难度高、收益小的功能沟通好,达成共识,避免之后再频繁找产品开发对齐。
- 从质量的角度考虑,开发过程中会有怎么样的坑,提前暴露出来,避免需求问题在测试阶段才暴漏,挤压测试时间。
- 评估需求是否会引入性能问题,涉不涉及到压力测试。
- 根据目前需求排期,梳理需求影响面和测试场景,评估测试需要时间。
2、需求开发阶段
开发技术方案评审
- 了解开发的业务实现逻辑,个人认为测试人员知道代码的实现逻辑是非常重要的,了解了代码的业务实现逻辑才更能站在测试的角度发现漏洞,单纯的进行黑盒测试不容易发现藏的比较深的bug,有一定的局限性。
- 评估技术方案的合理性,评估在该实现方案下会有什么样的坑,有没有更好的实现方法。
- 确定了技术方案后评估影响面和测试范围,并把测试范围说明,让开发同学补充,避免漏测。
- 稳定性评估,和产品、研发评估服务是否需要稳定性测试,若需要,线上的调用量是什么级别。
3、测试准备阶段
测试用例编写
- 测试用例编写建议具体到每一次点击和具体数据查看,避免宽泛的描述。
- 测试用例中应包括需求的全链路case,保证全链路可以跑通,针对开发的技术方案编写针对性的case。
- 编写测试用例的时候一定要狠扣需求prd细节,理解不清晰的地方及时跟产品、开发对齐。
- 站在用户使用系统的角度来判断会有哪些场景,评估本次需求对历史功能的影响面,确定回测范围。
- 尽量一条case覆盖的范围更深更广,避免同一个场景多次测试,加快测试时间,用相对少的case测相对多的场景。
测试评审
- 至少在接入测试的前一天进行需求评审,核心用例全面梳理,编写case过程中不确定的点提出来,跟产研达成一致。
- 介入测试前向开发提出冒烟用例,给开发留执行时间,避免挤占测试时间。冒烟用例一定要覆盖核心场景,避免介入测试后有功能阻塞性问题。
制定测试方案
功能测试
- 梳理测试场景,根据prd分析如何更快速的构造测试场景,不熟悉的需求可以跟开发、测试同学提前沟通。
- 数据构造场景,对于数据构造比较难的场景,且数据构造不为新需求内容,用mock的方式或者调用底层接口、修改数据库等方法快速构建数据,若构造数据场景为新需求的功能,要从用户视角来构造。
数据测试
- 提前确认好数据在哪个数据库或者缓存中的哪张表存储。
性能测试
- 评估一下接口的qps,根据qps和线上真实数据分布,构造压测数据。
- 需要压测的场景,梳理好压测的http/rpc接口,提交创建好压测用例。
4、测试阶段
功能测试
- 优先执行核心冒烟case,若冒烟case不通过,考虑打回。
- 测试过程中,如不符合预期,可以根据公司内部系统来查看日志判断服务是否请求到正确的泳道。
- 发现问题,查看日志判断是否是否是配置问题、环境问题、确定是代码问题后向开发提出,并在测试用例管理工具中提交缺陷,指定开发,修改完成后及时回测。
- 向开发提出bug时不能只说明现象,需要提供有用的信息,如id,请求curl,服务日志信息等。
- 利用公司内部的平台来快速、准确的构造数据,如mock数据、调用rpc接口、修改数据库等等。
- 注意功能实现的细节,功能有细节问题、不满足预期且开发无法优化时,跟产品同学指出。
性能测试
- 根据接口压测的qps和接口使用时间峰值评估压测时间。
- 及时跟开发沟通压测用例设计的合理性和完善性。
- 性能压测过程中关注监控报警和服务可用性,并同步开发同学一起关注,如有报警或者服务波动立刻停止压测。
5、交付阶段
- 准备好需要验证的场景数据,用测试账号来操作,避免对线上数据产生影响。
- 线上验证只需要关注核心场景,保证核心链路的可用性。
- 验证完成以后及时同步产品、研发同学。如需逐步放量,关注服务报警问题,若有问题趁早暴漏。
6、上线后
- 需求上线后关注服务报警,及时关注oncall群中是否有问题抛出。
7、自动化等提效方式
- 梳理需求新增的http接口以及rpc接口,评估其优先级,若为高频、高优接口将其接入自动化和流量回放。
- 避免自动化只验证了接口的可用性,接口的可用性只是最基本的需求,还要验证接口数据的正确性。
- 对于比较复杂的场景,最好构造全链路的场景自动化,满足该场景的全链路通畅和整体需求可用性。