我最近有一个测试任务，我正在测试一个相当完善的 API。团队通过为每个 API 调用创建基本的功能、边界和错误测试开始了第 1 阶段。结果证明，每个 API 调用需要进行三到四个测试。错误检查非常基础。诸如插入的行数之类的事情。我们在创建测试用例的过程中发现了这个阶段的大部分错误。
一旦该周期完成并修复了所有发现的错误，第 2 阶段就使用了数据驱动的方法。我们使用一组相当稳健的测试数据，尽可能地在数据中使用“毒丸”，对数以万计的变化进行了测试。令我惊讶的是，与投入的工时相比，在第 2 阶段发现的错误的数量和严重程度都非常低。我曾预计会找到一些外围杀手错误或至少相当数量的中等优先级错误。
根据发现的错误的数量和严重程度，团队的时间本可以更好地用于临时测试或转移到其他产品领域。
我的结果是侥幸，还是当您在 API 层进行自动化时，您是否发现您相对较快地达到了收益递减点？
达斯汀，
好问题。你看到的边际收益递减是经常遇到的。下面的图表虽然不是最容易理解的，但解释了很多边际收益递减的原因：
该图表取自一篇名为“组合软件测试”的文章发表在 IEEE Computer 上，我与 3 位博士合着，解释说绝大多数缺陷可以通过测试每个你能想到的值至少一次来触发。进行了几项彻底的研究来回答这个简单而重要的问题，“今天需要多少测试输入才能触发生产中的缺陷？” 测试了四个非常不同的系统（包括医疗设备的缺陷 - 红色 - 和 Mozilla 浏览器 - 绿色）。每个 SUT 中的每个缺陷都被分类......要触发这个缺陷，我们只需要一个测试输入；为了触发这一点，这对特定的测试输入需要出现在同一个测试用例中，等等。生产中大约 85% 的缺陷可以由一个或两个测试输入触发。四项研究中的一个缺陷需要触发六个特定的测试输入。不需要7个或更多。
这些发现的含义是什么？
他们是巨大的。根据这些发现：
最大的收益来自于在至少一个测试用例中测试每个测试输入。
下一个最大的收益将来自于在至少一个测试用例中一起测试每一对测试输入。
下一个最大的收益将来自于在至少一个测试用例中测试三个测试输入的每一个可能的组合。
如果您从那里继续覆盖 4 个测试输入的所有组合，和/或 5 个测试输入的所有组合，和/或 6 个测试输入的所有组合，在许多情况下，您可能会执行数十万个组合测试输入而没有看到任何缺陷。
当您从早期测试（由相对较少的测试组成）转移到后期测试（由数万个测试组成）时，您实现了哪些额外的新覆盖？
从我对数十个与您的结果相似的类似项目的分析中，我强烈怀疑您在测试的“第二轮”中运行的数万个测试，您添加的组合非常少，涉及“尚未测试的测试对”输入”（这将使您有合理的机会找到尚未发现的错误）。相反，在每个测试中添加的净新覆盖率通常是几个“尚未测试的特定组合，例如，在此测试中首次一起测试的 4 个或更多测试输入”（从统计上，我们可以看到极不可能触发缺陷）。
这些发现的最终含义是，如果您想在像您这样的情况下最大限度地提高发现缺陷的效率：
首先，至少执行一次所有测试输入。
接下来，执行一组将覆盖所有测试输入值对的测试（例如，执行成对测试 - AKA allpairs 测试 / 2-way 测试），然后考虑执行最小可能的测试集，以确保覆盖所有可能的组合涉及 3 路组合。如果您在执行 3-way 测试时发现的缺陷很少，您可能会认真考虑停止测试而不执行更高强度的测试集。
第一
我曾预计会找到一些外围杀手错误或至少相当数量的中等优先级错误
这些期望的原因是什么？是测试的覆盖范围吗？代码中是否存在明显的缺陷？尽管在上一个周期中发现并修复了杀手错误，但您是否期望它们仍然存在？上一次测试运行或当前测试运行的路径是否有重叠？
其次，回答您的直接问题：：您是否“快速”地达到收益递减点取决于您对第二次测试运行的期望（上述问题）是否符合现实？您是否对第二次试运行期望过高？现在，您今天所处的位置，我仍然认为值得投资，因为这些现在将充当关键的回归测试！，只要它们是健壮的（一致地显示通过和失败），实际上能够捕捉回归（可以通过代码中的错误注入来模拟？）