Chapter 05_白盒测试用例设计方法(20121204140133)

1、软件测试技术测试用例设计（一）本章目标本章目标了解测试用例概述了解测试用例的优点了解测试用例的作用了解白盒测试用例常用设计方法测试用例设计（一）测试用例设计（一）掌握测试用例的作用掌握白盒测试用例的设计方法测试用例概述测试用例概述 如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。对一个测试工程师来说,测试用例的设计编写是一项必须掌握的能力，但有效的设计和熟练的编写测试用例却是一个十分复杂的技术，测试用例编写者不仅要掌握软件测试技术和流程

2、，而且要对整个软件不管从业务，还是对软件的设计、程序模块的结构、功能规格说明等都要有透彻的理解。测试的设计方法不是单独存在的，具体到每个测试项目里都有很多种方法，每种类型都有各自的特点。什么是测试用例什么是测试用例测试用例，英文为TestCase,缩写为TC，指的是在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。 测试用例设计的好坏直接决定了测试的效果和结果。所以说在软件测试活动中最关键的步骤就是设计有效的测试用例。 测试用例可以针对黑盒测试设计用例，也可以针对白盒测试设计用例.根据什么编写测试用例根据什么编写测试用例根据什么写测试用例呢？我们编写测试用例的

3、唯一标准就是用户需求用户需求, ,具体的参考资料是需求规格说明书,但需要说明的是，用户需求不是一成不变的，而是在一直变化的，这就需要我们根据不断调整变化的需求，来修改和维护我们已写好的测试用例，这个工作量也很大。为什么需要测试用例为什么需要测试用例在开始实施测试之前设计好测试用例，避免盲目测试并提高测试效率，减少测试的不完全性；测试用例的使用令软件测试的实施重点突出、目的明确；根据测试用例的多少和执行难度，估算测试工作量，便于测试项目的时间和资源管理与跟踪；减少回归测试的复杂程度，在软件版本更新后只需修正少量的测试用例便可展开测试工作，降低工作强度、缩短项目周期；功能模块的测试用例的通用化和复

4、用化则会使软件测试易于开展，并随着测试用例的不断细化其效率也不断攀升；根据测试用例的操作步骤和执行结果，为分析软件缺陷和程序模块质量提供依据；可以方便地书写软件测试缺陷报告；可以根据测试用例的执行等级，实施不同级别的测试；总结：软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例。好的测试用例的特征好的测试用例的特征可以最大程度地找出软件隐藏的缺陷可以最高效率的找出软件缺陷可以最大程度地满足测试覆盖要求既不过分复杂、也不能过分简单使软件缺陷的表现可以清楚的判定测试用例包含期望的正确的结果待查的输出结果或文件必须尽量简单明了不包含重复

5、的测试用例测试用例内容清晰、格式一致、分类组织测试用例的影响因素测试用例的影响因素测试用例设计的主要影响因素：需求目标，是功能性的需求目标也是非功能性的需求目标。功能性测试比较清楚，正确与否一目了然，而非功能性测试，其相对性比较强，需要从不同角度比照。用户实际使用场景。从用户的角度来模拟程序的输入，包括用户的操作习惯， 使产品更能贴近用户的需求。软件功能需求规格说明书、产品设计文档。测试方法对测试用例的设计影响非常大。测试对象。客户端软件和服务器端系统、分布式系统和集中式系统等。软件实现所采用的技术。设计测试用例基本原则设计测试用例基本原则设计测试用例的基本原则如下： 利用成熟的测试用例设计方

6、法来指导设计 测试用例的针对性 测试用例的代表性 测试用例的可判定性 测试用例的可重现性 足够详细、准确和清晰的步骤 测试用例必须符合内部的规范的要求测试用例的测试用例的4 4性性测试用例的4性是指代表性、针对性、可判定性、可重现性：代表性代表性：能够代表并覆盖各种合理的和不合理、合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。针对性针对性：对程序中的可能存在的错误有针对性地测试可判定性可判定性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果可重现性可重现性：对同样的测试用例，系统的执行结果应当是相同的。测试用例设计的指导思想测试用例设计的指导思想软件测试需求和

7、测试计划是测试用例的设计基础按照测试用例框架设计和详细设计进行分布式的测试根据测试质量目标，测试周期，测试成本，测试者技能，确定合适的测试用例数量和测试内容的详细程度分析用户实际使用的场景，被测试软件的类型特征和测试方法寻求系统设计、功能设计的弱点，设计测试用例以寻求软件存在的缺陷，而不是简单的复制软件设计规格说明文档既要设计正面的测试用例，也要设计负面的测试用例测试用例的元素测试用例的元素测试用例是对测试场景和操作的描述,所以必须给出测试目标、测试对象、测试环境要求、软件数据和操作步骤，预期结果，概括为5W1H1E。测试目标：Why为什么而测？功能、性能、易用性、可靠性、兼容性、安全性等。测

8、试对象：What测什么？被测试的项目、如对象、菜单、按钮等。测试环境：Where在哪里测？测试用例运行时环境，包括系统配置和设定等要求，也包括操作系统、浏览器、网络环境等。测试前提：When什么时候开始测？测试用例运行的前提或条件限制。输入数据：Which哪些数据？在操作时系统所接受的数据。操作步骤：How如何测？执行软件的先后次序步骤。预期结果：判定依据？执行用例后的判定依据。测试用例的元素测试用例的元素测试用例通常包括以下几个组成元素：测试用例编号测试用例名称测试用例设计者软件版本号测试目的参考信息测试条件测试环境输入数据 操作步骤 预期结果 测试用例的范例测试用例的范例IDID类型类型测

9、试步骤测试步骤输入数据输入数据期望的结果期望的结果001登录输入用户、密码，点击“登录”用户名：user密 码：987654提示登录成功002登录输入用户、密码，点击“登录”用户名：test密 码：987654提示用户名错误，请重新输入003登录输入用户、密码，点击“登录”用户名：user密 码：123456提示密码错误，请重新输入004登录输入用户、密码，点击“登录”用户名：密 码：123456提示用户名不能为空，请输入用户名005登录输入用户、密码，点击“登录”用户名：user密 码：提示密码不能为空，请输入密码006登录输入用户、密码，点击“登录”用户名：#密 码：123456提示用户名

10、错误，请重新输入登录功能测试用例：用户名为user,密码为987654测试用例的分类测试用例的分类测试用例的分类如下: 接口测试用例 路径测试用例 功能测试用例 容错能力测试用例 性能测试用例 界面测试用列 安全性测试用例 压力测试用例 可靠性测试用例 安装/反安装测试用例功能测试用例设计步骤功能测试用例设计步骤确定测试可用资源确定测试条件/环境确定测试条件优先级确定测试功能点确定功能点的期望结果设计测试用例的文字执行以验证测试用例修改并完成测试用例阅读测试参考文档测试用例入库功能测试用例设计方法功能测试用例设计方法设计用例模板确定测试输入数据测试设计规格说明软件测试需求软件需求文档软件设计规

11、格说明测试用例框架设计测试用例详细设计组织测试用例软件测试计划测试用例评审用例白盒测试用例设计方法白盒测试用例设计方法白盒测试用例的设计方法白盒测试用例的设计方法逻辑覆盖：以程序的内部逻辑结构为基础，分为语句覆盖、判定覆盖、判定-条件覆盖、条件组合覆盖等基本路径测试：在程序控制流程的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。白盒测试用例注意事项白盒测试用例注意事项由于测试路径可能非常多，由于时间和资源问题，选出足够多的路径测试由于深入到程序编码，通常开发人员协助测试人员书写白盒测试用例下面以例子进行分析讲解下面以例子进行分析讲解 示例代码如下：void DoW

12、ork(int x,int y,int z) int k=0,j=0; if(x3)&(z5) j=x*y+10; /语句块2 j=j%3; /语句块3画出上面函数的流程图画出上面函数的流程图Yes入口Noabc执行语句块2执行语句块1YesdNoe出口执行语句块3(x3)&(z5)语句覆盖语句覆盖为了说明简略，分别对各个判断的取真、取假分支编号为b、c、d、e。为了测试语句覆盖率只要设计一个测试用例就可以把三个执行语句块中的语句覆盖了。测试用例输入为： x=4、y=5、z=5程序执行的路径是：abd该测试用例虽然覆盖了可执行语句，但并不能检查判断逻辑是否有问题，例如在第一个判断中把&错误的写

13、成了|，则上面的测试用例仍可以覆盖所有的执行语句。可以说语句覆盖率是最弱的逻辑覆盖准则。 分支覆盖分支覆盖 对于上面的程序，如果设计两个测试用例则可以满足条件覆盖的要求。 测试用例的输入为： x=4、y=5、z=5 x=2、y=5、z=5 上面的两个测试用例虽然能够满足条件覆盖的要求，但是也不能对判断条件进行检查，例如把第二个条件y5错误的写成y3 取真值为T1，取假值为-T1条件z5 取真值为T4，取假值为-T4则可以设计测试用例如下: 测试用例测试用例 通过路径通过路径 条件取值条件取值覆盖分支覆盖分支x=4、y=6、z=5 abdT1、T2、T3、T4 bdx=2、y=5、z=5 ace

14、-T1、T2、-T3、-T4 cex=4、y=5、z=15 acdT1、-T2、T3、-T4 cd 上面的测试用例不但覆盖了所有分支的真假两个分支，而且覆盖了判断中的所有条件的可能值。 条件覆盖条件覆盖 但是如果设计了下面的测试用例，则虽然满足了条件覆盖，但只覆盖了第一个条件的取假分支和第二个条件的取真分支，不满足分支覆盖的要求。 测试用例测试用例 通过路径通过路径 条件取值条件取值覆盖分支覆盖分支x=2、y=6、z=5 acd-T1、T2、-T3、T4 cdx=4、y=5、z=5 acdT1、-T2、T3、-T4 cd条件覆盖条件覆盖分支条件覆盖分支条件覆盖 分支条件覆盖就是设计足够的测试用

15、例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行，即要求各个判断的所有可能的条件取值组合至少执行一次。 根据定义只需设计以下两个测试用例便可以覆盖8个条件值以及4个判断分支。 测试用例测试用例 通过路径通过路径 条件取值条件取值覆盖分支覆盖分支x=4、y=6、z=5 abdT1、T2、T3、T4 bdx=2、y=5、z=11ace-T1、-T2、-T3、-T4 ce分支条件覆盖从表面来看，它测试了所有条件的取值，但是实际上某些条件掩盖了另一些条件。例如对于条件表达式(x3)&(z3）为假则一般的编译器不在判断是否z5）来说，若x=4测试结果为真，就认为表

16、达式的结果为真，这时不再检查（y5）条件了。因此，采用分支条件覆盖，逻辑表达式中的错误不一定能够查出来了。 分支条件覆盖分支条件覆盖条件组合覆盖条件组合覆盖 条件组合覆盖就是设计足够的测试用例，运行被测试对象，使得每一个判断的所有可能的条件取值组合至少执行一次。 现在对例子中的各个判断的条件取值组合加以标记如下：1.x3,z3,z=10 记做T1 -T2， 第一个判断的取假分支3.x=3,z0 记做-T1 T2， 第一个判断的取假分支4.x=10 记做-T1 -T2，第一个判断的取假分支5.x=4,y5 记做T3 T4， 第二个判断的取真分支6.x=4,y5 记做-T3 T4， 第二个判断的取

17、真分支8.x!=4,y 0) if(0= =iType) x=y+2; else if(1= =iType) x=y+10; else x=y+20; ret = x;第一步：画出控制流图第一步：画出控制流图c/c+语句中的控制语句表示含义如下：图中的每一个圆称为流图的结点，代表一条或多条语句。流图中的箭头称为边或连接，代表控制流。为了说明流图的用法，我们采用过程设计表示法，此处，流程图用来描述程序控制结构。可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)。在流图中，每一个圆，称为流图的结点，代表一个或多个语句。一个处理方框序列和一个菱形决测框可被映射为一个结点，流图中

18、的箭头，称为边或连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个结点，即使该结点并不代表任何语句(例如：参见if-else-then结构的符号)。由边和结点限定的范围称为区域。计算区域时应包括图外部的范围。任何过程设计都要被翻译成控制流图。 画出其程序流程图和对应的控制流图如下：467810111314467148101113程序流程图 控制流图 程序设计中遇到复合条件时，生成的流图变得更为复杂。当条件语句中用到一个或多个布尔运算符(逻辑OR，AND，NAND，NOR)时，就出现了复合条件。 下图为语句IF a OR b中的每一个a和b创建了一个独立的结点，包含条件的结点被称为判定

19、结点，从每一个判定结点发出两条或多条边。例如： if a or b x else y 对应的逻辑为：21b1a23第二步：计算圈复杂度第二步：计算圈复杂度 圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。 有以下三种方法计算圈复杂度：1.流图中区域的数量对应于环型的复杂性；2.给定流图G的圈复杂度V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中结点的数量；3.给定流图G的圈复杂度V(G)，定义为V(G)=P+1，P是流图G中判定结点的数量。 对应上面图中的圈复杂度，计算如下：流图中有四个区域；V(G)=10条边-8结点+2=4;V(G)=3个判定结点+1=4。4671481011132134第三步：导出测试用例第三步：导出测试用例 根据上面的计算方法，可得出四个独立的路径：路径1：4-14路径2：4-6-7-14路径3：4-6-8-10-13-4-14路径4：4-6-8-11-13-4-14根据上面的独立路径，去设计输入数据，使程序分