软件测试的方法和技术.pptx

《软件测试的方法和技术.pptx》由会员分享，可在线阅读，更多相关《软件测试的方法和技术.pptx（105页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、3.1 软件测试方法概述软件测试方法概述 软件测试的种类大致可分为人工测试和基于计算机的测试。而基于计算机的测试又可分为黑盒测试和白盒测试。1黑盒测试 黑盒测试是根据软件产品的功能设计规格，在计算机上进行测试，以证实每个已经实现的功能是否符合要求。黑盒测试意味着测试要在软件的接口处进行。第1页/共105页2白盒测试 白盒测试是根据软件产品的内部工作过程，在计算机上进行测试，以证实每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。白盒测试把测试对象看做一个打开的盒子，允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状

2、态，确定实际的状态是否与预期的状态一致。第2页/共105页3.2 白白 盒盒 测测 试试 白盒测试也称为结构测试或逻辑驱动测试，前提是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能够按预定要求正确工作，而不管产品的功能，主要用于软件验证。第3页/共105页 白盒测试方法又可分为静态测试和动态测试。静态测试是一种不通过执行程序而进行测试的技术，其关键功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。它瞄准的是纠正软件系统在描述、表示和规格上的错误，是任何进一步测试的前提。而动态测试需要软件的执行

3、，当软件系统在模拟的或真实的环境中执行之前、之中和之后，对软件系统行为的分析是动态测试的主要特点。它显示了一个系统在检查状态下是正确还是不正确。第4页/共105页 白盒测试的动态测试要根据程序的控制结构设计测试用例，其原则是：（1）保证一个模块中的所有独立路径至少被使用一次；（2）对所有逻辑值均需测试true和false；（3）在上下边界及可操作范围内运行所有循环；（4）检查内部数据结构以确保其有效性。第5页/共105页 下面将介绍几种实用的白盒测试用例设计方法，包括程序插桩、逻辑覆盖、基本路径测试等。3.2.1 程序插桩 在软件动态测试中，程序插桩是一种基本的测试手段，有着广泛的应用。1方法

4、简介 程序插桩方法是借助往被测程序中插入操作，来实现测试目的的方法。第6页/共105页 如果我们想要了解一个程序在某次运行中所有可执行语句被覆盖的情况，或是每个语句的实际执行次数，最好的办法是利用插桩技术。这里仅以计算整数X和整数Y的最大公约数程序为例，说明插桩方法的要点。图3-3给出了这一程序的流程图。第7页/共105页图3-3 插桩后求最大公约数程序的流程图 第8页/共105页设计插桩程序时需要考虑的问题包括：探测哪些信息；在程序的什么部位设置探测点；需要设置多少个探测点。第9页/共105页2断言语句 在程序中特定部位插入某些用以判断变量特性的语句，使得程序执行中这些语句得以证实，从而使程

5、序的运行特性得到证实。我们把插入的这些语句称为断言。这一做法是程序正确性证明的基本步骤，尽管算不上严格的证明，但方法本身仍然是很实用的。下面以求两个非负数NUM和DEN之商的Wensley迭代算法为例，对断言语句的作用做一简要说明。第10页/共105页图3-5 计算非负数之商的迭代程序 第11页/共105页 图3-6 插入断言后的迭代程序 第12页/共105页3.2.2 逻辑覆盖 逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术，是通过对程序逻辑结构的遍历实现程序的覆盖，它是一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。这一方法要求测试人员对程序的逻辑结构有清楚的了解

6、，甚至要能掌握源程序的所有细节。它属于动态测试。第13页/共105页 从覆盖源程序语句的详细程度分析，逻辑覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正条件判定覆盖。为便于理解，使用如下所示的程序，图3-7所示的是其流程图。第14页/共105页图3-7 参考例子流程图第15页/共105页int function1（bool a，bool b，bool c）int x;x=0;if(a&(b|c)x=1;return x;第16页/共105页1语句覆盖 为了暴露程序中的错误，程序中的每条语句至少应该执行一次。所以，语句覆盖的含义是：选择足够多的测试数据，使被测程序中每

7、条语句至少执行一次。第17页/共105页2判定覆盖 比语句覆盖稍强的覆盖标准是判定覆盖。按判定覆盖准则进行测试是指，设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假值均曾被满足。判定覆盖又称为分支覆盖。第18页/共105页3条件覆盖 在设计程序中，一个判定语句是由多个条件组合而成的复合判定。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。第19页/共105页4条件判定组合覆盖 条件判定组合覆盖的含义是：设计足够的测试用例，使得判定中每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果（真/假

8、）也至少出现一次。第20页/共105页5多条件覆盖 多条件覆盖也称为条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。第21页/共105页6修正条件判定覆盖 它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、or）连接的bool条件，每个条件对于判定的结果值是独立的。第22页/共105页7测试覆盖准则（1）Foster的ESTCA覆盖准则 前面所介绍的

9、逻辑覆盖其出发点似乎是合理的。所谓“覆盖”，就是想要做到全面而无遗漏。但是，事实表明，它并不能真的做到无遗漏。K.A.Foster从测试工作实践的教训出发，吸收了计算机硬件的测试原理，提出了一种经验型的测试覆盖准则。第23页/共105页（2）Woodward等 人 的 层 次LCSAJ覆盖准则 Woodward等人曾经指出结构覆盖的一些准则，如分支覆盖或路径覆盖，都不足以保证测试数据的有效性。为此，他们提出了一种层次LCSAJ覆盖准则。第24页/共105页3.2.3 基本路径测试 上节的例子是个比较简单的程序段，只有两条路径。但在实际问题中，即使一个不太复杂的程序，其路径的组合都是一个庞大的数

10、字。如果把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行零次和一次，就成为基本路径测试。设计出的测试用例要保证在测试中程序的每一条可执行语句至少执行一次。第25页/共105页1程序的控制流图 控制流图是描述程序控制流的一种图示方式。其中基本的控制结构对应的图形符号如图3-8所示。在图3-8所示的图形符号中，圆圈称为控制流图的一个结点，它表示一个或多个无分支的语句或源程序语句。第26页/共105页图3-8 控制流图的图形符号 第27页/共105页 图3-9（a）所示的是一个程序的流程图，它可以映射成图（b）所示的控制流图。图3-9 程序流程图和对应的控制流图 第28页/共105页2计算

11、程序环路复杂性 进行程序的基本路径测试时，程序的环路复杂性给出了程序基本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。所谓独立路径，是指包括若干未曾处理的语句或条件的一条路径。第29页/共105页 基本路径集不是惟一的，对于给定的控制流图，可以得到不同的基本路径集。通常环路复杂性可用以下3种方法求得。将环路复杂性定义为控制流图中的区域数。设E为控制流图的边数，N为图的结点数，则定义环路的复杂性为V(G)=EN+2。若设P为控制流图中的判定结点数，则有V(G)=P+1。第30页/共105页3基本路径测试法步骤 基本路径测试法适用于模块的详细设计及源

12、程序，其主要步骤如下。以详细设计或源代码作为基础，导出程序的控制流图。计算得到的控制流图G的环路复杂性V（G）。确定线性无关的路径的基本集。生成测试用例，确保基本路径集中每条路径的执行。第31页/共105页3.2.4 程序的静态测试1源程序静态分析 在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图、子程序表、宏和函数参数表等各类图形图表，可以清晰地标识整个软件系统的组成结构，使其便于阅读与理解，然后可以通过分析这些图表，检查软件有没有存在缺陷或错误。第32页/共105页 通常采用以

13、下一些方法进行源程序的静态分析。（1）生成各种引用表 标号交叉引用表 变量交叉引用表 子程序（宏、函数）引用表 等价表 常数表 第33页/共105页（2）错误静态分析 错误静态分析主要用于确定在源程序中是否有某类错误或“危险”结构。类型和单位分析 引用分析 表达式分析 接口分析 第34页/共105页2人工测试 静态分析中进行人工测试的主要方法有桌前检查、代码审查和走查。经验表明，使用这种方法能够有效地发现30%70%的逻辑设计和编码错误。第35页/共105页（1）桌前检查 由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析、检验，并补充相关的文

14、档，目的是发现程序中的错误。第36页/共105页（2）代码审查 代码审查是由若干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步。第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为审查的依据。小组成员在充分阅读这些材料后，进入审查的第二步，召开程序审查会。第37页/共105页（3）走查 走查与代码审查基本相同，其过程分为两步。第一步也把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机，即首先由测试

15、组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。第38页/共105页3.2.5 其他白盒测试方法简介1域测试 域测试是一种基于程序结构的测试方法。域测试正是在分析输入域的基础上，选择适当的测试点以后进行测试的。第39页/共105页2符号测试 符号测试的基本思想是允许程序的输入不仅仅是具体的数值数据，而且包括符号值，这一方法也因此而得名。第40页/共105页3Z路径覆盖 分析程序中的路径是指检验程序从入口开始，执行过程中经历的各个语句，直到出口。第41页/共105页4程序变异 程序变

16、异方法是一种错误驱动测试。所谓错误驱动测试方法，是指该方法是针对某类特定程序错误的。经过多年的测试理论研究和软件测试的实践，人们逐渐发现要想找出程序中所有的错误几乎是不可能的。比较现实的解决办法是将错误的搜索范围尽可能地缩小，以利于专门测试某类错误是否存在。错误驱动测试主要有两种，即程序强变异和程序弱变异。第42页/共105页 最后，归纳一下白盒测试中各种测试方法的应用策略。在白盒测试中，可以使用各种测试方法的综合策略如下。（1）在测试中，应尽量先使用工具进行静态结构分析。（2）测试中可采取先静态后动态的组合方式：先进行静态结构分析、代码检查，再进行覆盖率测试。第43页/共105页 （3）利用

17、静态分析的结果作为导引，通过代码检查和动态测试的方式对静态发现结果进行进一步的确认，使测试工作更为有效。（4）覆盖率测试是白盒测试的重点，一般可使用基本路径测试法达到语句覆盖标准；对于软件的重点模块，应使用多种覆盖率标准衡量代码的覆盖率。第44页/共105页（5）在不同的测试节点，测试的侧重点不同：在单元测试阶段，以代码检查、逻辑覆盖为主；在集成测试阶段，需要增加静态结构分析等；在系统测试阶段，应根据黑盒测试的结果，采取相应的白盒测试。第45页/共105页3.3 黑黑 盒盒 测测 试试 黑盒测试也称功能测试或数据驱动测试，前提是已知产品所具有的功能，通过测试来检测每个功能是否都正常使用。黑盒测

18、试方法主要有等价类划分、边界值分析、因果图、错误推测、功能图法等，主要用于软件确认测试。第46页/共105页3.3.1 等价类划分法 等价类划分是一种典型的黑盒测试方法。使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。由于不可能用所有可以输入的数据来测试程序，而只能从全部可供输入的数据中选择一个自己进行测试。如何选择适当的子集，使其尽可能多地发现错误，解决的办法之一就是等价类划分。第47页/共105页 首先，把数目极多的输入数据，包括有效的和无效的，划分为若干等价类，而所谓等价类，是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并

19、合理地假定：测试某等价类的代表值就等价于对这一类其他值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可用少量代表性测试数据，取得较好的测试结果。第48页/共105页等价类的划分有以下两种不同的情况。有效等价类 无效等价类 第49页/共105页划分等价类的原则如下。按区间划分 按数值划分 按数值集合划分 按限制条件或规则划分 第50页/共105页 在确立了等价类之后，建立等价类表，列出所有划分出的等价类，如表3-6所示。第51页/共105页 再从划分出的等价类中按以下原则选择测试用例。为每一个等价类规定一个惟一的编号。设计一个新的测试用例，

20、使其尽可能多地覆盖尚未覆盖的有效等价类；重复这一步骤，直到所有的有效等价类都被覆盖为止。设计一个新的测试用例，使其仅覆盖一个无效等价类，重复这一步骤，直到所有的无效等价类都被覆盖为止。第52页/共105页3.3.2 边界值分析法 人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。第53页/共105页 选择测试用例的原则如下。如果输入条件规定了值的范围，则应该取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据。如果输入条件规定

21、了值的个数，则用最大个数、最小个数、比最大个数多1个、比最小个数少1 个的数作为测试数据。第54页/共105页 根据规格说明的每一个输出条件，使用规则1。根据规格说明的每一个输出条件，使用规则2。如果程序的规格说明给出的输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个和最后一个元素作为测试用例。第55页/共105页 如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例。分析规格说明，找出其他可能的边界条件。第56页/共105页3.3.3 错误推测法 人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法

22、。错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。第57页/共105页3.3.4 因果图法 因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。利用因果图生成测试用例的基本步骤如下。分析软件规格说明的描述中哪些是原因，哪些是结果。原因是输入条件或输入条件的等价类，结果是输出条件。第58页/共105页 分析软件规格说明描述中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系，画出因果图。标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用若干标准的符

23、号标明约束条件。第59页/共105页 把因果图转换成判定表。为判定表中的每一列设计测试用例。通常在因果图中，用Ci表示原因，Ei表示结果，其基本符号如图3-12所示。第60页/共105页图3-12 因果图的基本符号 第61页/共105页 对于黑盒测试方法来说，以上4种方法是基本的测试方法，除此之外还有判定表驱动法、正交试验法、功能图法和场景法等。在实际测试中，往往是综合使用各种方法才能有效地提高测试效率和测试覆盖率，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效地提高测试水平。第62页/共105页 以下是各种测试方法选择的综合策略，可供读者在实际应用过程中参考。首先进行等价类划分，

24、包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力最强。第63页/共105页 可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法。第64页/共105页 对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。功能图法也是很好的测试用例设计方

25、法，我们可以通过不同时期条件的有效性设计不同的测试数据。对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。第65页/共105页3.3.5 场景法 现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。第66页/共105页 用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。1基本流和备选流 如图3-14所示，图中经过

26、用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。第67页/共105页图3-14 基本流和备选流第68页/共105页2ATM例子（1）例子描述图3-15所示是ATM例子的流程示意图。第69页/共105页图3-15 ATM流程示意图 第70页/共105页（2）场景设计 表3-8所示是生成的场景。第71页/共105页（3）用例设计 对于这7个场景中的每一个场景

27、都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。第72页/共105页第73页/共105页（4）数据设计 一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表3-10所示。第74页/共105页第75页/共105页3.4 测测 试试 用用

28、 例例 设设 计计 3.4.1 测试用例的基本概念 简单地说，测试用例就是设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果。第76页/共105页 如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且输入到问题跟踪系统内，通知软件开发人员。软件开发人员接到通知后，将问题修改完成于下一个测试版本内，测试工程师取得新的测试版本后，必须利用同一个测试用例来测试这个问题，确保该问题已修改完成。第77页/共105页 在测试时，不可能进行穷举测试，为了节省时间和资源，提高测试效率，必须要从数量极大的可用测试

29、数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。第78页/共105页 使用测试用例的好处主要体现在以下几个方面。在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。测试用例的使用令软件测试的实施重点突出、目的明确。第79页/共105页 在软件版本更新后只需修正少部分的测试用例便可开展测试工作，降低工作强度，缩短项目周期。功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断提高。第80页/共105页 测试用例主要有如下几种。功能测试用例。包含功能测试、健壮性测试、可靠性测试。性能测试用例。包含性能测试

30、、压力测试、强度测试。集成测试用例。包含接口测试、健壮性测试、可靠性测试。第81页/共105页 安全测试用例。安全测试用例。用户界面测试用例。用户界面测试用例、少量功能测试用例。安装/反安装测试用例。安装/反安装测试用例。测试种类、阶段和用例的关系如表3-11所示。第82页/共105页第83页/共105页 测试工作和开发通常一同进行，所以在完成测试计划编写后，就可以进行用例的编写工作了。测试和开发的对应关系如表3-12所示。第84页/共105页3.4.2 测试用例的设计步骤 测试按照阶段分为单元测试、集成测试以及系统测试。而各阶段都有相应的测试用例。这里，以单元测试的用例设计为依据来说明测试用

31、例的设计步骤。第85页/共105页 单元测试说明实际上由一系列单元测试用例组成，每个测试用例应该包含以下4个关键元素。被测单元模块初始状态声明，即测试用例的开始状态（仅适用于被测单元维持了调用间状态的情况）。被测单元的输入，包含由被测单元读入的任何外部数据值。第86页/共105页 该测试用例实际测试的代码，用被测单元的功能和测试用例设计中使用的分析来说明，如单元中哪一个决策条件被测试。测试用例的期望输出结果。测试用例的期望输出结果总是应该在测试进行之前在测试说明中定义。第87页/共105页下面说明测试用例的设计步骤。（1）步骤1：使被测单元运行这个阶段适合的技术有：模块设计导出的测试；对等区间

32、划分。第88页/共105页（2）步骤2：正面测试（Positive Testing）这个阶段适合的技术有：设计说明导出的测试；等价类分析；状态转换测试。第89页/共105页（3）步骤3：负面测试（Negative Testing）这个阶段适合的技术有：错误猜测；边界值分析；内部边界值测试；状态转换测试。第90页/共105页（4）步骤4：需求中其他测试特性用例设计这个阶段适合的技术有：设计说明导出的测试。第91页/共105页（5）步骤5：覆盖率测试用例设计 这个阶段适合的技术有：分支测试；条件测试；数据定义使用测试；状态转换测试。其中和均属于逻辑覆盖范畴。第92页/共105页（6）步骤6：测试执

33、行（7）步骤7：完善代码覆盖 这个阶段适合的技术有：分支测试；条件测试；设计定义试验测试；状态转换测试。第93页/共105页最后，总结一下用例设计的一般原则。通常应该避免依赖先前测试用例的输出，测试用例的执行序列早期发现的错误可能导致其他的错误而减少测试执行时实际测试的代码量。测试用例设计过程中，包括作为试验执行这些测试用例时，常常可以在软件构建前就发现BUG。还有可能在测试设计阶段比测试执行阶段发现更多的BUG。第94页/共105页 在整个单元测试设计中，主要的输入应该是被测单元的设计文档。在某些情况下，需要将试验实际代码作为测试设计过程的输入，测试设计者必须意识到不是在测试代码本身。第95

34、页/共105页3.4.3 测试用例的编写1测试用例计划的编写2测试设计说明3测试用例说明第96页/共105页测试用例的编写请参考表3-13。表3-13测试用例 第97页/共105页4测试程序说明 图3-16所示是“Windows计算器”的测试程序说明的例子片断。第98页/共105页图3-16 测试程序说明片断 第99页/共105页3.4.4 测试用例设计实例1软件设计说明导出的测试2基本路径测试3等价类划分4因果图法5边界值分析第100页/共105页3.4.5 测试用例的管理 可以把测试用例看成程序测试工程师编写的程序，这个程序也要经过“设计”、“开发”、“测试”、“版本管理”、“发布”、“维护”等一系列操作。第101页/共105页1用例评审有效的用例评审通常由下面两种形式组成。测试部门外部评审 测试部门内部评审 通常情况下先执行内部评审，然后执行外部评审。很多时候，内部评审会被忽略，建议要进行内部评审。第102页/共105页2用例管理版 本 管 理 是 用 例 管 理 的 核 心 部 分，建 议 采 用 工 具（例 如 Visual SourceSafe）对用例进行控制。建议用例参照图3-19进行管理。第103页/共105页图3-19 用例管理示意图 第104页/共105页感谢您的观看！第105页/共105页