目录

一、背景

二、测试左移

三、测试右移

四、如何保障质量

五、历史文章指路

一、背景

项目迭代迅速，系统庞大且复杂，当遇到需求质量差、开发质量差，测试时间紧张等情况，结果就是测试人员进行坎坷的冒烟测试，好不容易冒烟测试通过，又有无尽的分支bug，对于开发测试来说都是折磨。

而且有些场景在测试环境构造困难因此无法验证，最后的结果可能是导致bug流入生产，甚至有可能因为线上bug造成巨大损失。

那么作为质量保障人员如何去尽可能避免这样的问题，实践测试左移和测试右移，让测试在整个项目过程中掌握主动权进行质量保障。

二、测试左移

测试左移就是在提测之前已经介入了测试，将bug扼杀在摇篮当中。

2.1、需求阶段

2.1.1、在了解需求的前提下去评估需求的质量，分析需求的正确性性以及完整性；

• 正确性:  对照原始的需求，检查产品人员制定的文档是否偏离了最原始的用户需求；

• 明确性：检查需求文档中是否包含一些含糊其辞的词汇，比如 过多 ， 过少 ， 适量 , 是否 。检查用语是否清晰，无歧义；

• 完整性：对照原始的需求文档，检查产品人员制定的需求文档是否完全覆盖用户所有的需求点；

• 限制性：每个需求中是否清晰描述了这个软件能做什么，不能做什么，什么能输入，什么不能输入；

• 优先级：需求文档中哪些文档比较重要，哪些不重要，要有优先级；

• 一致性： 检查需求文档中的内容是否前后一致，确保不冲突，不矛盾；

2.1.2、评估新需求对已有功能的影响，是否兼容老逻辑，以及可能存在的风险；

2.1.3、涉及计算公式的需由产品提供样例demo，避免因需求理解偏差而造成实现偏差；

2.2、开发阶段

2.2.1、参与开发设计方案，了解开发的实现方式，作为测试人员需要评估改动范围以及是否有遗漏的模块和系统；

2.2.2、测试人员还可以通过提供测试案例或者自动化测试脚本的方式给开发，让开发人员在设计时考虑地更全面，同时方便开发人员自测，有助于提高产品质量；

2.2.3、需要在测试前了解数据流转的一个完整的流程，接口调用，数据落库。

2.3、日常建设

2.3.1、从用户角度出发以场景为维度去编写测试用例，在用例评审时阐述测试的场景，如有遗漏，或者与产品，开发有理解不一致的地方，及时发现，避免提测后才发现；

2.3.2、需要不断地培养产品、开发同学的质量意识，同时提供必要的技术支持，协助产品、开发更好的进行测试，比如测试用例、测试工具、测试脚本；

2.3.3、环境治理包括环境的快速复制，环境使用，配置同步（数据库表结构，系统配置，相关业务配置），环境问题的排查；

2.3.4、充分利用静态代码扫描，检查代码问题；

2.3.5、定期组内进行技术分享，项目复盘，讲解测试过程中可优化的点，将技术文档以及业务文档沉淀下来。

三、测试右移

测试右移就是建立完善的反馈、发现、定位问题机制。

通过线上监控和预警，及时发现问题并跟进解决，将影响范围降到最低；在开发设计时就要考虑预警功能，系统层（如cpu、内存问题）、应用层（如响应时间）、业务层（通过率）等出现异常的时候通过邮件或者钉钉等方式发出预警，并且针对预警做出快速响应。

3.1、建立生产问题跟踪库，将生产问题的现象，产生原因记录下来，划分责任人进行跟进解决；

3.2、建立生产故障紧急响应方案。

四、如何保障质量

4.1、深入了解业务需求，整个系统架构，数据流转过程，根据需求制定测试策略，明确测试目标；

4.2、引入或者开发测试工具，提升测试效率；

4.3、定时复盘，针对测试中的困难点找到优化的办法，若没有好的思路，要学会及时求助；

4.4、要有责任心，做一个靠谱的测试；

原文链接：https://mp.weixin.qq.com/s?src=11&timestamp=1651411006&ver=3772&signature=YftxzTOmTHbyv5LFnxxlSiBB9XqXh2i5NhgIYdjx222nBvsp9lDAcYvQhIdj7ilpFx8DjrJKz*vMOqGf-3MA3g6qn*sqgLiwQ0pzEtm64czgEfMDO251tqln1*8VmiC-&new=1