一个测试人员提出如下问题：
开发人员希望测试人员提供测试用例，以便自测。那么测试人员是否需要提供？
行业内一般是怎么操作的，如果提供，就有以下问题。
1.一些部门给测试制定的kpi是缺陷发现数量，那么，开发人员使用测试案例测出问题，测试是否能够记录缺陷，开发人员是否会主动上报。
2.开发人员使用测试用例自测结束后提测，此时测试人员是否应该使用同样的用例进行测试，如果用同样的用例，是否无法发现新的问题。
3.如果测试时发现了提供的测试用例场景以外的问题，此时责任应该如何划分，是算开发遗漏，还是测试案例遗漏。如果算开发遗漏，是否会出现测试人员故意将提供的用例简化的可能，以便完成自己的缺陷数量kpi。如果算作测试遗漏，那么开发人员是否因为无责导致推诿。
4.已知测试无法完全，交付的程序必然会有遗漏问题，但是，使用同一套用例，确实无法发现新问题，那么测试人员测试阶段除了按着用例再执行一次，和写用例之外，是否还有其他价值。
要回答这个问题，还是要先明确测试的职责和用例的作用。
测试的职责其实不是为了发现bug，而是为了尽可能准确地反映出产品质量状态。
而测试用例的主要作用，其实是帮助我们在进行测试前整理好测试思维，预先根据产品需求整理好需要测试的要点，避免遗漏。
明确以上基础以后，再回答以上的疑问：
- 是否应该提供用例给开发？
以bug数量作为KPI是非常错误的考核方式，出现题主担心的情况正是这种KPI的重要缺点。也就是人为地割裂了开发和测试的工作产出，而没有把他们的工作统一到产品质量这个共同目标上。而这种割裂，双方的产出还是互斥的，因此还指望测试给开发提供用例帮助开发去减少测试的产出，是不现实的。所以取消这种KPI是下面讨论的基础
- 是否应使用同一套用例测试？
开发使用用例进行自测，从质量角度应该是欢迎的。如果我们能确保开发确实按照用例完成了相关自测，且提交的版本是经过自测的版本。那么原则上测试无需再次重复测试相关用例。这里其实就是默认已经验证过的用例是不会带来问题的。如果同样的用例还能发现问题，要么是开发自测不严格，要么是用例本身比较模糊，测试场景覆盖不足。但从工作职责上，测试是需要评估产品质量状态，很难说开发已经测试过的部分，这部分的产品质量就不再是测试需要进行评估的范围，因此实际操作，肯定还是会复验（当然能自动化最好）
- 用例没有覆盖的场景如何界责任？
这个其实是正常情况。回顾测试的实际工作，通过提前编写好用例发现的bug和实际测试过程中探索发现的bug，二者的比例如何？ 相信真正实施测试的同学都清楚，实际探索发现的问题肯定会大于提前在用例中覆盖到的。这也是探索式测试的出发点。
所以这里题主担心的遗漏：开发遗漏，不以bug数作为KPI的话就不存在测试藏私的动力，而开发产品其实主要是以需求为基础来实现而不是用例，所以这里的所谓开发遗漏其实就是bug本身，而避免出现bug本来就是开发的职责。算测试遗漏，也不合适，因为在执行测试之前，在见到真实产品之前就把所有场景都覆盖到本身就不现实。
但之前我们说过用例的主要作用是提前对需要覆盖的测试要点进行覆盖。而这里的要点中，最重要的就是需求本身要求的功能，所以用例对需求的覆盖情况是要保证的，如果连需求中已经明确的功能都没有用例对应，那么应该算测试设计遗漏。
- 测试人员的价值？
其实这个疑问本身，已经告诉我们一个事实：就是按用例，按已有脚本进行测试执行，不是测试人员的价值所在。James Bach有个著名的论文，讨论了测试和检查的区别。按用例执行只是检查，不能算测试。真正的测试，除检查外还包含试验、研究、探索、设问、观察、推理等多方面能力，这些才是帮助我们发现更深层次产品缺陷，暴露产品质量问题的真正能力。
测试的价值不在执行用例。编写用例也只是测试过程中，帮助我们整理测试思维的一种方式。 因此不要把用例看作测试工作的核心，它只是一个辅助产出。
测试全栈系统提升课程正在上新优惠中:
共同学习，写下你的评论
评论加载中...
作者其他优质文章
