工程师们似乎在嵌入式软件开发的一个领域就是测试。工程师经常对设计和实现阶段感到兴奋，但是当涉及到证明系统工作时，努力和/或兴趣真的开始减弱。考虑到可能需要的时间和精力，这是完全可以理解的。嵌入式开发工程师测试嵌入式系统有许多不同的方法，但它们可以归结为两种主要的测试类型，白盒测试和黑盒测试。

　　黑盒测试通常由第三方或质量保证小组执行，他们了解外部系统行为需求，但缺乏对内部结构或代码操作的深入了解。另一方面，嵌入式软件工程师更有可能执行白盒测试，因为他们了解软件的结构和实现，在这种类型的测试中，工程师会考虑软件结构，以确保每一个分支、每一个案例和每一行代码都通过测试得到了执行和验证。

　　即使对于相对较小的程序来说，这也是一项令人望而生畏的任务。值得庆幸的是，有一种简单的方法来理解和生成确保适当测试覆盖所需的测试用例数量，那就是使用条件复杂度，也称为圈复杂性。传统上，在实现阶段推荐条件复杂度测试，以确保代码质量。其思想是分析程序中的每个函数，并提供一个结果复杂度值。值越高，函数就越复杂，导致错误风险更高，测试和维护困难。

　　这个测量真正有趣的是，它直接通过函数测量线性无关路径的数量!复杂度值提供了完整分支覆盖所需的测试用例数量的上限!这意味着，嵌入式开发人员通过对源代码执行这个简单的度量检查，不仅有助于确保代码保持简单，而且可以用来检查是否已经为分支覆盖测试定义了足够的测试用例!

　　现在想到的问题是，我们如何使用这个复杂度值来创建测试用例?答案首先在于条件复杂度是如何计算的。有两种方法可以解决这件事。第一种是简单地把if的个数，循环的个数相加并加一个。第二种方法是生成控制流图，确定边、节点和连通分量的数量，然后从边中减去节点的数量，再加上连通分量。因为这比简单地查看源代码要复杂得多，所以第一种方法要容易得多，也更有可能在开发周期中完成。

　　在测试基础上执行测试有许多不同的类型和方式，使用条件复杂性只是如何执行测试的一个简单例子。测试通常需要的不仅仅是简单的分支测试，而是需要沿着多个实现层和系统行为需求进行测试。无论如何，嵌入式开发人员从开发周期中使用的代码度量创建测试至少是一个好的开始。