本文讨论了中小型企业在嵌入式软件质量保证工作中的一些问题。从工作的准备到具体的经验，试图提供一条循序渐进，各阶段重点突出的途径，从而帮助中小型企业不断提高嵌入式系统软件的质量。

近年来集成电路技术的发展，使越来越多的嵌入式系统出现在我们面前，这个趋势使得许多传统行业中的中小型企业建立了自己的嵌入式软件开发团队。它们的共同特征主要有:

a. 嵌入式软件开发/测试人员在10人以下；

b. 嵌入式软件开发小组/部门在近几年内建立；

c. 所开发的产品，存在不含有嵌入式软件的旧型号。

目前国内的嵌入式系统产品，绝大部分是在这种情况下开发出来的。显然，这时除了嵌入式软件本身所具备的外围环境复杂，界面简陋、可用性和实时性要求高等特征之外，在一个中小型企业中新建嵌入式软件开发团队，也带来了其它难题。

中小型企业的典型问题

a. 开发周期短

导致缩短开发周期的压力主要来自两个方面:资金短缺和缺乏技术规划。后者在我们所讨论的情况中尤为突出。由于嵌入式软件带来产品功能，性能和成本上的变化，往往引起市场的混乱，使新产品推出的时机更加难以把握。同时中小型企业在市场中的位置，决定了它们难以承担市场引导的角色，而采取更为灵活务实的策略。这些因素使我们无法得到一个中长期规划，从容的进行开发和测试。

b. 缺少合格的质量保证人员

除了人力市场上难以找到合适的应聘者之外，中小型企业的开发任务数量上呈现的波动性，使它更需要一个精悍的核心团队，很难设立专职软件质量保证岗位编制。同时，一些典型的行政结构和工作流程上的问题，比如一线开发人员兼任管理职务，缺乏文档和缺陷管理工具和制度等，也损害了质量保证人员的主动性，不利于他们能力的增长。

c. 质量意识较弱

企业家大多精明而实干，他们对自己的产品心中有数，质量也在掌控之中。质量意识弱主要还是指消费者。毕竟理智而挑剔的消费群体，是规范市场所必需的。目前不仅普通消费者对嵌入式软件缺乏了解，相关部门往往也没有具体的检测要求，即使对软件失效可能威胁人员生命的产品都是如此。中小型企业更容易过度地顺应这种环境，这就在客观上助长了低质产品的流通，也抑制了企业内部质量保证工作的开展。

以上三个问题，分别是开发部主管，企业领导人和相关部门需要解决的。

准备工作

软件质量保证主要涉及两部分工作:提高发现缺陷的能力和改变软件质量平衡点。对于新建立的质保部门/小组，前期焦点主要在前者，而一段时间之后工作重点必然转移到后者。软件质量的平衡点出现在这种情形下:缺陷修复所对应的工作量和复杂度，引出数量相当的一批新缺陷。这种平衡点主要由团队能力，开发平台，工作流程和开发对象的规模和难度等因素决定。在适当的预算下，使质量平衡点高于顾客的预期，并且有足够的潜力和伸缩性保持这一关系，是软件质量保证工作的目标。

对于这项工作在企业活动中的定位，我们也应该有清醒的认识。以赢利为目标的企业不可能无休止的追求高质量，准确的说，企业需要的是对质量的调节能力，保证在满足顾客的需要的同时获得尽可能大的利润，软件质量保证则归属于这一工作范畴(图1)。

重视缺陷的评估分级

速度能够解决很多问题，根据企业实际情况选择恰当的切入点相当重要。常见的失误是把过多的资源投放在尽可能多地发现缺陷上，而忽略了不同种类缺陷的不同价值，造成了浪费。事实上，从系统的软硬件资源，通信带宽的冗余，体系结构设计的调整余地，需求变化的可能性，到开发过程改进上的潜力，诸多因素左右着这个问题的最佳答案。选择便于修复，而又有现实的市场意义的缺陷，迅速而彻底地完成准备->测试->改进的过程，而不是追求更高的测试覆盖率，会为后面的工作赢得宝贵而真实的体验。

工作中总是充满了不确定性，利用不完整信息进行判断是工作中固有的一部分，更好的办法则是进行有前瞻性的规划。技术管理者应对产品质量的大致情况，调整空间有所预见，并且有针对性地布置调整的手段，而不需要进行全面的测试后，才能对缺陷进行统计，评估和分级。

建立文档和缺陷管理制度

缺乏文档管理制度，无论黑箱还是白箱测试都不能获得所必需的准确输入信息。而缺陷管理工具，对于较复杂系统的改进而言，更是必不可少的。在实际工作中，我们也曾经尝试手工管理缺陷，在一段时间的混乱之后最终决定开发自己的缺陷管理系统。这套软件给测试人员，制造部、品管部、采购部和营销中心都分配缺陷的登记账号。系统使用B/S结构，并且实现了邮件自动通知功能，用户名和口令与windows域用户同步，这使内部网络上所有计算机都可以方便地登录使用。

几点经验

1. 正规的开发方法

这个标题容易使人联想到一连串时髦的术语，也容易使强调灵活简便的中小型企业产生排斥感。但是实践证实，如果人员能力和系统资源允许的话，这是降低人员工作强度，保证质量的一个好途径。我们的尝试是从提高软件的可验证性开始的。为了降低测试的难度，我们希望将关键模块的行为以有限状态机描述，并且提供以下明确的接口，以方便地测试每一次状态跃迁:

a. 设置被测试对象的状态；

b. 修改输入数值或者触发事件；

c. 获得被测试对象的状态；

d. 获得输出数值或者操作类型。

显然这样的代码很容易测试，但是却会占用更多的代码空间。为了考证额外开销的实际大小，我们设计了基于这种建模方式的C代码模板，并且在共创联盟(http://cosoft.org.cn/projects/mirage/)和sourceforge(http://sourceforge.net/projects/mirages/)上注册了相应的代码生成工具mirage项目(GPL)。在实现了一个简单的原型后，我们没有继续去完善这个代码生成工具。但是实践告诉我们，可以非常迅速地根据FSM编写牢固的代码框架，手工完善之后可以得到高质量的易于测试的源代码，从而把实现阶段的压力转移到设计阶段，并且在简洁的模型中进行。这些代码在时间效率上表现出色，但是空间上会有一定的额外开销。对于越复杂的软件，这种方法带来的益处越显著。同样的思路也可以用在汇编代码中，最近我们在PICmicro中，实现了相应的汇编代码模板，甚至应用在仅有4k指令空间的紧凑环境中。

2. 适当的工具配置计划

在前期我们往往需要抵制购买昂贵设备的诱惑，而把重点放在培育优秀的人员和优化开发流程上面，根据工作的进展逐次添置设备。需要特别注意的是，关注嵌入式软件测试的不仅仅是测试工具的开发商和芯片的设计者，集成开发环境的提供商，也越来越多地考虑如何为测试提供更多地支持。结合实际的需要，灵活利用好这些资源完全可以在很少的投入下，搭建起简单实用的测试过程。

下面我们举一个实际的例子。Keil公司的μVision2 IDE较新的版本支持AGSI[1]。通过AGSI可以开发一个动态连接库，用户可以把硬件仿真器与μVision2的软件仿真环境协同起来。

如上所述，我们在一个软件仿真环境内，对状态跃迁进行测试需要的实时功能有:

a. 改写数据存储器/寄存器/的数值；

b. 获得数据存储器/寄存器的数值；

c. 仿真环境主动弹出事件通知(断点等)；

这些恰好都是AGSI所能提供的，将Keil公司提供的示范代码作简单修改，我们完成了原型并验证了这个设计思路，同时μVision2本身也提供了覆盖率统计，性能分析等软件测试所需要的功能。

类似的例子还有很多，大家掌握软件测试的基本原理之后，可以很自如的作出工具配置的计划来。把它和团队结合在一起，才能逐步达成完美的效果。

强调测试自动化

测试或许是技术领域中最可能、也是最需要提高自动化程度的工作，对于资源紧缺的中小型企业而言更是如此。测试自动化主要包括:

a. 测试准备的自动化(如驱动器的生成)；

b. 测试用例的自动化生成；

c. 测试的实施，记录和诊断的自动化。

关键在前两点，目前主要有两种途径:

a. 利用被测试对象设计阶段的建模结果；

b. 对源代码进行自动分析。

正如上面提到的，利用移植技术我们可以生成高质量的源代码。如果因代码空间的压力无法采用，那么在测试过程中替代人工版本的实现，或者批量生成/验证测试用例上还是适用的。这其实是第一种途径；而对源代码进行自动分析，往往超过中小型企业的技术能力，通常在商业化的测试工具中运用。

发展趋势分析

嵌入式系统是一个高速发展的领域，相应地嵌入式软件测试技术也必然随后跟进。因为微处理器的速度越来越高，测试的难度越来越大。其次，随着集成度的提高，芯片开发商开始把测试支持作为产品的卖点。最后，可重配置器件的发展，将使软件与硬件的结合越来越紧密，无论在开发时还是在运行时[2]。这时候嵌入式软件测试相应的转变为嵌入式系统测试。当然，市场、企业和有关部门之间的互动，也是我们需要关注和预估的。