测试用例

测试用例

一、Test case的定义

测试用例，为了指导测试而编写的包含测试目的、测试环境、测试步骤和期望测试结果的一组文档。

二、Test case 的分类

测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例：

a) 正面测试用例：用于证明该需求已经满足；

b) 负面测试用例：反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求；

三、Test case的基本要素

Test case的基本要素包括：测试用例编号，测试标题，重要级别，测试输入，操作步骤，预期结果。

a)用例编号(ID)：定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。一般是自动生成的

b)测试标题(Title)： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “价格分类页面最后添加按价格段搜索的输入框 ” 。

c)路径(Path)：测试某个项目的某个部分。

d)状态(Status)：激活(Active) 关闭(closed)

e)分配(Assigned to)：分配给某人任务

f)优先级别(Priority\\level)： 定义测试用例的优先级别，数越小级别越高

g)测试类型(Test type)：

兼容性测试(Back Compat)

性能测试(Performance)

安全性测试(Security)

用户界面测试(UI测试)

错误处理测试(Error Handling)

安装测试(Setup)

h)自动化（Automated）

手工(Manual)

自动化(Automated)

i)自动优先级(Automation Priority)：采用自动化测试的程度，不必自动化测试(not necessary)

j)测试结果(Test Result)： test results

失败(Failed)

不确定(Inconclusive)

通过(Passed)

跳过(Skipped)、

k)测试概述(Test Summary)

l)测试步骤(Test Steps)：提供测试执行过程的步骤。对于较复杂的测试用例，测试用例的输入需要几个步骤完成。

m)历史(History)：History字段保存对测试用例的修改历史，每修改一次测试用例后保存，测试用例修改的部分保存在History中。在“Type your comment here”填写要说明的内容，填写的内容将在下面保存的区域内显示出来。

n)预期结果(Expected Results)：提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

四、编制测试用例

1、 测试用例文档

2、 测试用例的设置

3、 设计测试用例

五、测试用例的流程（见下页）

符合

逐步执行Test Steps

与预期结果比较

得到实际的输出结果

不符合

与原Test result显示结 果比较

符合

关闭

Test Result中选择passed

不符合

创建Bug

应用测试用例的流程

测试用例的几种设计方法

一、等价类划分

等价类划分主要适用于单个输入条件，输入为数值型的情况，如果输入规定了输入区间，可划分出一个有效等价类，两个无效等价类；如果输入只规定了输入范围，可划分出一个有效等价类，一个无效等价类。

二、边界值

边界值方法也是适用于单个输入条件的情况，输入类型可以数值、字符等，要测试的边界包括上点、下点、离点。

三、错误推测法

错误推测法主要是测试设计人员的测试经验相关,测试经验不同,设计出来的测试用例也区别很大。

四、因果图法

因果图方法考虑输入的组合，特别适用于多个输入条件相关有关联又相互约束的情况。

设计步骤：

1）罗列出输入与输出；

2）根据输入与输出画出因果图；

3）标出约束跟；

4）把因果图转化成判定表；

5）根据判定表的每一列设计测试用例。

五、判定表驱动法

判定表适合于解决多个逻辑条件的组合。将各种逻辑的组合罗列出来，避免遗漏。不能表达重复的操作。

判定表包括条件桩、条件项、动作桩、动作项。

条件桩：列出所有条件，次序无关；

条件项：列出所对应条件的所有可能情况下的取值；

动作桩：列出可能采取的操作，次序无关；

动作项：列出条件项各种取值情况下采取的操作。

设计步骤：

1）确定规则个数，条件及各条件取值的组合；

2）列出条件桩、动作桩；

3）列出条件项；

4）列出动作项；

5）初始化判定表；

6）规则简化、合并。

六、正交法

当输入条件很多时，因果图等设计方法设计出来的用例数往往多的惊人，用正交法可有效减少用例数。正交法的核心思想是从大量测试数据中选取有代表性的点来测试，从而

减少测试用例数。

设计步骤：

1）确定因子并画出正交表草图；

2）填充各因子的状态值；

3）加权筛选；

4）根据筛选过的正交表设计测试用例。

七、功能图法

功能图法适合于用来设计程序的控制结构的测试用例。有顺序、选择、重复三种控制结构。

设计步骤：

1）画出功能图；

2）生成局部测试用例；

3）生成测试路径；

4）合成测试用例。

八、场景法

场景法特别适用于控制流清晰的系统。

设计步骤：

1）画出程序控制流图（如果不能直接画出控制流图，可先画出程序流程图，再把流程图转换成控制流图）；

2）根据控制流图设计出场景；

3）根据场景设计测试用例。

中间可能会要计算环路复杂度V（G），计算公式如下：

V（G）=e-n+2

其中e是边的数目，n是结点的数目。

测试用例设计策略：

1、任何都要用边界值法；

2、用等价类划分补充测试用例；

3、根据测试设计人员经验用错误推测法追加测试用例；

4、根据程序逻辑追加逻辑测试用例；

5、根据程序情况，选择使用因果图法设计测试用例。

测试用例设计步骤：

1、根据设计规格设计基本的功能测试用例；

2、边界值测试用例；

3、状态转换测试用例；

4、错误推测测试用例；

5、异常测试用例；

6、性能测试用例。

另外还需反复利用八种测试用例设计方法对测试用例进行分解与合并，利用发散思维追加测试用例。

登录、添加、删除、查询模块的测试点小结

1、登录 2、添加 3、查询 4、删除

1、登录

① 用户名和密码都符合要求（格式上的要求）

② 用户名和密码都不符合要求（格式上的要求）

③ 用户名符合要求，密码不符合要求（格式上的要求）

④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ 2、添加

① ② 密码符合要求，用户名不符合要求（格式上的要求）

用户名或密码为空

数据库中不存在的用户名，不存在的密码

数据库中存在的用户名，错误的密码

数据库中不存在的用户名，存在的密码

输入的数据前存在空格

输入正确的用户名密码以后按[enter]是否能登陆

要添加的数据项均合理，检查数据库中是否添加了相应的数据留出一个必填数据为空

③ 按照边界值等价类设计测试用例的原则设计其他输入项的测试用例

④ 不符合要求的地方要有错误提示

⑤ 是否支持table键

⑥ ⑦ 3、删除

① ② 有数据被删除

③ 删除。

④ ⑤ ⑥ 按enter是否能保存

若提示不能保存，也要察看数据库里是否多了一条数据

删除一个数据库中存在的数据，然后查看数据库中是否删除

删除一个数据库中并不存在的数据，看书否有错误提示，并且数据库中没输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被输入的正确数据前加空格，看是否能正确删除数据

什么也不输入

是否指出table键

⑦ 是否支持enter键

4、查询

精确查询：

① 输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据

② 输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据

③ 输入格式或范围不符合要求的数据，看是否有错误提示

④ 输入数据库中不存在的数据

⑤ 不输入任何数据

⑥ 是否支持table键

⑦ 是否支持enter键

模糊查询：

在精确查询的基础上加上以下一点：

① 输入一些字符，看是否能查出数据库中所有的相关信息

用户注册和密码修改测试点

一、用户注册

只从用户名和密码角度写了几个要考虑的测试点，如果需求中明确规定了安全问题，Email，出生日期，地址，性别等等一系列的格式和字符要求，那就都要写用例测了~

以等价类划分和边界值法来分析

1、填写符合要求的数据注册： 用户名字和密码都为最大长度 （边界值分析，取上点）

2、填写符合要求的数据注册 ：用户名字和密码都为最小长度 （边界值分析，取上点）

3、填写符合要求的数据注册：用户名字和密码都是非最大和最小长度的数据（边界值分析，取内点）

4、必填项分别为空注册

5、用户名长度大于要求注册1位（边界值分析，取离点）

6、用户名长度小于要求注册1位（边界值分析，取离点）

7、密码长度大于要求注册1位（边界值分析，取离点）

8、密码长度小于要求注册1位（边界值分析，取离点）

9、用户名是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了，如含有空格，#等，看需求是否允许吧~）

10、密码是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了）

11、两次输入密码不一致（如果注册时候要输入两次密码，那么这个是必须的）

12、重新注册存在的用户

13、改变存在的用户的用户名和密码的大小写，来注册。（有的需求是区分大小写，有的不区分）

14、看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号显示

二．修改密码

当然具体情况具体分析哈~不能一概而论~

实际测试中可能只用到其中几条而已，比如银行卡密码的修改，就不用考虑英文和非法字符，更不用考虑那些ＴＡＰ之类的快捷键．

而有的需要根据需求具体分析了，比如连续出错多少次出现的提示，和一些软件修改密码要求一定时间内有一定的修改次数等等。

1、不输入旧密码，直接改密码

2、输入错误旧密码

3、不输入确认新密码

4、不输入新密码

5、新密码和确认新密码不一致

6、新密码中有空格

7、新密码为空

8、新密码为符合要求的最多字符

9、新密码为符合要求的最少字符

10、新密码为符合要求的非最多和最少字符

11、新密码为最多字符-1

12、新密码为最少字符+1

13、新密码为最多字符+1

14、新密码为最少字符-1

15、新密码为非允许字符（如有的密码要求必须是英文和数字组成，那么要试汉字和符号等）

16、看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号

17、看密码是否区分大小写，新密码中英文小写，确认密码中英文大写．

18、新密码与旧密码一样能否修改成功．

黑盒测试用例设计案例

假设现有以下的三角形分类程序。该程序的功能是，读入代表三角形边长的3个整数，判定它们能否组成三角形。如果能够，则输出三角形是等边、等腰或任意三角形的分类信息。图9.11显示了该程序的流程图和程序图。为以上的三角形分类程序设计一组测试用例。

【解】

第一步：确定测试策略。在本例中，对被测程序的功能有明确的要求，即：

（1）判断能否组成三角形；

（2）识别等边三角形；

（3）识别等腰三角形；

（4）识别任意三角形。因此可首先用黑盒法设计测试用例，然后用白盒法验证其完整性，必要时再进行补充。

第二步：根据本例的实际情况，在黑盒法中首先可用等价分类法划分输入的等价类，然后用边界值分析法和猜错法作补充。

等价分类法：

有效等价类

输入3个正整数：

(1)3数相等

(2)3数中有2个数相等，比如AB相等

(3)3数中有2个数相等，比如BC相等

(4)3数中有2个数相等，比如AC相等

(5)3数均不相等

(6)2数之和不大于第3数，比如最大数是A

(7)2数之和不大于第3数，比如最大数是B

(8)2数之和不大于第3数，比如最大数是C

无效等价类：

(9)含有零数据

(10)含有负整数

(11)少于3个整数

(12)含有非整数

(13)含有非数字符

边界值法：

(14)2数之和等于第3数

猜错法：

(15)输入3个零

(16)输入3个负数

第三步：提出一组初步的测试用例，如下表所示：

第四步：用白盒法验证第三步产生的测试用例的充分性。结果表明，上表中的前8个测试用例，已能满足对被测程序图的完全覆盖，不需要再补充其他的测试用例。

软件测试Bug和bug生命周期中的各种状态

所有软件开发过程的目的都是为客户（软件产品的终端用户）提供一个解决问题的方案（软件产品），以帮助客户更加高效地工作或生活（从时间和费用上来讲）。一个成功的软件开发过程就是为客户提供了所有他所要求的需求。

一个没有软件测试的软件开发过程是不完善的。软件测试是为了寻找并修复软件中的bug/错误，它可以帮助提高软件的质量，以保证用户可以正常使用软件产品。

什么是一个bug/错误？

软件中的bug 或者错误就是所有会影响软件整体或者部分功能的正常运行的软件行为。

怎样找到bug/错误？

我们主要依靠运行测试脚本或用例来找出那些软件产品中的不想看到的行为。

什么是测试用例？

测试用例是一类文档，测试用例中包含有用于执行的步骤或行为，而我们需要严格地按照这些步骤来执行以确认软件是否按照我们对它的期望执行。

发现bug或者错误后该怎么办？

一般在我们发现bug或者错误后，应该和开发人员交流以修复它。

从一个bug被发现到这个bug被关闭这一段时间，bug可能会有以下状态：new ，open Postpone，Pending Retest，Retest,Pending Reject,Reject,Deferred,closed.(请注意这里有很多种状态，我们需要根据不同情况来决定怎样或者是否需要跟开发人员沟通)

下面就对这几种状态进行以下解释：

New:（新的）

当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New

Assigned（已指派的）

当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”

Open（打开的）

一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”

Fixed（已修复的）

当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组

Pending Reset（待在测试的）

当bug被返还到测试组后，我们将bug的状态设置为“Pending Reset”

Reset(再测试)

测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”

Closed（已关闭的）

如果测试人员经过再次测试之后确认bug已经被解决之后，就将bug的状态设置为“Closed”

Reopen（再次打开的）

如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”

Pending Reject（拒绝中）

如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject”

Rejected(被拒绝的)

测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”

Postponed（延期）

有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”

Deferred（延期的）

有些情况一些特殊的bug显得不那么重要，同时也是可以消除的，这个时候我们可以将bug的状态设置为“Deferred”

用因果图来设计测试用例

使用因果图的好处

1 考虑了多个输入之间的相互组合、相互制约关系

2 能够帮助我们按一定步骤，高效率地选择测试用例，同时还能为我们指出，程序规格说明描述中存在着什么问题。

利用因果图导出测试用例需要经过的一般步骤

1.分析程序规格说明的描述中，哪些是原因，哪些是结果。

2.分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的因果图

3.在因果图上使用若干个特殊的符号标明特定的约束条件

4.把因果图转换成判定表

5.把判定表中每一列表示的情况写成测试用例

因果图基本符号

因果图实例讲解

某软件规格说明中包含这样的要求：

第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L;如果第二列字符不是数字，则给出信息M。

分开原因和结果

原因：1----第一列字符是A;

2----第一列字符是B;

3----第二列字符是一数字。

结果：21----修改文件;

22----给出信息L;

23----给出信息M。

此例子是讲解利用因果图设计测试用例的一个小例子。以中国象棋中走马的测试用例设计为例学习因果图的使用方法。

一、 分析中国象棋中走马的实际情况（下面未注明的均指的是对马的说明）

1、如果落点在棋盘外，则不移动棋子；2、如果落点与起点不构成日字型，则不移动棋子；3、如果落点处有自己方棋子，则不移动棋子；4、如果在落点方向的邻近交叉点有棋子（绊马腿），则不移动棋子；5、如果不属于1-4条，且落点处无棋子，则移动棋子；6、如果不属于1-4条，且落点处为对方棋子(非老将)，则移动棋子并除去对方棋子；7如果不属于1-4条，且落点处为对方老将，则移动棋子，并提示战胜对方，游戏结束。

二、 根据分析明确原因和结果

原因：1、 落点在棋盘上；

2、 落点与起点构成日字；

3、 落点处为自己方棋子；

4、 落点方向的邻近交叉点无棋子；

5、 落点处无棋子；

6、 落点处为对方棋子（非老将）；

7、 落点处为对方老将。

结果：21、不移动棋子；

22、移动棋子；

23、移动棋子，并除去对方棋子；

24、移动棋子，并提示战胜对方，结束游戏。

添加中间节点11，目的是作为导出结果的进一步原因，简化因果图导出的判定表

考虑结果不能同时发生，所以对其施加唯一约束O。原因5、6、7不能同时发生，所

以对其施加异约束E.

根据因果图建立判定表：(分为两表)

注：1、以上判定表中由于表格大小没有列出最后所选的测试用例；2、第2表中部分列被合并表示不可能发生的现象；3、通过中间节点将用例的判定表简化为两个小表。减少工作量。

四、根据判定表写测试用例表（略）

软件测试软件缺陷等级标准

按照CMM5中定义的规范，BUG一般分致命，严重，一般和提示。致命是严重影响产品的BUG，比如操作手册的错误，需求的错误等。严重是产品中使功能无法实现的BUG，

比如某个功能无法运行，GUI长时间僵死没有响应。一般是某个BUG的发生，只影响了一个功能，而其他功能可以正常运行。提示就是一些GUI的问题，或者友好性的问题。

更为详细的划分如下:

A类—严重错误，包括以下各种错误：

1． 由于程序所引起的死机,非法退出

2． 死循环

3． 数据库发生死锁

4． 因错误操作导致的程序中断

5． 功能错误

6． 与数据库连接错误

7． 数据通讯错误

-----------------------------------------------------------

B类—较严重错误，包括以下各种错误：

1． 程序错误

2． 程序接口错误

3． 数据库的表、业务规则、缺省值未加完整性等约束条件

-----------------------------------------------------------

C类—一般性错误，包括以下各种错误：

1． 操作界面错误（包括数据窗口内列名定义、含义是否一致）

2． 打印内容、格式错误

3． 简单的输入未放在前台进行控制

4． 删除操作未给出提示

5． 数据库表中有过多的空字段

-----------------------------------------------------------

D类—较小错误，包括以下各种错误：

1． 界面不规范

2． 辅助说明描述不清楚

3． 输入输出不规范

4． 长操作未给用户提示

5． 提示窗口文字未采用行业术语

6． 可输入区域和只读区域没有明显的区分标志

E类—测试建议