嵌入式系统中的软件测试问题
文章作者:Mark Pitchford
像状态机功能这样的高级需求以及遵守网络安全和功能安全标准是至关重要的。
在嵌入式系统的世界中，不仅仅是技术在继续发展和进化。用于开发该技术的工具和方法也在不断成熟和改进。
在20世纪80年代早期，我为一家小型计量公司开发软件，将工程数学应用于坐标测量机(CMMs)。我觉得我很擅长这个。但是我们的开发生命周期本质上把产品软件看作是一个沙箱。我们将从生产代码开始，添加功能，执行一些相当基本的功能测试，然后发布。
在这样一个小公司里，我们的工程团队自然包括了软件和硬件专家。事后看来，虽然我们所开发的软件需要广泛的客户支持，但它所运行的硬件却没有类似的消防文化。
软件开发是一门工程学科
软件和硬件支持之间的部分差异是由粗糙的开发过程造成的。但是，软件本身的可塑性以及由此产生的不断增长的功能能力也发挥了重要作用。简单地说，出错的方法远多于正确的方法，这一特点要求将其视为一门工程学科。
这些都不是什么新鲜事。领先的航空、汽车和工业功能安全标准，如DO-178、ISO 26262和IEC 61508，多年来一直要求采用这种方法。但是，如果您想从今天的尖端开发和测试工具中获益，那么拥有工程学科的思维方式是必要的，这些工具是为这种方法而设计的。
最近，ISO/IEC/IEEE 29119的开发显示了软件测试的重要性，这是一套可以在任何软件开发生命周期或组织中使用的软件测试国际标准。
需求问题
电气系统设计通常从一个状态机和对特定产品的不同操作模式的理解开始。工程师通常可以非常快速和轻松地将状态机功能映射到逻辑。如果状态机变得更复杂，它通常被转换成软件。
高级需求对于确保系统功能正确是至关重要的。这些需求描述了业务逻辑和预期功能的特征，并能够评估系统是否执行了它应该执行的任务。最佳实践遵循从高级需求到分析到覆盖的流程，自然而然地，需求跟踪工具被设计来支持这一点。
在状态机模型中，描述每个状态的需求是高级需求的例子。通过代码跟踪执行路径以确保每个需求都被正确解释，这是检查正确实现的一个非常好的方法。
功能安全标准将此扩展到需求可追溯性的概念。他们经常要求用户从高级需求中练习他们所有的代码，并用低级测试解释和测试任何未发现的用例。最近，网络安全领域的“左移”模式也反映了这一信息，如图1所示的v -模型。
图1顾名思义，V-model体现了一个产品开发过程，该过程在开发的每个阶段显示了测试规范之间的联系。来源:LDRA
测试组件，然后测试系统
在任何工程规程中，确保组件在集成到系统之前能够正确地工作是很重要的。为了将这种思维应用到软件中，工程师需要定义较低层次的需求，并确保每个功能和功能集发挥它们的作用。工程师还需要确保他们为系统的其他部分提供适当的接口。
单元测试包括在功能和模块级别参数化输入和输出，执行检查以确保输入和输出之间的连接是正确的，并遵循覆盖的逻辑。单元测试工具可以提供经过验证的测试工具和图形表示，将单独的输入和输出连接到执行路径，并使其正确性得到验证。
理解功能级和模块级的接口也很重要。静态分析工具可以显示这些接口，并在不同级别连接逻辑。
尽早发现问题
任何学科的工程师都会告诉您，问题发现得越早，修复它们的成本就越低。
静态分析执行源代码分析，为系统的执行建模，而不是实际运行它。只要编写好代码，静态分析就可以帮助开发人员最大限度地提高代码的清晰度、可维护性和可测试性。静态分析工具的主要功能包括:
- 代码复杂性分析:理解代码在哪里不必要地复杂，这样工程师就可以执行适当的缓解活动。
- 程序流程分析:绘制程序执行的设计-审查流程图，以确保程序在预期的流程中执行。
- 预测性运行时错误检测:通过尽可能多的可执行路径建模代码执行，并寻找潜在的错误，如数组边界溢出和除零。
- 遵循编码标准:选择编码标准通常是为了确保对网络安全、功能安全的关注，或者在MISRA标准的情况下，选择其中之一或两者。编码标准有助于确保代码遵循最佳编程实践，无论应用程序如何，这肯定是一个好主意。
图2像静态分析这样的活动在开发生命周期的早期是一种开销，但是从长远来看它们是有好处的。来源:LDRA
开发足够质量的代码
质量越高的工程产品就越昂贵，这一点也不奇怪。坚持任何开发过程都是要付出代价的，并且开发可能最好的开发在商业上并不总是可行的。
在安全性很重要的地方，功能安全标准通常需要对成本和失效概率进行分析。每个系统、子系统和组件都需要进行风险评估，以确保执行相应的缓解活动。无论系统是安全关键型还是安全关键型，相同的原则都是有意义的。如果您以相同的严格程度测试系统的每个部分，那么您将在系统中风险较低的部分过度投资，而无法充分减少风险较高的部分的故障。
软件安全实践从理解如果组件或系统出现故障将会发生什么开始，然后将潜在的故障跟踪到适当的活动中，以减少这样做的风险。例如，考虑一个控制飞机导航的系统，它的故障可能是灾难性的。必须在子条件覆盖级别上执行严格的缓解活动，以确保正确的代码生成。
与飞机上的娱乐系统相比。如果这个系统失败了，飞机就不会坠毁，所以测试一个机上娱乐系统比测试一个有可能立即造成人员伤亡的系统要求要低。
软件的延展性是福也是祸。这使得系统能够很容易地在合理范围内做任何事情。但是，当涉及到确保软件不出错时，同样的灵活性也可能成为阿喀琉斯之踵。
即使在商业世界中，虽然不是所有的软件故障都是灾难性的，但它们从来都不是可取的。许多开发人员在安全和安全关键的行业中工作，除了遵守最严格的标准外别无选择。但是这些标准所提倡的原则是存在的，因为它们已经被证明可以使最终产品的功能更好。因此，无论应用程序有多重要，以相称的方式采用这些原则是完全有意义的。
尽管适用于软件开发的功能安全和安全标准令人困惑，但它们之间的相似之处远远多于差异。所有这些都基于这样一个事实:软件开发是一种工程规程，要求我们建立需求，设计和开发来实现它们，并根据需求早期测试。
采用这种思维方式将为整个行业的支持工具打开大门，从而能够更有效地开发更高质量的软件。
本文最初发表于经济日报。
马克Pitchford他是LDRA Software Technology的技术专家，曾与开发团队合作，希望在安全和安全关键环境中实现兼容的软件开发。
相关文章: