严格捕获单元测试的测试用例

Question

假设我们有一个用伪语言定义的简单函数。

List<Numbers> SortNumbers(List<Numbers> unsorted, bool ascending);

我们传入一个未排序的数字列表和一个指定升序或降序排序顺序的布尔值。作为回报，我们得到一个排序的数字列表。

根据我的经验，有些人比其他人更擅长捕捉边界条件。问题是，“您如何知道何时‘完成’捕获测试用例”？

我们现在可以开始列出案例，一些聪明的人无疑会想到以前任何一个案例都没有涵盖的“另一个”案例。

Answer 1

不要浪费太多时间去思考 每一个 边界条件。你的测试将无法捕获 每一个 第一次出现错误。这个想法是进行测试 不错, ，然后每次出现错误 做 表面上，专门针对该错误编写一个新测试，这样您就再也不会收到它的消息了。

我想就代码覆盖率工具提出另一点说明。在像 C# 或 Java 这样有很多 get/set 和类似方法的语言中，您应该 不是 拍摄 100% 的覆盖率。这意味着您浪费了太多时间为琐碎的代码编写测试。你 仅有的 希望 100% 覆盖您复杂的业务逻辑。如果您的完整代码库覆盖率接近 70-80%，则说明您做得很好。如果您的代码覆盖率工具允许多个覆盖率指标，那么最好的一个是“块覆盖率”，它测量“基本块”的覆盖率。其他类型是类和方法覆盖（不会提供太多信息）和行覆盖（粒度太细）。

Answer 2

您如何知道何时“完成”捕获测试用例？

你不会。除了最微不足道的情况之外，你不可能达到 100%。此外，100% 的覆盖率（线条、路径、条件...）并不意味着您已经满足了所有边界条件。

最重要的是，测试用例不是写完就忘记的。 每次发现错误时，请编写一个附加测试。 检查原始程序是否失败，使用更正的程序检查是否通过并将其添加到您的测试集。

摘录自 软件测试的艺术 作者：格伦福德·J.迈尔斯：

1. 如果输入条件指定了一个值范围，请为该范围的末端编写测试用例，并为超出末端的情况编写无效输入测试用例。
2. 如果输入条件指定了多个值，请为最小和最大数量的值以及低于和超出这些值的值编写测试用例。
3. 对每个输出条件使用准则 1。
4. 对每个输出条件使用准则 2。
5. 如果程序的输入或输出是有序集合，请将注意力集中在该集合的第一个和最后一个元素上。
6. 此外，发挥你的聪明才智寻找其他边界条件

(出于版权原因，我只粘贴了最低限度的内容。)

要点 3.和 4.以上非常重要。人们往往会忘记输出的边界条件。5.没问题。6.真的没有帮助:-)

简短的考试

这比看起来更困难。迈尔斯提供了这个测试：

该程序从输入对话框中读取三个整数值。这三个值代表三角形的边长。程序显示一条消息，说明三角形是不等边三角形、等腰三角形还是等边三角形。

请记住，不等边三角形是没有两条边相等的三角形，而等腰三角形有两条相等的边，等边三角形有三个长度相等的边。此外，等腰三角形中等边的对角也相等（因此三角形中等角的对边也相等），并且等边三角形中的所有角都相等。

编写您的测试用例。你有多少？Myers 询问了有关您的测试集的 14 个问题，并报告说，高素质的专业项目的平均分是 7.8 分（满分 14 分）。

Answer 3

从实际的角度来看，我创建了一个我认为在接受之前必须通过的测试列表。我测试这些并在可能的情况下实现自动化。根据我估计的任务时间或给我的时间，我扩展了测试范围以包括在接受之前应该通过的项目。当然，必须和应该之间的界限是主观的。之后，当发现错误时，我会更新自动化测试。

Answer 4

@基思

我认为你已经做到了，如果你想了解自己的“完成程度”，代码覆盖率很重要，但我认为 100% 的目标有点不切实际。争取 75-90% 将为您提供相当好的覆盖率，而不会太过分......不要纯粹为了达到 100% 而进行测试，因为那时你只是在浪费时间。

Answer 5

一个好的代码覆盖率工具确实有帮助。

100% 的覆盖率并不意味着它绝对经过充分的测试，但它是一个很好的指标。

对于.Net NCover来说相当不错，但已经不再开源了。

---

@mike Stone-是的，也许应该是“高覆盖范围” - 我们的目标是最低80％，过去大约95％的收益率会降低，尤其是如果您拥有Belt'N'Bracs代码。