在进行测试时，通常会花很多精力选择“正确”的测试工具。这其实只是为了实现次要目标。当然，一个适合开发环境、项目和流程的工具是重要的。然而，对于良好测试而言，最重要的是测试用例的质量。只有“好”的测试用例才会发现软件存在缺陷。

一个简单的例子

        如下是对一个简单测试对象的说明：

        “start”和“length”定义了“value”的取值范围。被测函数用来确定给定值是否在定义的范围内。规定范围的上界不在范围内。所有数据类型都是整数。

        如下图所示的三个测试用例都通过了测试，并且达到了100%的MC/DC覆盖度。

图1 这三个测试用例通过并达到了100%的覆盖率

        图1测试用例都通过并已经达到了100%的覆盖度，但没有对所有的需求进行测试，即没有使用边界值进行测试。

边界值，最小/最大值，极端值，违规值

· 边界值

        需要多少测试用例（以及哪些测试数据）才能充分对边界值进行测试？下面使用一个“输入值是否小于5”的函数来研究这个问题。

图2 可能的实现以及哪些测试输入能检测缺陷

        图2表格第一列我“输入值是否小于5”的可能缺陷（即错误实现）。其中（i！= 5）和（i <> 5）均为“不相等”，归属不同编程语言（“！=”属于C / C ++，Java;“<>” 属于Pascal，PHP，SQL，Excel）。

        表2中第二列为缺陷的可能性组合。缺陷的可能性被认为与关系式中错误字符的数量和“外观”上的差异有关（从正确的（i <5）需要更多的改变才能将正确的（i <5）变换为不正确的（i> = 5），也更容易在视觉上发现）。

        表2中后三列为输入值为4、5、6时的测试结果，粗体和红色阴影表示测试失败。输入值4和5未检测到（i！= 5）和（i <> 5），输入值6（即第三测试用例）检测到了。（i <> 5）的实现方式更有可能发生，但使用“<>”运算符的编程语言对于嵌入式系统并不常见。

        （i == 4）无输入值检测到，需要额外输入值检测缺陷，需要四个测试用例（“内部”两个值和“外部”两个值）。这是René Tuinhout提出的黑盒边界值分析（B3VA）。“小于5”的值范围有更低边界且可作输入值，则不需要额外测试，下边界可以检测（i == 4）。

        结论：嵌入式系统（使用“！=”作为关系运算符），进行代码审查且目标是测试用例的数量较少，仅使用两个测试用例就可以。但为了检测一些缺陷，有时需要四个测试用例。

· 最小/最大值

        将给定数据类型的最大和最小（即最负）可能的输入值作为边界值的特殊情况。

图3 函数abs_short（）存在一个在使用最大/最小值输入时才会发现的问题

        图3函数abs_short（）在输入值为-5,0,5时，分别正确返回5,0,5，实现了100％的代码覆盖率。但输入值是-32768时（带符号的16位整数的最小（最负）值），预期结果为+32768。无法在给定的整数范围内表示，返回值为-32768，不是预期值。（背景：-32768 = 0x8000.0x8000-1 = 0x7FFF。反转值为0x8000，与开始时的值相同。）

·  极端值

        极端（或特殊）输入值不是直接取边界或最小/最大值，是另一种特殊值。

图4minimum（）函数存在编程缺陷

        图4是最小值函数。三个（无符号）整数（a，b和c）为输入，返回输入的最小值。

图5：用于检测最小值函数缺陷的测试用例

        图5，为该函数运行通过的测试用例。检查每个位置是否能正确检测到最小值（3），100％代码覆盖率，但没有极端或特殊的输入。对此函数，特殊的输入可以是三个相同正值，如输入（3,3,3），结果为0（不是预期结果3），表示最小值功能的实现存在缺陷。

 · 违规值

        图3函数“所有数据类型都是整数”。适用length的取值范围，故长度可能是负的。输入5，-2为长度，查看4是否被认为在范围之内。用（可能的）无效输入构建测试用例。

ISO26262中的建议

        ISO 26262：2011在第6部分第9节中列出软件单元测试的测试用例的设计方法。

图6：ISO26262中设计测试用例的方法

        图6为建议取决于汽车安全完整性等级（ASIL）。ASIL的范围从A到D，D最高级别。“强烈推荐”双加号（“++”）; “推荐”单个加号（“+”）。1a，1b，1c，...是替代条目; 1,2,3，...是连续的条目。替代条目，应根据ASIL应用适当的方法组合；连续条目，应按照ASIL进行应用。1a要求软件单元测试的测试用例来自需求；1b要求使用等价类的生成和分析来导出测试用例；1c要求分析边界值以导出测试用例。方法1a，1b和1c已在本文前面的部分中讨论过。1d要求错误猜测来导出测试用例。

· 错误猜测

        错误猜测需要经验丰富的测试人员，从过往的经验中找到敏感的测试用例。它是一种非系统的方法。例如，被测系统有两个按钮，假设一次只按下其中一个按钮：如果同时按下两个按钮会发生什么？这是错误猜测的示例。

可选方案

        本节讨论设计测试用例的其他可选方法。

· 来自源代码的测试用例

        使用工具从源代码自动生成测试用例。一些开源和商业工具都实现了一些技术方法（例如遗传算法或回溯），可以利用生成测试用例。源代码生成测试用例要注意：

    ·   遗漏：将无法发现代码中的遗漏。如要求“第一个参数等于第二个参数，则返回错误”若缺少这项检查的实现：由源代码生成的测试用例不会检测到此问题。

    ·  准确度：无法从代码中判断它是否正确。如无法判断（i <5）或（i <= 5）是否实现了代码的预期行为。

        可以让工具生成测试用例并将其和需求进行比对，如果不符合要求再对其进行相应的拓展或改变。近期有研究人员对此进行了研究，其主要观点如下：

    ·  自动生成的测试套件比人工创建的测试套件实现了更高的代码覆盖率。

    ·  使用自动生成的测试套件无法检测到更多缺陷。

    ·  自动生成的测试用例会对捕获预期的类行为产生负面影响。

        这项研究表明，自动化测试用例生成没有为测试带来优势，但它也没有缺点。虽有很多讨论的研究条件（编程语言，编程技巧等），但结果依然是令人惊讶的。

变异测试（Mutation Testing）

        评定测试用例质量的一种可行方法是变异测试（在IEC 61508标准中也被称为“错误播种”（error seeding））。有运行通过的测试用例时，可以“变异”代码。如，将判断（i<5）改成（i<=5），在计算结果上加1，把“&&”改为“||”，注释掉部分代码等。代码进行变异之后，重新运行测试用例。若所有测试用例能够通过，测试用例质量就比较低。至少一项测试用例应该会由于进行了变异而无法验证通过。

小结

        100%的代码覆盖率并不意味着“好”的测试用例。然而，在执行测试的过程中为了能够检测出软件的缺陷，需要高质量的用例。这项任务需要仔细而富有经验的人力工作才能达成，对于自动化生成的测试用例，应该持保留态度。