测试用例和测试计划

一、 测试用例的概念和作用

1.1.引言

对一个测试工程师来说,测试用例的设计编写是一项必须掌握的能力，但有效的设计和熟练的编写测试用例却是一个十分复杂的技术，测试用例编写者不仅要掌握软件测试技术和流程，而且要对整个软件不管从业务，还是对软件的设计、程序模块的结构、功能规格说明等都要有透彻的理解。

测试的设计方法不是单独存在的，具体到每个测试项目里都有很多种方法，每种类型都有各自的特点。

1.2什么是测试用例

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说，测试用例就是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所设计的执行结果。

1.3测试用例的特征：

1.最有可能抓住错误的；

2.不是重复的、多余的；

3.一组相似测试用例中最有效的；

4.既不是太简单，也不是太复杂。

1、正确性：测试用例最好是要求输入用户实际数据已验证系统是否满足需求规格说明书的需求，并且测试用例中的测试的应保证至少覆盖需求规格说明书中的各项功能。2、完整性：一些基本功能，如有遗漏，那是不可原谅的。
3、准确：按测试用例输入实施测试后，要能根据测试用例描述的输出得出正确的结论，不能出现模糊不清的语言。
4、清晰、简洁：好的测试用例描述清晰，每一步都应有相应的作用，有很强的的针对性，不应出现一些无用的操作步骤。
5、可维护性：由于软件开发过程中需求变更等原因的影响，常常对测试用例进行修改、增加、删除等，以便测试用符合相应测试要求。
6、适应性：测试用例应该适合特定的测试环境以及符合整个团队的测试水平。
7、可重复性：要求不同测试者在同样的测试环境下使用同样测试用例都能得出相应结论。
8、可追溯性、可移植性

1.3编写测试用例的好处：

1.3.1测试用例的作用：

1.在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

2.测试用例的使用令软件测试的实施重点突出、目的明确。

3.在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。

4.检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。

二、需求分析

2.1什么是需求？
客户的需要的东西以及对东西的要求

2.2需求的种类有什么？

1.用户需求：关注系统是否满足用户习惯

2.行业业务需求（界面提示信息为行业术语，处理和操作模式为行业从业人员习惯模式等）

3.实际使用环境需求（网络带宽，速率，断电数据备份，软件部署设置等）

4.操作使用需求（类似快捷键，紧急关闭，数据恢复保护，回退机制，安装兼容性，语言环境等）

5.用户需求引发的测试需求（按软件测试质量模型进行划分）

6.功能需求：关注系统是否满足功能要求

三、测试用例的设计方法和编写

3.1如何设计测试用例？

对各个功能模块进行测试点分析提取测试点再对测试点进行用例编写

比如对PC端QQ账号的登录模块，提取测试点就有：

①正常登陆 ②账号为空时点击登录 ③密码为空时点击登录 ④账号密码都为空时点击登录 ⑤密码错误时点击登录 ⑥找回密码功能是否有效 ⑦记住密码功能是否有效 ⑧ 自动登录功能是否有效 9 多个qq号登录 10.二维码扫描登录

3.2编写测试用例应该注意什么

根据产品规格，测试基本功能；

考虑设计一般用户（非专业人员）的使用方案；

考虑设计稀有或特殊的使用方案；

与系统其他组成部分的配合（如FAX和上网可能要用到MODEM，？测试中考虑对设备的共享）；

考虑特殊情况（如内存和硬件的冲突等）；

设计极端情况（如内存泄漏、破坏性测试等）；

好的测试用例集能花费最小的代价（人力、物力、财力、时间）做最好的测试。

3.3测试用例的4个特性

代表性：能够代表并覆盖各种合理的和不合理、合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。

针对性：对程序中的可能存在的错误有针对性地测试

可判定性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果

可重现性：对同样的测试用例，系统的执行结果应当是相同的。

第一个数字和第二个数字都为0-10之间的数计算结果

？+？ = ？

1-10 1 -10正向（反向）测试用例

3.4测试用例通常包括以下几个组成元素：

测试用例编号测试用例名称测试用例设计者软件版本号测试目的

参考信息测试环境输入数据操作步骤预期结果测试结果 测试功能模块

3.5测试用例示例

四、编写测试用例的基本方法

4.1等价类划分法

4.1.1概念

有效，无效

等价类划分是指分步骤地把海量（无限）的测试用例集减得很小，但过程同样有效。

等价类：何为等价类，某个输入域的集合，在这个集合中每个输入条件都是等效的。

一般可分为有效等价类和无效等价类

比如：在一个系统中，填写一个多少岁的未成年人数学考了多少分（假设成年人年龄为x,0

那么年龄按照等价类划分可分为x<0,018,有效等价类是0<x<=18，无效等价类是x<0，x>18

数学成绩按照等价类划分可分为y<0,0<=y<=100,y>100,有效等价类是0<=y<=100，无效等价类是y<0，y>100

4.1.2示例

计算两个1～100之间整数的和。

如果要进行完全测试，一共要设计多少个测试用例呢？

加数1有1～100共计100个取值，加数2也有1～100共计100个取值，所以他们之间的组合就有100*100=10000种组合可能，但这只是测试了正常范围内的取值。如果用户输入的数据不在1～100之间呢，穷举测试肯定不可能的。由此引入了等价类划分思想。

等价类划分为：

有效等价类：指符合《需求规格说明书》，输入合理的数据集合

无效等价类：指不符合《需求规格说明书》，输入不合理的数据集合

我们将输入域分成了一个有效等价类（1～100）和两个无效等价类（<1,>100），并为每一个等价类进行编号，然后我们就可以从每一个等价类中选取一个代表性的数据来测试，设计如下表所示的测试用例

在任意文本输入框中可以填写的字符类型中文英文特殊符号空格数字

4.1.3练习案例

划分等价类并编号,下表为等价类划分的结果

4.2边界值法

　一般边界值分析是因为程序开发循环体时的取数可能会因为<,<=搞错。

比如下面代码

　　for(int i = 0;i <100; i ++)有效等价划分    -1   0    100 101 {

　　      int j = i+1;

　　     System.out.println("循环第“+j+"次")//循环地做某件事情

}

　　这里的程序是循环了100次，所以会做100次;

　　如果程序员不小心，把i <100写成i <= 100，则会溢出，这时候边界值检查是一个很好的测试方法。

比如：在一个系统中，填写一个多少岁的成年人数学考了多少分（假设成年人年龄为x,0

根据上面的等价类划分法我们可知，年龄的有效等价类是0

数学成绩的,有效等价类是0<=y<=100，所以边界值就是-1，0，100，101

对数据进行软件测试，就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。即使最简单的程序要处理的数据量也可能极大，使这些数据得以测试的技巧是，根据一些关键的原则进行等价类的划分，以合理减少测试用例，这些关键的原则是：边界条件，次边界条件、空值和无效数据。

4.2.1确定边界值的方法（）

确定边界情况（输入或输出等价类的边界）

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

输入要求是1～ 100之间的整数，因此自然产生了1和100两个边界，我们在设计测试用例的时，要重点考虑这两个边界问题。

注明:边界值不是从每个等价类中挑一个作为代表，而是把每个等价类的边界都进行测试。

4.3因果图法

4.3.1概念:

因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

4.3.2因果图基本图形符号

恒等：若原因出现，则结果出现；若原因不出现，则结果不出现。

非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现。

或（∨）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。

与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现。

4.3.3因果图的约束符号

E（互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立

I（包含）：表示三个原因中至少有一个必须成立

O（惟一）：表示两个原因中必须有一个，且仅有一个成立

R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现

M（屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b值不定

4.3.4因果图测试用例

例如：有一个处理单价为2.5元的盒装饮料的自动售货机软件。若投入2.5元硬币，按“可乐”、“啤酒”、或“奶茶”按钮，相应的饮料就送出来。若投入的是3元硬币，在送出饮料的同时退还5角硬币。

分析这一段说明，我们可列出原因和结果

原因(输入)：

投入2.5元硬币；

投入3元；

按“可乐”按钮；

按“啤酒”按钮；

按“奶茶”按钮。

中间状态：① 已投币；②已按钮

结果(输出)：

退还5角硬币；

送出“可乐”饮料；

送出“啤酒”饮料；

送出“奶茶”饮料；

4.4判定表法

4.5场景法

4.5.1测试用例设计的思想

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

用例场景是通过描述流经用例的路径来确定的过程，

这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。

基本流和备选流如图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：

场景1基本流

场景2基本流备选流 1

场景3基本流备选流 1 备选流 2

场景4基本流备选流 3

场景5基本流备选流 3 备选流 1

场景6基本流备选流 3 备选流 1 备选流 2

场景7基本流备选流 4

场景8基本流备选流 3 备选流 4

注：为方便起见，场景5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。

4.6银行案例ATM

个人标识号(PIN＝personal identification number )，用于保护智能卡免受误用的秘密标识代码。PIN 与密码类似，只有卡的所有者才知道该 PIN。只有拥有该智能卡并知道 PIN 的人才能使用该智能卡

第一次测试中，根据测试计划，我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流：

基本流-提取预设金额（100 元、200元、500元、1000元）

备选流2 - ATM内没有现金

备选流3 - ATM内现金不足

备选流4 - PIN有误

备选流5 -帐户不存在/帐户类型有误

备选流6 -帐面金额不足

4.7错误推测法

错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。

一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充。

例如，测试手机终端的通话功能，可以设计各种通话失败的情况来补充测试用例：

1)无SIM 卡插入时进行呼出（非紧急呼叫）

2)插入已欠费SIM卡进行呼出

3)射频器件损坏或无信号区域插入有效SIM卡呼出

4)网络正常，插入有效SIM卡，呼出无效号码（如1、888、333333、不输入任何号码等）

5)网络正常，插入有效SIM卡，使用“快速拨号”功能呼出设置无效号码的数字

技巧：最重要的是要思考和分析测试对象的各个方面，多参考以前发现的bug的相关数据，总结的经验，个人多考虑异常的情况、反面的情况、特殊的输入，以一个攻击者的态度对待程序，就能设计出比较完善的测试用例来。

4.8正交表法

正交实验法就是利用排列整齐的表-正交表来对试验进行整体设计、综合比较、统计分析，实现通过少数的实验次数找到较好的生产条件，以达到最高生产工艺效果，这种试验设计法是从大量的试验点中挑选适量的具有代表性的点，利用已经造好的表格—正交表来安排试验并进行数据分析的方法。正交表能够在因素变化范围内均衡抽样，使每次试验都具有较强的代表性，由于正交表具备均衡分散的特点，保证了全面实验的某些要求，这些试验往往能够较好或更好的达到实验的目的。正交实验设计包括两部分内容：第一，是怎样安排实验；第二，是怎样分析实验结果。

应用场景：在一个界面中有多个控件，每个控件有多个取值，控件之间可以相互组合，不可能（也没有必要）为每一种组合编写一条用例，如何使用最少最优的组合进行测试。——正交排列法

判定表，因果图也是考虑控件组合，但是组合数量较少（一般不会超过20中）

公式：Ln(mk)

k是表的列数，表示控件的个数（因数个数）

m是每个控件的取值个数（因数水平）

n是表的行数，也就是需要测试组合的次数

正交表查询地址：https://www.york.ac.uk/depts/maths/tables/orthogonal.htm

正交排列法：http://support.sas.com/techsup/technote/ts723_Designs.txt

正交表测试用例设计方法的特点是什么？

1、用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；

2、对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；

3、体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法

测试用例评审：分为组内评审组外评审

组内评审由所有的测试人员进行评审组外项目开发产品客户进行的贫身

参加评审会的对用例

评审内容评审的内容有以下几个方面

1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。

2)优先极安排是否合理。

3)是否覆盖测试需求上的所有功能点。

4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。

5)是否已经删除了冗余的用例。

6)是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在"保护"20%的功能实现。 7)是否从用户层面来设计用户使用场景和使用流程的测试用例。

8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

评审的方式
1)召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
2)通用邮件与相关人员沟通
3)通用IM工具直接与相关人员交流方式只是手段，得到其它人员对于用例的反馈信息才是目的。无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。

在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审

评审结束标准

在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审

测试计划

--------一场对所有软件BUG展开的歼灭战

确定测试范围

制定测试策略

测试资源安排

-------测试时间、工作量、人员

-------由于每个人的思维存在局限性，每项测试最后安排不少于2个人测试，以便交叉测试

进度安排

-------最好能预留一段缓冲时间，用于应对计划的变更，以及让测试员有时间完善和补充测试用例

风险及对策

-------可考虑建立后备机制

测试计划，应该包括:

软件缺陷和软件缺陷种类

软件缺陷的定义

软件缺陷，常常又被叫做Bug，从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

格蕾丝·赫柏（Grace Murray Hopper），是一位为美国海军工作的电脑专家，也是最早将人类语言融入到电脑程序的人之一。而代表电脑程序出错的“bug” 这名字，正是由赫柏所取的。1947年9月9日，赫柏对Harvard Mark II设置好17000个继电器进行编程后，技术人员正在进行整机运行时，它突然停止了工作。于是他们爬上去找原因，发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾，这显然是由于飞蛾受光和热的吸引，飞到了触点上，然后被高电压击死。所以在报告中，赫柏用胶条贴上飞蛾，并把“bug”来表示“一个在电脑程序里的错误”，“Bug”这个说法一直沿用到今天。

软件缺陷的种类划分

按照软件缺陷的产生原因，可以将其划分为不同的缺陷类别：

　　1、功能不正常

　　简单地说就是所应提供的功能，在使用上并不符合产品设计规格说明书中规定的要求，或是根本无法使用。这个错误常常会发生在测试过程的初期和中期，有许多在设计规格说明书中规定的功能无法运行，或是运行结果达不到预期设计。最明显的例子就是在用户接口上所提供的选项及动作，使用者操作后毫无反应。

　　2、软件在使用上感觉不方便

　　只要是不知如何使用或难以使用的软件，在产品设计上一定是出了问题。所谓好用的软件，就是使用上尽量方便，使用户易于操作。如微软推出的软件，在用户接口及使用操作上确实是下了一番功夫。有许多软件公司推出的软件产品，在彼此的接口上完全不同，这样其实只会增加使用者的学习难度，另一方面也凸显了这些软件公司的集成能力不足。

　　3、软件的结构未做良好规划

　　这里主要指软件是以自顶向下方式开发，还是以自底向上方式开发。如果是以自顶向下的结构或方法开发的软件，在功能的规划及组织上比较完整，相反以自底向上的组合式方法开发处的软件则功能较为分散，容易出现缺陷。

　　4、提供的功能不充分

　　这个问题与功能不正常不同，这里指的是软件提供的功能在运作上正常，但对于使用者而言却不完整。即使软件的功能运作结果符合设计规格的要求，系统测试人员在测试结果的判断上，也必须从使用者的角度进行思考，这就是所谓的“从用户体验出发”。

　　5、与软件操作者的互动不良

　　一个好的软件必须与操作者之间可以实现正常互动。在操作者使用软件的过程中，软件必须很好地响应。例如在浏览网页时，如果操作者在某一网页填写信息，但是输入的信息不足或有误。当点击“确定”按钮后，网页此时提示操作者输入信息有误，却并未指出错误的哪里，操作者只好回到上一页重新填写，或直接放弃离开。这个问题就是典型的在软件对操作互动方面未做完整的设计。

　　6、使用性能不佳

　　被测软件功能正常，但使用性能不佳，这也是一个问题。此类缺陷通常是由于开发人员采用了错误的解决方案，或使用了不恰当的算法导致的，在实际测试中有很多缺陷都是因为采用了错误的解决方法，需要加以注意！

　　7、为做好错误处理

　　软件除了避免出错之外，还要做好错误处理，许多软件之所以会产生错误，就是因为程序本身对于错误和异常处理的缺失。例如被测软件读取外部的信息文件并已做了一些分类整理，但刚好所读取的外部信息文件内容已被损毁。当程序读取这个损毁的信息文件时，程序发现问题，此时操作系统不知该如何处理这个情况，为保护系统自身只好中断程序。由此可见设立错误和异常处理机制的重要性！

　　8、边界错误

缓冲区溢出问题在这几年已成为网络攻击的常用方式，而这个缺陷就属于边界错误的一种。简单来说，程序本身无法处理超越边界所导致的错误。而这个问题，除了编程语言所提供的函数有问题之外，很多情况下是由于开发人员在声明变量或使用边界范围时不小心引起的。

9、计算错误

　　只要是计算机程序，就必定包括数学计算。软件之所以会出现计算错误，大部分出错的原因是由于采用了错误的数学运算工时或未将累加器初始化为0.

　　10、使用一段时间所产生的错误

　　这类问题是程序开始运行正常，但运行一段时间后却出现了故障。最典型的例子就是数据库的查找功能。某些软件在刚开始使用时，所提供的信息查找功能运作良好，但在使用一段时间后发现，进行信息查找所需的时间越来越长。经分析查明，程序采用的信息查找方式是顺序查找，随着数据库信息的增加，查找时间自然会变长。这就需要改变解决方案了！

　　11、控制流程的错误

　　控制流程的好坏，在于开发人员对软件开发的态度及程序设计是否严谨。软件在状态间的转变是否合理，要依据业务流程进行控制。例如，用软件安装程序解释这类问题最方便直观。用户在进行软件安装时，输入用户名和一些信息后，软件就直接进行了安装，未提示用户变更安装路径、目的地等。这就是软件控制流程不完整导致的错误问题。

　　12、在大数据量压力下所产生的错误

　　程序在处于大数据量状态下运行出现问题，就属于这类软件错误。大数据量压力测试对于Server级的软件是必须进行的一项测试，因为服务器级的软件对稳定性的要求远比其它软件要高。通常连续的大数据量压力测试是必须实施的，如让程序处理超过10万笔数据信息，再来观察程序运行的结果。

　　13、在不同硬件环境下产生的错误

　　这类问题的产生与硬件环境的不同相关。如果软件与硬件设备有直接关系，这样的问题就是数量相当多。例如有些软件在特殊品牌的服务器上运行就会出错，这是由于不同的Server内部硬件了不同的处理机制。

　　14、版本控制不良导致的错误

　　出现这样的问题属于项目管理的疏忽，当然测试人员未能尽忠职守也是原因之一。例如一个软件被反映有安全上的漏洞，后来软件公司也很快将修复版本提供给用户。但在一年后他们推出新版本时，却忘记将这个已解决的bug-fix加入到新版本中。所以对用户来说，原本的问题已经解决了，但想不到新版本升级之后，问题又出现了。这就是由于版本控制问题，导致不同基线的merge出现误差，使得产品质量也出现了偏差。

　　15、软件文档的错误

　　最后这类缺陷是软件文档错误。这里所提及的错误，除了软件所附带的使用手册、说明文档及其它相关的软件文档内容错误之外，还包括软件使用接口上的错误文字和错误用语、产品需求设计PD、UI Spec等的错误。错误的软件文档内容除了降低产品质量外，最主要的问题是会误导用户！

软件缺陷的属性

按照严重程度分:

一般分为5个等级:

系统崩溃，严重，一般，次要，建议

按优先级分:

修正优先级：高，中，低

Bug定级示例

1级，系统崩溃定义：严重阻碍测试和开发工作对应优先级：最高具体可分为：1.功能完全没有实现2.应用闪退/崩溃无法运行3.应用必现安全模式，无法运行4.其他导致功能无法测试的问题

2级，至关重要定义：非阻碍用例执行的严重问题对应优先级：高具体可分为：1.简单操作应用闪退/崩溃，卡死

2.数据丢失3.严重影响系统，自身功能无法运行4.严重数值计算错误5.数据库损坏或无法保存配置6.安全性问题（包括数据加密等）