目录

测试用例什么是测试用例测试用例的要素白盒测试白盒测试的基本介绍白盒测试用例设计方法一、 逻辑覆盖法1.语句覆盖2. 判定覆盖3.条件覆盖4.判定-条件覆盖5.条件组合覆盖6.路径覆盖二、基本路径测试法总结黑盒测试分类功能测试性能测试测试设计方法1.等价类法2.边界值法3.判定表法4.因果图法5.状态迁移图法6.场景法7.正交实验法8.错误推测法9？流程分析法黑盒方法总结

测试用例

什么是测试用例

软件测试的核心，为了特定目的而设计的一组具有测试输入、执行条件、预期结果的输出文档

测试用例的要素

eg.测试qq邮箱登录功能

xx----xx—为了特定的目的—x---x—x---测试输入—执行条件----预期结果

用例编号、用例标题、测试项目、用例级别、预置条件、测试输入、执行步骤、预期结果

*实际工作中根据项目要求用例设计要素可以做调整，上述要素几乎覆盖常见用例设计模板

白盒测试

白盒测试的基本介绍

黑白盒一般配合测试，重点（业务复杂模块）进行白盒测试覆盖完全

黑盒：根据业务需求设计

白盒：根据系统内部实现（尽可能覆盖内部逻辑）

优点：代码覆盖率高

缺点：覆盖所有代码路径难度大（eg.在有多个逻辑判断时）

业务功能可能覆盖不全

测试开销大

白盒测试用例设计方法

各方法需尽可能达到100%覆盖

静态：测试过程中不执行代码

eg.

桌面检查：交叉解释？？代码审查：开发会议讲解代码等（进行规范）代码走查：其它与会人准备测试数据（测试用例）演示查看人工输入：更关心功能实现、代码扫描工具——减少检查编码的时间，但是不能替代前面三种

动态：测试过程中不执行代码

逻辑覆盖法（含语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖）、基本路径测试法，这两种是脚本写作的主要方法

覆盖率：度量测试完整性的一个手段

item：程序的逻辑结构*（语句、判定、条件、判定条件、判定套件、条件组合、路径）

一、 逻辑覆盖法

通过对程序逻辑结构的遍历实现程序的覆盖

eg.

1.语句覆盖

设计测试用例，使得程序中每条语句至少被执行一次

在六种逻辑覆盖标准值中，语句覆盖标准最弱：

eg.以上面的程序为例，当条件代码错误，仍然能顺利执行所有代码

2. 判定覆盖

也叫分支覆盖，设计测试用例，是的程序中的各判断的“真”和“假”至少被执行一次。即：程序中的每个分支至少执行一次

eg.案例代码中有判定2个，判定结果4个

设计测试用例执行了3个分支，分支覆盖率为3/4=75%

这种方法下同样会忽略条件中取or的情况

eg.

3.条件覆盖

设计测试用例，判定中的每个条件(同一语句中的多个条件)至少有一次取真值，有一次取假值

较比判定覆盖，增加了对判定中所有条件的测试，但条件覆盖并不能保证判定覆盖

eg.

4.判定-条件覆盖

设计测试用例，使得测试程序中国的每个判断本身的判定结果（真假）至少满足一次，同时，每个逻辑条件的可能值（真假）至少满足一次，同时，每个逻辑条件的可能值（真假）也至少能被满足一次。即同时满足100%判定覆盖和100%条件覆盖的标准）

满足判定-条件覆盖标准，一定能够满足条件覆盖、判定覆盖和语句覆盖。

判定条件覆盖会忽略条件中取或（or）的情况（后面的例子就不满足条件）

eg.

5.条件组合覆盖

条件组合覆盖：设计测试用例，使得被测试程序中的每个判定中条件结果的所有可能组合至少执行一次。

条件组合覆盖可以满足判定覆盖、条件覆盖、判定-条件覆盖

该类型不能保证所有路径被执行

eg.

6.路径覆盖

设计测试用例，覆盖程序中所有可能的路径

不要与语句覆盖混淆

优点：路径覆盖可以对程序进行彻底的测试，比以上5种的覆盖面更广

缺点：不满足条件覆盖、也不能够满足判定-条件覆盖

二、基本路径测试法

在程序控制流图的基础上，通过分析程序的环路复杂性，导出基本可执行路径集合，从而设计测试用例

基本路径测试法步骤：

eg.

（1）根据代码画出程序控制流图

（2）计算程序的环路复杂度

判断节点和语句节点用圆圈代表，箭头不变

环路复杂度可以用于判断路径条数是否完全

（3）导出可执行路径

保证每个节点都经过

（4）设计测试用例

总结

白盒应用场景 ：主要用于单元测试阶段

一般采用先静态、后动态的方法，如此修改成本低

设计用例一般使用基本路径测试；重点模块使用多种覆盖率标准

黑盒测试

分类

功能测试

逻辑功能测试

界面测试

易用性测试

安装测试

兼容性测试

性能测试

时间性能（事务响应时间等）

空间性能（系统资源消耗）

一般性测试

稳定性测试

负载测试：通过负载测试来确定在各种工作负载下，系统各项性能指标的变化情况。

压力测试：通过确定一个系统的瓶颈或者刚好不能接受的性能点，以获得系统能够提供的最大服务级别

测试设计方法

1.等价类法

等价类定义：所有测试的数据中，具有某种共同特征的数据子集

有效等价类 ：满足所有规则

无效等价类：只要有一条规则不满足即可

思考步骤可以分为下面几个方面：

1.确定有效等价类和无效等价类

2.有效等价类划分（题目条件，还要注意边界值（极值），中间再随意找个值）

3.无效等价类划分（与有效等价类相反，及其它特殊情况）

*注意：如以上的场景中，输入框一、二，同一用例选定正确一个错误输入，根据需求来判断对错

eg. [0,100]

x<0和x>100属于无效等价类

等价类划分是一种重要的额、常用的黑盒测试方法，不需要考虑程序内部结构，只需要考虑程序的输入规格即可，它将不能穷举的测试过程进行合理分类，从而保证设计出的测试用例具有完整性和代表性。

**eg.**1~100加法器分析(不能有中文、无效符号、小数等)

**eg.**对QQ账号进行测试，账号要求6-10位正整数

根据以上案例，当测试文本框类的程序可以考虑如下的情况：

1.文本框要求输入的长度

2.输入的类型

3.组成规则

4.是否为空

5.是否重复-区分大小写

6.是否去除空格

2.边界值法

大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部

边界值：选取正好等于、刚好大于/小于边界值作为测试数据

边界值法一般和等价类法会同时使用

eg.输入的参数值必须大于等于0且小于等于100的整数

eg.固定电话号码测试

地区码（3-4位）+电话号码（8位）

边界值的方法小结（？？？怪怪的）

如果输入条件规定了值的范围，则应该去到刚到这个范围的边界值，以及刚刚超过这个范围边界的值作为输入数据（上点，离点）

-两位证书加法器数的范围为-99~99，则应测试-99，-100和99,100

输入条件规定了值的个数

姓名要求1-20个字符，需要测试0,1，2,个字符和19,20,21个字符某商品信息查询系统，每页最多显示10条商品信息，我们就应该准备商品信息，使能够查询出10条、11条、1条、0条商品记录边界值和等价类的区别：边界值分析不是从某等价类中随便挑一个作为代表，而是这个等价类的每个边界都要座位测试条件

有效用例：一个用例覆盖尽可能多的有效等价类

无效用例：无效等价类覆盖一个即可

总结：边界值和等价类相辅相成

常见边界值：

但是，该方法具有局限性：使用等价类方法时,对于输入域和输入域存在关联时无法覆盖

eg.

3.判定表法

根据上面的例子，可以得到

条件状：输入（所有条件） 条件项：成功失败条件全组合（针对条件桩的取值）

动作桩：结果 （所有结果） 动作项：结果与条件桩对应值（针对动作桩的取值）

步骤：

（1）分析需求，确定条件桩和动作桩

（2）全组合条件得到条件项

（3）根据条件项依次填写动作项，得到初始判定表：写0,1

（4）简化判定表（合并相似规则（相同动作 ））

（5）输出用例（一个规则对应一条测试用例）

*合并使用“-”代表无关条件，选什么都不影响结果（但是为了防止少测，一般不用）

eg.支付宝个人账户注册——验证用户：

第一项要求输入手机号或者电子邮箱作为账户名，

第二项要求正确输入验证码，两者都验证成功后填写账户信息；

但如果第一项校验不正确，则报错（输入手机号或电子邮箱格式有误）；

如果第二项验证不成功，则报错L（验证码输入错误）、

采用该方法列表如下（可以先写好再继续分析精简可能性）：

最终输出的用例只有6种。

判定表发设计用例——规则（组合）数：2^n（n为条件数）

条件数：4→规则：16

条件数：5→规则：32

条件数：6→规则：64

条件数：7→规则：128

…

eg.评选三好学生，前提是遵纪守法

4.因果图法

因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适用于检查程序输入条件的各种组合情况。因果图测试用例常采用竖行

特点：

1.考虑所有输入/输出条件的相互制约关系以及组合关系

2.考虑输出条件之间的依赖关系

3.再根据分析的关系来转化为判定表的规则

因果图法产生的背景：

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到，但多个输入条件组合起来可能出错的情况却被忽视了。如果在测试时必须考虑输入条件的各种组合，则可能的组合数目是将天文数字，因此必须考虑采用一种适合描述多种条件的组合、相应产生的多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）

1.恒等-有因就有果，没有因就没有果

2.非-条件有一个是真，结果就是真，条件都是假，结果才是假

4.且（与）-条件都为真，结果才是真，一个条件为假，结果就是假

输入条件与结果之间的关系：

互斥、包含、唯一？？

因果图法基本步骤：

利用因果图导出测试用例需要经过一下几步骤：

①找出所有可能的原因，愿意即输入条件或输入条件的等价类②找出所有的结果，结果即输出条件③明确所有输入条件中回见的制约关系以及组合关系

·哪些条件不能组合到一起，哪些条件可以组合到一起④明确是所有输出条件之间的制约关系以及组合关系

·哪些输出结果不能同时输出，哪些输出结果可以同时输出⑤找出什么样的输入条件组合会产生哪种输出结果⑥把因果图转换成判定表/决策表⑦为判定表/决策表中的每一列表示的情况设计测试用例

eg.可以根据因果图（通常不用画出来，只需要找到关系）列测试用例表格

可以写成如下的测试用例：

（和判定表法非常类似了，但需要的条件写1，不用的条件不写）

eg.上例中采用因果图法进行

（1）分析需求，获取条件和动作

（2）分析条件与条件、条件与动作之间的关系

（3）通过关系画出因果图

（4）将因果图转换为判定表

判定表和因果图的区别

1.找到左右输入条件编号

2.找到所有输出条件编号

3.找出所有输入、输出的制约关系

5.状态迁移图法

以上的方法均针对单个功能点，还需要测试系统整体业务流程

首先需要找出所有的状态，分析各个状态之间的转换条件和转换路径；随后从起状态迁移路径覆盖的角度来设计测试用例。该方法多用于协议测试（eg.TCP协议、状态机）

状态迁移图测试步骤：

（1）分析需求，找到状态节点

（2）画出状态迁移图

（3）画出状态迁移树

（4）扎到状态钱一书路径，转化为用例

eg.飞机售票系统

要求

预定：只有输入无输出——树根

已使用/已取消：只有输出无输入——树叶

从树根到树叶的整条路径为一条测试路径：

抽取4条路径：

路径1：预定-已取消

路径2：预定-已支付-已取消

路径3：预定-已支付-已出票-已取消

路径4：预定-已支付-已出票-已使用

6.场景法

现有的软件几乎都是用事件触发来控制流程的，事件触发时的情景便成了场景，而同一事件的不同的触发顺序和处理结果就形成事件流。价格这种在软件设计方面的私信啊引入到软件测试中，生动的描绘出时间出发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易得到理解和执行。

产品经理会给业务需求，直接可以写测试用例

当拿到一个测试任务时候，我们并不是先关注某个空间的边界值、等价类是否满足要求，而是先要关注它的主要功能和业务流程是否正确实现，这就需要使用场景法来完成测试。当业务流程测试（场景法，直接试程序）没有问题，也就是该软件的主要功能没有问题时，我们再重点从边界值、等价类的方面对空间进行更细致、完整测试

？从流程的开始到结束称为一个场景；

冒烟测试主要采用场景法进行测试。

需要找全场景：所有路径都覆盖

用例场景重要概念：

基本流

· 按照正确的业务流程来实现的一条操作路径（模拟正确的操作流程）备选流

·导致程序出现错误的操作流程（模拟错误的操作流程）备选流的特殊场景（异常流）

用例场景是用来描述流经用例路径的过程，这个过程从开始到结束遍历用例中所有基本流和备选流

在使用场景法设计测试用例时，需要覆盖系统用例中的主要成功场景和扩展场景，并且需要适当补充各种正反面的测试用例和考虑出异常场景的情形。

*场景法步骤：

分析需求，基本流和备选流

↓

根据基本流和备选流生成场景

↓

根据场景生成用例

前5 条覆盖了所有路径（后面几条？？？）

场景1：基本流

场景2：基本流-备选流程1-基本流

场景3：基本流-备选流程2-基本流

场景4：基本流-异常流程1

场景5：基本流-备选流程2-异常流程2

场景6：基本流-备选流程1-备选流程2-异常流程2

场景7：基本流-备选流程1-备选流程2-基本流

场景8：基本流-备选流程1-异常流程1

eg.仍然使用以上支付宝注册的案例

测试用例：

用例1：第一项输入手机号，第二项验证码正确，进入填写账户信息页面

用例2：第一项输入电子邮箱，第二项验证码正确，进入填写账户信息页面

用例3：第一项输入不是手机号或者电子邮箱，报错L（输入手机号或电子邮箱格式错误）

用例4：第一项输入手机号或者电子邮箱，第二项验证码错误，报错M（验证码输入错误）

7.正交实验法

正交排列法能够使用最小的测试过成绩和获得最大的测试覆盖率，当可能的输入数据的组合数量很大时，由于不可能为每个输入组合都创建测试用例，可以采用这种方法。

正交实验设计方法：是由数理统计学科中正交实验方法进化出的一种测试多条件多输入的用例设计方法，从大量的（实验）数据（测试例）中挑选适量的，有代表性的点（这些点具有“均匀分散，齐整可比”的特点），从而合理地安排实验（测试）的一种科学实验设计方法。具有高效、快速、经济、的特点。

正交表的概念：正交表是一种特制的表，一般指的正交表即为：Ln(M^k)

n为表的行数，也就是需要测试组合的次数k是表的列数，表示控件的个数（因素的个数，或因子数）m是每个控件包含的取值个数（各因素的水平数，即各因素的状态数）eg：L9(3^4)

·有4个控件

·每个控件有3个取值

·含9位需要测试的组合个数（由正交表由因子和水平会给出试验用例数目）

·称为 4因素3水平

条件：因子

取值：水平

正交排列法的使用步骤：

1.根据所测程序中空间的个数（因素以及每个控件的屈指个数（水平），选取一个合适的正交排列表2.把空间极其取值列举出来，并对其进行编号3.把空间极其取值映射到正交排列表中

·把正交排列表中的ABCD（因子）分别替换成4个控件

·把每列中的1,2，3（状态）分别换成这个空间的3个取值（水平），排列顺序要按照表中给出的顺序根据映射好的正交排列表编写测试用例

**如何查找正交表：**根据因子和水平数查找

网站/techsup/technote/ts723_Designs.txt数理统计、试验设计等方面的书及附录中

正交表使用方法：

根据控件和取值选择一个合适的正交表列举取值并编号，生成取值表把取值表与选择的正交表进行映射

eg.若进行网站兼容性测试、要求满足以下条件：

（1）Web浏览器：Nescape 6.2、IE 6.0、Opera 4.0

（2）插件：无、RealPlayer、MediaPlayer

（3）应用服务器：IIS、Apache、Netscape Enterprise

（4）操作系统：Windows 2000、Windows NT、Linux

解：需要查4因子3水平，查询正交表：

Column-Number：4因子

Experiment-Number：实验次数

以（3,1）为例，1代表，第三个用例中因子1选用水平1

进行详细的替换：

在此之前可以先列一张简单表格

eg2. 某银行交易系统的卡号查询功能界面如图所示

5因子2水平（输入或不输入），但是并不能找到2^5的表。

此时应该选择的正交表，满足以下条件：

表中的因素数>=5表中至少有5个因素的水平数>=2行数取最少的一个

所以，只有7因子2水平表最为接近： L8（2^7）

只对前5种因子进行替换：

并且，它也存在局限性：

目前常见的正交排列表只有前面附录文件中的几种及时是已有额正交排列表，基本要求每个控件中取值的个数要相等，这在实际软件中很少有

没有现成的正交排列表？

通过正交排列发的学习，我们更多的应该学习到一种测试思想，月就是在所有组合集合中旋球测试数据时，应该均匀度的选取其中的组合作为测试用例，而不要只在某个局部选取数据。

**混合正交表：**水平数（变量）的水平数（变量的取值）不相同

在实际情况中经常遇上

eg.

利用正交表生成工具allpairs

· 很多情况下无法找到合适的正交表，就要是引用正交报表生成工具

· 使用步骤：

1. 制作取值表（只列出数据即可，不用编号）

.

2.复制取值表的数据，放到文本文档汇总保存（注意不要更改任何格式，例如文件叫Test2.txt）

3. 把文本文档放在allpairs文件夹中

4. win+r后输入cmd进入控制台

5. 进入allpair文件夹

6. 在控制台中输入allpairs.exe.Test2.txt>chenggong.txt （chengong是自定义的名，用来存放生成的组合用例，表可以自动生成，不必提前建好）

Test CASES即为正交表

不过，采用该方法进行测试的最少组合数量，但是，在测试中有余下的多种组合并没有测试（以四因子三水平法为例，本来需要测试3^^4=81种，所以采用正交图法还有72种未测），如果时间允许，应该再对一些用例进行补充。因为遗漏的组合越多，存在缺陷的可能性就越大。（关系到时间问题，如内测、公测等）

8.错误推测法

错误推测法是指利用直觉和经验猜测出出错的可能类型，有针对性列举出程序中所有可能的错误和容易发生欧五额情况，它是测试经验丰富的测试人员喜欢使用的一种测试用例设计方法

基本思想：

列举出可能犯错或者易发生的清单，然后根据清单编写测试用例，这种方法很大程度上是凭经验进行的，即凭人们额对过去所作测试结果的分析，对所揭示缺点的规律性做直觉的推测来发现缺陷。

使用场景：一般和以上方法配合使用

采用错误推测法，最重要的是要思考和分析测试对象的各个方面，多参考以前发现的Bug相关数据、总结经验，个人多考虑异常情况、特殊的输入，以一个工具这的调度对待程序，才能够设计出比较完善的测试用例

9？流程分析法

已有流程图，流程已知（也常用在冒烟测试）

流程分析法主要是针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，是从白盒设计方法中的路径覆盖分析法借鉴过来的一种方法。

在白盒测试中，路径就是指函数代码的某个分值组合，路径覆盖法需要狗仔足够的用例覆盖函数的所有代码路径在黑盒测试中，若将软件系统的某个流程看成路径的话，则可以针对该路径使用路径分析的方法设计测试用例。

优点：

降低了测试用例设计难度，只要搞清楚各种流程，就可以设计出高质量的测试用例来，而不能需要太多测试方面的经验在测试时间紧迫的情况下，可以由放矢的选择测试用例，而不用完全根据经验来取舍。

步骤：

详细了解需求根据需求说明或界面原型，找出业务流程的各个叶绵绵以及各页面之间的流转关系画出业务流程（产品经理使用Axure软件制作）写用例，覆盖所有的路径分支（正常、异常、错误流程）

流程分析法总结：

流程分析法适用于有先后顺序的测试。常用于业务流程测试、安装流程测试流程分析法重点在于测试流程。因此，一般每个流程用一个测试用例验证。

它只是在测试整理流程是否正确，细节还需要使用等街垒、边界值等方法进行具体分析

黑盒方法总结

测试防范的选择：

通常再去顶测试方法时，应遵循一下原则：

根据程序的和总要型和一旦发生故障将造成的损失来确定测试等级和测试重点。认真选择测试策略，一边能尽可能少的使用测试用例，发现尽可能多的程序错误。因为一次完整的软件测试过后，如果程序占一流的错误过多并且严重，则表明更改此测试时不足的，而测试不足则意味着让用户承担隐藏错误带来的风险，但测试过度也会资源浪费，所以需要找到一个平衡点

选定测试方法时，需要参考几条参考原则（1/2）：

（1）拿到一个测试任务时，先关注它的主要功能和业务流程，业务逻辑是否正确实现，考虑使用场景法（2）需要输入数据的地方，考虑采用等价类划分法，包括输入条件和输出条件的等价划分，将无限测试变为有限测试（3）再任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强。（4）如果程序的功能说明中含有输入条件的组合请款，则一开始就应该考虑选用因果图和判定表法。（5）对于参数配置类的软件，需要考虑参数之间的组合情况，考虑使用正交排列法选择较少的组合方式（最少的测试用例获得最大的测试覆盖率）（6）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充更多的测试用例（7）采用错误推断法再追加测试用例——依靠测试工程师的经验

测试用例的力度：

测试用例的本质：

*测试用例设计并不是一个阶段。测试用例的涉及也需要迭代，再软件开发的不同阶段都要回来重新评审和完善测试时间。

测试用例评审：

1.同行评审

测试用例的检查方式有很多，同行评审是其中最敏捷的一种个体和交互比过程和共聚更有价值，强调了测试用例设计者间的探讨、写作

2.用户评审：

- 顾客（程序员）的写作比合同谈判更有价值