软件测试技术 教学课件 ppt 作者 佟伟光 第03章

第3章软件测试的方法和技术3.1软件测试方法概述3.2白盒测试3.3黑盒测试3.4测试用例设计3.1软件测试方法概述软件测试的种类大致可分为人工测试和基于计算机的测试。而基于计算机的测试又可分为黑盒测试和白盒测试。1．黑盒测试黑盒测试是根据软件产品的功能设计规格，在计算机上进行测试，以证实每个已经实现的功能是否符合要求。黑盒测试意味着测试要在软件的接口处进行。2．白盒测试白盒测试是根据软件产品的内部工作过程，在计算机上进行测试，以证实每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。白盒测试把测试对象看做一个打开的盒子，允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。3.2白盒测试白盒测试也称为结构测试或逻辑驱动测试，前提是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能够按预定要求正确工作，而不管产品的功能，主要用于软件验证。白盒测试方法又可分为静态测试和动态测试。静态测试是一种不通过执行程序而进行测试的技术，其关键功能是检查软件的示和描述是否一致，没有冲突或者没有歧义。它瞄准的是纠正软件系统在描述、表示和规格上的错误，是任何进一步测试的前提。而动态测试需要软件的执行，当软件系统在模拟的或真实的环境中执行之前、之中和之后，对软件系统行为的分析是动态测试的主要特点。它显示了一个系统在检查状态下是正确还是不正确。白盒测试的动态测试要根据程序的控制结构设计测试用例，其原则是：（1）保证一个模块中的所有独立路径至少被使用一次；（2）对所有逻辑值均需测试true和false；（3）在上下边界及可操作范围内运行所有循环；（4）检查内部数据结构以确保其有效性。下面将介绍几种实用的白盒测试用例设计方法，包括程序插桩、逻辑覆盖、基本路径测试等。3.2.1程序插桩在软件动态测试中，程序插桩是一种基本的测试手段，有着广泛的应用。1．方法简介程序插桩方法是借助往被测程序中插入操作，来实现测试目的的方法。如果我们想要了解一个程序在某次运行中所有可执行语句被覆盖的情况，或是每个语句的实际执行次数，最好的办法是利用插桩技术。这里仅以计算整数X和整数Y的最大公约数程序为例，说明插桩方法的要点。图3-3给出了这一程序的流程图。图3-3插桩后求最大公约数程序的流程图R=R–QQ=Q–RC(5)=C(5)+1出口Q≠RC(3)=C(3)+1C(4)=C(4)+1Q≠RC(6)=C(6)+1C(2)=C(2)+1R=YQ=XC(1)=C(1)+1入口设计插桩程序时需要考虑的问题包括：①探测哪些信息；②在程序的什么部位设置探测点；③需要设置多少个探测点。2．断言语句在程序中特定部位插入某些用以判断变量特性的语句，使得程序执行中这些语句得以证实，从而使程序的运行特性得到证实。我们把插入的这些语句称为断言。这一做法是程序正确性证明的基本步骤，尽管算不上严格的证明，但方法本身仍然是很实用的。下面以求两个非负数NUM和DEN之商的Wensley迭代算法为例，对断言语句的作用做一简要说明。图3-5计算非负数之商的迭代程序procedureDIVIDE(NUM,DEN,E,Q)*Eistheaccuracyrequired.E≥0.Qisboth**theresultatexitandatanyinterimstage.**A.BandWaretheotherelementsoftheprogramvector.*Q:=0A:=0B:=DEN/2W:=1untilW<Eloopif(NUM–A–B)≥0thenQ:=Q+W/2A:=A+BendifB:=B/2W:=W/2endloopend图3-6插入断言后的迭代程序procedureDIVIDE(NUM,DEN,E,Q)*Eistheaccuracyrequired.E≥0.Qisboth**theresultatexitandatanyinterimstage.**A.BandWaretheotherelementsoftheprogramvector.*Q:=0A:=0B:=DEN/2W:=1@K:=0untilW<Eloop@assertW=1/2**K@assertA=DEN*Q@assertB=DEN*W/2@assertNUM/DEN(W<QandQ≤NUM/DENif(NUM(A(B)≥0thenQ:=Q+W/2A:=A+BendifB:=B/2W:=W/2@K:=K+1endloop@assertNUM/DEN(W<QandQ≤NUM/DENend3.2.2逻辑覆盖逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术，是通过对程序逻辑结构的遍历实现程序的覆盖，它是一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。这一方法要求测试人员对程序的逻辑结构有清楚的了解，甚至要能掌握源程序的所有细节。它属于动态测试。从覆盖源程序语句的详细程度分析，逻辑覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正条件判定覆盖。为便于理解，使用如下所示的程序，图3-7所示的是其流程图。图3-7参考例子流程图F结束x=1(a)AND(bORc)x=0开始Tintfunction1（boola，boolb，boolc）{intx;x=0;if(a&&(b||c))x=1;returnx;}1．语句覆盖为了暴露程序中的错误，程序中的每条语句至少应该执行一次。所以，语句覆盖的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。2．判定覆盖比语句覆盖稍强的覆盖标准是判定覆盖。按判定覆盖准则进行测试是指，设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假值均曾被满足。判定覆盖又称为分支覆盖。3．条件覆盖在设计程序中，一个判定语句是由多个条件组合而成的复合判定。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。4．条件判定组合覆盖条件判定组合覆盖的含义是：设计足够的测试用例，使得判定中每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。5．多条件覆盖多条件覆盖也称为条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。6．修正条件判定覆盖它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、or）连接的bool条件，每个条件对于判定的结果值是独立的。7．测试覆盖准则（1）Foster的ESTCA覆盖准则前面所介绍的逻辑覆盖其出发点似乎是合理的。所谓“覆盖”，就是想要做到全面而无遗漏。但是，事实表明，它并不能真的做到无遗漏。K.A.Foster从测试工作实践的教训出发，吸收了计算机硬件的测试原理，提出了一种经验型的测试覆盖准则。（2）Woodward等人的层次LCSAJ覆盖准则Woodward等人曾经指出结构覆盖的一些准则，如分支覆盖或路径覆盖，都不足以保证测试数据的有效性。为此，他们提出了一种层次LCSAJ覆盖准则。3.2.3基本路径测试上节的例子是个比较简单的程序段，只有两条路径。但在实际问题中，即使一个不太复杂的程序，其路径的组合都是一个庞大的数字。如果把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行零次和一次，就成为基本路径测试。设计出的测试用例要保证在测试中程序的每一条可执行语句至少执行一次。1．程序的控制流图控制流图是描述程序控制流的一种图示方式。其中基本的控制结构对应的图形符号如图3-8所示。在图3-8所示的图形符号中，圆圈称为控制流图的一个结点，它表示一个或多个无分支的语句或源程序语句。图3-8控制流图的图形符号CASE多分支结构选择结构IF选择结构UNTIL循环结构顺序结构WHILE循环结构图3-9（a）所示的是一个程序的流程图，它可以映射成图（b）所示的控制流图。图3-9程序流程图和对应的控制流图R4结点边11109874621（b）控制流图1186543217（a）程序流程图)区域R1R2R32．计算程序环路复杂性进行程序的基本路径测试时，程序的环路复杂性给出了程序基本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。所谓独立路径，是指包括若干未曾处理的语句或条件的一条路径。基本路径集不是惟一的，对于给定的控制流图，可以得到不同的基本路径集。通常环路复杂性可用以下3种方法求得。①将环路复杂性定义为控制流图中的区域数。②设E为控制流图的边数，N为图的结点数，则定义环路的复杂性为V(G)=E−N+2。③若设P为控制流图中的判定结点数，则有V(G)=P+1。3．基本路径测试法步骤基本路径测试法适用于模块的详细设计及源程序，其主要步骤如下。①以详细设计或源代码作为基础，导出程序的控制流图。②计算得到的控制流图G的环路复杂性V（G）。③确定线性无关的路径的基本集。④生成测试用例，确保基本路径集中每条路径的执行。3.2.4程序的静态测试1．源程序静态分析在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图、子程序表、宏和函数参数表等各类图形图表，可以清晰地标识整个软件系统的组成结构，使其便于阅读与理解，然后可以通过分析这些图表，检查软件有没有存在缺陷或错误。通常采用以下一些方法进行源程序的静态分析。（1）生成各种引用表①标号交叉引用表②变量交叉引用表③子程序（宏、函数）引用表④等价表⑤常数表（2）错误静态分析错误静态分析主要用于确定在源程序中是否有某类错误或“危险”结构。①类型和单位分析②引用分析③表达式分析④接口分析2．人工测试静态分析中进行人工测试的主要方法有桌前检查、代码审查和走查。经验表明，使用这种方法能够有效地发现30%～70%的逻辑设计和编码错误。（1）桌前检查由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析、检验，并补充相关的文档，目的是发现程序中的错误。（2）代码审查代码审查是由若干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步。第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为审查的依据。小组成员在充分阅读这些材料后，进入审查的第二步，召开程序审查会。（3）走查走查与代码审查基本相同，其过程分为两步。第一步也把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机，即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时程序的踪迹，供分析和讨论用。3.2.5其他白盒测试方法简介1．域测试域测试是一种基于程序结构的测试方法。域测试正是在分析输入域的基础上，选择适当的测试点以后进行测试的。2．符号测试符号测试的基本思想是允许程序的输入不仅仅是具体的数值数据，而且包括符号值，这一方法也因此而得名。3．Z路径覆盖分析程序中的路径是指检验程序从入口开始，执行过程中经历的各个语句，直到出口。4．程序变异程序变异方法是一种错误驱动测试。所谓错误驱动测试方法，是指该方法是针对某类特定程序错误的。经过多年的测试理论研究和软件测试的实践，人们逐渐发现要想找出程序中所有的错误几乎是不可能的。比较现实的解决办法是将错误的搜索范围尽可能地缩小，以利于专门测试某类错误是否存在。错误驱动测试主要有两种，即程序强变异和程序弱变异。最后，归纳一下白盒测试中各种测试方法的应用策略。在白盒测试中，可以使用各种测试方法的综合策略如下。（1）在测试中，应尽量先使用工具进行静态结构分析。（2）测试中可采取先静态后动态的组合方式：先进行静态结构分析、代码检查，再进行覆盖率测试。（3）利用静态分析的结果作为导引，通过代码检查和动态测试的方式对静态发现结果进行进一步的确认，使测试工作更为有效。（4）覆盖率测试是白盒测试的重点，一般可使用基本路径测试法达到语句覆盖标准；对于软件的重点模块，应使用多种覆盖率标准衡量代码的覆盖率。（5）在不同的测试节点，测试的侧重点不同：在单元测试阶段，以代码检查、逻辑覆盖为主；在集成测试阶段，需要增加静态结构分析等；在系统测试阶段，应根据黑盒测试的结果，采取相应的白盒测试。3.3黑盒测试黑盒测试也称功能测试或数据驱动测试，前提是已知产品所具有的功能，通过测试来检测每个功能是否都正常使用。黑盒测试方法主要有等价类划分、边界值分析、因果图、错误推测、功能图法等，主要用于软件确认测试。3.3.1等价类划分法等价类划分是一种典型的黑盒测试方法。使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。由于不可能用所有可以输入的数据来测试程序，而只能从全部可供输入的数据中选择一个自己进行测试。如何选择适当的子集，使其尽可能多地发现错误，解决的办法之一就是等价类划分。首先，把数目极多的输入数据，包括有效的和无效的，划分为若干等价类，而所谓等价类，是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等价于对这一类其他值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可用少量代表性测试数据，取得较好的测试结果。等价类的划分有以下两种不同的情况。①有效等价类②无效等价类划分等价类的原则如下。①按区间划分②按数值划分③按数值集合划分④按限制条件或规则划分在确立了等价类之后，建立等价类表，列出所有划分出的等价类，如表3-6所示。表3-6等价类表示例 输入条件 有效等价类 无效等价类 ··· ··· ··· ··· ··· ···再从划分出的等价类中按以下原则选择测试用例。①为每一个等价类规定一个惟一的编号。②设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类；重复这一步骤，直到所有的有效等价类都被覆盖为止。③设计一个新的测试用例，使其仅覆盖一个无效等价类，重复这一步骤，直到所有的无效等价类都被覆盖为止。3.3.2边界值分析法人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。选择测试用例的原则如下。①如果输入条件规定了值的范围，则应该取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据。②如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1个、比最小个数少1个的数作为测试数据。③根据规格说明的每一个输出条件，使用规则1。④根据规格说明的每一个输出条件，使用规则2。⑤如果程序的规格说明给出的输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个和最后一个元素作为测试用例。⑥如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例。⑦分析规格说明，找出其他可能的边界条件。3.3.3错误推测法人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。3.3.4因果图法因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。利用因果图生成测试用例的基本步骤如下。①分析软件规格说明的描述中哪些是原因，哪些是结果。原因是输入条件或输入条件的等价类，结果是输出条件。②分析软件规格说明描述中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系，画出因果图。③标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用若干标准的符号标明约束条件。④把因果图转换成判定表。⑤为判定表中的每一列设计测试用例。通常在因果图中，用Ci表示原因，Ei表示结果，其基本符号如图3-12所示。图3-12因果图的基本符号∧E1（d）与∨E1（c）或（b）非E1E1（a）恒等对于黑盒测试方法来说，以上4种方法是基本的测试方法，除此之外还有判定表驱动法、正交试验法、功能图法和场景法等。在实际测试中，往往是综合使用各种方法才能有效地提高测试效率和测试覆盖率，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效地提高测试水平。以下是各种测试方法选择的综合策略，可供读者在实际应用过程中参考。①首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。②在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力最强。③可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。④对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。⑤如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法。⑥对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。⑦功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。⑧对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。3.3.5场景法现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。1．基本流和备选流如图3-14所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。图3-14基本流和备选流2．ATM例子（1）例子描述图3-15所示是ATM例子的流程示意图。图3-15ATM流程示意图提款提款银行系统客户ATM操作员转账存款系统启动（2）场景设计表3-8所示是生成的场景。表3-8场景设计 场景1——成功提款 基本流 场景2——ATM内没有现金 基本流 备选流2 场景3——ATM内现金不足 基本流 备选流3 场景4——PIN有误（还有输入机会） 基本流 备选流4 场景5——PIN有误（不再有输入机会） 基本流 备选流4 场景6——账户不存在/账户类型有误 基本流 备选流5 场景7——账户余额不足 基本流 备选流6注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。（3）用例设计对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。表3-9测试用例表 TC（测试用例）ID号 场景/条件 PIN 账号 输入（或选择）的金额 账面金额 ATM内的金额 预期结果 CW1 场景1：成功提款 V V V V V 成功提款 CW2 场景2：ATM内没有现金 V V V V I 提款选项不可用，用例结束 CW3 场景3：ATM内现金不足 V V V V I 警告消息，返回基本流步骤6，输入金额 CW4 场景4：PIN有误（还有不止一次输入机会） I V n/a V V 警告消息，返回基本流步骤4，输入PIN CW5 场景4：PIN有误（还有一次输入机会） I V n/a V V 警告消息，返回基本流步骤4，输入PIN CW6 场景4：PIN有误（不再有输入机会） I V n/a V V 警告消息，卡予保留，用例结束（4）数据设计一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表3-10所示。表3-10测试用例表 TC（测试用例）ID号 场景/条件 PIN 账号 输入（或选择）的金额（元） 账面金额（元） ATM内的金额（元） 预期结果 CW1 场景1：成功提款 4987 809-498 50.00 500.00 2000 成功提款。账户余额被更新为450.00 CW2 场景2：ATM内没有现金 4987 809-498 100.00 500.00 0.00 提款选项不可用，用例结束 CW3 场景3：ATM内现金不足 4987 809-498 100.00 500.00 70.00 警告消息，返回基本流步骤6，输入金额 CW4 场景4：PIN有误（还有不止一次输入机会） 4978 809-498 n/a 500.00 2000 警告消息，返回基本流步骤4，输入PIN CW5 场景4：PIN有误（还有一次输入机会） 4978 809-498 n/a 500.00 2000 警告消息，返回基本流步骤4，输入PIN CW6 场景4：PIN有误（不再有输入机会） 4978 809-498 n/a 500.00 2000 警告消息，卡予保留，用例结束3.4测试用例设计3.4.1测试用例的基本概念简单地说，测试用例就是设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果。如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且输入到问题跟踪系统内，通知软件开发人员。软件开发人员接到通知后，将问题修改完成于下一个测试版本内，测试工程师取得新的测试版本后，必须利用同一个测试用例来测试这个问题，确保该问题已修改完成。在测试时，不可能进行穷举测试，为了节省时间和资源，提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。使用测试用例的好处主要体现在以下几个方面。①在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。②测试用例的使用令软件测试的实施重点突出、目的明确。③在软件版本更新后只需修正少部分的测试用例便可开展测试工作，降低工作强度，缩短项目周期。④功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断提高。测试用例主要有如下几种。①功能测试用例。包含功能测试、健壮性测试、可靠性测试。②性能测试用例。包含性能测试、压力测试、强度测试。③集成测试用例。包含接口测试、健壮性测试、可靠性测试。④安全测试用例。安全测试用例。⑤用户界面测试用例。用户界面测试用例、少量功能测试用例。⑥安装/反安装测试用例。安装/反安装测试用例。测试种类、阶段和用例的关系如表3-11所示。表3-11测试阶段与测试用例关系列表 测试阶段 测试类型 执行人员 单元测试 模块功能测试，包含部分接口测试、路径测试 开发人员 集成测试 接口测试、路径测试，含部分功能测试 开发人员，如果测试人员水平较高可以由测试人员执行 系统测试 功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试 测试人员 验收测试 对于实际项目基本同上，并包含文档测试；对于软件产品主要测试相关技术文档 测试人员，可能包含用户测试工作和开发通常一同进行，所以在完成测试计划编写后，就可以进行用例的编写工作了。测试和开发的对应关系如表3-12所示。表3-12测试用例编写的时间安排 开发阶段 依据文档 编写的用例 需求分析结束后 需求文档 系统测试对应的用例 概要设计阶段结束后 概要设计、体系设计 集成测试对应的用例 详细设计阶段 详细设计文档 单元测试对应的用例3.4.2测试用例的设计步骤测试按照阶段分为单元测试、集成测试以及系统测试。而各阶段都有相应的测试用例。这里，以单元测试的用例设计为依据来说明测试用例的设计步骤。单元测试说明实际上由一系列单元测试用例组成，每个测试用例应该包含以下4个关键元素。①被测单元模块初始状态声明，即测试用例的开始状态（仅适用于被测单元维持了调用间状态的情况）。②被测单元的输入，包含由被测单元读入的任何外部数据值。③该测试用例实际测试的代码，用被测单元的功能和测试用例设计中使用的分析来说明，如单元中哪一个决策条件被测试。④测试用例的期望输出结果。测试用例的期望输出结果总是应该在测试进行之前在测试说明中定义。下面说明测试用例的设计步骤。（1）步骤1：使被测单元运行这个阶段适合的技术有：①模块设计导出的测试；②对等区间划分。（2）步骤2：正面测试（PositiveTesting）这个阶段适合的技术有：①设计说明导出的测试；②等价类分析；③状态转换测试。（3）步骤3：负面测试（NegativeTesting）这个阶段适合的技术有：①错误猜测；②边界值分析；③内部边界值测试；④状态转换测试。（4）步骤4：需求中其他测试特性用例设计这个阶段适合的技术有：设计说明导出的测试。（5）步骤5：覆盖率测试用例设计这个阶段适合的技术有：①分支测试；②条件测试；③数据定义——使用测试；④状态转换测试。其中①和②均属于逻辑覆盖范畴。（6）步骤6：测试执行（7）步骤7：完善代码覆盖这个阶段适合的技术有：①分支测试；②条件测试；③设计定义——试验测试；④状态转换测试。最后，总结一下用例设计的一般原则。通常应该避免依赖先前测试用例的输出，测试用例的执行序列早期发现的错误可能导致其他的错误而减少测试执行时实际测试的代码量。测试用例设计过程中，包括作为试验执行这些测试用例时，常常可以在软件构建前就发现BUG。还有可能在测试设计阶段比测试执行阶段发现更多的BUG。在整个单元测试设计中，主要的输入应该是被测单元的设计文档。在某些情况下，需要将试验实际代码作为测试设计过程的输入，测试设计者必须意识到不是在测试代码本身。3.4.3测试用例的编写1．测试用例计划的编写2．测试设计说明3．测试用例说明测试用例的编写请参考表3-13。表3-13 测试用例编号： 编制人 审定人 时间 软件名称 编号/版本 测试用例 用例编号 参考信息（参考的文档及章节号或功能项）： 输入说明（列出选用的输入项，列出预期输出）： 输出说明（逐条与输入项对应，列出预期输出）： 环境要求（测试要求的软、硬件、网络要求）： 特殊规程要求： 用例间的依赖关系： 用例产生的测试程序限制：4．测试程序说明图3-16所示是“Windows计算器”的测试程序说明的例子片断。图3-16测试程序说明片断标识符：计算器。目的：本程序说明描述执行加法测试用例的步骤。特殊要求：本次测试不需要特殊的硬件和软件。程序步骤：日志：测试员按测试要求记录程序执行过程，所有必须填写的项都必须填写，包括问题的记录。设置3.4.4测试用例设计实例1．软件设计说明导出的测试2．基本路径测试3．等价类划分4．因果图法5．边界值分析3.4.5测试用例的管理可以把测试用例看成程序——测试工程师编写的程序，这个程序也要经过“设计”、“开发”、“测试”、“版本管理”、“发布”、“维护”等一系列操作。1．用例评审有效的用例评审通常由下面两种形式组成。①测试部门外部评审②测试部门内部评审通常情况下先执行内部评审，然后执行外部评审。很多时候，内部评审会被忽略，建议要进行内部评审。2．用例管理版本管理是用例管理的核心部分，建议采用工具（例如VisualSourceSafe）对用例进行控制。建议用例参照图3-19进行管理。图3-19用例管理示意图使用用例&维护&升级进入版本控制库修改用例用例评审编写用例