测试中的误报和漏报同样的值得反复修正

制品过程中，测试用例执行失败，那么不一定是发现了问题也有可能是外部因素导致的，这就是缺陷误报；在上线后，用户触发了遗漏缺陷，会引起一系列连锁反应，甚至导致资损，这些遗漏的缺陷是因为漏报导致的。
那么无论是误报，还是漏报都会导致制品团队的返工，也是最大的浪费。

误报的返工

测试过程中我们常常会遇见引起测试用例失效的原因不是被测系统的BUG导致的，而是由于一些测试环境、测试数据、外部依赖等原因导致的，虽然这些并不能定义为BUG，但是同样引起了测试工作的返工因此也需要解决误报。

误报是内部制品过程的浪费。我们在质量保障过程中，从需求阶段的开卡开始，就投入了测试工程师参与其中，针对研发工程师在完成需求过程中需要变更的接口提前准备了接口自动化测试的case，并且在完成验卡后通过流水线触发新增接口的自动化测试完成对应的质量保障活动，这一些的投入都是为了能够提高交付过程的流畅度。如果自动化测试在触发的时候出现了失效，我们更希望于这个失效状态都是被测系统的BUG导致的，但是现实中往往很多时候是由于一些外部系统的依赖、本地测试数据的污染等一些外围原因导致的，而不是被测试系统的BUG，这就是BUG误报，我们简称误报。
虽然不是被测试系统的BUG引起的测试失效，但是误报同样需要重视，因为它导致测试工作的返工。针对误报，可以通过添加技术需求卡的形式进入迭代过程阶段，这样既可以在团队中形成留痕也可以促使该种引起误报的问题不再出现。在添加完卡片后，就有研发工程师自己是情况而定是在本次迭代解决还是在未来某次迭代解决。

漏报的损失

在第一版软件评测师教程中提出的软件测试的原则就明