嵌入式软件白盒测试技术

领测技术（EzTester）简介嵌入式软件白盒测试技术——第4代白盒测试方法的理论与实践ApprovedbyWAYNEWorkStudio

At2007/05/18讲师介绍讲师：WayneChan(wayne@ezT)任职经历曾在HW公司工作8年（1997～2004），先后担任测试技术经理、公司测试系统工程师、公司测试技术总架构师等职务，是HW公司白盒测试技术体系的缔造者。2005年~2007年，担任测试技术咨询专家，为众多公司提供测试技术专项咨询服务，帮助企业构建和推广测试技术体系。专业背景在嵌入式软件白盒测试领域拥有15年从业经验，具备丰富的测试技术背景和测试技术管理经验。从1997年开始主导HW公司交换机产品实践白盒测试，是国内较早在测试技术领域有研究的专家。主导HW公司白盒测试平台体系的研发，历经五年最终在全公司形成规模应用（超过5000人使用）业界第四代白盒测试方法的主要倡导者，该方法论已被维普资讯纳入科技文献检索，所涉及数项核心技术已申请美国专利。主导规划了CSE测试脚本语言和VcTester嵌入式软件白盒测试体系，其中CSE是中国第一个具备世界水平的脚本语言体系。2000年被派往印度主管测试工具合作项目，与印度infosys、BFL等公司开展合作，深入学习了印度软件业的测试技术和方法。目录课程介绍单元一：白盒测试基本概念单元二：嵌入式白盒测试遵循的理念-----------------------------------------单元三：嵌入式软件测试设计技术单元四：嵌入式软件测试评估技术单元五：第4代白盒测试方法单元六：如何组织嵌入式软件白盒测试<课后材料清单，选讲内容>本课程目标：理解白盒测试技术的演进过程与发展趋势深入理解嵌入式软件白盒测试的主要困难与解决对策掌握第四代白盒测试方法论，包括3个关键域、9个关键特征掌握如何实施嵌入式软件在线白盒测试？包括在线测试驱动、在线脚本桩、在线测试改进等掌握如何开展嵌入式软件的持续集成测试？掌握如何有效设计白盒测试用例，如何评价白盒测试的完备性?掌握如何对白盒测试问题进行分析，找出问题根源？掌握如何进行嵌入式软件白盒自动化测试规划和设计，确保测试脚本的持续重用了解业界都有哪些主流的嵌入式白盒测试工具，掌握如何选型？了解业界优秀公司嵌入式软件白盒测试的方法和经验学习目标课程难度偏高课程风格HighMiddleLow注重实践性两个重点做正确的事！正确的做事！目录白盒测试基本概念什么是白盒测试?白盒测试在研发全流程中的位置单元测试与集成测试是什么？不是什么？企业不做白盒测试的主要原因白盒测试三种境界为什么要做白盒测试？实施白盒测试的差异性验证白盒测试抽象模型嵌入式软件的白盒测试特点嵌入式白盒测试遵循的理念嵌入式软件测试设计技术嵌入式软件测试评估技术第4代白盒测试方法如何组织嵌入式软件白盒测试什么是白盒测试？白盒测试是一种“软件测试”狭义“软件测试”的定义1990年的IEEE/ANSI标准(IEEE/ANSI,1990[Std610.12-1990])：

在既定的状况条件下，运行一个系统或组件，观察记录结果，并对其某些方面进行评价的过程。1979年GlenfordJ.Myers在《TheArtofSoftwareTesting》中定义：软件测试是为了发现错误而运行程序的过程。广义“软件测试”由验证、确认、测试3个方面组成验证：检测软件开发的每个阶段、每个步骤的结果是否正确无误，是否与软件开发各阶段的要求或期望的结果相一致。验证意味着确保软件会正确无误地实现软件的需求，开发过程是沿着正确的方向进行的。确认：评估将要开发的软件产品是否正确无误、可行和有价值的。确认意味着确保一个待开发软件是正确无误的，是对软件开发构想的检测。测试：与狭义“软件测试”概念一致。V模型软件验证与确认（VerificationandValidation，简称V&V）验证针对各步骤的产品设计，确认针对预设的产品构想W模型W模型：全过程的、同步的、全方位的测试模型案例：SVVP计划任务什么是白盒测试？狭义的“白盒测试”包括：单元测试与集成测试广义的“白盒测试”包括：从设计、编码，再到单元测试、集成测试各阶段中针对可见源码的V&V活动代码检视（代码审查）属不属于白盒测试？软件编译报错后修改代码，属不属于白盒测试活动？白盒测试活动最早出现在哪个开发阶段？“白盒测试”是与“黑盒测试”相对的一个概念黑盒测试是被测代码不可见的测试，包括功能测试、验证测试等白盒测试是被测代码可见的测试，包括单元测试、集成测试、部分协议测试等白盒测试基本过程编写测试用例：查看修改变量，调用函数，验证测试结果查看代码覆盖率，改进测试设计生成正式的测试报告案例：D项目集成测试的困惑某固网产品D项目主要负责话务统计的实现，该项目在头脑灵活、精明强干的明星经理肖某带领下，各项工作都很出色，需求调研很深入，还借鉴了业界优秀的话统模型，正当D项目一帆风顺的运行到模块集成测试，肖经理突然发现：精心构造话统模型却难以测试。这种多业务分解，基于事务处理，又是多线索的统计模型很难按常规方法（甚至是调试方式）去测试，而略过集成测试直接做系统测试，就意味着要消耗大量精力在各种组合条件的测试用例设计，以及手工测试操作上。肖经理犯愁了，总觉得前面的项目运作缺了点什么…白盒测试在研发全流程中的位置白盒测试在研发全流程中的位置单元测试与集成测试是什么？不是什么？IPL对单元测试的描述单元测试是针对与其它部分隔的、独立的单元所展开的测试。在不同编程环境下单元的含义有所不同，比如在C语言中，被测单元是常规函数或子过程，在C++语言中，单元是指一个类，在Ada语言中单元是指函数或过程，或者是AdaPackage，而在4GL语言（如Delphi）中，单元还可以是一个菜单、按钮、某个显示单元等。单元测试：针对程序中基本组成部件的测试关注的被测单元应是分隔开的、独立的被测单元不只是函数对象也可是手工的、不可重复的测试单元测试不是：源码不可见的测试被测范围不确定的测试集成测试：比单元测试处于更高级别某些情况下，被测对象与单元测试无明显界限集成测试区别于单元测试主要是：被测对象的表现特征不同，及由此带来测试方法有所不同。企业不做单元测试的原因一个游戏：将小车开出谜宫语录在恰当的时间以恰当的方法做恰当的事情！孔夫子语录：IhearandIforget.IseeandIremember.IdoandIunderstand.讨论：白盒测试的问题与难题大家在做单元测试与集成测试过程中，都遇到过哪些问题？按重要性排序列出前10条。白盒测试三种境界混沌状态：只有零星白盒测试实践，缺少成功案例各成员对白盒测试普遍认识模糊大家都忙于救火，系统测试的投入尚无保障，代码级测试无投入有序状态：已有多个项目成功推行单元测试，已成可拷贝的活动有一批人对白盒测试具有清晰认识，领导层对实践的前景既不悲观，也不盲目乐观设立专门机构推动UT与IT，白盒测试活动也有流程保障少数项目有显著效果，多数项目稍有成效，个别项目是失败的自组织状态：时时测试、持续测试已成风气白盒测试已成员工的普遍行为与自发行为有所为有所不为白盒测试三种境界处于混沌状态贵在尝试！处于有序状态贵在坚持！处自组织状态贵在自知！子曰：吾十有五，而志于学，三十而立，四十而不惑，五十而知天命，六十而耳顺，七十从心所欲，不逾矩。为什么要做白盒测试？案例公司（ABC）遗留缺陷率：1～4BUG/KLOCUSA国防部（DOD）遗留缺陷率：0.01BUG/KLOC为什么要做白盒测试？一个比喻：清洗面包机为什么要做白盒测试？由CapersJones与McGraw-Hill的统计表明：若将问题发现、定位与解决都计算进去，单元测试效率最高，是集成测试的2倍，是系统测试的3倍。为什么要做白盒测试？白盒测试能较彻底解决编码阶段引入的问题需求分析概要设计详细设计编码单元测试集成测试系统测试验收测试实施白盒测试的差异性验证两个性质接近的项目（项目A与项目B），项目A没做正规白盒测试，仅拿调试当测试，项目B实施规范的白盒测试，这两项目结束时分别按问题根源对全部BUG作统计。从“白盒测试问题比例”与“逻辑问题比例”可看出：不做白盒测试必然导致大量问题漏测项目A：缺少规范的白盒测试项目B：规范测试案例：问题根源分析案例：ODC问题根源分析ODC来源于IBM，OrthogonalDefectClassification白盒测试抽象模型嵌入式软件的白盒测试特点开发语言以C语言为主体运行环境比较复杂（驻留于各式单板，与各种IO设备打交道）实时、多任务对于通信软件：代码量大、复杂程度高产品设计要为测试环境构造提供条件要挖掘所有潜力来提高测试设计的效率对于通信软件：测试体系要开放，与其它工具配合使用环境敏感效率苛刻目录白盒测试基本概念嵌入式白盒测试遵循的理念为什么尽早测试？为什么持续测试？在线测试驱动与在线测试桩在线测试设计、运行及改进白盒测试的粒度与可见性白盒、黑盒，抑或灰盒调试是不是测试？检视器的概念嵌入式软件测试设计技术嵌入式软件测试评估技术第4代白盒测试方法如何组织嵌入式软件白盒测试为什么尽早测试？阶段需求设计编码单元测试验收测试交付后维护纠正费早测试付出代价就越低案例：什么是持续测试？案例：一次测试与持续测试某通信产品在V1版本编码完成时，进行过规范的单元测试活动，之后V2、V3要不断增加功能、修改功能，就放弃单元测试了。当V3最后市场交付时统计发现，相对V1版本，代码修改量已达到40%。QA从其中两个模块随机抽取100个问题单做缺陷分析，结果发现：第一个模块有50%的问题是在V1版本单元测试结束后引入的，而另一模块也有30%问题是单元测试后引入的。为什么持续测试持续集成的典型特征是：写一点测一点

ObjectMentor：我们在做任何事情时（无论是写测试、写产品代码还是重构），都要保证系统能够一直运行。运行测试的间隔时间是秒或者分钟级的。即使是10分钟都太长了。反映了一种质量优先的策略微软的“每日构建”与“冒烟测试”IBM的“渐增Build测试”XP的持续集成、测试先行等实践持续集成对“软件稳定性”实现重用查错、改错的效率提高了被测系统随时可运行，可展现功能，降低风险时时可测试时时做测试案例：Joel测试案例：Joel测试——改进代码的12个步骤演示：在线测试演示：在线测试设计（在线测试驱动、在线测试桩）在线测试调试在线测试执行在线测试评估改进全局变量/函数：vd.xx类型定义：vt.xx/vt.struct.xx/vt.union.xx<演示材料的背景…>拉通测试小循环结果评估用例设计用例调试测试执行白盒测试的粒度与可见性关注函数接口还是关注函数内部代码行？考虑因素：测试设计的工作量用例维护的工作量是否必须基于接口做测试设计，还是基于代码行做设计？白盒、黑盒，抑或灰盒白盒测试设计形式对照源码编写测试用例看到哪行覆盖，哪行未覆盖，来优化测试用例对照源码调试测试用例，并定位测试问题依照源码维护测试用例黑盒测试操作方式依据设计规格用例脚本只关注测试运行环境与输入输出接口一键运行，没有单步跟踪调试是不是测试？调试与测试的共性目的：查错或确认无错构造运行环境：配置数据、修改变量、模拟桩判别是否预期：过程表现、结果表现调试与测试的差异可重复性粒度与可维护性3个概念：调试、检视、测试检视器检视器介于调试器与测试器之间是一种提供脚本化控制的调试器也是一种提供调试功能的测试脚本生成器观察控制点（PointsofControlandObservation，PCO）位于被测单元的上下层之间具有调试断点的功能支持调试操作自动生成测试脚本演示：检视器演示：检视器的主要功能目录白盒测试基本概念嵌入式白盒测试遵循的理念嵌入式软件测试设计技术白盒测试的3类形式化表述语言映射技术三种测试设计模式一次性集成与增殖集成测试设计与产品设计的耦合关系测试脚本如何自动生成为什么要TDD？TDD三原则嵌入式软件测试评估技术第4代白盒测试方法如何组织嵌入式软件白盒测试白盒测试的3类形式化表述原生表述（CppUnit、JUnit、CodeTest）转化表述（ParasoftC++Test、RTRT、Cantata++）映射表述（VcTester）编写C测试代码编译连接执行测试测试评估编译连接执行测试测试评估编写测试脚本并转化成C代码语法分析编译连接执行测试分析测试编写测试脚本案例：CppUnit与RTRT的测试用例案例：CppUnit与RTRT的测试用例案例：TCL命令字注册案例：使用TCL命令字注册发起单元测试使用Tcl_CreateCommand注册被测C函数，使用Tcl_GetVar与Tcl_SetVar存取变量。比如将C函数MyFunc注册为TCL的扩展命令TCL_MyFunc：Tcl_CreateCommand(interp,“TCL_Myfunc",Myfunc,NULL,NULL);语言映射技术全局变量/函数：vd.xx类型定义：vt.xx/vt.struct.xx/vt.union.xx语言映射技术A函数B函数C函数脚本桩函数B函数A函数B函数C函数A函数B函数C函数脚本桩函数打脚本桩之前替代模式打桩插入模式打桩演示：C语言映射到CSE脚本演示：C语言映射到CSE脚本演示：3种测试设计模式演示：3种测试设计模式仿真模式点控制模式混合模式

一次性集成与增殖集成一次性集成增殖集成（自顶向下、自底向上、混合方式）优点缺点自顶向下测试

可以自然地做到逐步求精，一开始便能让测试者看到系统的框架

需要提供桩模块在输入/输出模块接入系统以前，在桩模块中表示测试数据有一定困难模拟测试数据困难观察和解释测试输出往往也是困难的

自底向上测试

构造测试数据比较容易测试中较少模拟桩函数特别适合于关键模块在结构图的底部的情况

直到最后一个模块被加进去之后才能看到整个程序（系统）的框架

只有到测试过程的后期才能发现时序问题和资源竞争问题测试设计与产品设计的耦合关系紧耦合的需求：测试重用，参考引用，结构化封装松耦合的需求：用例维护，版本发布，隔离BUG紧耦合模式分离模式松耦合模式XUNITRTRTVcTester演示：分离模式的应用实例演示：分离模式的应用实例案例：ParasoftC++Test的脚本生成案例：ParasoftC++Test的脚本自动生成（Source模式）ObjListiMaxNULL0Normal1-1MaxIntMinIntvoidBubbleSort(OBJ_DATA_PTRObjList,intiMax)Obj1Obj2NULLNULLNormalNormalint__stdcallObjCompare(OBJ_DATA*Obj1,OBJ_DATA*Obj2)案例：ParasoftC++Test的脚本生成案例：ParasoftC++Test的脚本自动生成（Native模式）什么脚本能生成，什么不能？图灵停机与图灵测试测试脚本自动生成依据什么？什么测试脚本能自动生成，什么不能生成？演示：VcTester的测试脚本自动生成演示：VcTester的测试脚本自动生成什么是TDD?《ExtremeProgrammingApplied》：Beforeyouwritecode,thinkaboutwhatitwilldo.Writeatestthatwillusethemethodsyouhaven’tevenwrittenyet.在编写代码前设计测试用例Atestisnotsomethingyou“do”,itissomethingyou“write”andrunonce,twice,threetimes,etc.测试驱动开发Test-DrivenDevelopment（测试指示开发）“指示”意味着：测试为片断代码提供使用规格也隐含“测试即设计文档”这个饱受争议的论题TDD操作步骤编写测试用例编译修正编译错误运行测试用例，看它报错修改代码运行测试用例，看它通过重构代码

并测试为什么要TDD？实施TDD的深刻原因一次好测试：既测试可见代码，也测试不可见代码一次好测试：是基于规格的测试，而不是“机械测试”案例：AnInitialInvestigationofTestDrivenDevelopmentinIndustry如何实施TDD？实施TDD的难点克服未见代码先写用例的恐慌提高TDD中编码与调试的效率案例：ObjectMentor–TDD三条军规

1.除非为了使一个失败的unittest通过，否则不允许编写任何产品代码

2.在一个单元测试中只允许编写刚好能够导致失败的内容（编译错误也算)3.只允许编写刚好能够使一个失败的unittest通过的产品代码演示：第4代白盒方法的TDD实践演示：第4代白盒方法的TDD实践讨论：测试先行、持续集成、冒烟测试测试先行（TDD）、持续集成、冒烟测试，这3者之间有什么关系？目录白盒测试基本概念嵌入式白盒测试遵循的理念嵌入式软件测试设计技术嵌入式软件测试评估技术常用覆盖率统计标准基于调用的覆盖率统计技术如何选择覆盖率标准用例覆盖度缺陷密度评估白盒测试问题管理第4代白盒测试方法如何组织嵌入式软件白盒测试常用覆盖率统计标准语句覆盖（Statement

Coverage

）判定覆盖（Decision

Coverage

）

条件覆盖（Condition

Coverage

）多条件覆盖（Multiple

Condition

Coverage

）

判定条件组合覆盖（Condition/Decision

Coverage

）

修正条件/判定覆盖（Modified

Condition/Decision

Coverage，MCDC）路径覆盖（Path

Coverage

）

基于调用的覆盖率统计技术位置无关调用覆盖（Location-independentcallcoverage）

LICC=(已覆盖的不重复的函数调用个数/全部不重复的函数调用个数)*100%位置相关调用覆盖率（Location-dependentcallcoverage

）

LDCC=(已覆盖的函数调用个数/全部函数调用个数)*100%比如某函数中调用了3个子函数，其中第1个子函数调用在函数定义的两个地方出现，其余2个子函数都只在一处调用（即，只使用了一次）。如果这个3个子函数都被调用过，而且第1个子函数只一个位置调用了，另一个位置尚未覆盖到。这时，我们计算LICC是“3/3=100%”，而LDCC是“3/4=75%”。演示：覆盖率定制的一个实例演示：覆盖率定制的一个实例如何选择覆盖率标准？是不是选择覆盖率标准越高越好？持续集成对覆盖率指标有哪些要求？选择恰如其分的评估标准避免源码中“噪声”给质量评估带来波动语句覆盖判定覆盖条件覆盖判定条件覆盖MCDC覆盖LCSAJ覆盖路径覆盖用例覆盖度为什么引入用例覆盖度(TestCaseCoverage)？定义

TCC=用例中调用被测函数的总次数/函数定义的分支总数函数分支总数=1+if语句总数*2+while语句总数*2+for语句总数*2用例覆盖度的价值弥补代码覆盖率的评估欠缺评估标准可定制演示：TCC定制实例缺陷密度评估缺陷密度定义：发现问题数/千行代码主要评估指标缺陷密度遗留缺陷密度测试用例密度回归测试通过率

DI值=(致命问题*10+严重问题*3+一般问题*1+提示问题*0.1)*难度系数是否符合Compertz退出准则案例：研发Metrics质量体系白盒测试问题管理流程测试开发管理三方会议开启分派设计变更分派解决符合设计不用解决延迟解决关闭ODC缺陷分析触发因素问题发现活动验证开发开发验证结果影响严重程度原因结果定位责任来源问题位置缺陷年龄缺陷类型内容类型缺陷界定问题根源对象ODC缺陷分析检视发现的主要是一般问题压力测试发现一个致命问题缺陷根源分析一种系统的解决问题的方法，通过标示问题，分析问题的根本原因，针对根本原因制定可行的纠正预防措施，以达到解决问题和预防问题再次发生的目的标识问题根本原因分析制定纠正预防措施Rayleigh分析方法目录白盒测试基本概念嵌入式白盒测试遵循的理念嵌入式软件测试设计技术嵌入式软件测试评估技术第4代白盒测试方法白盒测试要遵循的原则嵌入式白盒测试的核心难题是什么？分区推动理论白盒测试发展历程：从第1代到第4代3个关键域与9项关键特征红绿灯通行机制测试小循环融入研发大循环白盒测试技术的演进没有银弹—除了重用还是重用如何组织嵌入式软件白盒测试白盒测试要遵循的原则Good-enough原则Zero-bug&Good-enough投入&产出Pareto原则（20/80原则）全方位、多角度嵌入式白盒测试的核心难题是什么？测试效率问题测试质量问题第4代白盒测试方法着重解决这两个问题！另外着眼于保障白盒测试是易操作、易推行的。环境敏感效率苛刻分区推动理论测试同比：在恒定质量前提下，每新增1KLOC代码所需开发投入，与新增用例设计的投入之比例低效1:2，一般1:1，很好2:1拐点：1:1混沌状态有序状态自组织状态白盒测试技术发展历程第一代白盒测试方法测试操作不规范、不可重复，无测试评估print/assert/拿调试当测试第二代白盒测试方法形式化描述用例并阶段重用，有覆盖评估RTRT/CppTest/CodeTest/TrueCoverages等工具第三代白盒测试方法坚持质量优先的可持续测试（写一点测一点）xUnit工具第四代白盒测试方法软件调测完全高效的融入研发全过程VcTester/GccTester测试设计效率低下全脚本语言、调测一体、突破效率瓶颈白盒测试技术演进第2代区别第1代，主要克服两大缺陷：没有测试评估（比如覆盖率）测试操作不可重复第3代区别第2代，增加了：对持续集成运作模式的支持第4代区别第3代，在于：强调对调试操作的重用3个关键域9项关键特征第一关键域：在线测试在线测试驱动在线脚本桩在线测试用例设计、运行，及评估改进第二关键域：灰盒调测基于调用接口调试即测试集编码、调试、测试于一体第三关键域：持续测试测试设计先行持续保障信心重构测试设计3个关键域9项关键特征第一关键域：在线测试在线测试驱动在线脚本桩在线测试用例设计、运行，及评估改进第二关键域：灰盒调测基于调用接口调试即测试集编码、调试、测试于一体第三关键域：持续测试测试设计先行持续保障信心重构测试设计测试效率易操作/易推行测试质量演示：集成调测平台演示：集成化的编辑、调试与测试平台演示：红绿灯通行机制演示：红绿灯通行机制拉通研发大循环结果评估用例设计用例调试测试执行问题定位编码/改错源码调试结果评估调试(源码与脚本)产品发布运行编码/改错(源码与脚本)自动测试运行白盒测试技术演进是否评估测试效果是否自动测试是否持续测试是否调测一体第1代白盒测试方法否否否否第2代白盒测试方法是是否否第3代白盒测试方法是是是否第4代白盒测试方法是是是是测试操作重用稳定性重用调试过程重用软件测试的银弹没有银弹（布鲁克斯，1986年）在近十年内，没有任何单独的软件工程进展可以使软件生产率有数量级的提高大家熟悉的软件项目具有一些人狼的特性（至少在非技术经理看来），常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。因此，我们听到了近乎绝望的寻求银弹的呼唤，寻求一种可以使软件成本像计算机硬件成本一样降低的尚方宝剑。人月神话（查珀尔希尔，1986年）软件开发总是非常困难的，天生就没有银弹。想想现代软件系统中这些无法规避的内在特性吧：复杂度、一致性、可变性和不可见性。软件测试的银弹StandishGroup的研究StandishGroup从1994年开始用了10年时间，研究了大约3万5千个开发项目，他们定义成功的项目：软件开发按时完成预算未超出软件功能涵盖了预定需求软件没有被缺陷致残软件已被使用，且产生了积极的效果最初的结果显示：只有16%的项目是成功的，而且他们每年都更新这一统计，发现之后该比例并没有太大改变。软件测试的银弹：除了重用，还是重用！目录白盒测试基本概念嵌入式白盒测试遵循的理念嵌入式软件测试设计技术嵌入式软件测试评估技术第4代白盒测试方法如何组织嵌入式软件白盒测试与白盒测试相关的前期开发活动是开发人员做单元测试还是测试人员做？白盒测试活动中的角色与配合关系规划白盒测试注意事项仿真层中间件如何构造？持续集成的体系架构持续集成、每日构建、冒烟测试之间的关系与白盒测试相关的前期开发活动可测试性需求分析测试策略拟定SVVP计划制定测试工具选型评估可测试性设计测试设计白盒测试是一项系统工程！白盒测试活动中的角色单元测试与集成测试该由谁来实施？人员组织与角色项目经理QATC开发人员开发人员开发人员测试经理QA测试系统工程师自动化工程师测试人员测试人员规划白盒测试的几点注意事项注重前期规划避免在目标系统（单板）做单元测试有所为有所不为，难以实施白盒测试应以其它测试手段（如代码检视、设计评审等）弥补先推单元测试，后推集成测试注意测试设计的重用依据实践的推论嵌入式软件的单元测试及底层的集成测试，应在仿真平台进行集成测试，尤其是基于消息驱动、组件调用，或者定义简洁上下层接口的测试，可以在真实平台下进行受限于实际环境，未能详尽做单元或集成测试的，应加强其它类型测试予以弥补。单元测试----调试/代码正规检视/lint检查集成测试----调试/设计评审上单板做白盒测试的主要弱点测试成本高（搭建测试环境、调试与测试麻烦）面对初始代码，代码不稳定导致上单板效率低下上单板的测试常混杂了集成测试的需求由于嵌入式平台的多样性，通常缺乏有效的测试工具要求前期PCB较多投板一个典型的仿真层中间件底层接口任务管理队列管理内存管理日志管理维护管理配置管理接口管理补丁管理测试接口应用层接口手机产品PDA产品宽带产品数通产品PSOSVXWORKSUNIXWIN98NTINTELCPUPPCCPUARMCPUVOS平台无线产品持续集成的体系架构持续集成、每日构建、冒烟测试的关系时时使用