不同的嵌入式开发人员和团队对质量的定义可能会有很大的不同。因为每个人对质量都有自己的定义，所以团队必须以一种不仅记录而且可以测量的方式定义质量。在这篇文章中，我们将探讨几个可测量的软件度量，这些度量可以用来定义软件质量。

　　遵守行业最佳实践(标准)

　　嵌入式系统行业有很多标准，这些标准的侧重点可能略有不同，从简单的风格标准到为开发人员提供C语言子集的MISRA-C等标准。按照规定的标准开发软件可以保证避免常见的陷阱，提高软件的质量。

　　MISRA-C是嵌入式开发人员遵循的一种非常常见的编码标准。静态代码分析器可以用来验证标准中大约90%的指令，但有些指令是无法通过工具验证的。为了确保符合标准，开发人员需要定期执行代码检查，并手动检查其余指令。达到标准是确保软件达到最低质量水平的一个好方法。

　　最小化圈复杂度

　　McCabe圈复杂度度量是一个简单的测量，可以对任何确定通过该函数的路径数的函数执行。值小于等于10的函数被认为是易于测试和维护的简单函数。然而，超过10条之后，测试所需的路径数量开始变得更加复杂、困难，并且易于开发和维护，这可以用来表明代码质量较低。事实上，随着复杂度接近大于20的数字，几乎不可能正确测试函数。如果你不能正确地展示一个功能，它是如何工作的？

　　测量复杂性也可以是一个自动化的过程。有一些免费的工具，比如CCCC和Eclipse metriculator插件，可以用来测量圈复杂度。还有一些IDE，比如Understand，可以用来收集关于代码库的度量信息。成功测量这一指标的关键是：首先，决定进行测量;第二，在将新代码检查到代码库之前执行测量。它也应该在持续集成服务器上执行。

　　没有警告的编译

　　警告是编译器告诉嵌入式开发人员他们正在做一些看起来不太正确的事情的方式。考虑到大多数编译器都会让开发人员在代码中做一些可怕的事情，事实上，编译器是在警告开发人员，这意味着开发人员应该注意!编译时没有一个警告的代码是一个易于衡量的指标，它表明软件达到了其他软件可能无法达到的质量水平。仍然可能存在bug或其他质量问题，但至少代码本身在语义上是正确的。

　　代码测试覆盖率

　　在我们行业的开发周期中，最大缺陷之一是开发代码覆盖率为100%的测试。事实上，问题不在于100%的代码覆盖率;这只是理解测试实际上覆盖了多少代码!如果一个团队知道他们的测试用例覆盖了85%的软件，这是一回事。然而，大多数团队甚至不知道这一点。代码覆盖率可以作为衡量软件质量水平的一个重要指标。显然，与仅测试到50%的产品相比，测试到85%的产品更坚固，质量更高。开发人员可以测量这个值，并将其用作代码质量的内部度量。

　　编码确认

　　代码验证与测试覆盖率类似，不同的是，我们不是测量覆盖了多少代码，而是测量测试实际通过或失败的百分比。例如，我们可以根据以下因素生成数值：

　　正在执行的测试

　　通过测试

　　需求覆盖率

　　使用这些指标，我们可以根据测试执行的成功程度，生成0到10之间的数值。然后，这为我们提供了一个评估指标，如果我们没有达到所需的代码验证级别，我们可以返回并改进测试过程，直到达到所需的级别，这也对应于所需的代码质量级别。

　　结论

　　为了拥有高质量的软件，“质量”一词需要由开发团队定义。该定义应该包括可测量的指标，这些指标可以在整个嵌入式开发过程中轻松跟踪和监控。在本文中，我们探讨了一些高级定义，这些定义应该是创建高质量代码库所遵循的最低标准和过程。实现这些指标将帮助你不仅提高总体代码质量，还可以消除和防止软件缺陷。