文章摘要

本篇文章主要描述了自己在大厂工作的这段时间，自己对技术、业务、质量的理解，针对做什么、怎么做才能提升产品质量发表自己的看法，以项目为周期，谈一下在项目的不同阶段，测试需要做什么事。

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接口，评估其优先级，若为高频、高优接口将其接入自动化和流量回放。
• 避免自动化只验证了接口的可用性，接口的可用性只是最基本的需求，还要验证接口数据的正确性。
• 对于比较复杂的场景，最好构造全链路的场景自动化，满足该场景的全链路通畅和整体需求可用性。