测试工程师如何降低漏测

1. 漏测原因

1. 需求评审质量低，需求设计简单、只是简单描述功能，功能逻辑较少

2. 需求变更频繁

3. 缺少需求分解（sql 文档、用例设计）

4. 测试人员思维局限，需求分解覆盖面不全，考虑不足

5. 测试人员执行过程不规范，人为漏测

6. 测试执行人员质量意识不足，发现的缺陷定义严重性程度低或不认为是问题

7. 测试环境与生产环境有较大出入

8. 测试环境或测试数据受限，无法模拟并覆盖执行所有正常和异常的场景分支

9. 功能回归策略问题

10. 测试资源有限

2. 漏测预防或改进措施

2.1 提高需求评审质量

• 需求评审至少有产品、开发和测试人员三方参加

• 需求评审必须安排业务熟悉和测试经验丰富的测试人员参加，对于不清楚的需求，要在会上提出更多逻辑疑问。

2.2 需求变更要及时更新

一定要考虑到需求变更会不会导致其他模块（业务流程上考虑、参考业务流程图）

2.3 需求分解及时更新维护

主要靠自觉性，如果实在没时间就写来源表、业务逻辑描述即可

2.4 提高需求分解质量

数据来源（从哪来），业务逻辑（怎么做），数据写入（到哪去）

2.5 测试流程要规范

• 冒烟测试：花少量时间对增、删、查、改功能进行流程测试

• 业务测试：按照测试需求分解、需求文档分别细测两遍以及数据库验证

• 回归测试：验证关闭 bug 时要把相关功能也测试到，避免开发因修改 bug 引出其他问题

• 系统复测：按照主业务流程复测较好，能涉及到大部分模块并且是用户用到较多的功能。（先不按照需求分解去测试，可能会想到之前想不到的业务逻辑），有时间再对 1、2 级 bug 复测。用例执行：在测试过程中严格按照测试用例执行

2.6 测试环境要尽量贴近生产环境

2.7 漏测的原因分析总结

根据每月漏测较多的项目，自己要总结原因，具体什么原因导致的漏测

2.8 测试资源有限

时间不充足，导致一些功能点在测试过程中被忽略，可以根据里程碑节点来判断不同程度的测试

1. 里程碑评审：保证主功能没问题，可以存在小的问题，即冒烟测试通过

2. 系统演示：保证主要功能没问题，且界面数据显示要完整；次要功能可能不会演示到可先不改。

3. 上线：禅道 1、2 级 bug 改完，优化类、功能完善类不影响客户使用可先不改

3. 测试方法

1、全面校验（1）起码需求清楚说明的，一定要各个字段全面验证正确性，不需要每个字段一条用例，可以一条用例覆盖所有字段，但是一定要验证到所有字段 （2）特殊验证：有的数据新提交的和继承表中数据可能存在一致的情况，我们必须要造不一致的数据来验证是否进行了继承和是否继承正确，并按需求逐字段校验（并不是造一条正向用例验证都正确了就行）

2、相关功能回归测试(1) 先验证此问题是否已经解决 (2) 再验证相关模块或功能是否有新引入的 bug (3) 公用模块或功能是否全面修改：如果该模块是专有模块，只有某一功能使用，针对该功能进行测试即可。如果该模块是公用模块，涉及功能较多，需针对所有使用情况进行全量覆盖

3、多组合测试实际使用过程中会比我们测试过程中数据更多更复杂，所以要尽可能地造多种组合情况的数据进行测试，测试过程中可能会发现很多没有想到的问题或可优化完善的部分，不至于后期更多次地迭代发版（是否存在异常、是否全面、顺序是否正确）

最后： 下方这份完整的一套软件测试视频教程已经整理上传完成，朋友们如果需要可以自行免费领取 【保证100%免费】

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!