JTS-%E4%BD%BF%E7%94%A8%E6%96%87%E6%A1%A3%E7%BF%BB%E8%AF%91-C/C-V1.2/

[giscus[bot]]

JTS-%E4%BD%BF%E7%94%A8%E6%96%87%E6%A1%A3%E7%BF%BB%E8%AF%91-C/C-V1.2/

本文是 Juliet Test Suite v1.2 for C_Cpp - User Guide.pdf 的中文翻译，官方网站位于 https://samate.nist.gov/SARD/documentation#juliet
第一章：介绍
1.1 文件目的
本文档描述了为C/C++开发的Juliet测试套件v1.2。该测试套件由国家安全局（NSA）的安全软件中心（CAS）创建并开发，专门用于评估静态分析工具的能力。它适用于任何希望将测试用例用于自己的测试目的，或希望更深入了解测试用例创建方式的人员。
本文档解释了测试用例命名和设计背后的理念，并提供了如何使用命令行界面（CLI）编译和运行它们的指导。第8节还提供了如何评估工具结果的详细信息。
测试用例可公开下载于 http://samate.nist.gov/SRD/testsuite.php。
1.2 测试用例是什么？
测试用例是可以构建的代码片段，用于研究静态分析工具。一个测试用例针对的正是一类缺陷，但其他不相关的缺陷可能偶然存在。例如，C测试用例“CWE476_NULL_Pointer_Dereference__char_01”只针对空指针解引用缺陷。除了包含目标缺陷的构造之外，每个测试用例通常还包含一个或多个执行与有缺陷构造类似功能的非缺陷构造。一小部分测试用例不包含非缺陷构造，被认为是“仅坏”测试用例（见第4.5节）。
1.3 为什么需要测试用例？
为了研究静态分析工具，CAS需要软件进行工具分析。CAS之前考虑使用“自然”或“人造”软件。自然软件是没有为测试静态分析工具而创建的软件。开源软件应用程序，如Apache Web服务器httpd.apache.org和OpenSSH套件www.openssh.com，是自然软件的例子。人造软件，在这个情况下，是包含故意缺陷并专门为测试静态分析工具而创建的软件。测试用例是人造软件的一个例子。
1.3.1 自然代码的限制
在以前的研究工作中，CAS在测试静态分析工具时使用了自然和人造代码的组合。此外，CAS遵循了国家标准与技术研究院（NIST）静态分析工具博览会（SATE），该博览会检验了静态分析工具在自然代码上的性能。

从这些努力中获得的经验表明，使用自然代码通常面临特定的挑战，例如：

评估工具结果以确定其正确性 - 当静态分析工具在自然代码上运行时，每个结果都需要审查以确定代码是否真的在指定位置有指定类型的缺陷（即，结果是否正确或“假阳性”）。对于大多数自然代码的结果来说，这种审查并非易事，通常无法在合理的时间内以高度的确定性确定给定结果的正确性。

比较不同工具的结果 - 在自然代码上比较静态分析工具的结果很复杂，因为不同的工具以不同的方式报告结果。例如，许多缺陷涉及“源”的受污染数据和“汇”不当使用该数据的地方。一些工具可能报告源，而其他工具报告汇。有时，多个受污染数据的源都指向一个汇，这可能导致不同工具报告不同数量的结果。

识别代码中没有工具发现的缺陷 - 在评估静态分析工具时，需要一个“标准”列表，列出代码中的所有缺陷，以便识别每个工具未能报告的缺陷。对于自然代码来说，创建这个“标准”很困难，特别是在识别没有任何自动化工具报告的缺陷时，因此只能通过手动代码审查来发现。

评估工具在代码中未出现的构造上的性能 - 自然代码的限制在于，即使是不同项目的组合，也可能不包含CAS想要测试的所有有缺陷和无缺陷的构造。即使代码中出现的缺陷类型也可能因复杂的控制和数据流而被混淆，以至于自然代码中的缺陷即使被通常能捕获该类型缺陷的工具也会未被检测到。为了解决这个问题，CAS考虑使用“播种”方法将缺陷和非缺陷嵌入到自然代码中。最终，CAS决定创建测试用例，而不是使用“播种”，因为CAS认为使用“播种”代码研究静态分析工具将过于复杂，并且导致测试的构造少于预期。

基于这些经验和挑战，CAS决定开发人造测试用例来测试静态分析工具。使用人造代码通过允许CAS控制、识别和定位代码中包含的缺陷和非缺陷来简化工具研究。
1.3.2 测试用例的限制
尽管使用测试用例简化了静态分析工具研究，但它可能以以下两种方式限制结果的适用性：

测试用例比自然代码简单 - 一些测试用例故意是正在测试的缺陷的最简单形式。即使是包含控制或数据流复杂性的测试用例也比自然代码简单，无论是在代码行数还是在分支、循环和函数调用的数量和类型上。这种简单性可能会夸大结果，即工具可能报告在测试用例中它们很少在自然、非平凡代码中报告的缺陷。

测试用例中缺陷和无缺陷构造的频率可能不反映它们在自然代码中的频率 - 每个类型的缺陷在测试用例中测试一次，无论这种缺陷类型在自然代码中有多常见或罕见。因此，两个在测试用例上有相似结果的工具可能在自然代码上提供非常不同的结果，例如，如果一个工具发现常见缺陷，而另一个工具只发现罕见缺陷。即使在测试用例上表现不佳的工具也可能在自然代码上表现良好。同样，每个无缺陷构造在测试用例中也只出现一次，无论该构造在自然代码中有多常见。因此，测试用例上的假阳性率可能与工具在自然代码上的比率大不相同。

1.4 创建测试用例
大多数非类基缺陷的测试用例是使用包含缺陷的源文件和CAS创建的名为“测试用例模板引擎”的工具生成的。生成的测试用例文件包含在第一行的注释中，表明它们是生成的。
一些缺陷类型不能被CAS的自定义测试用例模板引擎生成。这些缺陷类型的测试用例是手动创建的。由于资源限制，这些测试用例被创建为只包含缺陷的最简单形式，没有添加控制或数据流复杂性。

第二章：测试用例范围
本节提供了测试用例范围的详细信息。通常，测试用例侧重于底层平台上可用的函数，而不是第三方库的使用。
尽管C和C++是不同的编程语言，但它们被视为一个单元，因为C++通常是C的超集。此外，大多数软件保证工具都支持C和C++。
尽可能地，C/C++测试用例将API调用限制在C标准库中，该库在所有平台上都可用。为了涵盖更多的问题，一些测试用例针对Windows平台（使用Windows特定的API函数）。未来，这项工作可以扩展到涵盖Windows之外的其他平台独有的API函数。不使用任何第三方C或C++库函数。
C测试用例代码针对C89标准，以便测试用例可以使用可能不支持C语言新版本的各种工具进行编译和分析。
测试用例限制了C++构造和特性的使用，仅在需要它们时使用（例如，与C++类或“new”操作符相关的测试用例）。除非针对的缺陷类型需要，否则测试用例不使用C++标准库。
2.1 测试用例选择
CAS在选择测试用例的缺陷类型时使用了几个来源：

软件保证团队在CAS中的经验
CAS之前工具研究中使用的缺陷类型
供应商关于其工具识别的缺陷类型的信息
MITRE通用弱点枚举（CWE）中的弱点信息

虽然每个测试用例都使用CWE标识符作为其名称的一部分，但创建测试用例并不需要特定于缺陷类型的CWE条目。为所有适当的缺陷类型创建测试用例，并使用最相关的CWE条目（可能相当通用和/或抽象）为每个测试用例命名。
2.2 测试用例统计
测试用例涵盖了2011年CWE/SANS前25个最危险软件错误中的11个。在测试用例未涵盖的14个CWE条目中，有10个是设计问题，不适合CAS测试用例的结构。其他四个不是特定于C/C++的，并且在相关的Java测试用例中得到涵盖。（见附录B，了解与前25个相关的测试用例的详细信息）。

https://hcy-asleep.github.io/JTS-%E4%BD%BF%E7%94%A8%E6%96%87%E6%A1%A3%E7%BF%BB%E8%AF%91-C/C-V1.2/