测试LINT的策略

### 测试LINT的策略 #### 1. 测试的重要性与核心问题 在软件开发中，测试是确保软件质量的关键环节。如果没有有意义的测试来保证软件包的质量，那么之前的所有工作都可能付诸东流。我们需要回答两个关键问题： - 如何确保软件功能符合其规格，尤其是在数学计算上的正确性？ - 怎样实现软件功能的稳定性和可靠性？ 这两个问题虽紧密相关，但涉及不同的问题领域。一个函数可能在数学上不正确，比如底层算法实现有误，但仍能稳定地重现错误，为给定输入提供相同的错误输出。而那些看似返回正确结果的函数，也可能存在其他错误，如向量长度溢出或使用未正确初始化的变量，由于有利（或不利）的测试条件而未被检测到未定义行为。 #### 2. 相关参考资料 在软件测试领域，有许多有价值的参考资料，它们能为解决实际问题提供具体帮助： - [Dene]：涵盖软件开发的整个过程，包含基于作者实践经验的方法指导和清晰有用的示例，在编程和系统集成的各个阶段反复探讨测试主题。 - [Harb]：完整描述了C编程语言和C标准库，对ISO标准的规定给出了许多有价值的提示和评论，是不可或缺的参考资料。 - [Hatt]：详细介绍了用C创建安全关键软件系统的内容，通过具体示例和统计数据展示典型经验和错误来源，并提供全面的方法建议。 - [Lind]：一本优秀且幽默的书籍，展现了对C编程语言的深刻理解，能将这种理解传递给读者。 - [Magu]：涉及子系统设计，讨论了接口的解释和处理带输入参数函数的原则，阐明了风险编程和防御性编程的区别，强调了有效使用断言作为测试辅助工具和避免未定义程序状态的重要性。 - [Murp]：包含大量可轻松用于测试程序的工具，能立即产生有用的结果，还提供了用于实现断言、测试动态内存对象处理和报告测试覆盖率的库。 - [Spul]：对C和C++语言的测试方法和工具有广泛的介绍，给出了有效使用它们的众多提示，包含对C和C++中典型编程错误的广泛概述，并讨论了识别和消除这些错误的技术。 #### 3. 静态分析 测试的方法学方法可分为静态测试和动态测试。静态测试主要是代码检查，逐行仔细检查源代码，查找与规格的偏差（如所选算法）、推理错误、代码行排列或风格指南的不准确、可疑结构以及不必要的代码序列等问题。 代码检查可借助分析工具，如著名的Unix lint工具，这些工具能在很大程度上自动化这一繁琐任务。静态分析能发现的问题领域包括： - 语法错误 - 缺少或不一致的函数原型 - 函数参数传递的不一致性 - 对不兼容类型的引用或连接 - 使用未初始化的变量 - 不可移植的结构 - 对特定语言结构的不寻常或不合理使用 - 无法到达的代码序列 使用函数原型是自动化工具进行严格类型检查的必要条件。借助原型，符合ISO标准的C编译器能够跨所有模块检查传递给函数的参数类型并检测不一致性。许多编译器也可设置为分析源代码，当开启适当的警告级别时，它们能识别出许多问题。例如，GNU项目的C/C++编译器gcc具有高于平均水平的分析功能，可通过 -Wall -ansi 和 -pedantic 选项激活。 在设置FLINT/C函数的静态测试时，除了在多个不同编译器上进行测试外，主要使用了Gimpel Software的PC-lint（版本7.5）和弗吉尼亚大学安全编程小组的Splint（版本3.1.1）。 PC-lint对测试C和C++程序非常有用，它能识别约两千个不同的问题，并使用有限的机制从代码中推导运行时自动变量加载的值并纳入诊断。这样，许多通常只有在运行时（希望是在测试期间而非之后）才能检测到的问题，如向量越界，在静态分析阶段就能被发现。 Splint可在Linux下运行，它区分四种模式（弱、标准、检查、严格），每种模式都有特定的预设，能进行不同程度的严格测试。除了典型的lint功能外，Splint还能测试程序中是否存在特定规格，这些规格以特殊格式的注释插入源代码中。这样可以制定函数实现和调用的边界条件，并检查其是否符合规格，还可能进行额外的语义控制。对于未配备补充规格的程序，建议将 -weak 模式作为标准设置。 在测试FLINT/C函数时，合理使用这两个工具的前提是精确测试所使用的选项，并创建相应的配置文件，以便为个人使用配置这些工具。经过对FLINT/C代码的广泛修订，在测试阶段结束时，这两个工具都没有产生经过仔细检查后可被视为严重的警告。 以下是静态分析的流程： ```mermaid graph TD A[开始] --> B[选择分析工具（PC-lint、Splint等）] B --> C[设置工具选项] C --> D[创建配置文件] D --> E[对FLINT/C代码进行静态分析] E --> F{是否有严重警告} F -- 是 --> G[修订代码] G --> E F -- 否 --> H[结束] ``` #### 4. 运行时测试 运行时测试的目标是证明软件的一个构建块符合其规格。为了使测试具有足够的表达能力，证明开发和执行测试所花费的时间和金钱是合理的，我们必须对测试提出与科学实验相同的要求：测试必须完全记录，其结果必须可重现并能由外部人员检查。区分测试单个模块和集成系统测试是有用的，尽管两者的界限是模糊的。 为了在测试模块时实现这一目标，测试用例必须设计成能够尽可能全面地测试函数，即实现对被测试函数的最大覆盖。可以使用各种指标来确定测试覆盖率，例如： - C0覆盖率：测量函数或模块中实际执行的指令部分，或具体来说，哪些指令未被执行。 - C1覆盖率：记录所采用的分支部分。 - 路径覆盖率：测量函数的路径被执行的部分，这是比前两者更复杂的测量方法。 测试的目标是通过完全检查软件接口行为的测试用例实现最大覆盖。这涵盖了两个相互关联不太紧密的方面：一个遍历函数所有分支的测试驱动程序仍可能遗漏错误；另一方面，即使不考虑函数的某些分支，也可以构造测试用例来测试函数的所有属性。因此，测试的质量至少可以从两个维度来衡量。 如果仅根据规格知识设置测试用例不足以实现高测试覆盖率（即所谓的黑盒测试），则有必要在构造测试用例时考虑实现细节，这就是所