嵌入式系统软件的质量保证

IBM中国有限公司软件部高级技术顾问 靳超

一. 质量是产品的生命

　　当今随着软、硬件技术的发展,嵌入式系统广泛应用于航空航天、国防军事、电子通讯等行业，其中软件也越来越复杂。而这些领域应用特点，决定了嵌入式系统往往是高安全、任务关键的系统，软件的微小瑕疵，就可能严重威胁到生命和国家的安全、天文数字的巨额财产损失。就使得保证嵌入式软件的质量和可靠性，变得至关重要。而在这些领域，对产品质量从来就保持着高度的重视，有将“质量视为产品的生命”的传统。这样，相关行业的高层管理人员和开发人员对于软件的质量也逐渐提高了重视程度。近年来，在组织上，建立了完善的软件测试体系，从自检，到专检，直到甲方的测试中心；在开发和测试方法上，沿袭了多年在系统工程和硬件设计中积累的经验，在项目管理中将“两条指挥线四总”的体制推广到软件领域，建立了中国的软件过程成熟度的评价体系GJB5000；在自动化工具方面，投入了大量的经费和人员在测试设备的开发、购置和建设方面。应该说，软件，作为嵌入式产品主要的组成部分之一，对其质量的重视，是目前相关行业内的一个共识 。
　　然而在现实生活中，许多软件产品却时常陷入质量低下的旋涡，总是不尽人意，问题常常表现在：
　.　相关产品的领导得不到产品质量的具体信息，不能对软件研发体系交付产品的质量建立信心；
　.　项目管理人员无法实时对项目中软件部分所处的质量状态有所了解；
　.　产品在集成阶段，常常因为软硬件混合的集成问题难以解决，而造成延期，甚至由于进度的要求，降低产品的质量基线；
　.　开发团队没有时间和资源继续测试，发布未经过完善测试的产品，然后在维护产品上花费更多的时间、经费和人员；
　.　于此同时，研发体系困惑于测试工具的使用，发现那些购买是良好演示的工具却无法测试我们开发出来的系统；
　.　软件总是由总师设计出来，由开发人员编写出来，最后在项目即将交付时，交给测试人员，由他们承担质量责任。
　.　软件测试更象一场“运动”，在项目交付阶段临时组织起来的测试团队，面对交付的压力，不得不寻求无需学习，无需准备、无需了解被测对象的，无需硬件，无需源码，最好什么都不需要的“人工智能”的测试工具，只要能出报告，而无暇顾及软件质量的本质要求。
　　.　现有的工具往往无法满足这些测试的需求，我们常常找些看似满足的，但在实际使用中，又会发现由于我们对工具使用预期不恰当的定位，工具原本的功能由于其他的因素无法发挥。
　　.　现有的工具常常处于闲置状态，而开发团队又有很多问题得不到解决，需要更多的工具。
　　究其根源，除了软件本身故有的复杂性，还和不同的组织对软件产品质量内涵有着不同的认识，造成不同的工作方式和态度，养成了不同的工作和思维习惯，和由此带来不同的产品质量结果。
　　IBM Rational多年来在软件工程和质量保证方面积累了丰富的方法和经验。本文依据部分嵌入式开发机构中对软件质量保证工作的一些理解，分析相应开发机构工作中可能的问题，并提出以RUP为核心的全过程的质量管理的思想和具体的实现方式，提出不同单位的过程改进方法，以一种渐进的方式，从简单的工作开始，逐渐深入的改进组织的软件质量管理水平
　　但我们也需要看到，尽管可能不需要一个繁重的、一蹴而就的过程来达到高质量的要求，但是关注质量的组织思维倾向是必要的条件，并且这必须由最高管理层驱动。

二. 定义质量

　　对于任何一个组织，定义共同的对质量的理解，是重要的第一步。软件开发组织经常按照一种不精确的、概括的质量观念来运转。
在IBM Rational统一过程中，质量定义如下：
　.　满足或超出认定的一组需求
　.　使用经过认可的评测方法和标准来评估
　.　使用认定的流程来生产。
　　在这个定义中，我们首先看需求，IBM Rational的软件质量在用户需求方面的定义分为这样几个方面：

　
　　讲到质量保证，归根结底就是为客户提供更高品质的产品，更好地满足客户的需求。而且客户的需求是多维的，产品的功能性需求应该是客户首先要考虑的因素，同时还包括其他四个方面。除了这些技术因素之外，用户的需求还应该包括产品要在指定的时间和预算范围内完成。

{{分页}}
　　第二方面，这个质量定义中明确指出，质量更体现在软件开发的整个过程和一个标准的评价方式上。在过程质量方面，经常举的一个例子就是汽车生产过程。当我们面对推销员推销两款汽车，其中一款是由先进的生产线生产的产品，而另一款是由技术精湛的师傅手工精制而成，在汽车的质量方面，您会作何感想呢？通过了解市场上同型号车的质量状况，你可以轻松做到对第一辆车心中有数；但对第二辆呢？由此可见，你对第一辆车的信任，来自于过程质量。
　　.　软件开发过程质量就是指为了生成工件而对可接受流程的实施和遵守程度，体现在三个层次：
　.　产品本身和用来生产、组装软件产品的零部件质量，包括用来进行软件开发或在软件开发过程中产生的代码、文档、模型和可执行系统等工件；
　.　软件开发活动本身对标准化软件开发过程的遵守和贯彻的程度，主要体现在软件开发过程的标准化、流程化、自动化程度和团队基本协作平台的效率，各个过程对质量的承诺；
　　用来对整个软件产品进行验收的评测手段，它应该是被业界广泛认可和接受的方法，应以优先考虑经典的测试方式的实现，构筑质量评价的基础，然后再针对某些低效环节补充其他专门的测试手段。
　　一个软件生产企业的过程质量一般可以用它的软件过程成熟度等级来评估，但它依赖我们采取的方法、工具和软件开发平台来决定。
　　我们应该如何达到这一质量目标呢？尽管要求更好质量的下意识反应就是扩大测试团队，但是这可能不是最好的方法。作为替代，应当在你的过程中关注每一个步骤的质量。RUP全过程的质量保证过程强调的是在RUP的九个工作流程中都要逐渐形成产品的内在质量，是由所有团队成员按照要求完成自己的工作并按照RUP中提供的手段检查自己的工作而缔造的。而测试流程是由专门的各个测试角色来负责，目的在于评估和改善产品质量，监控质量状态的方面。
　　有些开发人员或许会感觉这样做不现实，做不到，或目标太远大而不实际，我们在这里想要展示的就是不这样做，我们仅有的质量保证和测试活动在应对未来复杂的系统开发测试需求时，将耗费巨大的经费和时间，甚至根本无法实施。而同时，我们将提出一个渐进的改进方式，最终达到全过程质量保证体系的要求，我们要做的，仅仅是，开始！

三. RUP全过程质量保证

　　Rational Unified Process(简称RUP)是一个可以通过Web来使用的软件工程过程。作为软件工业事实上的标准，它回答了我们以下问题：在整个软件开发的各个过程中，应该由谁（角色）在什么时候（详细工作流程）做什么（任务）和产生什么样的开发结果（工件），以完成整个项目的开发目标。建立有效的工作过程，可以提高团队的生产效率，控制开发过程中的风险，保证软件开发进度并且提高软件产品质量。同时通过为所有重要的开发活动提供全面的指南、模板和示例，使整个软件开发团队能够有效共享成功经验，提高团队效率，最终保证软件开发质量。

　　.　全过程质量保证思想
　　RUP把整个软件开发过程分解成：业务建模、需求管理、分析设计、实施、测试、部署、配置与变更管理、项目管理和环境等九个核心工作流程。每个核心工作规程由多个详细工作流程组成。RUP使用角色、任务和作为输入输出的工件来组织每个详细工作流程，实现软件开发组织内部人、资源和流程的融合。在许多组织中，将测试团队成员视为缺点的清除者，在生命周期后期将他们放在一个应用软件上，让他们去查找其它团队成员引入的缺陷。为了最有效地测试，测试团队必须更关注于系统级质量问题上。RUP通过建立完整的软件开发过程，使得产品的质量由项目团队的每个成员所代表的角色共同负责，具体体现在：
　
　　　　.　每个工作流程设定相应的工作指南和工作检查点
      .　每个角色承担相应的质量任务
 　　    .　角色的每个任务要产生合格的工件
           .　产品的每个工件建立工件指南、模板和工件检查点
　　在RUP中，整个软件开发过程如上图所示，它以指定的工件为输入，通过软件开发角色和标准化的软件开发活动，生产出满足质量要求的输出工件。为确保每个工作环节的有效执行和每个工作环节产生的工件质量，RUP为主要工作流程提供了对应的工作指南和检查点，为每个工件建立指南、模板和检查点，从而保证了软件开发的过程质量。
　　大家可能都曾注意到，RUP的九个核心工作流程并没有一个质量保证的流程。原因就在于我们认为质量是在产品各个流程中形成的一种产品的属性，而不是一件流程，质量就是质量。它意味着，应当在你的过程中关注每一个步骤的质量。理解这个，是创建一个真正成功的应用软件交付过程的关键。
　　我们都曾经誓言视质量为产品的生命，在此在回顾一下我们的誓言，将使我们更有信心沿着正确的道路走下去。
　
　　.　过程质量
　　努力建立组织级别的，可以针对不同类型项目，指定项目管理的流程，工作分配和检查点。在项目较多是，可以考虑使用项目组合管理工具来导入在RUP基础上裁剪的项目管理模板进行辅助管理，以保障过程的贯彻实施和监控。
　　当我们考虑使用RUP时，大家常常因为自己不是迭代化的开发方式，认为RUP对自己没有价值。其实，即便我们暂时不准备采用迭代化的开发方式，我们也可以把一个V型的开发模式当作一个迭代，来从RUP中吸取其他值得我们参考的思想，改进我们的实际流程。本身在RUP的迭代方式模型中，就有一个类似于瀑布的称之为“Grand design” 的开发方式，来应对小型的，或是大型又极端重要的，需求长时间保持清晰稳定的项目开发。
　　实际上大家实际工作中都或多或少的采取了一些迭代开发的方式，首先在很多关键领域的项目开发中采取的预言、初样、正样的方式，本身就是可以认为是某种形式的迭代，我们可以顺利的沿用自己习惯的开发方式，在RUP的过程和工具中吸取对我们有效的部分，并在其他条件成熟时在细化现有开发模式阶段的粒度。
　　美国国防部原本提倡瀑布过程和观点，在发现那么多采用了该方法的失败之后，不但不再强调对它的要求(如1988年的STD-2167A标准)，而且从1994年的报告开始，积极地鼓励采用更加现代化的迭代式生命周期来取代瀑布型做法。

{{分页}}
　　
　　.　软件工程成功经验共同铸就软件质量的思想
　　激烈的市场竞争催生高质量的软件。同时，软件行业经过几十年的发展，软件生产工艺、软件开发方法和工具都大大进步、日趋成熟，这一切使开发人员尽可采用更给高效的开发方式，尽享其带来的好处，开发高质量的软件。RUP以迭代式软件开发、架构为核心的软件开发、用例驱动的软件开发和风险驱动的软件开发为特色，集中体现了以下六个软件工程成功经验，通过它们共同铸就了高品质软件：
　　　　.　迭代式软件开发：能够有效控制项目风险、增加对项目控制能力、减少需求变更对项目的影响，实现持续的质量验证，实现测试技术的早期验证，提高软件的可测试性；
 .　有效管理需求：能够做到质量保证从头作起，在软件开发一开始，就把好需求质量关，实现需求的可追踪性和需求变更的有效管理；
 .　基于构件的软件架构：采用可视化建模技术来构建以构件为基础、面向服务的系统框架，可以有效地管理系统的复杂度，增强系统的灵活性和可扩展性，并解决了大家在采用迭代设计方法时构件不易识别和划分的问题；
 .　可视化建模：能够有效解决团队沟通、管理系统复杂度、提高软件重用；
 .　持续的质量验证：借助迭代式软件开发方法，可以大大提前软件集成测试和系统测试在整个开发生命周期中的时间，实现持续地软件质量验证，做到尽早测试、尽早反馈，从而确保产品满足客户的需求；
 .　管理变更：能够为整个软件开发团队提供基本协作平台，使企业管理好自己的软件资产，通过有效管理所有的变更请求，使开发团队能够很好的控制开发进度、及时了解项目状况，同时为项目的量化管理提供帮助。
　　由此可见，在软件开发过程中，高品质软件是由以上软件工程的成功经验共同铸就的。
　
　　.　尽早测试
　　作为质量保证工作的一部分，尽早测试是指在整个软件开发生命周期中通过各种软件工程技术尽量早的完成各种软件测试任务的一种思想。IBM Rational主要在以下三个方面为我们提供的尽早测试的软件工程技术：
　　首先，软件的整个测试生命周期是与软件的开发生命周期基本平齐的过程，保证当软件的第一个发布出来后，测试人员要马上基于它进行测试脚本的实现，并基于测试计划中的测试目的执行测试用例，对测试结果进行评估报告。这样，我们可以通过各种测试指标实时监控项目质量状况，提高对整个项目的控制和管理能力。
　
　　其次，通过迭代是软件开发把原来的整个软件开发生命周期分成多个迭代周期，在每个迭代周期都进行测试，这样在很大程度上提前了软件系统测试发生的时间，这可以在很大程度上降低项目风险和项目开发成本。
　　最后，IBM Rational的尽早测试成功经验还体现在它扩展了传统软件测试阶段从单元测试、集成测试到系统测试、验收测试的划分，将整个软件的测试按RUP中的角色和阶段，划分成开发人员测试和系统测试两个阶段，把软件的测试责无旁贷地扩展到整个开发人员的工作过程。通过提前测试发生的时间来尽早地提高软件质量、降低软件测试成本。

　　.　持续测试
　　作为质量保证工作的一部分，测试成功经验持续测试是从迭代式软件开发模式得来。在迭代的方法中，我们将整个项目的开发目标划分成为一些更易于完成和达到的阶段性小目标，这些小目标都有一个定义明确的阶段性评估标准。每个迭代中都包括需求、设计、编码、集成、测试等一系列的开发活动，都会增量式集成一些新的系统功能。通过每次迭代，我们都产生一个可运行的系统，通过对于这个可运行系统的测试来评估该次迭代有没有达到预定的迭代目标，并以此为依据来制定下一次迭代的目标。由此可见，在迭代式软件开发的每个迭代周期我们都会进行软件测试活动，整个软件测试的完成是通过每个迭代周期不断增量测试和回归测试实现的。
　　采用连续测试的软件成功测试经验，不但能够持续的提高软件质量、监控质量状态，同时也使系统测试的尽早实现成为可能。从而有效的控制开发风险、减低测试成本和保证项目进度。

　　.　自动化测试
　　作为质量保证工作的一部分，在整个软件的测试过程中要想实现尽早测试、连续测试，可以说完善的测试流程是前提，自动化测试工具是保证。方法是质量保证活动的基础，工具的作用多体现在对质量保证活动的自动化，以提高工作效率。我们可以体会到，没有质量保证活动的最佳方法，工具的自动化没有实现的基础，工具的作用无法体现；没有工具辅助的质量保证活动，也会因为太高的工作强度，或过于文档化、太繁琐而无法实施贯彻。自动化测试的实现，使软件测试团队能够将更多的经历放在更有创造性的工作上，并且将降低由于规章制度的遵从性需求给开发测试人员带来的额外的工作量。

四. 用正确的过程和平台实现质量

　　IBM提供一个完整的方案以帮助开发团队构建更高质量的软件。这个开放和标准的平台包括IBM软件的许多工具，包括IBM Rational统一过程。在开发的每个阶段和每个流程都强调关注质量，帮助团队来识别开发生命周期中的早期问题。以下部分描述了RUP和IBM软件开发平台中的工具如何支持每个工作流程中的质量实践的。

{{分页}}
　　为减少重复描述，先将相关工具的功能统一简要描述。下面的所有工具都可以以插件的形式集成到开放的Eclipse平台上，为开发者提供前所未有的集成环境。
　　IBM Rational System Developer 用于系统建模和开发的集成环境。
　　IBM Rational TestManager 用于计划、管理和报告任何测试工作要求。
　　IBM Rational Manual Tester 用以提高手工测试工作的效率。
　　IBM Rational Test RealTime 用于嵌入式系统的静态度量、代码规则检查、单元测试、覆盖率分析、内存分析、性能分析、代码跟踪、线程分析、基于消息的分布式系统测试的跨平台解决方案。
　　要推动团队沟通、协作和合作，IBM Rational还提供额外的解决方案：
　　IBM Rational RequisitePro 用于需求和用例管理 。
　　IBM Rational ClearQuest 用于基于工作流的缺陷和变更管理 。
　　IBM Rational ClearCase 用于配置管理。
　　IBM Rational Method Composer 用于组织开发方法的构造和发布。
　　IBM Rational ProjectConsole 使管理人员能够更加形象的了解项目质量状态。它支持由开发环境自动收集的数据，动态产生有网页形式发布的一个项目状况和数据矩阵。
　　IBM Rational SoDA自动地产生和维护全面的项目文档和报告。
　　顺便提一下，在开发方面，我们还有Apex——针对高安全性嵌入式系统Ada语言开发工具Rational Ada Developer。
　　
　　.　分析
　　Meta Group报告，引起客户不满意问题的百分之八十可以追溯到对需求的糟糕理解上。对于任何嵌入式开发项目，不论是新的系统开发，或遗留系统更新集成，质量开始于分析业务，以确保系统需求清晰且准确地反映了业务和客户需求。
　　首先，我们可以将被测系统置于其将运行的环境中，采用建模的方式，激发和整理用户业务和分析人员的思维，捕获尽可能完整的需求，并在后续的迭代中完善；通过建模的分析方式，建立松耦合、接口清晰的架构，为测试的设计提供基础；通过采用相适应的架构机制，提高系统的可测试性；通过采用流程管理工具，自动化辅助需求的评估和审计；将最优确认的需求，用条目化的方式管理需求文档，实现从需求，到分析，到设计，到实现，到测试的双向跟踪，以实现测试中发现缺陷到各层次的跟踪，和影响范围的分析。
　　此活动的工具包括Rational RequisitePro、Rational System Developer、Rational ClearQuest。

　　.　设计
　　在设计中，主要的质量集中在构架上，这是软件的“灵魂”。低质量的构架会引起大范围的质量问题，包括（软件）脆弱，缺乏升级，以及发现缺陷也难以修改。这些问题随着应用软件项目不断发展，变得越来越难以解决；并且随着应用软件从设计到开发、测试和部署，纠正缺陷的成本以指数在增长。如果软件开发人员可以有效地发现、隔离和解决设计和开发期间的结构上的不足，这项工作会在整个项目期间获得受益。开发人员也应该确保，软件是按照一种保持构架完整性和灵活性的方式来实现的，因此，随着业务需求变化，开发人员可以快速地进行变更。
　　针对此工作流程的工具有Rational System Developer、Rational RequisitePro。

　　.　开发
　　平均起来，开发人员在他们写的每千行代码中会产生100到150个错误。当然，这个数量随着开发人员和项目不同而不同。即使只有一小段代码，产生百分之十的错误也是很严重的。
　　RUP倡导开发人员主导的测试和分析上。尽管单元测试和运行时分析已经变得更为主流，但是许多管理人员仍然有这样的误解，即这些过程向时间表中增加了不必要的时间。事实上，如果不采用这些措施，开发时间表通常会一样或更加延长，这是由于在质量保证或客户发现问题后，开发人员在生命周期中调试代码后所花费的时间。对于那些想要减少风险和增加可预测性的团队来说，开发团队采用一种良好结构的、主动的质量保证方法是一个好的解决方案。
　　针对此工作流程的工具有Rational System Developer、Rational Test RealTime、IBM Rational TestManager、IBM Rational RequisitePro。

　　.　测试
　　管理系统级功能和性能测试是持续保证质量的一个主要部分。一个开发组织既不应当过分强调，也应当减少系统测试的重要性。如前所述，保证质量不只是测试团队的职责；测试也不只是质量保证的唯一领域。某些测试可以并且应当由开发人员来运行，在某些情况下，可以由构架师来运行。大量的质量保证工作，在RUP的原则下，是由其他开发角色构造的。
针对此工作流程的工具有Rational Test RealTime、IBM Rational TestManager、Rational Manual Tester 、IBM Rational RequisitePro。

　　.　支持保证质量的团队职责
　　质量是开发团队中的每个人的职责，但是它也是团队作为一个整体的职责。在一个迭代的过程中，每个迭代确保了每个工件质量的持续的重新评估，这样，迭代的方式下，经常可以保证提交质量更高的产品，也就不奇怪了。团队必须做他们可以做的任何事情，来控制迭代中的活动和工件，建立可追溯性，并简化沟通。有效的软件配置管理和变更管理是保证质量的一个基本工具；它帮助组织确保软件在每次构建是可重复的和可靠的，并且保证缺陷和变更请求得到正确的管理。
　　针对此工作流程的工具有IBM Rational Team Unifying Platform，一套完整的基本工具和过程，这个平台包括 Rational Unified Process、Rational RequisitePro、Rational ClearCase、Rational ClearQuest、Rational ProjectConsole。

五. 质量过程改进的步骤

　　当我们考虑需要什么来构建任务关键和高安全性的系统软件，并听说过程质量改进时，大家往往想到的一个复杂的过程。其实，软件过程质量改进，如软件开发，可以是一个迭代的过程。你不需要一步就完成所有的事情。即使是小的变化，包括调整你的组织中对质量的看法，也会产生一个切实的改进。
　　我们将给大家指出两条参考的改进的线路图，我们分别称之为递进式的（或者可以称之为本质的）和演进式的（我也称之为反应式的）。递进式的更多考虑工作流程间的依赖性，做到先改善基础流程，在基于已有的改善基础，做进一步改进。而演进式的多来自于工作中感知到的问题和瓶颈，依据问题的表面做反应式的改进。基于改进后再发现新的问题，如此反复。当然，我也在努力发现一种可以兼顾工作流程间依赖性，有可以快速显示改进效果的改进方式。
　　从个人角度看，由于理解有局限，我的建议常常还是反应式的。即使在这样很难考虑到太多前瞻性的工作方式中，我们需要注意：1. 我们是不是了解自己现在的瓶颈，并以此确定方向，并始终坚持自己的方向。2. 我们是不是可以做的更好，我们的改善有更多的预见性，对问题分析，从表面到本质，而不仅仅是反映式的。
　　质量保证工作改善我们可以简单的划分为以下几个方面：
　　配置管理和变更管理、静态分析和单元测试、集成测试和系统测试、迭代开发和连续测试、全过程质量、组织级质量体系、架构分析、需求管理、项目管理。我们将在以后的文章中详细描述每种改进的内容。
递进式的改进方式。

{{分页}}
　
演进式的实施方式。
 
六. 对质量保证的几种理解

　　一下主题，仅是我们所见到和所希望达到的对软件质量的几种不同的理解，没有顺序关系，也不涉及改进先后的建议。

6.1. 测试是重要并应该智能的

　　在这样的嵌入式系统开发团队中，团队成员已经认识到软件质量的重要性，并努力谋求在软件质量方面的改善，并且积极的寻求适当的方法，提高测试的效率和易用性，并且意图构建可以无缝融入原有开发流程中的测试方法。这些目标，也是我们的目标。
　　我们也应该看到，无论什么样的方法和工具，目前，都无法改变这样一个事实，软件开发和测试工作是艰苦的。“易用性”现在常常是个被过度使用的概念。现在还不存在这样的工具，他能成为软件测试的精灵手杖和魔术子弹。软件开发团队不应寄希望于只要自己使用了某种软件测试工具，那么就应该可以获取测试带来的种种好处。当一个工具给大家这样的印象时，我们只需要回顾软件质量在客户需求方面的几个需要考虑的维度上，它满足的那些？一个按钮的解决方案是存在的，但我们可以看看这样的测试工具主要完成了什么类型的测试工作，我们应该如何使用他们，应该在什么情况下引进他们才是最有效果的。采取与所处阶段不相符的测试方法，实际上不但无法达到提高产品质量的目的，而且往往由于实施的环境不具备，这些工具本身应该具有的功能也无法实现。这样的工具，在研发团队中被束之高阁也就变得在所难免了。
　　在这一过程中，我们建议在于，回顾组织对软件质量的定义；并围绕这一定义，结合组织的特点，找到目前工作的着眼点（以文中反应式的改进路线看，就是发现工作中的质量瓶颈，可参考文中提到的改进路线图）；紧紧围绕这一着眼点，来指定相关的流程方法（对流程有疑问，可以致电IBM Rational）；围绕这一方法，发现方法实施中可以通过自动化工具有效提高效率的地方；依此寻求工具支持。而不应反而以易用性选工具，以工具定测试需求，以需求来配套方法。

6.2. 系统测试保证产品质量

　　在这样的嵌入式系统开发团队中，团队成员解决了原来的系统测试可视化程度不高的问题，在原有的测试激励环境下，构建了相应的测试系统，提供可以量化的覆盖率、性能等指标。并且把量化的系统测试当成对整个开发过程健康状况的评审和反馈，提出以测试促进软件工程的思想，这些是值得我们借鉴的。
　
　　我们也应该看到，由于缺乏早期的测试活动，产品的质量问题在集成和系统阶段被发现，往往造成修改代价过高，有时对一个早期没有建立良好架构的系统,甚至由于害怕的修改引入新的更严重的故障而保留缺陷发布；由于没有统一的工具用于单元和系统测试阶段，甚至没有单元测试，使测试工具在系统级需要解决很多和用户编码风格兼容性问题；同时发现由于早期未采用迭代化的开发方式下，而且即便是瀑布式的开发方式，在早期也没有注意测试技术的考虑和验证，知道产品即将交付时，才发现测试技术未经过实际的验证，不适应系统测试的需求，寻求新的测试方式无疑是为即将到来的发布雪上加霜；即便有可用的测试方法，由于在系统设计早期，测试团队没有介入到系统开发中去，我们所构建的系统不具备可测试的条件；同时，早期设计时，急于开展编码，没有对系统进行清晰的需求分析和设计，只能为测试提供含糊的需求；没有预先准备的测试计划和测试用例；这样的系统测试,往往不得已又陷入了只能做“一个按钮，一本报告”的轻松局面；这种测试，甚至起到的相反的示范效应，增强了开发团队对测试效果的怀疑，同时开发团队也没有意识到自己其实就是质量形成的主体。
　　在这一过程中，我们建议在于，加强单元测试，不但可以消除一些可以在单元阶段可以消除的问题，而且可以通过在单元和系统阶段使用相同的工具，这样，即使是瀑布式的开发方式，系统测试技术也能及早的加以验证，提高可用性；加强系统需求分析和架构设计，是系统架构强内聚、弱耦合、接口明确，提高系统的可测试性；在系统开发的早期，测试人员作为系统开发团队的重要部分，参与系统设计流程，解决测试相关问题（有那些问题，RUP中有详述），为测试对设计提出要求；加强软件开发过程的管理，为测试提供清晰明确的需求和架构；

6.3. 分阶段测试提高测试效率

　　在这样的嵌入式系统开发团队中，建立了在经典测试理论体系中包含的静态分析，单元测试，集成测试，系统测试的测试工作和相应的配套的自动化工具，对各种测试的责任人有认识上的理解和划分，有一些测试过程中需要的和产生相关文档，对测试流程有一些零散的制度和自发的实施行为。
　　我们也应该看到，在这样的组织中，常常存在由于不恰当的对单元测试的理解，导致为覆盖率而编写测试用例的倾向，促使开发人员认为单元测试流于形式，没有实际作用；对单元测试的不理解，根据代码编写用例的工作方式，从态度上滋生的抵触情绪，认为单元测试和单元测试工具是增加工作负担的形式主义；由于在设计时没有考虑测试的需要，测试人员也从未介入过设计工作，软件的可测试性需求得不到体现，甚至测试人员也认为良好的测试就应该是对开发毫无影响的测试；被测试的软件本身并不具备可测试性，使用多么昂贵的测试工具也很难发挥作用；对设计文档的需求，包括需求文档到详细的软件规格说明的需求得不到满足，开发人员也往往是更具模糊的、口头达成的设计开始编码；没有组织级别的测试体系和度量标准；测试行为和对工具的使用多出自于人为的自觉；工具散落在组织各处，项目间测试经验、甚至测试工具使用经验都得不到整理和传承；在组织内，没有人负责测试流程和测试工具支持的工作。

{{分页}}
　　在这一过程中，我们建议在于，建立基于组织的开发测试体系和辅助工具管理方式，制度化并通过使用工具帮助在组织中贯彻实施；大家可以参考rational的RUP统一过程的最佳实践，和Rational Method Composer定制和部署适合自己的工具；使用各类管理工具，对软件开发过程的基础管理实现尽可能高的自动化，使用IBM Rational ProjectConsole，将基础项目数据形象的展现管理者；重视软件测试团队的作用，在系统设计时，要理解和鼓励测试人员参与到早期设计的需要；测试人员积极介入系统的设计，提高对系统的把握能力，在系统设计时期，加入系统可测试性的属性，验证系统测试方法。

6.4. 完善的质量保证的活动

　　在这样的嵌入式系统开发团队中，作为一个单独的活动，建立的独立的V&V（验证和确认）的流程，通过验证评估各个开发阶段产出的工件的质量，包括各种形式的设计文档和工件，通过确认，评价各个开发阶段于对本阶段需求的符合程度，建立的对开发各个阶段完善的评估和反馈体制。
　
　　在这一过程中，我们建议在于，我们鼓励组织成员，将软件质量不要仅仅限于测试团队或仅仅某些过程，我们要力求引到组织迈向全过程质量管理之路；，检测仅仅是项目质量状态的审查和反馈的过程；我们可以将视野放在RUP的整个九个工作流程，从中提取我们可以采纳的提高质量的工作方法，和基于每个角色和每个任务的检查方式；加强系统的架构设计，建立高质量、易于维护、易于改进的体系架构；考虑采用迭代的设计方法，将强调早期文档的验证工作，转向到更强调对每个迭代结束以后的可执行系统的验证。

6.5. 基于组织的高质量的过程

　　在这样的嵌入式系统开发团队中，开发机构建立了完善的开发流程和各个阶段的管理手段。建立了基于软件开发全过程检测，力争在开发过程本阶段修正错误能力。组织对于质量的理解，已经从减少软件运行错误、加强软件测试、避免软件缺陷的一般性层面，发展到对整个软件开发生命周期的全过程质量管理；这样组织中的质量管理部门，主要负责开发流程的执行，并专门负责制定产品开发流程，他针对整个软件开发流程，关心的是怎样在软件开发生命周期中来保证好软件的质量。
　
　　在这一过程中，我们可以相互学习，来追逐软件开发过程管理的更高目标，从在开发过程中尽早发现与修正错误，进展到尽量预防错误的出现。通过对错误的分析，完善各阶段的检测手段，做到在本开发阶段发现及修正错误。这是软件过程改进的一项重要内容，是开发机构可以预期有一个高质量的产品及一个低成本、高效率的软件过程的重要标志。

6.6. 迭代开发持续测试保证软件质量

　　迭代式软件开发，能够有效控制项目风险、增加对项目控制能力、减少需求变更对项目的影响，实现持续的质量验证，实现测试技术的早期验证，提高软件的可测试性；保证持续地质量保证的实现。主要说明，所有的开发活动和工件都需要通过持续的测试和复审来检查质量。这意味着测试不仅仅是软件构建之后的一个阶段。测试是在整个迭代开发周期中执行的，每次都有一个不同的目标，依照RUP这是大家都知道的一个任务。例如，测试在精化阶段，可以集中在确认构架上，而在构建阶段中，测试可以集中在查找最重要的软件缺陷上。

6.7. 质量是一种文化

　　在这样的组织中，我们专注于我们的客户和客户的客户的价值，并以此为产品质量的最终衡量标准，了解软件交付的质量，不仅仅是软件会出多少个故障，这很重要，但不只是这些，更多的要帮助我们的用户了解最终客户业务的价值。
质量改进本质上是一种思维习惯问题。

七. 从上至下驱动质量

　　续保证质量要求管理和工作的付出，这些需要从领导高层至下驱动的，它要求领导和组织复杂事务的管理能力。质量改进本质上是一种思维习惯问题；当来自上层的管理人员在整个组织慢慢灌输质量文化时，质量就会渗透到每个项目中。
　　在这样一种文化中，工作会给管理人员提供极大的好处。他们不再必须考虑带有已知或未知缺陷而发货的产品运行可能的后果，。并且促使产生质量的严格过程、团队责任心和目标矩阵也创建了项目进度和质量的可预言性。与那些不断地重新确定项目范围，并且仍然错过期限的团队不同，高质量的团队可以精确地确定范围、估算和确定时间，并且顺利地在计划的经费和工期内交付。这样的开发体系，可以有助于你的产品的质量水平和产品功能有别于你的竞争对手。

八. 获得软件高质量的高收益

　　最重要的是，全过程的质量保证体系总是会比忽略考虑质量成本要低。事实上，提高产品质量基本上没有成本，如果你正确地做的话。
在国际上，随着软件质量保证理论及应用研究工作的不断深入，针对软件质量保证工作的工作重点也经历了如下发展历程：
　　1. 70年代以前，Ad-hoc testing，与调试没有区分；
　　2. 70年代末到80年代中期，测试基础理论和实用技术形成，软件测试作为软件质量保证（SQA）的主要手段和职能；
　　3. 80年代末到90年代中期，测试工具在质量和数量上不断增长，测试与SQA（注重于过程和质量监督）分离。注重于工具对测试效率的影响；SQA为另一专业领域。
　　4. 90年后期到目前，重新关注有效的过程管理对于软件测试的重要性，将软件工程视为软件测试的基础，或形成各种独立的测试模型、测试能力成熟度模型。
　　我们现在哪里呢？
　　高品质软件，需要完整的软件开发过程和整合的软件开发平台来共同铸就。IBM Rational软件开发平台，就是以各种国际标准和开放平台为基础，为嵌入式系统软件产品的开发和生产过程提供了前所未有的开发速度和质量保证。
　　本文的很多思想都来源于IBM developerWorks Web上的文章，对细节有兴趣的开发人员可以在此网站上浏览更多相关文章。IBM也提供了许多服务，帮助开发团队交付高质量软件。开发人员可以参加面对面和基于Web的培训课程，这些课程都通过IBM developerWorks Web门户，集中在工具使用和技巧改进上，并且专业服务咨询可以与开发团队一起创建定制质量实施计划，生成初始的项目评估、安装、指导、培训和维护。