测试是否应该给开发自测提供用例？

背景

收到不少小伙伴的咨询，作为一个测试，是否应该在开发人员自测时提供测试用例或者测试数据？

这是实际工作中大家经常遇到的实际困扰，特别是现在很多团队强调测试左移，要求测试提供用例、准备测试数据很常见。但同时一些团队依然在将缺陷作为KPI考核指标，而因此还引发诸多后遗症：

之前的文章【】我们详细讨论过测试的真正目的。

所以我们应该明确：测试的职责其实不是为了去发现bug，是为了去反映出产品质量状态。

而在测试工作中，测试用例的主要作用，其实是帮助我们在进行测试前梳理、归纳好各种测试路径，预先根据产品需求整理好需要进行测试的要点，避免实际执行时产生遗漏。

以上是我们谈到测试左移时，探讨用例移交的基础。

从团队角度，最终必然是面向产品质量。而根据著名的缺陷和成本的关系曲线，越早发现缺陷，成本越低，交付质量信心就越强。

所以从这个角度，测试左移，包括向开发提供测试用例，都是符合质量目标的。

但实际操作中，团队的KPI考核导向，会影响实际执行效果。

也就是如果像很多团队以Bug数量作为KPI，那么必然导致移交用例的效果大打折扣。

这个KPI，其实人为割裂了开发团队和测试团队的产出：开发需要尽可能少地产生Bug，测试却要尽可能多地发现Bug。

而测试用例、测试数据其实反映的是测试发现Bug的测试思维。将用例移交开发，会帮助开发减少Bug，但却会影响自己发现Bug的产出。

所以在这种导向下，测试即便提供用例，也很难保证用例的覆盖。只会流于形式。

所以从产品质量来看，作为测试角色，开发阶段提供测试用例，协助开发团队完成充分自测是岗位的义务，但要想真的落实产生效果，前提是必须取消这种按Bug数量进行考核的度量模式。

首先，必须认清一个事实：测试是不可能做到100%全覆盖的。在项目早期阶段，仅依靠需求和尚未完全完成的开发版本编写的测试用例，能覆盖到的测试场景就更为有限。

实际工作中，即便在系统测试中，按测试用例执行发现的Bug和实际测试中探索发现的Bug相比，占比也极为有限。这也是 探索式测试 推行的出发点。

也就是说，开发阶段，按照用例测试后，后续系统测试阶段继续发现未覆盖的问题，是一个100%的确定事件。

那么如何保证这个阶段用例的覆盖充分呢?

首先，还是要强调，质量是团队目标。不用纠结与界定是开发遗漏还是测试遗漏，共同目标都是减少遗漏。

其次，测试用例应该看作是思维工具的产出，是测试思路的体现。测试提供的用例本身并不一定是全部，开发也一样应该考虑覆盖场景。

用例的需求覆盖率和代码覆盖率是比较适合的量化指标，用来衡量这个阶段的用例覆盖情况。

开发阶段完成自测的原则，是保证产品的需求被完整实现，不出现严重的阻塞问题，产品的主要逻辑和架构得到验证。

达到以上目标就可以认为开发自测阶段顺利完成。而不应纠结于具体的某一个Bug在自测阶段是否覆盖。

经过充分自测的产品，已经执行过的测试用例，提交测试后原则上其实无需再次重新测试。也就是默认已验证过的场景，不会产生问题。

但实际工作中，开发的自测是否充分？用例执行是否严格？包括用例本身的覆盖是否有模糊地带？这些其实都是未知数。

而测试的工作职责，是需要在产品发布前，准备评估产品的质量状态。很难说经过开发自测的部分，就无需再次进行评估。

所以，即便是用例本身没有发生变化，同一套用例也依然是需要进行复验的。当然，这里非常适合通过自动化测试来覆盖已有用例，而让测试人员的精力更多放到探索式测试上。

其实从上面的描述，我们也知道，测试在测试阶段，更重要的职责是还要完成探索式测试。测试用例本身更多是测试思维的体现，是测试思路的一种表现形式，它只是一个辅助产出。并不是测试的核心。

对于测试来说，我之前文章中也多次提及，James Bach有个著名的论文，讨论了测试和检查的区别。按用例执行只是检查，不能算测试。真正的测试，除检查外还包含试验、研究、探索、设问、观察、推理等多方面能力，这些才是帮助我们发现更深层次产品缺陷，暴露产品质量问题的真正能力。

所以，测试人员的价值，当然不仅仅是产生用例。而更多是揭示未知，去评估除对团队来说，还是黑盒的产品质量状态。