安全关键时代的遗留代码

当考虑安全和安全关键风险时，遗留代码重用的成本和便利性优势可能会降低或复杂化。如果遗留代码被证明在功能上正确且在操作上可行，则其接受是基于对预期会发生什么的假设。但是，通常会导致故障的是意外情况，而结构测试提供了一种缓解意外情况的方法。

今天，对遗留软件的“构建”接受正在受到更多的审查。这是由于在军事和商业系统中，越来越强调安保和安全评价标准。关于认证的软件方面，必须提供可重复验证过程的证据和支持该过程的分析。结构测试是验证此证据的一种机制。

虽然曾经被视为不必要的成本负担，但严格的、基于标准的开发和验证过程是全球嵌入式系统行业安全重要性的新兴全球视角的结果。这种观点的定义是与商业航空旅行、医疗设备产品部署、全球汽车产品开发标准化以及国防和安全等各种活动相关的风险。在这些应用程序中，与意外软件和系统行为相关的责任、成本和任务影响被认为是不可接受的。

作为美国联邦航空局国际飞行软件工作组的成员，该工作组正在制定下一版DO-178软件标准，我目睹了人们越来越意识到在飞行软件系统中使用遗留软件。工作组努力确保遗留代码得到适当的管理和验证，并且它实际上不会成为“死”或无法访问的代码，在这种代码中，它可能无意中被调用用于运行时执行，而无需事先进行适当的测试。从历史上看，死代码被视为意外软件行为的原因，并对飞行安全构成重大风险。

随着嵌入式系统中面向对象应用程序的出现，使用C++、Java和Ada 2005等语言，工作组还意识到重用遗留代码的可能性呈指数级增长。旧组件可以与新组件共享成员函数，并且在运行时执行之前，这些共享函数的精确行为实际上不可见。在面向对象的系统中，意外发生的可能性更高。

美国军方也认识到与意外软件行为相关的风险，特别是在安全漏洞的背景下。空军研究实验室与国家安全局、国防部主要承包商、学术界和软件供应商合作，正在管理一个多独立级别的安全/安全（MILS）计划，将DO-178B与安全标准相结合。这包括共同标准和中央情报局局长指令6/3，保护信息系统中的敏感隔离信息。虽然MILS计划不直接解决遗留代码，但其许多目标正在应用于包含遗留软件的新项目和部署。MILS 程序的软件开发和验证指南主要来自 DO-178B，现在给软件供应商和系统集成商带来了实施可重复验证流程和降低与意外软件行为相关的风险的巨大挑战。

鉴于与安全和安全关键型软件相关的挑战，我们需要确定有关遗留代码的最佳实践，并提出一种维护和更新遗留代码的方法。这些挑战可以通过结构测试来解决。结构测试（有时称为“软件测试软件”）提供了一个运行时环境，在该环境中，自动生成测试用例，以基于系统范围的路径级代码分析来执行软件行为。尽管过去结构测试因没有明确验证功能正确性而受到批评，但这种观点没有认识到结构测试的目标是练习整个软件结构，捕获异常并测量结果代码覆盖率 - 而不是显式测试软件功能。

除非正确分析遗留软件的“竣工”架构，否则无法预测更改的影响，也无法有效地应用更改。幸运的是，结构测试固有的静态分析也可以生成架构的图形表示，包括调用树图、控制流图、数据耦合表和设置/使用表。这些可视化对于处理来自多个来源的代码（如建模工具、手动代码和软件库）的工程师特别有用。结构测试静态分析维度的另一个副产品是将编码规则自动应用于源代码，确保旧代码和新代码之间的实现一致性。

测试技术的进步催生了新一代工具，而不仅仅是另一种工具。这些进步恰逢其时，以满足国际软件标准化、嵌入式软件市场的全球化以及安保和安全关键验证标准的日益重视的需求。现在，传统软件用户可以排除意外的软件行为，并帮助确保我们的安全。

审核编辑：郭婷