在嵌入式系统中进行软件测试很重要

在嵌入式系统世界中，不仅仅是技术在不断发展，用于开发该技术的工具和方法也在日趋成熟和改进。

在1980年代初期，我为一家小型计量公司开发了软件，将工程数学应用于坐标测量机（CMM）。我们的开发生命周期实质上将生产软件视为沙盒。我们将从生产代码开始，添加功能，执行一些相当基本的功能测试，然后进行交付。

在这么小的公司中，我们的工程团队自然会包括软件和硬件专家。事后看来，令人惊讶的是，尽管我们开发的软件确实需要广泛的客户支持，但对于所运行的硬件，却几乎没有相同文化。

软件开发是一门工程学科

软硬件支持之间的部分差异是原始开发过程的结果。但是，软件的可扩展性和随之而来的功能不断扩展也起着重要作用。简而言之，错误的方法比正确的方法要多得多，而且该特性要求将其视为工程学科。

这些都没有新意。多年来，领先的航空，汽车和工业功能安全标准（例如DO-178，ISO 26262和IEC 61508）都要求这种方法。但是，要想从当今最先进的开发和测试工具中受益，拥有工程学科的思维定势是至关重要的。

最近，ISO / IEC / IEEE 29119的开发表明了软件测试的重要性，ISO / IEC / IEEE 29119是一套可以在任何软件开发生命周期或组织中都可以使用的国际软件测试标准。

要求事项

电气系统设计通常从状态机开始，并且了解特定产品的不同操作模式。工程师通常可以非常快速，轻松地将状态机功能映射到逻辑。如果状态机变得更加复杂，则通常将其转换为软件。

高要求对于确保系统正常运行至关重要。这样的要求表征了业务逻辑和预期的功能，并可以评估系统是否按照预期的方式工作。最佳实践遵循从高层需求到分析再到覆盖的流程，自然而然，需求可追溯性工具就是为此而设计的。

在状态机模型中，表征每个状态的需求是高级需求的示例。通过代码跟踪执行路径以确保正确解释每个需求是检查正确实现的一种方法。

功能安全标准将其扩展到需求可追溯性的概念。他们通常要求用户根据高级要求来执行所有代码，并通过低级测试来解释和测试所有未发现的案例。最近，网络安全中的“向左移动”呼应了这一信息，如图1所示的V模型。

图1顾名思义，V模型体现了产品开发过程，该过程显示了每个开发阶段测试规范之间的联系。资料来源：LDRA

测试组件，然后测试系统

在任何工程学科中，重要的是要确保组件在集成到系统之前能够独立正常工作。要将这种思想应用于软件，工程师需要定义较低级别的要求，并确保每个功能集都在发挥作用。工程师还需要确保为系统的其余部分提供适当的接口。

单元测试涉及在功能和模块级别对输入和输出进行参数设置，进行检查以确保输入和输出之间的连接正确，并遵循覆盖逻辑。单元测试工具可以提供经过验证的测试工具和图形表示，将各个输入和输出连接到执行路径，并可以验证其正确性。

了解功能和模块级别的界面也很重要。静态分析工具可以显示这些接口，并在不同级别上连接逻辑。

尽早发现问题

任何学科的工程师都会告诉您，发现问题的时间越早，修复这些问题的费用就越少。

静态分析执行源代码分析，以在不实际运行系统的情况下对系统的执行进行建模。编写代码后即可使用，静态分析可帮助开发人员最大程度地提高代码的清晰度，可维护性和可测试性。静态分析工具的主要功能包括：

Code-complexity分析：了解您的代码不必要的复杂之处，以便工程师可以执行适当的缓解。

程序流分析：绘制程序执行的设计-审查流程图，以确保程序按预期流执行。

预测性运行时错误检测：通过尽可能多的可执行路径对代码执行进行建模，并寻找潜在的错误，例如数组边界溢出和零除。

遵守编码标准：通常选择编码标准以确保对网络安全性，功能安全性的关注，或者就MISRA标准而言，选择一种或两种。编码标准有助于确保代码遵循最佳编程实践，这与应用程序无关，无疑是个好主意。

图2静态分析之类的活动在开发生命周期的早期阶段是一项开销，但从长远来看，它们却能带来回报。资料来源：LDRA

足够质量的代码

高质量的工程产品更昂贵不足为奇了，坚持任何开发过程都需要付出一定的代价，并且开发最好的产品可能并不总是在商业上可行。

在安全性很重要的地方，功能安全性标准通常需要分析成本和发生故障的可能性。每个系统，子系统和组件都需要进行此风险评估，以确保执行适当的缓解措施。无论系统对功能安全还是信息安全，都是有意义的。如果您以相同的严格程度测试系统的每个部分，则会在风险较低的系统部分中过度投资，而在风险较高的情况下，将无法充分缓解故障。

软件安全实践首先要了解如果组件或系统出现故障会发生什么，然后将潜在的故障跟踪到适当的活动中以减轻这样做的风险。例如，考虑一个控制飞机引导的系统，在该系统中故障可能是灾难性的。必须在子条件覆盖范围内执行严格的缓解活动，以确保正确生成代码。

然而如果是飞机娱乐系统发生故障，飞机将不会坠毁，因此与可能立即造成生命损失的系统相比，测试机上娱乐系统的要求较低。

软件的可塑性既是福也是祸。使系统几乎可以在合理范围内执行任何操作非常容易。但是，在确保软件不会失败时，同样的灵活性也可能成为致命弱点。

即使在商业世界中，虽然并非所有软件故障都是灾难性的，但它们也不可取。许多开发人员在对安全至关重要的行业中工作，除了遵守最严格的标准外别无选择。但是这些标准所倡导的原理之所以存在，是因为已经证明它们可以使最终产品发挥更好的功能。因此，无论应用程序有多重要，按比例采用这些原则是完全有意义的。

尽管适用于软件开发的功能安全标准过多，令人困惑，但它们之间的相似之处远胜于区别。所有这些都是基于这样一个事实，即软件开发是一门工程学科，要求我们建立需求，进行设计和开发以实现它们，并尽早对需求进行测试。

采用这种思维方式将为整个行业的支持工具打开大门，从而可以更高效地开发更高质量的软件。

Mark Pitchford是LDRA Software Technology的技术专家，他与开发团队合作，希望在功能安全性和信息安全性至关重要的环境中实现合规软件开发。