第七讲软件测试技术

GIS软件测试技术

第七讲软件测试概论软件测试法则软件测试方法软件测试范例软件测试组织软件测试技术－内容提要2概论－软件质量与缺陷软件产品既必需满足用户的功能要求，又必须稳定可靠地完成用户的作业。软件质量体现在多个方面，但首先要面对并必须解决的方面是软件缺陷。软件缺陷有可能会给系统质量尤其是可靠性带来重大影响。3概论－现状我们无法提供无缺陷的软件各种研究报告表明，每写1000行代码会产生30到85个缺陷大多数缺陷可通过测试捕获在大量的已完成测试的软件中，每1000行代码仍存在0.5—3缺陷4概论－软件缺陷例1错误或含糊的规格说明不适当的设计需求:“阻止鱼雷攻击发射它的潜艇“(198?)设计:鱼雷发射后在发生180度转向时自毁。5概论－软件缺陷例2事件1999年；火星气象卫星(MarsClimateOrbiter)到达火星之后不久就消失；火星极地登陆者(MarsPolarLander)在火星上着陆时坠毁。原因地面系统软件和飞行器上软件分别使用公制和英制两种单位。教训没有进行充分的测试；发现异常时，没有被恰当的解释。6概论－软件缺陷例3事件

1996年6月4日，Ariane5发射40秒后爆炸。

原因将一个64位浮点值转换为16位有符号整数值时，超出了16位整数的表示范围，而这个异常未得到正确解决。教训对于重用模块，作了Ariane5和Ariane4具有相同环境的假设；错误处理模块的处理机制不正确；重用模块在新的环境下完全没有进行测试。7概论－软件缺陷的属性失误(mistake)在软件开发过程中软件开发人员产生隐错／缺陷(bug/defect)在软件产品中软件中存在设计者的错误行为(失误)→导致软件中留有错误的设计(缺陷)→导致软件错误地执行(故障)→导致软件的错误行为(失效)。故障(fault)在软件运行中缺陷被激活失效(failure)在运行阶段用户经历的8概论－获得高质量软件软件工程方法正式技术评审度量与控制标准与过程SQA测试软件质量9概论－缺陷过滤容错(Defecttolerance)编译失误避错(Defectavoidance)排错(defectremoval)复查使用缺陷逃逸测试10概论－定义国家标准GB/T11457—1995软件工程术语:由人工或自动方法来执行或评价系统或系统部件的过程，以验证它是否满足规定的需求；或识别出期望的结果和实际结果之间有无差别。IEEE/ANSI:使用为发现错误所选择的输入和状态的组合而执行代码的过程。11概论－目标在给定的时限内尽可能多的发现缺陷和隐患证实给定的软件产品满足其需求规格说明用最低的成本和投入确认软件测试的质量建立高质量的测试用例，完成有效地测试，提交有用的问题报告为软件开发过程的改进提供数据支持12概论－验证与确认验证与确认是广泛认可的质量保证方法和手段软件测试是软件验证与确认的重要组成部分验证是指对某项规定活动进行检查的过程，以确保该活动实现了规定功能。确认是指审查已建立的软件产品是否符合客户需要的过程。Boehm:验证(Verification):”Arewebuildingtheproductright?”确认(Validation):”Arewebuildingtherightproduct?”13概论－测试与调试测试不是调试，调试也不是测试。主要区别：测试是一种检验，调试是推理过程。测试从已知条件开始，使用预先定义的规程并且有可预知的结果；调试的开始条件可能是不可知的，结果不可预见。测试经常由非程序设计人员完成，调试必须由程序设计者完成。14概论－神话可以对程序进行彻底的测试只要测试人员尽力做好工作，就可以发现所有程序错误可以通过尝试程序所有可能的输入和状态对程序进行测试好的测试包必须包含大量的测试用例好的测试用例总是复杂难懂的软件测试自动化可以替代测试工程师，很好的完成软件测试软件测试简单又容易，任何人都可以做，不需要培训jmerchant1@

15概论－局限性技术不可能通过测试获得100%的质量信心无法确信可以达到100%足够的软件测试不存在发现全部缺陷的单项技术，一种测试技术在发现特定类型的缺陷方面最有效率工程无法确信规格说明100%正确无法确信测试系统(或环境)的正确性无法确信测试人员完全理解了软件产品没有能够适用于所有软件的测试工具没有足够的资源彻底完成软件测试16概论－正确理解测试有效的测试对于开发可靠、安全和成功的软件是必须的。测试具有有效范围，它不是其他软件工程方法的替代品。17概论－测试投入适量的测试投入取得最佳的测试效果风险管理影响测试投入的因素系统的目的潜在的用户数量信息的价值开发机构的成熟度18概论－测试投入(HP)19概论－测试投入(IBM)一般项目：项目总投入的30%~40%高可靠性和高安全性项目：项目其它投入的3~5倍20概论－回顾软件质量与缺陷的关系导致软件致命缺陷的原因往往很简单软件测试的定义、目标和作用有关软件测试的一些神话软件测试的局限性应正确的理解软件测试软件测试的投入视具体情况而定21法则－无止境除了最简单的程序，任何程序的完全测试都是不可能的。测试可以表明缺陷的存在，但绝不能证明没有缺陷。测试只能使好的设计变得更好“Youcan’ttestinquality.Ifit’snottherebeforeyoubegintesting,itwon’tbetherewhenyou’refinishedtesting.”22法则－复杂性高质量的测试要求测试人员彻底理解系统或产品测试质量需要适当的测试集和有效的测试方法保证缺乏有效的测试工具日程安排得不当23法则－尽早开始开发过程每前进一步，发现和修复缺陷的平均代价要增长10倍；随着开发过程的进展，测试的有效性会不断下降；促使开发人员尽早考虑软件的可测试性；缺陷放大模型：来自以前步骤的错误通过的错误放大的错误1:X新产生的错误错误检测有效百分比传给下一个阶段的错误24法则－需要有效管理应建立有效的测试过程，测试过程是否与其它软件过程协调一致，对测试有效性有重要影响；测试工作应该有计划进行；对被测对象和测试本身实施配置与变更管理，不能为了便于测试擅自修改程序；分派有经验、富有创造性的人员承担测试；采用独立测试保证测试有效性。25法则－基于风险测试是一种高风险的活动，其质量依赖于：对软件产品及其相关领域知识的理解高效率的测试方法、覆盖率、工具有创造力并具有丰富软件测试经验的工程师质量费用日程测试需要在时间、成本和质量之间权衡26法则－可追溯所有的测试源于用户需求维持完整的证据链进行可重复的测试和可再现的测试避免不可重复的即兴测试27法则－系统化全面的测试多种方法多个层次多类角色针对性测试符合性驱动测试缺陷驱动测试自动的测试肯定与否定的测试测试软件应该做的和不该做的测试有效和无效、期望和不期望的输入28法则－类聚性软件缺陷具有类聚性；缺陷隐藏在角落里，聚集在边界上；程序中隐藏缺陷的概率与其已发现的缺陷数成比例。29法则－Pareto法则软件测试的Pareto法则(8:2):20%的模块产生80%的缺陷20%的缺陷消耗80%的维护费用图例：模块B模块C缺陷数模块A274184%96%100%30法则－回顾测试是无止境的测试是复杂的测试应尽早开始测试需要有效管理应基于风险开展软件测试测试应做到可追溯测试必须系统化测试对象存在类聚性Pareto法则适用于测试领域31方法－相关概念方法:测试用例(testcase):

输入、执行条件以及为一个特殊目标所开发的预期结果的集合。32设计－好的测试用例具有合理的捕获缺陷的概率执行了重要的区域做了应引起注意的事情不做多余的事情既不太简单也不太复杂不与其它测试用例冗余使得缺陷显而易见考虑缺陷的隔离和识别33方法－测试方法分类静态测试技术动态测试技术白盒测试(White-BoxTesting)黑盒测试(Black-BoxTesting)34方法－静态测试的特征静态测试是不动态执行程序代码而寻找程序代码中可能存在的缺陷或评估程序代码的过程。可以由人工进行，充分发挥人的逻辑思维优势。可以借助软件工具自动进行。35方法－常用静态测试方法代码复查代码检查(CodeInspection)代码走查(Walkthrough)桌面检查(DeskChecking)代码审查(CodeReview)静态分析(主要由软件工具自动进行)36方法－代码复查的入口准则需求描述文档程序设计文档程序的源代码清单编码标准代码复查检查表37方法－代码复查规程获得程序的源代码清单选择代码复查方法进行代码复查记录发现的缺陷修复所发现的每个缺陷确保所做的修复正确无误将缺陷登录到缺陷日志38方法－代码复查的基本内容覆盖率复查程序逻辑复查命名和类型复查变量检查程序语法检查程序检查39方法－代码复查的出口准则完整的、修复过的源程序清单完整的时间记录日志完整的缺陷记录日志40方法－代码复查的优缺点优点：代码复查能快速找到缺陷代码复查比动态测试更有效率(3~5倍)代码复查看到的是问题本身而非征兆缺点：代码复查非常耗费时间(30min/100line)代码复查需要知识和经验(30%~80%)代码复查应在编译和动态测试之前进行41方法－静态分析的内容控制流分析数据流分析接口分析表达式分析与软件缺陷相关的其它信息过程的调用层次编码与命名规则模块规模、调用/被调用关系、扇入/扇出数所用变量和常量的交叉引用表42方法－动态测试特征实际运行被测试程序，取得程序运行的真实情况和动态情况，进行分析；测试的质量依赖于使用的测试数据；生成测试数据和分析测试结果需要时间与经费投入；动态测试涉及人员、设备和数据等多个方面，要求有较好的管理和工作规程。43方法－白盒测试已知产品内部工作流程，通过测试来检测产品的内部动作是否按照详细设计规格说明的规定正常进行，而不管它的功能；也称为结构测试或逻辑驱动测试；目标是对所有逻辑路径进行测试，穷举路径；依据详细设计规范；一种验证技术。44方法－逻辑路径的数量程序的执行序列(逻辑路径)的数目是庞大的，简单的重复就有可能使执行序列的数目增大到天文数字。例子：For(inti=0;i<n;++i) {if(a.get(i)==b.get(i)) x[i]=x[i]+100; else x[i]=x[i]/2;}解：可能的执行序列/路径数是2n＋1当n=20时，执行序列/路径数是1,048,57745方法－基本覆盖基于控制流的测试语句覆盖分支覆盖条件覆盖条件组合覆盖基本路径覆盖循环覆盖数据流覆盖变元覆盖(mutationcoverage)46方法－控制流图一个段是一个或多个无条件连续执行的语句。一个段在控制流图中用一个结点表示，结点可以用任何方便的形式命名。一个控制条件转移是一个分支，一个分支段在控制流图中用一个输出边表示。一个程序的入口点用入口结点表示，它是一个没有输入边的结点，一个程序的出口点用出口结点表示，它是一个没有输出边的结点。47方法－控制流图例XYZ48方法－语句覆盖程序中每条语句至少被执行一次行覆盖、段覆盖、基本块覆盖语句覆盖的盲点(=>0;循环;条件)语句覆盖是最起码的测试要求49方法－分支覆盖程序中的每一个分支至少通过一次决策覆盖分支覆盖的盲点短路估值使分支覆盖不必考虑所有条件忽略了从复合谓词引出的隐含路径分支覆盖不能保证所有入口－出口路径都被执行50方法－条件覆盖判定中的每个条件获得各种可能的结果不要求测试所有可能的分支51方法－条件组合覆盖每个判定中条件的各种组合至少出现一次。达到了条件组合覆盖，所有的语句、分支和条件都将覆盖，但不保证路径覆盖。在实际测试中，由于谓词表达式的短路估值和排它性条件使得达到所有条件组合不可能。52方法－基本路径覆盖圈复杂度C=e-n+2基本路径覆盖要求测试C条不同的入口－出口路径在某些程序中，分支覆盖可在少于C条路径的情况下获得基本路径覆盖可能既没有获得语句覆盖也没有获得分支覆盖。53方法－循环覆盖每种循环结构都有一个不同的控制流图简单循环、嵌套循环、顺序循环、面条循环从最内层循环开始测试，直到最外层控制变量值最低完全最小值－1?✓

最小值?✓

✓

最小值＋1✓

✓

典型值✓

最大值－1✓

最大值✓

✓

最大值＋1?✓

54方法－数据流覆盖通过一定的覆盖准则检查程序中每个数据对象的每次定义、使用和消除。数据流模型(DUK)数据流覆盖策略55方法－变元覆盖测试覆盖被测实现的指定的变体，如测试探测到变元，则变体“退役”，如测试探测不到变元，则修正测试包。变元是指为程序植入小的变化，一般是常出现的错误，如将>=改写成>。用于检查系统的容错能力和测试套件的充分性。56方法－覆盖分析器覆盖分析器是分析测试覆盖率的工具覆盖分析器工作原理通过对源代码的词法分析，插入可跟踪代码，再编译连接；当装配过可跟踪代码的软件执行时，就会产生一个跟踪文件；测试完成后，利用跟踪文件生成覆盖报告。57方法－覆盖率的作用不可执行的路径或条件不可能到达或冗余的代码不充分的测试用例集58方法－覆盖率与缺陷查找覆盖与发现缺陷之间没有必然联系获得任何覆盖目标都不意味着没有缺陷需求相关的缺陷丢失的代码中断相关的缺陷兼容性/配置相关的缺陷59方法－黑盒测试已知软件产品应该具有的功能，通过测试来检测每个功能是否都能正常使用；黑盒法着眼于程序外部结构，不考虑内部逻辑结构；穷举输入/状态测试，测试情况有无穷多个；依据需求规范；检查程序实现的功能，是一种确认技术；也称为功能测试或数据驱动测试。60方法－输入/状态空间

一些很普通的程序所包含的输入输出组合的数目都是非常惊人的，有些更是天文数字。

例：读入三个数值，表示三角形的三条边，程序输出一条信息，说明该三角形是等边三角形、等腰三角形、不等边三角形。解：在限制坐标点取值为1~10的整数的情况下，3条直线有104╳104╳104＝1012种可能的输入，每秒测试1000条直线，需要1012/103＝109s，每年按3.1536╳107s计算，需要109/(3.1536╳107)=31.7年。注：考虑输入域之外/实数/更大范围61方法－黑盒测试的不彻底性不可能测试所有的输入有效的输入无效的输入输入的编辑特性输入时间的考虑不可能测试多个输入的所有组合StateSpaceExplosion62方法－黑盒测试的常用方法边界值分析(boundaryanalysis)等价类划分(equivalenceclasspartitioning)组合逻辑测试(combinationallogictesting)基于状态转换的测试(state-basedtesting)随机测试(randomtesting)63方法－边界值测试任何程序都可以看做是一个函数，程序的输入构成函数的定义域，程序的输出构成函数的值域。可基于定义域或值域进行边界值测试；边界值测试更适合于非强类型语言，如C；边界区域是错误高发区；边界值测试融入了一定程度的否定测试设计；边界值测试通过边界值分析获得测试用例。64方法－边界值分析abx1x2cd65方法－边界值分析基本思想最小值、略高于最小值、正常值、略低于最大值、最大值假设单缺陷66方法－边界值分析abx1x2cdn个变量有4n＋1个测试用例67方法－健壮性测试abx1x2cdn个变量有6n＋1个测试用例68方法－最坏情况测试abx1x2cdn个变量有5n个测试用例69方法－健壮最坏情况测试abx1x2cdn个变量有7n个测试用例70方法－特殊值测试使用最佳工程判断，依赖测试人员的能力；具有高度主观性，但是非常有效；例子:NextDate()的测试多种情况:1－28，1－29，1－30，1－31闰年71方法－边界值分析局限性变量具有独立性变量受物理量的约束对于复杂软件完全使用边界值分析可能不现实边界值测试的用例集存在大量冗余和严重漏洞72方法－等价类划分的含义选择有限子集来“代表”所有可能的输入全集；将被测软件的输入和输出分成区许多区域，对于一个区中的任何值，软件的行为是等价的；等价类划分假设任何单一区内的所有值具有相同的测试目的，因此，每个区测试一个值；等价类划分属于肯定类测试设计技术；等价类划分受测试者主观因素的影响。73方法－等价类划分步骤划分等价类考虑有效等价类和无效等价类确定测试用例给每个等价类一个唯一编号设计一个新的测试用例，使其覆盖未被覆盖的有效等价类，直到所有有效等价类都被覆盖为止。设计一个新的测试用例，使其覆盖未被覆盖的无效等价类，直到所有无效等价类都被覆盖为止。74方法－等价类划分举例例子：计算一个实数的平方根规格说明：输入–实数输出–实数当输入为0或更大的数值时,将返回输入值的正数平方根当输入为小于0的数值时,将显示错误信息“Squarerooterror-negativeinput”并返回0函数Print_Line将用于显示错误信息75方法－等价类划分例解四个等价类划分:两个输入划分:{<0},{>=0}输出划分:{>=0},{error}两个测试用例:用例1:输入4,返回2实现了>=0的输入划分实现了>=0的输出划分用例2:输入-10,返回0,用Print_Line输出"Squarerooterror-illegalnegativeinput"实现了<0的输入划分实现了"error“的输出划分76方法－可用等价类分析的变量输入变量输出变量内部变量硬件与系统软件配置设备状态77方法－组合逻辑测试意义方法因果图判定表逻辑函数78方法－基于状态转换的测试状态转换测试用于被设计成状态机的软件，或者被测软件实现了模型化成状态机的需求。通过建立导致转换的事件的方法来设计测试用例，测试状态之间的转换。使用状态和事件的非法组合来设计否定类的测试用例。79方法－随机测试测试输入数据是在所有可能输入值中随机选取。随机选取用随机模拟的方法，包括用伪随机数发生器、硬件随机模拟器产生输入数据。在测试次数很大时，可在数据输入空间按均匀分布选用。在测试次数较少时，最好在常用的输入数据域以及最可能发生错误的输入数据域选用。80方法－总结(1)从原理上讲，功能(黑盒)测试能检测出所有错误，但要花费无限的时间。结构(白盒)测试基本上是有限的，但即使是全部执行也不能测试出全部的错误。某种程度上讲，测试的技巧就是在结构(白盒)测试与功能(黑盒)测试之间如何进行选择。-----Beizer81方法－总结(2)不同测试用例设计方法具有不同的测试粒度；代码覆盖分析可帮助减少黑盒测试无法避免的盲点；测试应首先考虑被测程序实现需求的测试，然后进行代码覆盖分析。82范例－相关概念范例：提供了某一领域的思考框架。测试设计(testdesign):通过使用一定的测试方法与策略产生一个测试用例包的过程。包括：测试点的识别、将测试点置入测试序列和为测试序列中的每个测试点定义预期输出。测试包(testsuite):

一组相关的测试用例。它服务于被测实现的一个特殊版本或一个特定测试目标。83范例－典型范例功能测试(Functiontesting)域测试(Domaintesting)基于规范的测试(Specification-basedtesting)基于风险的测试(Risk-basedtesting)压力测试(Stresstesting)探索性测试(Exploratorytesting)想定测试(Scenariotesting)随机测试(StochasticorRandomtesting)84范例－功能测试特征基本目标:详尽测试每一个功能,每次一个。能力:详尽分析每个被测试项目典型案例:字处理程序,孤立测试每一个菜单项数据库,孤立测试每份报表盲点:遗漏了交互作用85范例－功能测试方法使用扩充式用例技术进行测试设计利用覆盖CRUD分析完善测试设计 CRUD－Create,Read,Update,Delete使用基于操作剖面方法在一个成熟的测试包中，破坏性测试与确认性测试的比例大约为4:186范例－域测试特征基本目标:所面对的问题需要太多的测试用例。采取分层抽样的策略，合理的从巨大的总量中选取较少的测试用例。能力:用相对小的测试集高概率的发现问题直观清晰的方法,良好的归纳典型案例:简单数值字段的等价类划分打印机兼容性测试盲点:不在边界值或明显特别情况的缺陷实际的域经常是未知的87范例－域测试方法一般方法:将一个字段的可能值的集化分成若干子集,挑选一些值代表每个子集。典型的值就是边界，更为一般的情况,找到每个子集的“最佳代表”,并用这些有代表性的值运行测试。更进一步方法:将几个“最佳代表”组合进行测试。一些方法还选择最优化的组合子集。88范例－基于规范的测试基本目标:检查产品与需求文档中每条规范的一致性能力:发现需求规范实现的遗漏和问题典型案例:可追溯矩阵,追踪测试用例与每个规范项用户文档测试盲点:不在规范中的问题89范例－基于风险的测试基本目标:根据你试图管理的问题(或风险)的类别定义和提练测试根据测试的区域或问题的相关风险确定优先次序典型案例:等价类分析基于使用频度的测试压力测试,错误处理测试,安全性测试,寻找预期或担心的错误的测试从预测错误列表中抽样失效模式和影响分析(FMEA)90范例－基于风险的测试能力:最佳优先次序(假设能正确识别风险并确定优先权)高能力测试盲点:无法确定的风险，更加象意外的风险一些“风险驱动”测试人员似乎比较主观。如何知道覆盖率水平?如何知道没有遗漏关键内容?91范例－压力测试基本目标:通过极端情况下运行产品来了解软件的能力和弱点，在极端环境下的失败告诉我们在正常情况下应该对软件进行什么修改。典型案例:缓冲区溢出缺陷大量数据,超常事务链低内存条件,驱动程序失效,病毒,其它危险92范例－压力测试能力:暴露将会出现的弱点暴露安全风险盲点:通过压力测试无法使其更加可见的弱点93范例－探索性测试基本目标:测试人员得到的软件没有文档或者很迟才会有文档，测试人员必须一边了解产品，一边设计测试用例，以便运行测试寻找缺陷。典型案例:对整个产品进行技巧性探索测试快速测试紧急情况测试第三方构件发现问题/继续探究缺陷94范例－探索性测试能力:关注客户,关注风险发挥每个测试人员的能力优势快速响应环境的变化好管理,避免重复的分析和测试高的缺陷发现率盲点:遗漏的比知道的风险更多受到每个测试人员弱点的局限这是技巧性工作,不是很适合新手95范例－想定测试基本目标:挑战反映实际使用的用例典型案例:用商业规则、客户数据、竞争者的结果来评价产品生命历史测试使用用例描述产品能力和使用模型，按照使用用例扩展测试用例96范例－想定测试能力:复杂,现实的事件，可以处理复杂的不易于模型化的情况暴露那些因超时产生的失效盲点:单个功能失效会降低这个方法的效率必须仔细考虑以便达到好的覆盖97范例－想定测试理想的想定测试的特征:现实(来源于实际的客户或竞争对手的情景)测试是失败还是通过，很明确复杂,它使用了多个特征和功能98范例－随机测试基本目标:利用计算机创建、执行、评价大量的测试。单个测试达不到能力，能力有赖于大量的测试可以在大范围内抽样,在超常的时间范围内测试,提供了发现长时间大量测试才能发现的缺陷的机会。能力:每次回归不依赖于旧的测试部分预言可以在幼稚的代码中快速、经济的发现缺陷可以发现长而复杂的操作链产生的问题，通过有计划的测试发现这些问题很困难99范例－随机测试典型案例:伪随机随机测试统计可靠性评估测试非模型化随机测试模型化随机测试基于其它属性的随机测试盲点:需要辨别通过与失败的能力，太多的人认为“不垮台=不失败”执行的预期结果需要仔细管理测试人员化费很多时间分析代码，很少时间用于分析客户100范例－总结好测试用例的特征几种黑盒测试模式101组织－系统组成支撑平台软件构件模块系统102组织－模块与构件模块：软件系统的基本组成单位由一个程序员完成在系统详细规范中详细说明其功能特性能被单独地汇编和测试规模较小，逻辑较简单构件：一个构件包括实现一个或多个产品功能所需的所有数据文件、库、可重用模块和工程化组件。一个构件可与其它构件进行集成。103组织－软件开发与测试过程104组织－V模型图例：计划修改需求可行性研究需求定义项目启动需求规范化概要设计详细设计编码需求规范设计规范模块规范代码单元测试已测模块集成集成软件集成测试已测软件已确认软件系统测试项目完成可操作软件操作项目结束确认测试需求描述评审评审走查读代码测试用例测试用例测试用例测试用例测试用例测试用例集成计划构件资料阶段基线产品105组织－测试为什么要分阶段？与软件开发过程相适应为了说明软件系统内组件/构件的互操作性需要进行三种基本的测试单独组件/构件的测试测试组件/构件间互操作测试组件/构件结合成的软件系统106组织－单元测试特点单元测试关注程序的基本组成部分－模块单元测试的依据－软件设计规格说明若干个模块可以并行测试由于单元测试的对象规模和复杂性较低，可利用以白盒为主的多种测试技术进行比较充分细致的测试，发现错误后容易隔离和定位被测模块测试用例结果测试工程师107组织－单元测试内容被测模块模块接口局部数据结构边界条件独立执行路径错误处理的路径测试用例108组织－单元测试环境被测模块驱动模块结果测试用例模块接口局部数据结构边界条件独立执行路径错误处理的路径桩1桩2桩n109组织－单元测试进入条件要求的文档可提交；符合规格要求的软件单元源程序清单，并已无错误地通过编译或汇编；被测试软件单元已纳入配置管理中；具备了规定的单元测试环境和测试工具。110组织－单元测试通过准则命名符合规则；控制流程正确；变量存取无误差；所有软件单元达到质量度量指标；功能与设计说明一致；性能达到软件设计指标；覆盖测试达到规定的覆盖率；对发现的问题已进行修改并通过回归测试。111组织－集成的概念集成可在多个层次上进行两个组件集成的例子:Component#1OperationsandFunctionswithI/OinputinterfaceoperationComponent#2OperationsandFunctionswithI/Ooutputinterfaceoperation112组织－集成测试特征一组相互依赖的组件或模块放在一起进行测试，以确保其作为一个整体的质量。集成测试是一个渐进的过程

模块构件软件配置项子系统软件系统113组织－集成测试策略非渐增式集成(大爆炸集成)渐增式集成自顶向下集成深度优先方法广度优先方法自底向上集成高频集成114组织－大爆炸集成测试含义前提被测系统在通过系统范围的测试后，只有少量构件加入或修改。被测系统较小并具有良好可测试性，每个构件都经过充分测试。被测系统的构件紧密连接，无法分别测试。测试未考虑构件之间的相依性或风险。115组织－自顶向下集成测试顶上的模块借助桩进行测试每次替换一个桩，可选用“深度优先”或者“广度优先”方式。每当新的模块集成进来，重新运行一些测试子集。ABCDEFG116组织－自顶向下集成测试步骤首先开发和测试在最高控制层的构件，下层构件用桩实现；继续在每一层按宽度或深度优先进行，用真正的模块代替桩，并建立下层桩；每一个模块集成进来的时候都要进行测试；用回归测试保证没有引入新错误；以这种方式继续直到所有被测系统中的桩已经实现和测试。117组织－自顶向下集成测试模式ABEHCDFIGJLMK广度优先–ABCDEFGHIJKLM深度优先–ABEHCFIDGJLMK118组织－自顶向下集成测试特性优点：测试和集成可以较早开始；减少了驱动器开发费用。缺点：需要建立大量的桩；底层的需求变化会影响上层构件。119组织－自底向上集成测试ABCDEFG以深度优先次序每次替换一个驱动模块可工作的模块被聚合在一起，形成build并集成。簇120组织－自底向上集成测试步骤第一阶段对底层模块编码，并使用驱动模块对其测试；底层模块组合成能够实现软件特定子功能的簇，写驱动模块对簇进行测试；移走驱动模块，沿着程序结构的层次向上对簇进行组合，使用驱动模块对其测试；以这种方式继续集成直到整个系统使用真实的主控制模块进行测试。121组织－自底向上集成测试模式ABEHCDFIGJLMKBuild1–HEBBuild2–IFCDBuild3–LMJKG将build1,2和3与A集成。122组织－自底向上集成测试特性优点:不需要桩；可并行测试。缺点:需要大量驱动器123组织－高频集成测试特征适用于时间紧复杂度高的软件自底向上/自顶向下的集成方式每日构建与冒烟测试(DailyBuildandSmokeTesting)冒烟测试：冒烟测试从头到尾检测整个系统(当前状态下)。它不一定必须是穷举的，但是应该能够暴露主要问题。冒烟测试应该是足够充分的，如果构件通过了冒烟测试，就可以假定该构件已经足够稳定，可以继续进行更加彻底的测试。

－McConnel,S.124组