测试用例质量的重要性

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