嵌入式软件白盒测试技术PPT.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,领测技术（,E,z,Tester,）简介,嵌入式软件白盒测试技术,第,4,代白盒测试方法的理论与实践,Approved by WAYNE Work StudioAt 2007/05/18,1,讲师介绍,讲师：,Wayne Chan (wayneezT),任职经历,曾在,HW,公司工作,8,年（,1997,2004,），先后担任测试技术经理、公司测试系统工程师、公司测试技术总架构师等职务，是,HW,公司白盒测试技术体系的缔造者。,2005,年,2007,年，担任测试技术咨询专家，为众多公司提供测试技术专项咨询服务，帮助企业构建和推广测试技术体系。,专业背景,在嵌入式软件白盒测试领域拥有,15,年从业经验，具备丰富的测试技术背景和测试技术管理经验。,从,1997,年开始主导,HW,公司交换机产品实践白盒测试，是国内较早在测试技术领域有研究的专家。,主导,HW,公司白盒测试平台体系的研发，历经五年最终在全公司形成规模应用（超过,5000,人使用）,业界第四代白盒测试方法的主要倡导者，该方法论已被维普资讯纳入科技文献检索，所涉及数项核心技术已申请美国专利。,主导规划了,CSE,测试脚本语言和,VcTester,嵌入式软件白盒测试体系，其中,CSE,是中国第一个具备世界水平的脚本语言体系。,2000,年被派往印度主管测试工具合作项目，与印度,infosys,、,BFL,等公司开展合作，深入学习了印度软件业的测试技术和方法。,2,目录,课程介绍,单元一：白盒测试基本概念,单元二：嵌入式白盒测试遵循的理念,-,单元三：嵌入式软件测试设计技术,单元四：嵌入式软件测试评估技术,单元五：第,4,代白盒测试方法,单元六：如何组织嵌入式软件白盒测试,3,本课程目标：,理解白盒测试技术的演进过程与发展趋势,深入理解嵌入式软件白盒测试的主要困难与解决对策,掌握第四代白盒测试方法论，包括3个关键域、9个关键特征,掌握如何实施嵌入式软件在线白盒测试？包括在线测试驱动、在线脚本桩、在线测试改进等,掌握如何开展嵌入式软件的持续集成测试？,掌握如何有效设计白盒测试用例，如何评价白盒测试的完备性?,掌握如何对白盒测试问题进行分析，找出问题根源？,掌握如何进行嵌入式软件白盒自动化测试规划和设计，确保测试脚本的持续重用,了解业界都有哪些主流的嵌入式白盒测试工具，掌握如何选型？,了解业界优秀公司嵌入式软件白盒测试的方法和经验,学习目标,4,课程难度偏高,课程风格,High,Middle,Low,注重实践性,5,两个重点,做正确的事！,正确的做事！,6,目录,白盒测试基本概念,什么是白盒测试,?,白盒测试在研发全流程中的位置,单元测试与集成测试是什么？不是什么？,企业不做白盒测试的主要原因,白盒测试三种境界,为什么要做白盒测试？,实施白盒测试的差异性验证,白盒测试抽象模型,嵌入式软件的白盒测试特点,嵌入式白盒测试遵循的理念,嵌入式软件测试设计技术,嵌入式软件测试评估技术,第,4,代白盒测试方法,如何组织嵌入式软件白盒测试,7,什么是白盒测试？,白盒测试是一种“,软件测试,”,狭义“,软件测试,”的定义,1990,年的,IEEE/ANSI,标准,(IEEE/ANSI,1990 Std 610.12-1990),：,在既定的状况,条件下，运行一个系统或组件，观察记录结果，并对其某些方面进行评价的过程。,1979,年,Glenford J.Myers,在,The Art of Software Testing,中定义：,软件测试是,为了发现错误,而,运行程序,的过程。,广义“,软件测试,”由验证、确认、测试,3,个方面组成,验证,：检测软件开发的每个阶段、每个步骤的结果是否正确无误，是否与软件开发各阶段的要求或期望的结果相一致。验证意味着确保软件会正确无误地实现,软件的需求,，开发过程是沿着正确的方向进行的。,确认,：评估将要开发的软件产品是否正确无误、可行和有价值的。确认意味着确保一个待开发软件是正确无误的，是对软件,开发构想,的检测。,测试,：与狭义“软件测试”概念一致。,8,V,模型,软件验证与确认（,Verification and Validation,，简称,V&V,）,验证针对各步骤的产品设计，确认针对预设的产品构想,9,W,模型,W,模型：全过程的、同步的、全方位的测试模型,10,案例：,SVVP,计划任务,11,什么是白盒测试？,狭义的“,白盒测试,”包括：单元测试与集成测试,广义的“,白盒测试,”包括：从设计、编码，再到单元测试、集成测试各阶段中针对可见源码的,V&V,活动,代码检视（代码审查）属不属于白盒测试？,软件编译报错后修改代码，属不属于白盒测试活动？,白盒测试活动最早出现在哪个开发阶段？,“白盒测试”是与“黑盒测试”相对的一个概念,黑盒测试是被测代码不可见的测试，包括功能测试、验证测试等,白盒测试是被测代码可见的测试，包括单元测试、集成测试、部分协议测试等,白盒测试基本过程,编写测试用例：查看修改变量，调用函数，验证测试结果,查看代码覆盖率，改进测试设计,生成正式的测试报告,12,案例：,D,项目集成测试的困惑,某固网产品,D,项目主要负责话务统计的实现，该项目在头脑灵活、精明强干的明星经理肖某带领下，各项工作都很出色，需求调研很深入，还借鉴了业界优秀的话统模型，正当,D,项目一帆风顺的运行到模块集成测试，肖经理突然发现：精心构造话统模型却难以测试。,这种多业务分解，基于事务处理，又是多线索的统计模型很难按常规方法（甚至是调试方式）去测试，而略过集成测试直接做系统测试，就意味着要消耗大量精力在各种组合条件的测试用例设计，以及手工测试操作上。,肖经理犯愁了，总觉得前面的项目运作缺了点什么,13,白盒测试在研发全流程中的位置,14,白盒测试在研发全流程中的位置,15,单元测试与集成测试是什么？不是什么？,IPL,对单元测试的描述,单元测试是针对与其它部分隔的、独立的单元所展开的测试。在不同编程环境下单元的含义有所不同，比如在,C,语言中，被测单元是常规函数或子过程，在,C+,语言中，单元是指一个类，在,Ada,语言中单元是指函数或过程，或者是,Ada Package,，而在,4GL,语言（如,Delphi,）中，单元还可以是一个菜单、按钮、某个显示单元等。,单元测试：,针对程序中基本组成部件的测试,关注的被测单元应是分隔开的、独立的,被测单元不只是函数对象,也可是手工的、不可重复的测试,单元测试不是：,源码不可见的测试,被测范围不确定的测试,集成测试：,比单元测试处于更高级别,某些情况下，被测对象与单元测试无明显界限,集成测试区别于单元测试主要是：被测对象的表现特征不同，及由此带来测试方法有所不同。,16,企业不做单元测试的原因,17,一个游戏：将小车开出谜宫,18,语录,在恰当的时间以恰当的方法做恰当的事情！,孔夫子语录：,I hear and I forget.I see and I remember.I do and I understand.,19,讨论：白盒测试的问题与难题,大家在做单元测试与集成测试过程中，都遇到过哪些问题？按重要性排序列出前,10,条。,20,白盒测试三种境界,混沌状态：,只有零星白盒测试实践，缺少成功案例,各成员对白盒测试普遍认识模糊,大家都忙于,救火,，系统测试的投入尚无保障，代码级测试无投入,有序状态：,已有多个项目成功推行单元测试，已成可拷贝的活动,有一批人对白盒测试具有清晰认识，领导层对实践的前景既不悲观，也不盲目乐观,设立专门机构推动,UT,与,IT,，白盒测试活动也有流程保障,少数项目有显著效果，,多数项目稍有成效,，个别项目是失败的,自组织状态：,时时测试、持续测试已成风气,白盒测试已成员工的,普遍行为与自发行为,有所为有所不为,21,白盒测试三种境界,处于混沌状态贵在,尝试！,处于有序状态贵在,坚持！,处自组织状态贵在,自知！,子曰：吾十有五，而,志于学,，三十而立，四十而,不惑,，五十而知天命，六十而耳顺，七十,从心所欲，不逾矩。,22,为什么要做白盒测试？,案例公司（,ABC,）遗留缺陷率：,1,4BUG/KLOC,USA,国防部（,DOD,）,遗留缺陷率：,0.01BUG/KLOC,23,为什么要做白盒测试？,一个比喻：清洗面包机,24,为什么要做白盒测试？,由,Capers Jones与McGraw-Hill,的统计表明：若将问题发现、定位与解决都计算进去，,单元测试效率最高，是集成测试的,2,倍，是系统测试的,3,倍,。,25,为什么要做白盒测试？,白盒测试能较彻底解决编码阶段引入的问题,需求分析,概要设计,详细设计,编码,单元测试,集成测试,系统测试,验收测试,26,实施白盒测试的差异性验证,两个性质接近的项目（项目,A,与项目,B,），项目,A,没做正规白盒测试，仅拿调试当测试，项目,B,实施规范的白盒测试，这两项目结束时分别按问题根源对全部,BUG,作统计。,从“白盒测试问题比例”与“逻辑问题比例”可看出：,不做白盒测试必然导致大量问题漏测,项目,A,：缺少规范的白盒测试,项目,B,：规范测试,27,案例：问题根源分析,案例：,ODC,问题根源分析,ODC,来源于,IBM,，,Orthogonal Defect Classification,28,白盒测试抽象模型,29,嵌入式软件的白盒测试特点,开发语言以,C,语言为主体,运行环境比较复杂（驻留于各式单板，与各种,IO,设备打交道）,实时、多任务,对于通信软件：代码量大、复杂程度高,产品设计要为测试环境构造提供条件,要挖掘所有潜力来提高测试设计的效率,对于通信软件：测试体系要开放，与其它工具配合使用,环境敏感,效率苛刻,30,目录,白盒测试基本概念,嵌入式白盒测试遵循的理念,为什么尽早测试？,为什么持续测试？,在线测试驱动与在线测试桩,在线测试设计、运行及改进,白盒测试的粒度与可见性,白盒、黑盒，抑或灰盒,调试是不是测试？,检视器的概念,嵌入式软件测试设计技术,嵌入式软件测试评估技术,第,4,代白盒测试方法,如何组织嵌入式软件白盒测试,31,为什么尽早测试？,阶段,需求,设计,编码,单元测试,验收测试,交付后维护,纠正费用,1,5,10,20,50,200,越早测试付出代价就越低,32,案例：什么是持续测试？,案例：一次测试 与 持续测试,某通信产品在,V1,版本编码完成时，进行过规范的单元测试活动，之后,V2,、,V3,要不断增加功能、修改功能，就放弃单元测试了。,当,V3,最后市场交付时统计发现，相对,V1,版本，代码修改量已达到,40%,。,QA,从其中两个模块随机抽取,100,个问题单做缺陷分析，结果发现：第一个模块有,50%,的问题是在,V1,版本单元测试结束后引入的，而另一模块也有,30%,问题是单元测试后引入的。,33,为什么持续测试,持续集成的典型特征是：写一点测一点,Object Mentor,：我们在做任何事情时（无论,是写测试、写产品代码还是重构），都要保,证系统能够一直运行。运行测试的间隔时间,是秒或者分钟级的。即使是,10,分钟都太长了。,反映了一种质量优先的策略,微软的“每日构建”与“冒烟测试”,IBM,的“渐增,Build,测试”,XP,的持续集成、测试先行等实践,持续集成对“软件稳定性”实现重用,查错、改错的效率提高了,被测系统随时可运行，可展现功能，降低风险,时时可测试,时时做测试,34,案例：,Joel,测试,案例：,Joel,测试,改进代码的,12,个步骤,35,演示：在线测试,演示：,在线测试设计（在线测试驱动、在线测试桩）,在线测试调试,在线测试执行,在线测试评估改进,全局变量,/,函数：,vd.xx,类型定义：,vt.xx/vt.struct.xx/vt.union.xx,36,拉通测试小循环,结果评估,用例设计,用例调试,测试执行,37,白盒测试的粒度与可见性,关注函数接口还是关注函数内部代码行？考虑因素：,测试设计的工作量,用例维护的工作量,是否必须,基于接口做测试设计，还是基于代码行做设计？,38,白盒、黑盒，抑或灰盒,白盒测试设计形式,对照源码编写测试用例,看到哪行覆盖，哪行未覆盖，来优化测试用例,对照源码调试测试用例，并定位测试问题,依照源码维护测试用例,黑盒测试操作方式,依据设计规格,用例脚本只关注测试运行环境与输入输出接口,一键运行，没有单步跟踪,39,调试是不是测试？,调试与测试的共性,目的：查错或确认无错,构造运行环境：配置数据、修改变量、模拟桩,判别是否预期：过程表现、结果表现,调试与测试的差异,可重复性,粒度与可维护性,3,个概念：调试、检视、测试,40,检视器,检视器介于调试器与测试器之间,是一种提供脚本化控制的调试器,也是一种提供调试功能的测试脚本生成器,观察控制点（,Points of Control and Observation,，,PCO,）,位于被测单元的上下层之间,具有调试断点的功能,支持调试操作自动生成测试脚本,41,演示：检视器,演示：检视器的主要功能,42,目录,白盒测试基本概念,嵌入式白盒测试遵循的理念,嵌入式软件测试设计技术,白盒测试的,3,类形式化表述,语言映射技术,三种测试设计模式,一次性集成与增殖集成,测试设计与产品设计的耦合关系,测试脚本如何自动生成,为什么要,TDD,？,TDD,三原则,嵌入式软件测试评估技术,第,4,代白盒测试方法,如何组织嵌入式软件白盒测试,43,白盒测试的,3,类形式化表述,原生表述（,CppUnit,、,JUnit,、,CodeTest,）,转化表述（,P,arasoft C+Test,、,RTRT,、,Cantata+,）,映射表述（,VcTester,）,编写,C,测试代码,编译连接,执行测试,测试评估,编译连接,执行测试,测试评估,编写测试脚本并,转化成,C,代码,语法分析,编译连接,执行测试,分析测试,编写测试脚本,44,案例：,CppUnit,与,RTRT,的测试用例,案例：,CppUnit与RTRT的测试用例,45,案例：,TCL,命令字注册,案例：使用,TCL命令字注册,发起单元测试,使用,Tcl_CreateCommand,注册被测,C,函数，使用,Tcl_GetVar,与,Tcl_SetVar,存取变量。,比如将,C,函数,MyFunc,注册为,TCL,的扩展命令,TCL_MyFunc,：,Tcl_CreateCommand(interp,“TCL_Myfunc,Myfunc,NULL,NULL);,46,语言映射技术,全局变量,/,函数：,vd.xx,类型定义：,vt.xx/vt.struct.xx/vt.union.xx,47,语言映射技术,A,函数,B,函数,C,函数,脚本桩函数,B,函数,A,函数,B,函数,C,函数,A,函数,B,函数,C,函数,脚本桩函数,打脚本桩之前 替代模式打桩 插入模式打桩,48,演示：,C,语言映射到,CSE,脚本,演示：,C语言映射到CSE脚本,49,演示：,3,种测试设计模式,演示：,3,种测试设计模式,仿真模式,点控制模式,混合模式,50,一次性集成与增殖集成,一次性集成,增殖集成（自顶向下、自底向上、混合方式）,优点,缺点,自顶向下测试,可以自然地做到逐步求精，一开始便能让测试者看到系统的框架,需要提供桩模块,在输入,/,输出模块接入系统以前，在桩模块中表示测试数据有一定困难,模拟测试数据困难,观察和解释测试输出往往也是困难的,自底向上测试,构造测试数据比较容易,测试中较少模拟桩函数,特别适合于关键模块在结构图的底部的情况,直到最后一个模块被加进去之后才能看到整个程序（系统）的框架,只有到测试过程的后期才能发现时序问题和资源竞争问题,51,测试设计与产品设计的耦合关系,紧耦合的需求：测试重用，参考引用，结构化封装,松耦合的需求：用例维护，版本发布，隔离,BUG,紧耦合模式,分离模式,松耦合模式,XUNIT,RTRT,VcTester,52,演示：分离模式的应用实例,演示：分离模式的应用实例,53,案例：,Parasoft C+Test,的脚本生成,案例：,Parasoft C+Test的脚本自动生成,（,Source,模式）,ObjList,iMax,NULL,0,Normal,1,-1,MaxInt,MinInt,void BubbleSort(OBJ_DATA_PTR ObjList,int iMax),Obj1,Obj2,NULL,NULL,Normal,Normal,int _stdcall ObjCompare(OBJ_DATA*Obj1,OBJ_DATA*Obj2),54,案例：,Parasoft C+Test,的脚本生成,案例：,Parasoft C+Test的脚本自动生成,（,Native,模式）,55,什么脚本能生成，什么不能？,图灵停机与图灵测试,测试脚本自动生成依据什么？,什么测试脚本能自动生成，什么不能生成？,56,演示：,VcTester,的测试脚本自动生成,演示：VcTester,的,测试脚本自动生成,57,什么是,TDD?,Extreme Programming Applied,：,Before you write code,think about what it will do.Write a test that will use the methods you havent even written yet.,在编写代码前设计测试用例,A,test,is not something you“do”,it is something you“write”and run once,twice,three times,etc.,测试驱动开发,Test-Driven Development,（测试指示开发）,“指示”意味着：,测试为片断代码提供使用规格,也隐含“测试即设计文档”这个饱受争议的论题,58,TDD,操作步骤,编写测试用例,编译,修正编译错误,运行测试用例，,看它报错,修改代码,运行测试用例，,看它通过,重构代码,并测试,59,为什么要,TDD,？,实施,TDD,的深刻原因,一次好测试：既测试可见代码，也测试不可见代码,一次好测试：是基于规格的测试，而不是“机械测试”,案例：,An Initial Investigation of Test Driven Development in Industry,60,如何实施,TDD,？,实施,TDD,的难点,克服未见代码先写用例的恐慌,提高,TDD,中编码与调试的效率,案例：,Object Mentor,TDD,三条军规,1.,除非为了使一个失败的,unit test,通过，否则不允许编写任何产品代码,2.,在一个单元测试中只允许编写刚好能够导致失败的内容（编译错误也算,),3.,只允许编写刚好能够使一个失败的,unit test,通过的产品代码,61,演示：第,4,代白盒方法的,TDD,实践,演示：,第,4,代白盒方法的,TDD,实践,62,讨论：测试先行、持续集成、冒烟测试,测试先行（,TDD,）、持续集成、冒烟测试，这,3,者之间有什么关系？,63,目录,白盒测试基本概念,嵌入式白盒测试遵循的理念,嵌入式软件测试设计技术,嵌入式软件测试评估技术,常用覆盖率统计标准,基于调用的覆盖率统计技术,如何选择覆盖率标准,用例覆盖度,缺陷密度评估,白盒测试问题管理,第,4,代白盒测试方法,如何组织嵌入式软件白盒测试,64,常用覆盖率统计标准,语句覆盖（,StatementCoverage,）,判定覆盖（,DecisionCoverage,）,条件覆盖（,ConditionCoverage,）,多条件覆盖（,MultipleConditionCoverage,）,判定条件组合覆盖（,Condition/DecisionCoverage,）,修正条件,/,判定覆盖,（,ModifiedCondition/DecisionCoverage,，,MCDC,）,路径覆盖（,PathCoverage,）,65,基于调用的覆盖率统计技术,位置无关调用覆盖（,Location-independent call coverage,）,LICC=(,已覆盖的不重复的函数调用个数,/,全部不重复的函数调用个数,)*100%,位置相关调用覆盖率（,Location-dependent call coverage,）,LDCC=(,已覆盖的函数调用个数,/,全部函数调用个数,)*100%,比如某函数中调用了,3,个子函数，其中第,1,个子函数调用在函数定义的两个地方出现，其余,2,个子函数都只在一处调用（即，只使用了一次）。如果这个,3,个子函数都被调用过，而且第,1,个子函数只一个位置调用了，另一个位置尚未覆盖到。这时，我们计算,LICC,是“,3/3=100%”,，而,LDCC,是“,3/4=75%”,。,66,演示：覆盖率定制的一个实例,演示：,覆盖率定制的一个实例,67,如何选择覆盖率标准？,是不是选择覆盖率标准越高越好？,持续集成对覆盖率指标有哪些要求？,选择恰如其分的评估标准,避免源码中“噪声”给质量评估带来波动,语句覆盖,判定覆盖,条件覆盖,判定条件覆盖,MCDC,覆盖,LCSAJ,覆盖,路径覆盖,68,用例覆盖度,为什么引入用例覆盖度,(Test Case Coverage),？,定义,TCC=,用例中调用被测函数的总次数,/,函数定义的分支总数,函数分支总数,=1+if,语句总数*,2+while,语句总数*,2+for,语句总数*,2,用例覆盖度的价值,弥补代码覆盖率的评估欠缺,评估标准可定制,演示：,TCC,定制实例,69,缺陷密度评估,缺陷密度定义：,发现问题数,/,千行代码,主要评估指标,缺陷密度,遗留缺陷密度,测试用例密度,回归测试通过率,DI,值,=(,致命问题*,10+,严重问题*,3+,一般问题*,1+,提示问题*,0.1)*,难度系数,是否符合,Compertz,退出准则,案例：研发,Metrics,质量体系,70,白盒测试问题管理流程,测试,开发,管理,三方会议,开启,分派,设计变更,分派,解决,符合设计,不用解决,延迟解决,关闭,71,ODC,缺陷分析,触发因素,问题发现活动,验证,开发,开发,验证,结果影响,严重程度,原因,结果,定位,责任来源,问题位置,缺陷年龄,缺陷类型,内容类型,缺陷界定,问题根源对象,72,ODC,缺陷分析,检视发现的主要是一般问题,压力测试发现一个致命问题,73,缺陷根源分析,一种系统的解决问题的方法，通过标示问题，分析问题的根本原因，针对根本原因制定可行的纠正预防措施，以达到解决问题和预防问题再次发生的目的,标识问题,根本原因分析,制定纠正,预防措施,74,Rayleigh,分析方法,75,目录,白盒测试基本概念,嵌入式白盒测试遵循的理念,嵌入式软件测试设计技术,嵌入式软件测试评估技术,第,4,代白盒测试方法,白盒测试要遵循的原则,嵌入式白盒测试的核心难题是什么？,分区推动理论,白盒测试发展历程：从第,1,代到第,4,代,3,个关键域与,9,项关键特征,红绿灯通行机制,测试小循环融入研发大循环,白盒测试技术的演进,没有银弹,除了重用还是重用,如何组织嵌入式软件白盒测试,76,白盒测试要遵循的原则,Good-enough,原则,Zero-bug&Good-enough,投入,&,产出,Pareto,原则（,20/80,原则）,全方位、多角度,77,嵌入式白盒测试的核心难题是什么？,测试效率问题,测试质量问题,第,4,代白盒测试方法着重解决这两个问题！,另外着眼于保障白盒测试是,易操作、易推行,的。,环境敏感,效率苛刻,78,分区推动理论,测试同比：,在恒定质量前提下，每新增,1KLOC,代码所需开发投入，与新增用例设计的投入之比例,低效,1:2,，一般,1:1,，很好,2:1,拐点：,1:1,混沌状态,有序状态,自组织状态,79,白盒测试技术发展历程,第一代白盒测试方法,测试操作不规范、不可重复，无测试评估,print/assert/,拿调试当测试,第二代白盒测试方法,形式化描述用例并阶段重用，有覆盖评估,RTRT/CppTest/CodeTest/TrueCoverages,等工具,第三代白盒测试方法,坚持质量优先的可持续测试（写一点测一点）,xUnit,工具,第四代白盒测试方法,软件调测完全高效的融入研发全过程,VcTester/GccTester,测试设计效率低下,全脚本语言、调测一体、突破效率瓶颈,80,白盒测试技术演进,第,2,代区别第,1,代，主要克服两大缺陷：,没有测试评估（比如覆盖率）,测试操作不可重复,第,3,代区别第,2,代，增加了：,对持续集成运作模式的支持,第,4,代区别第,3,代，在于：,强调对调试操作的重用,81,3,个关键域,9,项关键特征,第一关键域：在线测试,在线测试驱动,在线脚本桩,在线测试用例设计、运行，及评估改进,第二关键域：灰盒调测,基于调用接口,调试即测试,集编码、调试、测试于一体,第三关键域：持续测试,测试设计先行,持续保障信心,重构测试设计,82,3,个关键域,9,项关键特征,第一关键域：在线测试,在线测试驱动,在线脚本桩,在线测试用例设计、运行，及评估改进,第二关键域：灰盒调测,基于调用接口,调试即测试,集编码、调试、测试于一体,第三关键域：持续测试,测试设计先行,持续保障信心,重构测试设计,测试效率,易操作,/,易推行,测试质量,83,演示：集成调测平台,演示：,集成化的编辑、调试与测试平台,84,演示：红绿灯通行机制,演示：,红绿灯通行机制,85,拉通研发大循环,结果评估,用例设计,用例调试,测试执行,问题定位,编码,/,改错,源码调试,结果评估,调试,(,源码与脚本,),产品发布运行,编码,/,改错,(,源码与脚本,),自动测试运行,86,白盒测试技术演进,是否评估测试效果,是否自动测试,是否持续测试,是否调测一体,第,1,代白盒测试方法,否,否,否,否,第,2,代白盒测试方法,是,是,否,否,第,3,代白盒测试方法,是,是,是,否,第,4,代白盒测试方法,是,是,是,是,测试操作重用,稳定性重用,调试过程重用,87,软件测试的银弹,没有银弹（,布鲁克斯，,1986,年,）,在近十年内，没有任何单独的软件工程进展可以使软件生产率有数量级的提高,大家熟悉的软件项目具有一些,人狼,的特性（至少在非技术经理看来），常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。因此，我们听到了近乎绝望的寻求银弹的呼唤，寻求一种可以使软件成本像计算机硬件成本一样降低的尚方宝剑。,人月神话,（查珀尔希尔，,1986,年）,软件开发总是非常困难的，天生就没有银弹。想想现代软件系统中这些无法规避的内在特性吧：复杂度、一致性、可变性和不可见性。,88,软件测试的银弹,Standish Group,的研究,Standish Group,从,1994,年开始用了,10,年时间，研究了大约,3,万,5,千个开发项目，他们定义成功的项目：,软件开发按时完成,预算未超出,软件功能涵盖了预定需求,软件没有被缺陷致残,软件已被使用，且产生了积极的效果,最初的结果显示：只有,16%,的项目是成功的，而且他们每年都更新这一统计，发现之后该比例并没有太大改变。,软件测试的银弹：,除了重用，还是重用！,89,目录,白盒测试基本概念,嵌入式白盒测试遵循的理念,嵌入式软件测试设计技术,嵌入式软件测试评估技术,第,4,代白盒测试方法,如何组织嵌入式软件白盒测试,与白盒测试相关的前期开发活动,是开发人员做单元测试还是测试人员做？,白盒测试活动中的角色与配合关系,规划白盒测试注意事项,仿真层中间件如何构造？,持续集成的体系架构,持续集成、每日构建、冒烟测试之间的关系,90,与白盒测试相关的前期开发活动,可测试性需求分析,测试策略拟定,SVVP,计划制定,测试工具选型评估,可测试性设计,测试设计,白盒测试是一项,系统工程！,91,白盒测试活动中的角色,单元测试与集成测试该由谁来实施？,人员组织与角色,项目经理,QA,TC,开发人员,开发人员,开发人员,测试经理,QA,测试系统工程师,自动化工程师,测试人员,测试人员,92,规划白盒测试的几点注意事项,注重前期规划,避免在目标系统（单板）做单元测试,有所为有所不为，难以实施白盒测试应以其它测试手段（如代码检视、设计评审等）弥补,先推单元测试，后推集成测试,注意测试设计的重用,93,依据实践的推论,嵌入式软件的单元测试及底层的集成测试，应在仿真平台进行,集成测试，尤其是基于消息驱动、组件调用，或者定义简洁上下层接口的测试，可以在真实平台下进行,受限于实际环境，未能详尽做单元或集成测试的，应加强其它类型测试予以弥补。,单元测试,-,调试,/,代码正规检视,/lint,检查,集成测试,-,调试,/,设计评审,94,上单板做白盒测试的主要弱点,测试成本高（搭建测试环境、调试与测试麻烦）,面对初始代码，代码不稳定导致上单板效率低下,上单板的测试常混杂了集成测试的需求,由于嵌入式平台的多样性，通常缺乏有效的测试工具,要求前期,PCB,较多投板,95,一个典型的仿真层中间件,底层接口,任务管理,队列管理,内存管理,日志管理,维护管理,配置管理,接口管理,补丁管理,测试接口,应用层接口,手机产品,PDA,产品,宽带产品,数通产品,PSOS,VXWORKS,UNIX,WIN98,NT,INTEL CPU,PPC CPU,ARM CPU,VOS,平台,无线产品,96,持续集成的体系架构,97,持续集成、每日构建、冒烟测试的关系,时时使用 阶段使用 阶段使用,日常调测的脚本，经整理形成规范的回归测试集，从回归测试集中选取部分基础用例构成冒烟测试集,日常测试集与回归测试集是私有的，冒烟测试集是公共的,冒烟测试集归谁维护？,项目组中各人的测试用例要不要合并？,冒烟测试是无人伺服的测试,回归测试与冒烟测试都从版本服务器获取自动构建的版本,98,案例：,IEEE Software best practices,案例：,IEEE Software best practices:,Daily Build and Smoke Test,99,讨论：白盒测试,Top10,问题如何解决？,白盒测试,Top10,问题如何解决？,100,本课程参考资料,第,4,代白盒测试方法参考资料,www.ezT,第,4,代白盒测试方法通俗释义,第,4,代白盒测试方法介绍,-,理论篇,第,4,代白盒测试方法介绍,-VcTester,实践篇,为什么要做白盒测试,企业如何推行白盒测试,实施白盒测试的几个误区,如何选择嵌入式白盒测试工具,VcTester,持续集成框架的应用价值,使用,VcTester,实施持续集成的组织管理模式,使用,VcTester,构造持续集成及每日构建平台,如何在,VcTester,集成自动构建功能,如何将,Pclint,嵌入到,VcTester,中使用,内存泄露检工具,VLD,如何与,VcTester,配合使用,VcTester,插装原理与各种覆盖率配置,101,类别,序号,课 程 名 称,课时,测试技术管理,TST01,嵌入式产品测试管理培训,（,Test Management Training for Embedded Product,）,2,天,TST02,嵌入式软件白盒测试技术培训,（,White-box Test Technology Training for Embedded Software System,）,1,天,TST03,嵌入式软件白盒测试,Dry-Run,培训,（,White-box Test Dry-run Training for Embedded Software System,）,1,天,关于,ezTester,：,我们专注于嵌入式产品领域，专业为全球厂商提供一流的白盒测试解决方案及配套测试工具。,目前我们为业界提供两类服务，一是白盒测试技术咨询，二是自行研发并销售配套测试工具。,相关课程介绍,注：,TST02,与,TST03,常合并为企业内训,2,天,102,后续服务,不闻不若,闻之,，闻之不若,见之,；见之不若,知之,，知之不若,行之,；学至于行而止矣。,-,荀子,儒效篇,企业内部培训,时间：,2,天,针对本企业实际产品与实际问题,讲解内容可按要求定制,学员亲临实践,白盒测试体系顾问式咨询,专题培训,1,天、现场辅导,2,4,天,周期：,30,天,帮助公司规划白盒测试技术体系,103,结束,谢谢！,深圳市领测科技有限公司,南山区创业路保利城大厦,7,层,中国,深圳,[phone],saleezT,www.ezT,104,