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

领测技术（EzTester）简介,嵌入式软件白盒测试技术,第4代白盒测试方法的理论与实践,Approved by WAYNE Work StudioAt 2007/05/18,讲师介绍,讲师：Wayne Chan(wayneezT)任职经历曾在HW公司工作8年（19972004），先后担任测试技术经理、公司测试系统工程师、公司测试技术总架构师等职务，是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 Std 610.12-1990)：在既定的状况条件下，运行一个系统或组件，观察记录结果，并对其某些方面进行评价的过程。1979年Glenford J.Myers在The Art of Software Testing中定义：软件测试是为了发现错误而运行程序的过程。广义“软件测试”由验证、确认、测试3个方面组成验证：检测软件开发的每个阶段、每个步骤的结果是否正确无误，是否与软件开发各阶段的要求或期望的结果相一致。验证意味着确保软件会正确无误地实现软件的需求，开发过程是沿着正确的方向进行的。确认：评估将要开发的软件产品是否正确无误、可行和有价值的。确认意味着确保一个待开发软件是正确无误的，是对软件开发构想的检测。测试：与狭义“软件测试”概念一致。,V模型,软件验证与确认（Verification and Validation，简称V&V）验证针对各步骤的产品设计，确认针对预设的产品构想,W模型,W模型：全过程的、同步的、全方位的测试模型,案例：SVVP计划任务,什么是白盒测试？,狭义的“白盒测试”包括：单元测试与集成测试广义的“白盒测试”包括：从设计、编码，再到单元测试、集成测试各阶段中针对可见源码的V&V活动代码检视（代码审查）属不属于白盒测试？软件编译报错后修改代码，属不属于白盒测试活动？白盒测试活动最早出现在哪个开发阶段？“白盒测试”是与“黑盒测试”相对的一个概念黑盒测试是被测代码不可见的测试，包括功能测试、验证测试等白盒测试是被测代码可见的测试，包括单元测试、集成测试、部分协议测试等白盒测试基本过程编写测试用例：查看修改变量，调用函数，验证测试结果查看代码覆盖率，改进测试设计生成正式的测试报告,案例：D项目集成测试的困惑,某固网产品D项目主要负责话务统计的实现，该项目在头脑灵活、精明强干的明星经理肖某带领下，各项工作都很出色，需求调研很深入，还借鉴了业界优秀的话统模型，正当D项目一帆风顺的运行到模块集成测试，肖经理突然发现：精心构造话统模型却难以测试。这种多业务分解，基于事务处理，又是多线索的统计模型很难按常规方法（甚至是调试方式）去测试，而略过集成测试直接做系统测试，就意味着要消耗大量精力在各种组合条件的测试用例设计，以及手工测试操作上。肖经理犯愁了，总觉得前面的项目运作缺了点什么,白盒测试在研发全流程中的位置,白盒测试在研发全流程中的位置,单元测试与集成测试是什么？不是什么？,IPL对单元测试的描述 单元测试是针对与其它部分隔的、独立的单元所展开的测试。在不同编程环境下单元的含义有所不同，比如在C语言中，被测单元是常规函数或子过程，在C+语言中，单元是指一个类，在Ada语言中单元是指函数或过程，或者是Ada Package，而在4GL语言（如Delphi）中，单元还可以是一个菜单、按钮、某个显示单元等。单元测试：针对程序中基本组成部件的测试关注的被测单元应是分隔开的、独立的被测单元不只是函数对象也可是手工的、不可重复的测试单元测试不是：源码不可见的测试被测范围不确定的测试集成测试：比单元测试处于更高级别某些情况下，被测对象与单元测试无明显界限集成测试区别于单元测试主要是：被测对象的表现特征不同，及由此带来测试方法有所不同。,企业不做单元测试的原因,一个游戏：将小车开出谜宫,语录,在恰当的时间以恰当的方法做恰当的事情！,孔夫子语录：I hear and I forget.I see and I remember.I do and I understand.,讨论：白盒测试的问题与难题,大家在做单元测试与集成测试过程中，都遇到过哪些问题？按重要性排序列出前10条。,白盒测试三种境界,混沌状态：只有零星白盒测试实践，缺少成功案例各成员对白盒测试普遍认识模糊大家都忙于救火，系统测试的投入尚无保障，代码级测试无投入有序状态：已有多个项目成功推行单元测试，已成可拷贝的活动有一批人对白盒测试具有清晰认识，领导层对实践的前景既不悲观，也不盲目乐观设立专门机构推动UT与IT，白盒测试活动也有流程保障少数项目有显著效果，多数项目稍有成效，个别项目是失败的自组织状态：时时测试、持续测试已成风气白盒测试已成员工的普遍行为与自发行为有所为有所不为,白盒测试三种境界,处于混沌状态贵在 尝试！处于有序状态贵在 坚持！处自组织状态贵在自知！,子曰：吾十有五，而志于学，三十而立，四十而不惑，五十而知天命，六十而耳顺，七十从心所欲，不逾矩。,为什么要做白盒测试？,案例公司（ABC）遗留缺陷率：14BUG/KLOC,USA国防部（DOD）遗留缺陷率：0.01BUG/KLOC,为什么要做白盒测试？,一个比喻：清洗面包机,为什么要做白盒测试？,由Capers Jones与McGraw-Hill的统计表明：若将问题发现、定位与解决都计算进去，单元测试效率最高，是集成测试的2倍，是系统测试的3倍。,为什么要做白盒测试？,白盒测试能较彻底解决编码阶段引入的问题,实施白盒测试的差异性验证,两个性质接近的项目（项目A与项目B），项目A没做正规白盒测试，仅拿调试当测试，项目B实施规范的白盒测试，这两项目结束时分别按问题根源对全部BUG作统计。,从“白盒测试问题比例”与“逻辑问题比例”可看出：不做白盒测试必然导致大量问题漏测,项目A：缺少规范的白盒测试,项目B：规范测试,案例：问题根源分析,案例：ODC问题根源分析 ODC来源于 IBM，Orthogonal Defect Classification,白盒测试抽象模型,嵌入式软件的白盒测试特点,开发语言以C语言为主体运行环境比较复杂（驻留于各式单板，与各种IO设备打交道）实时、多任务对于通信软件：代码量大、复杂程度高产品设计要为测试环境构造提供条件要挖掘所有潜力来提高测试设计的效率对于通信软件：测试体系要开放，与其它工具配合使用,环境敏感效率苛刻,目录,白盒测试基本概念嵌入式白盒测试遵循的理念为什么尽早测试？为什么持续测试？在线测试驱动与在线测试桩在线测试设计、运行及改进白盒测试的粒度与可见性白盒、黑盒，抑或灰盒调试是不是测试？检视器的概念嵌入式软件测试设计技术嵌入式软件测试评估技术第4代白盒测试方法如何组织嵌入式软件白盒测试,为什么尽早测试？,越早测试付出代价就越低,案例：什么是持续测试？,案例：一次测试 与 持续测试某通信产品在V1版本编码完成时，进行过规范的单元测试活动，之后V2、V3要不断增加功能、修改功能，就放弃单元测试了。当V3最后市场交付时统计发现，相对V1版本，代码修改量已达到40%。QA从其中两个模块随机抽取100个问题单做缺陷分析，结果发现：第一个模块有50%的问题是在V1版本单元测试结束后引入的，而另一模块也有30%问题是单元测试后引入的。,为什么持续测试,持续集成的典型特征是：写一点测一点 Object Mentor：我们在做任何事情时（无论 是写测试、写产品代码还是重构），都要保 证系统能够一直运行。运行测试的间隔时间 是秒或者分钟级的。即使是10分钟都太长了。反映了一种质量优先的策略微软的“每日构建”与“冒烟测试”IBM的“渐增Build测试”XP的持续集成、测试先行等实践持续集成对“软件稳定性”实现重用查错、改错的效率提高了被测系统随时可运行，可展现功能，降低风险,时时可测试时时做测试,案例：Joel测试,案例：Joel测试改进代码的12个步骤,演示：在线测试,演示：在线测试设计（在线测试驱动、在线测试桩）在线测试调试 在线测试执行 在线测试评估改进,全局变量/函数：vd.xx 类型定义：/,拉通测试小循环,白盒测试的粒度与可见性,关注函数接口还是关注函数内部代码行？考虑因素：测试设计的工作量用例维护的工作量是否必须基于接口做测试设计，还是基于代码行做设计？,白盒、黑盒，抑或灰盒,白盒测试设计形式对照源码编写测试用例看到哪行覆盖，哪行未覆盖，来优化测试用例对照源码调试测试用例，并定位测试问题依照源码维护测试用例黑盒测试操作方式依据设计规格用例脚本只关注测试运行环境与输入输出接口一键运行，没有单步跟踪,调试是不是测试？,调试与测试的共性目的：查错或确认无错构造运行环境：配置数据、修改变量、模拟桩判别是否预期：过程表现、结果表现调试与测试的差异可重复性粒度与可维护性3个概念：调试、检视、测试,检视器,检视器介于调试器与测试器之间是一种提供脚本化控制的调试器也是一种提供调试功能的测试脚本生成器观察控制点（Points of Control and Observation，PCO）位于被测单元的上下层之间具有调试断点的功能支持调试操作自动生成测试脚本,演示：检视器,演示：检视器的主要功能,目录,白盒测试基本概念嵌入式白盒测试遵循的理念嵌入式软件测试设计技术白盒测试的3类形式化表述语言映射技术三种测试设计模式一次性集成与增殖集成测试设计与产品设计的耦合关系测试脚本如何自动生成为什么要TDD？TDD三原则嵌入式软件测试评估技术第4代白盒测试方法如何组织嵌入式软件白盒测试,白盒测试的3类形式化表述,原生表述（CppUnit、JUnit、CodeTest）转化表述（Parasoft C+Test、RTRT、Cantata+）映射表述（VcTester）,案例：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 类型定义：/,语言映射技术,A函数,B函数,C函数,脚本桩函数,B函数,A函数,B函数,C函数,A函数,B函数,C函数,脚本桩函数,打脚本桩之前 替代模式打桩 插入模式打桩,演示：C语言映射到CSE脚本,演示：C语言映射到CSE脚本,演示：3种测试设计模式,演示：3种测试设计模式仿真模式点控制模式混合模式,一次性集成与增殖集成,一次性集成增殖集成（自顶向下、自底向上、混合方式）,测试设计与产品设计的耦合关系,紧耦合的需求：测试重用，参考引用，结构化封装松耦合的需求：用例维护，版本发布，隔离BUG,紧耦合模式,分离模式,松耦合模式,XUNIT,RTRT,VcTester,演示：分离模式的应用实例,演示：分离模式的应用实例,案例：Parasoft C+Test的脚本生成,案例：Parasoft C+Test的脚本自动生成（Source模式）,void BubbleSort(OBJ_DATA_PTR ObjList,int iMax),int _stdcall ObjCompare(OBJ_DATA*Obj1,OBJ_DATA*Obj2),案例：Parasoft C+Test的脚本生成,案例：Parasoft C+Test的脚本自动生成（Native模式）,什么脚本能生成，什么不能？,图灵停机与图灵测试测试脚本自动生成依据什么？什么测试脚本能自动生成，什么不能生成？,演示：VcTester的测试脚本自动生成,演示：VcTester的测试脚本自动生成,什么是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（测试指示开发）“指示”意味着：测试为片断代码提供使用规格 也隐含“测试即设计文档”这个饱受争议的论题,TDD操作步骤,为什么要TDD？,实施TDD的深刻原因一次好测试：既测试可见代码，也测试不可见代码一次好测试：是基于规格的测试，而不是“机械测试”案例：An Initial Investigation of Test Driven Development in Industry,如何实施TDD？,实施TDD的难点克服未见代码先写用例的恐慌提高TDD中编码与调试的效率案例：Object Mentor TDD三条军规 1.除非为了使一个失败的unit test通过，否则不允许编写任何产品代码 2.在一个单元测试中只允许编写刚好能够导致失败的内容（编译错误也算)3.只允许编写刚好能够使一个失败的unit test通过的产品代码,演示：第4代白盒方法的TDD实践,演示：第4代白盒方法的TDD实践,讨论：测试先行、持续集成、冒烟测试,测试先行（TDD）、持续集成、冒烟测试，这3者之间有什么关系？,目录,白盒测试基本概念嵌入式白盒测试遵循的理念嵌入式软件测试设计技术嵌入式软件测试评估技术常用覆盖率统计标准基于调用的覆盖率统计技术如何选择覆盖率标准用例覆盖度缺陷密度评估白盒测试问题管理第4代白盒测试方法如何组织嵌入式软件白盒测试,常用覆盖率统计标准,语句覆盖（StatementCoverage）判定覆盖（DecisionCoverage）条件覆盖（ConditionCoverage）多条件覆盖（MultipleConditionCoverage）判定条件组合覆盖（Condition/DecisionCoverage）修正条件/判定覆盖（ModifiedCondition/DecisionCoverage，MCDC）路径覆盖（PathCoverage）,基于调用的覆盖率统计技术,位置无关调用覆盖（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%”。,演示：覆盖率定制的一个实例,演示：覆盖率定制的一个实例,如何选择覆盖率标准？,是不是选择覆盖率标准越高越好？持续集成对覆盖率指标有哪些要求？选择恰如其分的评估标准避免源码中“噪声”给质量评估带来波动,语句覆盖,判定覆盖条件覆盖,判定条件覆盖MCDC覆盖LCSAJ覆盖,路径覆盖,用例覆盖度,为什么引入用例覆盖度(Test Case Coverage)？定义 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项关键特征,第一关键域：在线测试在线测试驱动在线脚本桩在线测试用例设计、运行，及评估改进第二关键域：灰盒调测基于调用接口调试即测试集编码、调试、测试于一体第三关键域：持续测试测试设计先行持续保障信心重构测试设计,测试效率易操作/易推行,测试质量,演示：集成调测平台,演示：集成化的编辑、调试与测试平台,演示：红绿灯通行机制,演示：红绿灯通行机制,拉通研发大循环,白盒测试技术演进,软件测试的银弹,没有银弹（布鲁克斯，1986年）在近十年内，没有任何单独的软件工程进展可以使软件生产率有数量级的提高大家熟悉的软件项目具有一些人狼的特性（至少在非技术经理看来），常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。因此，我们听到了近乎绝望的寻求银弹的呼唤，寻求一种可以使软件成本像计算机硬件成本一样降低的尚方宝剑。人月神话（查珀尔希尔，1986年）软件开发总是非常困难的，天生就没有银弹。想想现代软件系统中这些无法规避的内在特性吧：复杂度、一致性、可变性和不可见性。,软件测试的银弹,Standish Group的研究Standish Group从1994年开始用了10年时间，研究了大约3万5千个开发项目，他们定义成功的项目：软件开发按时完成 预算未超出 软件功能涵盖了预定需求 软件没有被缺陷致残 软件已被使用，且产生了积极的效果 最初的结果显示：只有16%的项目是成功的，而且他们每年都更新这一统计，发现之后该比例并没有太大改变。软件测试的银弹：除了重用，还是重用！,目录,白盒测试基本概念嵌入式白盒测试遵循的理念嵌入式软件测试设计技术嵌入式软件测试评估技术第4代白盒测试方法如何组织嵌入式软件白盒测试与白盒测试相关的前期开发活动是开发人员做单元测试还是测试人员做？白盒测试活动中的角色与配合关系规划白盒测试注意事项仿真层中间件如何构造？持续集成的体系架构持续集成、每日构建、冒烟测试之间的关系,与白盒测试相关的前期开发活动,可测试性需求分析测试策略拟定SVVP计划制定测试工具选型评估可测试性设计测试设计,白盒测试是一项系统工程！,白盒测试活动中的角色,单元测试与集成测试该由谁来实施？人员组织与角色,项目经理,QA,TC,开发人员,开发人员,开发人员,测试经理,QA,测试系统工程师,自动化工程师,测试人员,测试人员,规划白盒测试的几点注意事项,注重前期规划避免在目标系统（单板）做单元测试有所为有所不为，难以实施白盒测试应以其它测试手段（如代码检视、设计评审等）弥补先推单元测试，后推集成测试注意测试设计的重用,依据实践的推论,嵌入式软件的单元测试及底层的集成测试，应在仿真平台进行集成测试，尤其是基于消息驱动、组件调用，或者定义简洁上下层接口的测试，可以在真实平台下进行受限于实际环境，未能详尽做单元或集成测试的，应加强其它类型测试予以弥补。单元测试-调试/代码正规检视/lint检查 集成测试-调试/设计评审,上单板做白盒测试的主要弱点,测试成本高（搭建测试环境、调试与测试麻烦）面对初始代码，代码不稳定导致上单板效率低下上单板的测试常混杂了集成测试的需求由于嵌入式平台的多样性，通常缺乏有效的测试工具要求前期PCB较多投板,一个典型的仿真层中间件,持续集成的体系架构,持续集成、每日构建、冒烟测试的关系,时时使用 阶段使用 阶段使用日常调测的脚本，经整理形成规范的回归测试集，从回归测试集中选取部分基础用例构成冒烟测试集日常测试集与回归测试集是私有的，冒烟测试集是公共的 冒烟测试集归谁维护？项目组中各人的测试用例要不要合并？冒烟测试是无人伺服的测试回归测试与冒烟测试都从版本服务器获取自动构建的版本,案例：IEEE Software best practices,案例：IEEE Software best practices:Daily Build and Smoke Test,讨论：白盒测试Top10问题如何解决？,白盒测试Top10问题如何解决？,本课程参考资料,第4代白盒测试方法参考资料 第4代白盒测试方法通俗释义第4代白盒测试方法介绍-理论篇第4代白盒测试方法介绍-VcTester实践篇为什么要做白盒测试企业如何推行白盒测试实施白盒测试的几个误区如何选择嵌入式白盒测试工具VcTester持续集成框架的应用价值使用VcTester实施持续集成的组织管理模式使用VcTester构造持续集成及每日构建平台如何在VcTester集成自动构建功能如何将Pclint嵌入到VcTester中使用内存泄露检工具VLD如何与VcTester配合使用VcTester插装原理与各种覆盖率配置,关于ezTester：我们专注于嵌入式产品领域，专业为全球厂商提供一流的白盒测试解决方案及配套测试工具。目前我们为业界提供两类服务，一是白盒测试技术咨询，二是自行研发并销售配套测试工具。,相关课程介绍,注：TST02与TST03常合并为企业内训2天,后续服务,不闻不若闻之，闻之不若见之；见之不若知之，知之不若行之；学至于行而止矣。-荀子儒效篇,企业内部培训时间：2天针对本企业实际产品与实际问题讲解内容可按要求定制学员亲临实践,白盒测试体系顾问式咨询专题培训1天、现场辅导24天周期：30天帮助公司规划白盒测试技术体系,结束,谢谢！,深圳市领测科技有限公司南山区创业路保利城大厦7层中国 深圳+86 755 2117 0680,