如何减少漏测

一、漏测的原因有以下的几个方面：

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

　2、需求变更频繁

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

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

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

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

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

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

   9、功能回归策略问题

  10、测试资源有限

二、漏测预防或改进措施：

1、提高需求评审质量

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

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

2、需求变更要及时更新sql文档或者测试用例

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

3、需求分解（sql文档、用例设计）及时更新维护

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

4、提高需求分解质量

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

5、测试流程要规范

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

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

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

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

       用例执行：在测试过程中严格按照测试用例执行

6、测试环境要尽量贴近生产环境

7、漏测的原因分析总结

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

8、测试资源有限

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

1. 里程碑评审：保证主功能没问题，可以存在小的问题，即冒烟测试通过
2. 系统演示：保证主要功能没问题，且界面数据显示要完整；次要功能可能不会演示到可先不改。
3. 上线：禅道1、2级bug改完，优化类、功能完善类不影响客户使用可先不改

三、不予解决、设计如此、无法重现、外部原因四类bug的解决方式

1、不予解决

字面意思：这是个bug，但是开发不想解决，或者是开发认为不应该解决，或者有时候开发标注的时候容易和设计如此混淆。

解决办法：

（1）开发备注如下，并有聊天截图（也有没有的情况），但是也要和产品再次确认后确认是否关闭。（确认原因：每个人理解有偏差；觉得产品说的不太合理）

（2）需求有动，和原来需求差异较大，没必要再修改原来求的bug。

（3）测试对理解需求不透彻，尽量避免这类bug出现，并记录在sql文档中

（4）测试提bug之前，开发自己知道这个bug已经解决但没发版，有的开发标注已解决，有的标注不予解决，需要新版本确认好再关闭。

（5）有的bug现阶段可以先不解决，前提已经和产品确认过，产品也同意暂时不解决，可以降低优先级，bug激活指给自己，但是不要删除。

2、设计如此

字面意思：这不是bug，需求设计就是这样写的

解决方法：

（1）需求已更改，测试不知道，需要查看最新版设计，需求上没有的话就要和产品确认。

（2）需求上没明确说明，要和产品确认需求，并了解开发代码逻辑，例如下面这个bug，如果关联删除不止涉及此模块，还涉及其他模块，且开发代码有和项目编码关联，关联不上不会再app端显示的。

3、无法重现

字面意思：开发不能重现的bug

解决方法：

（1）需要再次确认最新版本，看是否能重现，如果操作步骤复杂，最好能亲自给开发操作，或者录屏、打电话沟通，帮助开发复现。

（2）我们自己也复现不了的，尽量回忆当时自己的操作步骤，一般都是在特定条件下出现的，若操作了半个小时候还没复现，就激活指给自己，日后测试过程中注意下，看是否能复现。

（3）好多开发是在本地环境去复现问题，有时候本地、线上代码不一致，所以要让开发去线上复现问题

4、外部原因

字面意思：发版、数据库更改、数据问题、服务器、网络原因导致的。

解决办法：

（1）明确版本号、查看数据库等

四、对于开发不改的bug怎么沟通

1、提高自身测试能力，能分清前后端bug。

     如果实在分不清楚指给前端人员，前端人员是有责任去定位问题，如果是后端问题，由前端人员再指给后端。

2、提高逻辑思维，不能被开发忽悠（最好懂点简单的代码）

解决办法：和开发沟通无效（原因：不会改；不想改），找开发负责人沟通修改，一般开发负责人在能力较强、态度负责。如果开发负责人也觉得不需要修改或者不会改，就要叫上产品人员沟通，此问题是否解决。

3、测试人员要主动

开发遇到不会改的bug，我们需要借鉴下其他系统有没有类似功能，提供给开发；如果没有可找开发负责人协助解决。