1，漏测可能产生的影响
1.1 团队：漏测会影响团队成员对你的信任，对你的技术、业务能力产生怀疑，甚至质疑你存在的价值；
1.2 个人：作为漏测者，心理压力会倍增，以至于影响下次的测试任务；
1.3 公司：因为漏测而导致产品危机，甚至公司损失，会牵连到整个团队，轻则警告批评、影响绩效，重则劝退离职。
2，产生漏测的常见原因
2.1 流程规范：
- 整个团队的流程规范建设不完善，比如不通过测试直接上线等。
- 需求评审、开发设计评审、用例评审流于形式，各方对于需求理解不深，不一致。
- 需求变更频繁，没有建立相应的机制。
2.2 测试人员：
- 测试人员没有根据制定的测试标准规范执行，并推动上下游环节执行流程规范。
- 测试人员对业务理解不透彻，用例设计覆盖不全。
2.3 团队协作：
- 开发时间不够，压缩测试时间。
- 一句话需求，需求不明确，导致开发未理解透彻，过程中又私自改动需求。
- 测试环境和生产环境存在差异
- 测试人员同时负责多个项目，冲突并行，难免漏测。
3，避免漏测的方法措施
3.1 吃透业务需求
需求评审阶段：在评审前，产品需将需求文档和原型图发给开发、测试。在开会前，研读好需求文档后，对理解不明确和产生歧义的地方列出清单。待产品经理组会来评审需求时，针对问题清单，逐一解答，并形成评审纪要。
3.2 提高用例质量
提高用例覆盖率，结合业务设计有效业务场景，保证测试有效性。针对不同的业务场景，采用合适的用例设计方法。
3.3 测试用例评审
内部评审：组建业务专家虚拟小组，对测试人员的测试用例进行内部评审，并给出评审建议、结果。
多方外部评审：在需求理解的基础上讲解测试设计的思路，列出所有的测试点和测试场景，产品、开发评审是否有遗漏的场景。
3.4 开展交叉测试
如果条件和时间允许，可以在不同测试人员间进行相互测试，特别是重大版本。
3.5 有效回归测试
随着版本迭代，及时更新整理回归用例。同时考虑到环境因素，在上线前，在预生产环境上要进行完备的回归测试。
3.6 遗留bug处理
对遗留bug的处理需要严格执行流程规范，需要多方达成一致，不能隐瞒风险。
3.7 做好漏测复盘
对待漏测，态度上必须重视，分析为何会漏测，并加入checklist中，避免相同的漏测出现。
3.8 树立用户思维
把自己当作产品用户来看待被测对象。
EDWard演示的问题清单：
1，项目缺陷和产品缺陷的状态优化，将接受/处理改为处理中，将已验证去掉。
原因分析：没有从一个用户的角度去考虑，究竟缺陷的状态需要有哪些，哪些又是多余的，只是根据产品的需求做验证。
改进：在面对产品需求时，多问为什么，从而才能探索到需求背后的真实含义。
2，产品名称和项目名称可以重复，导致用户在页面不能区分出来。
原因分析：没有考虑用户的交互体验，单纯从功能层面考虑是否可用。
改进：在测试过程中，保持思维的多样性，把自己当成一个用户来看待被测对象。
3，创建项目需求和项目缺陷时，对期望解决时间没有做校验，在当天以前的时间不能选择。
原因分析：已经向产品提出过这一点，但是产品坚持需求就是这样的，没有继续和产品探讨为什么这样做的根因。
改进：针对与产品不一致的情况，可以拉通PM、开发，多方一起商量解决，坚持自己的测试专业性。
4，流水线将制品推到DCE进行部署时，没有部署成功。
原因分析：EDWard的证书不齐全导致部署失败。这一步是版本主流程的最后一个闭环功能，在流程没有闭环的情况下，为了发布时间而进行发布，虽然制定了hotfix的方案，但已经触碰到底线原则。
改进：在主功能流程没有闭环的情况下，产品功能不完整，不允许发布上线，树立测试的底线。
5，史诗处于已关闭状态时，已关闭要变为灰色字体，与项目需求保持一致
原因分析：史诗与项目需求不处于同一个页面，两处的状态会同步，在相同状态下，但底色不一致。测试时，对于细节的严谨性不足，导致了这样的情况。
改进：在UI评审时，需要加强对于细节的研究，将问题暴露在测试之前。对UI提出统一规范的要求，及产品加强在需求文档的说明。