假设我们有一个用伪语言定义的简单函数。
List<Numbers> SortNumbers(List<Numbers> unsorted, bool ascending);
我们传入一个未排序的数字列表和一个指定升序或降序排序顺序的布尔值。作为回报，我们得到一个排序的数字列表。
根据我的经验，有些人比其他人更擅长捕捉边界条件。问题是，“你怎么知道你什么时候'完成'捕获测试用例”？
我们现在可以开始列出案件了，一些聪明的人无疑会想到以前任何一个都没有涵盖的“再一个”案件。
答案 0 :(得分：10)
不要浪费太多时间来考虑每个边界条件。您的测试将无法第一次捕获每个错误。我的想法是让测试相当不错，然后每当一个bug 表面时，专门针对那个bug写一个新的测试，这样你再也不会听到它了
我想谈谈代码覆盖工具的另一个注意事项。在像C＃或Java这样的语言中你有很多获取/设置和类似的方法，你应该不以100％的覆盖率进行拍摄。这意味着你在为简单的代码编写测试时浪费了太多时间。您仅希望100％覆盖复杂的业务逻辑。如果您的完整代码库接近70-80％的覆盖率，那么您的工作做得很好。如果您的代码覆盖率工具允许多个覆盖率指标，那么最好的是“块覆盖率”来衡量“基本块”的覆盖率。其他类型是类和方法覆盖（不会给你太多信息）和线覆盖（太细粒度）。
答案 1 :(得分：6)
您如何知道何时“完成”捕获测试用例？
你没有。除了最琐碎的案例外，你不能达到100％。此外，100％覆盖率（线条，路径，条件......）并不能告诉您已达到所有边界条件。
最重要的是，测试用例不是一劳永逸的。 每次发现错误时，请编写一个额外的测试。使用原始程序检查失败，检查通过更正的程序并将其添加到测试集中。
Glenford J. Myers的The Art of Software Testing摘录：
（出于版权原因，我只粘贴了最低限度。）
以上第3点和第4点非常重要。人们倾向于忘记产出的边界条件。好的。 6.真的没有帮助： - ）
这比看起来更困难。迈尔斯提供了这个测试：
程序从输入对话框中读取三个整数值。这三个值表示三角形边的长度。程序显示一条消息，指出三角形是斜角，等腰还是等边。
请记住，斜角三角形是没有两边相等的三角形，而等腰三角形有两个相等的边，等边三角形有三条长度相等的边。此外，等腰三角形中与等边相对的角度也相等（也可以是三角形中相等角度的边相等），并且等边三角形中的所有角度相等。
编写测试用例。你有多少？迈尔斯询问了14个关于你的测试集的问题，并报告说高质量的专业课程在可能的14分中平均为7.8。
答案 2 :(得分：1)
从实际的角度来看，我创建了一个我认为必须在接受之前通过的测试列表。我测试这些并尽可能自动化。根据我估计完成任务的时间或我已经花了多少时间，我将测试范围扩展到包括在接受之前应该通过的项目。当然，必须和应该之间的界限是主观的。之后，我会在发现错误时更新自动化测试。
答案 3 :(得分：0)
一个好的代码覆盖工具确实有帮助。
100％的覆盖率并不意味着它肯定经过充分测试，但它是一个很好的指标。
对于.Net NCover来说非常好，但不再是开源的。
@Mike Stone - 是的，或许这应该是“高覆盖率” - 我们的目标是最低80％，过去约95％通常收益递减，特别是如果你有带'n'括号代码。
答案 4 :(得分：0)
@Keith
我认为你已经把它钉了出来，如果你想看看你是怎么做到的，代码覆盖很重要，但我认为100％是一个不切实际的目标。努力达到75-90％将会给你很好的报道而不会过分...不要为了达到100％的目的而进行测试，因为那时你只是在浪费你的时间。