为什么应该使用基于标准的开发实践（即使您不必）

整个行业都围绕验证和验证实践发展起来，这些实践受到 IEC 61508、ISO 26262、IEC 62304、MISRA C 和 CWE 等功能安全、安保和编码标准的支持。当然，并不是每个人都必须遵循这些标准所提倡的正式流程和方法，特别是如果他们的软件不需要满足这些标准的严格要求。但这些标准支持最佳实践，因为经验表明它们代表了实现高质量、可靠和强大软件的最有效方法。

遵循这些标准的最佳实践开发技术有助于确保首先不会将错误引入代码中，从而减少可能会拖慢上市时间和增加成本的大量调试活动的需要。当然，并非所有开发人员都有足够的时间和预算来开发航空航天、汽车或医疗设备行业的应用程序。然而，他们部署的技术代表了一个对任何开发团队都具有巨大潜在好处的工具箱，无论是否强制使用它们。

错误类型和解决方法

可以在软件中发现两种关键类型的错误，并使用工具解决以防止引入错误：

• 编码错误。一个例子是尝试访问数组边界之外的代码。这些类型的问题可以通过执行静态分析来检测。
• 应用程序错误。这些只能通过确切知道应用程序应该做什么来检测，这意味着根据要求进行测试。

编码错误和代码审查

静态分析是一种检测编码错误的有效技术，尤其是在项目一开始就部署时。分析完代码后，可以查看不同类型的结果。代码审查是根据 MISRA C:2012 等编码标准检查代码的地方，我们将在本文中重点关注这一点。

理想情况下，所有嵌入式项目都应使用诸如 Ada 之类的安全语言。 Ada 包含许多特征来强制执行自然减少错误的思考过程（例如严格键入）。不幸的是，很难找到具有 Ada 知识和经验的程序员，因此大多数公司转而使用 C 和/或 C++。然而，即使对于有经验的开发人员，这些语言也存在缺陷。幸运的是，通过执行代码审查，可以避免大多数这些潜在的陷阱。

避免代码缺陷的最佳方法是避免将它们放在那里。这听起来很明显，但这正是编码标准的作用。在 C 和 C++ 世界中，大约 80% 的软件缺陷是由大约 20% 的语言的错误使用引起的。如果限制语言的使用，避免语言中已知有问题的部分，那么缺陷就可以避免，软件质量会大大提高。

C/C++ 编程语言失败的基本语言相关原因是未定义的行为、实现定义的行为和未指定的行为。这些行为会导致软件错误和安全问题。

作为实现定义行为的示例，请考虑当有符号整数右移时高位的传播。结果是0x40000000还是0xC0000000？

图 1：某些 C 和 C++ 构造的行为取决于所使用的编译器。 （来源：LDRA）

答案取决于您使用的编译器（图 1）。它可以是。在 C 语言中未指定对函数参数求值的顺序。在图 2 所示的代码中——其中 rollDice() 函数只是从包含值“1、2、3 和 4”的循环缓冲区中读取下一个值——预期的返回值将是 1234。但是，不能保证这一点，至少有一个编译器会生成返回的代码值 3412。

图 2：某些 C 和 C++ 构造的行为未由语言指定。 （来源：LDRA）

C/C++ 语言存在很多这样的陷阱，但是通过使用编码标准，可以避免这些未定义、未指定和实现定义的行为。同样，使用诸如 goto 之类的构造 或 malloc 会导致缺陷，因此可以使用编码标准来防止使用这些构造。混合有符号和无符号值时会出现很多问题，这在大多数情况下不会产生问题，但有时可能会出现有符号值溢出并变为负数的极端情况。

编码标准还可以检查代码是否以特定风格编写；例如，验证未使用制表符、缩进是特定大小或括号位于特定位置。这很重要，因为需要进行一些手动代码审查，并且当在不同的编辑器中查看代码时，制表符具有不同的大小，那么奇怪的布局会分散审查者的注意力，无法集中精力审查代码。

一些开发人员因编写“聪明”的代码而感到内疚，这些代码可能高效且紧凑，但也可能神秘而复杂，使其他人难以理解。最好保持简单并让编译器负责制作高效的二进制文件。再次重申，使用编码标准有助于防止开发人员创建未记录的和过于复杂的代码。

最著名的编程标准可能是 MISRA 标准，该标准于 1998 年首次针对汽车行业发布。这些标准的流行反映在提供某种程度的 MISRA 检查的嵌入式编译器的数量上。 MISRA 的最新版本是 MISRA C:2012，其页数几乎是其前身的两倍。大多数附加文档都包含有关为什么每个规则存在的有用解释，以及该规则的各种例外的详细信息。 MISRA 有几个指南，在适用时，它们包含对标准或未定义、未指定和实现定义的行为的引用。一个例子可以在图 3 中看到。

图 3：MISRA C 对未定义、未指定和实现定义的行为的引用。 （来源：LDRA）

大多数 MISRA 指南都是“可判定的”，这意味着工具应该能够识别是否存在违规行为。但是，有一些准则是“无法确定的”，这意味着工具并不总是可以推断是否存在违规行为。一个例子是当一个未初始化的变量作为输出参数传递给应该初始化它的系统函数时。但是，除非静态分析可以访问系统函数的源代码，否则无法知道该函数在初始化之前是否使用了该变量。如果使用简单的 MISRA 检查器，则它可能不会报告此违规行为，从而可能导致假阴性。或者，如果 MISRA 检查器不确定，则它可以报告违规行为，这可能导致误报。什么是最好的？不知道可能有问题？或者确切地知道在哪里花时间确保绝对没有问题？当然，假阳性比假阴性更可取。

2016 年 4 月，MISRA 委员会发布了对 MISRA C:2012 的修正案，增加了额外的 14 条准则，以帮助确保 MISRA 不仅适用于安全关键型软件，也适用于安全关键型软件。其中一项准则是指令 4.14，如图 4 所示，该指令有助于防止由于未定义行为而导致的陷阱。

图 4：MISRA 和安全注意事项。 （来源：LDRA）

应用程序错误和需求测试

应用程序错误只能通过测试产品是否完成它应该做的事情来发现，这意味着有需求。避免应用程序错误既需要设计正确的产品，也需要正确设计产品。

设计正确的产品意味着预先建立需求并确保需求和源代码之间的双向可追溯性，以便每个需求都得到实现，每个软件功能都可以追溯到一个需求。任何缺失或不必要的功能（不满足要求）也是应用程序错误。产品设计权是确认开发的系统代码满足项目需求的过程，可以通过进行基于需求的测试来实现。

图 5 显示了双向可追溯性的示例。在这个简单的例子中，选择了单个功能，从功能到低级需求，再到高级需求，最后到系统级需求，突出显示了上游可追溯性。

图 5：双向追溯，选择了功能。 （来源：LDRA）

在图 6 中，选择了一个高级需求，突出显示了对系统级需求的上游可追溯性和对低级需求和源代码功能的下游可追溯性。

点击查看大图

图 6：双向可追溯性，选择了需求。 （来源：LDRA）

这种可视化可追溯性的能力可以在生命周期的早期发现可追溯性问题（应用程序错误）。

测试代码功能需要了解它应该做什么，这意味着要有低级要求来说明每个功能的作用。图 7 显示了一个低级需求的示例，在这种情况下，它完全描述了单个功能。

图 7：低级需求示例。 （来源：LDRA）

测试用例源自低级需求，如表 1 所示。

表 1：源自低级需求的测试用例。 （来源：LDRA）

使用单元测试工具，然后可以在主机或目标上执行这些测试用例，以确保代码的行为符合要求。图 8 显示所有测试用例均已回归并通过。

图 8：执行单元测试。 （来源：LDRA）

当测试用例运行完毕后，应测量结构覆盖率以确保所有代码都已运行。如果覆盖率不是 100%，那么可能需要更多的测试用例或应该删除多余的代码。

结论

随着软件复杂性的增加，潜在的软件错误也会增加。最佳实践开发技术有助于防止这些错误的发生。最佳实践开发包括使用最先进的编码标准（例如 MISRA C:2012）、测量代码指标、跟踪需求和实施基于需求的测试。在没有义务满足标准的情况下应用这些技术的程度显然由开发团队决定。然而，这些标准支持这些实践，因为经验表明它们代表了实现高质量、可靠和健壮的软件的最有效方式。并且无论产品是否对安全至关重要，这肯定是对其开发团队有利的结果。