6

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

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

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

根据我的经验，有些人比其他人更擅长捕捉边界条件。问题是，“你怎么知道你什么时候'完成'捕获测试用例”？

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

4

5 回答 5

10

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

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

于 2008-08-15T18:17:17.387 回答
6

你怎么知道你什么时候“完成”了捕获测试用例？

你没有。除了最微不足道的情况外，你无法达到 100%。此外，100% 的覆盖率（线、路径、条件......）并不能告诉你你已经达到了所有的边界条件。

最重要的是，测试用例不是“一写即忘”。每次发现错误时，都要编写一个额外的测试。使用原始程序检查它是否失败，使用更正的程序检查它是否通过并将其添加到您的测试集中。

Glenford J. Myers的软件测试艺术节选：

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

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

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

短期考试

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

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

请记住，不等边三角形是没有两条边相等的三角形，而等腰三角形有两条相等的边，等边三角形有三条等长的边。此外，等腰三角形中等边对边的对角也相等（由此可知三角形中等角对边相等），等边三角形中所有内角都相等。

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

于 2008-08-16T09:08:23.623 回答
1

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

于 2008-09-26T01:42:25.813 回答
0

一个好的代码覆盖率工具真的很有帮助。

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

对于.Net NCover 来说相当不错，但不再是开源的。

@Mike Stone - 是的，也许那应该是“高覆盖率” - 我们的目标是最低 80%，超过 95% 通常是收益递减，特别是如果你有带“n”大括号的代码。

于 2008-08-15T18:18:57.430 回答
0

@基思

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

于 2008-08-15T18:33:05.527 回答