设计测试用例一般有8个方法,分别是等价类划分、边界值、场景法、因果图、判定表、正交排列表、状态转换图、测试大纲法等

一、等价类划分及边界值

首先这两个设计测试用例的方法一般是一起的,等价类划分即将所有合理的、有意义的或不合理的、无意义的数据分为有效等价类和无效等价类,运用有限的测试用例去覆盖无穷的数据输入,而边界值则是对等价类划分的补充。

设计测试用例的步骤:

  • 划分等价类
  • 细化等价类划分
  • 建立等价类表
  • 根据等价类表划分编写测试用例

其中,当我们熟练了之后,2、3步骤可以忽略

我们以实际例子说明。

需求:

年龄输入框:1-99整数,可以为空

分析步骤:

1、划分等价类

1)有效等价类

①1-99整数;

②为空;

2)无效等价类

①<1的整数;

②>99的整数;

③小数;

④特殊字符;

2、细分等价类(加入边界值)(可省略)

1)有效等价类

①1-99整数,如1(边界),2(边界),55,98(边界)、99(边界)

②为空,空格

2)无效等价类

①<1的整数,如0(边界),-1,-100

②>99的整数,如100(边界),999,无穷大

③小数,如0.1,10.55,小数点后多位

④特殊字符,如!、@、*、%或组合)……&等

3、建立等价类表(可省略)

将输入的数据和预期结果以表格展示出来,下图示例

年龄
编号 输入数据 预期结果
1 1 通过
2 2 通过

4、根据等价类表划分编写测试用例

二、场景法

现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。

设计测试用例的步骤:

  • 根据说明(流程图),描述出程序的基本流及各项备选流
  • 根据基本流和各项备选流生成不同的场景
  • 对每一个场景生成相应的测试用例

举例,下面是一个简单登录的流程图

liuchengtu1、根据说明(流程图),描述出程序的基本流及各项备选流

基本流:

基本流1:输入正确的用户名

基本流2:输入正确的密码

基本流3:点击“登录”按钮,程序能正常登录

备选流:

备选流1:不输入用户名和密码

备选流2:输入正确的用户名,错误的密码

备选流3:密码为空

备选流4:用户名为空

备选流5:输入错误的用户名,正确的密码

备选流6:输入错误的用户名,错误的密码

2、根据基本流和各项备选流生成不同的场景(部分举例)

场景描述 基本流 备选流
场景1:输入正确的用户名及密码点击登录,成功登录 基本流  
场景2:用户名、密码为空点击登录程序给与提示 基本流 备选流1

 V表示Valid,有效的,I表示Invalid,无效的。

编号 场景 用户名 密码 预期结果
1 场景1:成功登录 V V 提示登录成功
2 场景2:用户名、密码为空,登录失败 I I 给与错误提示

3、对每一个场景生成相应的测试用例

  用例描述中详细写出测试数据。

三、因果图、判定表

因果图是一种利用图解法分析输入与输出的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。因果图和判定表一般是同时使用的。

设计测试用例的步骤:

  • 找出所有输入条件并编号,即“原因”
  • 找出所有输出条件并编号,即“结果”
  • 明确输入与输出之间的关系(制约关系和组合关系)
  • 根据因果图,写出判定表
  • 根据判定表写出测试用例

举例:

需求:›有一个饮料自动售货机(处理单价为5角钱硬币)的控制处理软件,它的软件规格说明如下:

  • 若投入5角钱的硬币,按下“橙汁”或“啤酒”的按钮,则相应的饮料就送出来。若投入1元钱的硬币,同样也是按“橙汁”或“啤酒”的按钮,则自动售货机在送出相应饮料的同时退回5角钱的硬币。
  • 不能同时投两个硬币,不能一次同时购买2瓶及以上饮品。

1、找出所有输入条件并编号

  • 投入1元硬币(1)
  • 投入5角硬币(2)
  • 按下“橙汁”按钮(3)
  • 按下“啤酒”按钮(4)

2、找出所有输出条件并编号 

  • 退还5角(a)
  • 送出“橙汁”饮料(b)
  • 送出“啤酒”饮料(c)
  • 错误提示(d)
  • 退还1元(e)

3、明确输入与输出之间的关系(图省略)

如1、2为互斥,3、4为互斥;ab、ac、ad、de可以组合,bcd可以单独出现;ae、bc、bd、cd、be、ce互斥

图示例:13组合输出ab

yinguotu

›4、根据因果图,写出判定表

 1表示选择输入条件及造成的输出结果,以列来看

  1 2 3 4 5 6 7 8
输入 1 投币1元 1 1     1      
2 投币5角     1 1   1    
3 按下橙汁 1   1       1  
4 按下啤酒   1   1       1
 
输出 a 退回5角 1 1       1    
b 送出橙汁 1   1          
c 送出啤酒   1   1        
d 错误提示         1 1 1 1
e 退还1元         1      

5、根据判定表写出测试用例

退还1元硬币,提示错误

用例编号 用例操作 预期结果
1 投入1元硬币,按下“橙汁”按钮 送出橙汁,退还5角硬币
2 投入1元硬币,按下“啤酒”按钮 送出啤酒,退还5角硬币
3 投入5角硬币,按下“橙汁”按钮 送出橙汁
4 投入5角硬币,按下“啤酒”按钮 送出啤酒
5 投入1元硬币 退还1元硬币,提示错误
6 投入5角硬币 退还5角硬币,提示错误
7 按下“橙汁”按钮 提示未投币
8 按下“啤酒”按钮 提示未投币

四、正交排列表

常用正交表下载:http://pan.baidu.com/s/1bpMCjBT

通过已有的正交排列参考表将要测试的因素代入进去,可以已最少的用例覆盖最多的可能

举例:测试一个字符属性设置功能(选项),测试过程中需要考虑4个方面问题。

  • 字符类型:中文、英文、特殊符号
  • 字符属性:字型字号、普通效果、特殊效果
  • 字符位置:单元格、排版框、区域
  • 操作系统:Windows98、 Windows2000、Linux

因为是4个因素,每个因素里还有3个可能,所以我们可以参考L9(34)正交排列这个排列

序号  A  B  C  D
1 1 1 1 1
2 1 2 2 2
3 1 3 3 3
4 2 1 2 3
5 2 2 3 1
6 2 3 1 2
7 3 1 3 2
8 3 2 1 3
9 3 3 2 1

其中ABCD对应的是四个因素,而123分别对应每个因素中的三个选项,变更后为测试用例组合:

测试用例编号  字符类型  字符属性  字符位置  操作系统
1 中文 字型字号 单元格 Windows98
2 中文 普通效果 排版框 Windows2K
3 中文 特殊效果 区域 Linux
4 英语 字型字号 排版框 Linux
5 英语 普通效果 区域 Windows98
6 英语 特殊效果 单元格 Windows2K
7 特殊符号 字型字号 区域 Windows2K
8 特殊符号 普通效果 单元格 Linux
9 特殊符号 特殊效果 排版框 Windows98

五、状态转换图

设计测试用例的方法:

  • 找出程序的所有输入动作,并进行编号
  • 找出程序的所有状态
  • 找出什么动作会导致什么状态发生,画出状态转换图
  • 把相关联的动作和状态联系起来,设计测试用例

举例:某程序登录框,需输入账户和密码,提供关闭和登录按钮

1、找出程序的所有输入动作,并进行编号:

  • ip1→输入账号;
  • ip2→输入密码;
  • ip3→点击“登录”按钮;
  • ip4→点击“关闭”按钮。

2、找出程序的所有状态:

  • 启动状态
  • 账号已输入
  • 密码已输入
  • 账号已输入、密码已输入
  • 错误提示状态
  • 登录成功
  • 退出

3、找出什么动作会导致什么状态发生,画出状态转换图

如图所示:

zhuangtai4、把相关联的动作和状态联系起来,设计测试用例

把相关联的动作和状态联系起来,设计测试用例,为了减少测试用例数量,一条测试用例最好沿着状态转换图的一条路径编写完,如上图,大概有11条路径。

六、测试大纲法

测试大纲法适用于跳转页面较多的界面用例设计,如安装。

设计测试用例的方法:

  • 找出所有的窗口以及每个窗口的输入动作(注意先后顺序)
  • 找到各个窗口之间的联系,并据此编写测试用例

1、大纲是一种着眼于需求的方法,为了列出各种测试条件,就将需求转换为大纲的形式。

2、在根和每个叶节点之间存在唯一的路径,每条路径定义了一个特定的输入条件集合,用于定义测试用例。

如图示例,下图为各个界面所展示的可点击的操作(只是模拟,没有实际数据,哈哈),而一条路径就可以为我们定义一条测试用例。

cesdagang

 

持续更新中ing

1、她现在已经不在了,因为我并没有照顾好她,这是第一次拿起相机,也是唯一一次为她留的纪念。

IMG_0113

2、春寒料峭,梅花山中却出现一抹翠绿,娇小窈窕,实在惹人怜爱。

IMG_1922

3、待到山花烂漫时,她在丛中笑

IMG_1878

4、虽然渺小,却能夺人心魄。就像我们,宇宙中的一个微点,却能万般灿烂。

IMG_1660

5、她叫丽娜莲,美丽端庄,却在枝头透露出些许抚媚,像多喝了点美酒的姑娘脸庞

IMG_4294

6、轻肌弱骨散幽葩,更将金蕊泛流霞。杯中窥花。

juhua

7、杂草中顽强的长出一株不知名的小花,带着独有的倔强,迎接属于她的阳光。

xiaohua

8、日照人面红,风吹百合香。

2015-10-04 151844

9、然而就只是背影,在家乡的渲染下,也散发出点点温馨

2015-10-03 215857

10、南京夫子庙元宵灯会的一景,下面漆黑一片的其实是拥挤的人群

2015-03-05-191020

11、一个神奇而伟大的海洋生物,即可入药,雄性还具有育儿袋——海马

img_1638

我在测试过程中,一般把bug严重程度分为四个等级,在最后验收符合0,0,2,5收敛准则即可,即严重程度紧急、严重的bug数为0,严重程度一般的bug数小于等于2个,严重程度低的bug数最多只有5个。

一、Bug严重程度——紧急

  • 造成系统崩溃、死机、死循环的问题
  • 数据库数据丢失,与数据库连接错误
  • 主要功能、基本模块缺失
  • 阻塞测试执行的问题且不可逾越

        这些问题在测试中很少出现,一旦出现,需终止当前版本的测试

二、Bug严重程度——严重

  • 主要功能部分缺失
  • 用户数据丢失
  • ­一级菜单不能使用但不影响其他功能测试
  • ­功能实现与需求严重不符
  • ­由于Bug的存在使产品其它部分不能测试
  • ­由于计算方法问题,使数据错误
  • ­由于设计原因,造成前后不一致,但问题可恢复
  • ­容错性方面存在不足
  • ­由于精度问题造成数据不一致
  • 程序接口错误

        该等级问题出现,若不影响其他功能测试情况下可继续进行该版本的测试。

三、Bug严重程度——一般(普通)

  • ­功能没有完全实现,但不影响使用
  • ­功能存在缺陷但不会影响系统稳定性

       该等级问题在实际测试中存在最多,合理安排解决bug。

四、Bug严重程度——低 

  • 界面问题
  • 性能优化问题
  • 建议问题

        此问题在测试初期较多,优先程度较低,在测试后前出现较少,应及时处理。

另附一个标准化分为5个等级的图表。

缺陷种类 缺陷级别 详细说明
功能缺陷 Urgent
(V级)
1.操作系统无法正常使用,死机,出现致命错误
2.数据丢失
3.被测试系统频繁崩溃,程序出错,使功能不能继续使用
4.性能与需求不一致
5.系统资源引发性能问题
6.系统配置引发错误
7.安全性问题
Very High
(IV级)
1.功能与需求不一致,或功能未实现
2.功能有错误,影响使用
3.数据传输有错误
4.安装与卸载问题
High
(III级)
1.功能有错误,但不影响使用
2.界面错误
3.边界条件出错
Medium
(II级)
1.界面设计不规范
2.消息、提示不准确
3.交互不友好
需求缺陷 Low
(I级)
1.软件设计有问题
2.文档不完整或不准确
3.需求冻结后,描述不清楚的地方

下面主要举例一些测试的分类及测试策略,在实际开展测试中可有所删减

1、功能测试:最主要的一种测试类型,对提供给用户的功能进行验证测试。主要针对功能错误或遗漏、界面问题、性能错误(软件本身的性能,处理性能;与性能测试进行区分)、数据及访问错误,初始化及终止错误。

2、性能测试:检查系统是否满足在需求中所规定达到的性能,性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置,系统资源使用状况;外部因素包括响应时间,吞吐量等。又可包含负载测试、压力测试、稳定性测试。性能主要考虑的指标:并发用户数UV、每秒事务数TPS、系统响应时间、设备性能等

3、负载测试:在我们的测试过程中,来逐步增加负载,并且记录下被测系统相应的性能表现,最终确定出系统在正常指标范围下的最大负载。

4、压力测试:压力测试又称强度测试,主要是检查系统运行环境在极限情况下软件运行的能力,比如说给一个相当大的负荷或网络流量给应用软件。

5、稳定性测试:一般是以稍大于正常业务量的一个负载,对系统进行持续的长时间的测试。比如说24*5,即连续5天对系统施加压力,以确定系统在长时间压力下的稳定性如何。

6、安全测试:对软件产品进行测试以确保其符合产品安全需求和质量标准,我们提到安全测试一般还有一个相提并论的概念,即渗透测试。

7、渗透测试:通过模拟对软件系统的恶意攻击行为来评估系统安全性的一种测试。

8、兼容性测试:对软件产品在软件本身的兼容性、不同平台下的兼容性、软件对运行设备的兼容性、软件互操作性(如微信)、浏览器的兼容性等方面进行测试。

9、文档测试:针对软件产品的交付品,配套的文档类部件的测试。检查内部/外部文档的清晰性和准确性,对外部文档而言,还必须考虑文档的简单明了,相关的技术术语是否解释清晰等方面的检查。如用户手册、使用说明、用户帮助文档等。关注的点主要是完整性、正确性、一致性、易理解性、易浏览性。

10、易用性测试:从使用的合理性和方便程度对系统及软件进行相关的测试和检查,在不影响程序主体和耗费时间太长的前提下,建议多从用户的使用角度来考虑,用户是否感觉方便,注重用户的体验

11、本地化测试:针对软件的本地化版本实施的针对性测试,主要包括语言、书写习惯、时区、日期格式、货币、当地风俗、法律法规,政治敏感内容等。

12、多语言测试:对不同的语言平台,环境下,包括界面,语法,基本功能方面的测试。

13、部署测试:也称安装测试,主要验证系统部署过程,并确保软件经过安装测试后可以正常使用。主要测试内容:在不同环境下的部署验证;参照部署文档执行,过程的合理、正确性;基础测试数据。

14、无障碍测试:也称可访问性测试,是指软件需要提供便于特殊人群使用的功能,包括视障、听障、老年人、身体残疾用户等。

15、正常测试:测试某个功能是否满足需求的定义,功能是否正确,完备。

16、边界测试:对某个功能的边界情况进行测试。

17、异常测试:对某些功能来说,其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的,类似这样的情况需要书写相关的异常测试。

18、接口测试:在模块组装测试中,很多问题出现在接口部分。单个模块的功能实现了,但组装在一起,就无法正常工作。接口测试要包括两部分的测试:(1)根据设计文档,构造测试数据,验证接口是否正确;(2)将接口关联的模块组装在一起进行联调测试。接口测试可以同时检查设计文档的正确性。

19、界面测试:主要为了测试基于UI界面的测试。

20、启动/停止测试:检查系统,启动,停止,监控,维护等相关的功能是否正常

下载地址:http://pan.baidu.com/s/1b96AtC

列举一些重要的:

1、acceptance testing验收测试含义:也称为交付测试,是在软件产品完成了单元测试、集成测试和系统测试之后,产品发布之前所进行的软件测试活动,它是技术测试的最后一个阶段,目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。

2、actual result 实际结果含义:组件或系统测试之后产生或观察到的行为。

3、alpha testing Alpha测试含义:α测试,是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。

4、beta testing Beta测试含义:β测试,用户在开发组织外,没有开发人员参与的情况下进行的测试,检验软件是否满足客户及业务需求。只有当α测试达到一定的可靠程度时,才能开始β测试。

5、benchmark test基准测试含义:为使系统或组件能够进行度量和比较而制定的一种测试标准,一般用于性能测试中的单用户场景。

6、black-box testing 黑盒测试含义:不考虑组件或系统内部结构的功能或非功能测试。

7、white-box tesing 白盒测试 含义:通过分析组件/系统的内部结构进行的测试。

8、boundary value 边界值 含义:通过分析输入或输出变量的边界或等价划分的边界来设计测试用例,例如,取变量的最大、最小值、中间值、比最大值大的值、比最小值小的值等。

9、bug(defect) 缺陷 含义:从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;从产品外部看,缺陷是系统所需要实现的某种功能的失效或违背。

10、bug report(defect report) 缺陷报告 含义:对造成软件组件或系统不能实现预期功能的缺陷进行描述的报告文件。

11、cause-effect graph 因果图 含义:用来表示输入(原因)与结果之间关系的图表,因果图可以用来设计测试用例。

12、daily build 每日构建 含义:每天对整个系统进行编译和链接的开发活动,从而保证在任何时候包含所有变更的完整系统是可用的。 

13、debugging tool 调试工具 含义:程序员用来复现软件失败、研究程序状态并查找相应缺陷的工具。调试器可以让程序员单步执行程序、在任何程序语句中终止程序和设置、检查程序变量。  

14、decision table 决策表 含义:一个可用来设计测试用例的表格,一般有条件桩、行动桩和条件规则条目和行动规则条目组成,可与因果图结合起来。

15、equivalence partition 等价类划分 含义:根据规格说明,输入域或输出域的一个子域内任何值都能使组件或系统产生相同的响应结果。原则上每个等价类中至少要选取一个典型的点来设计测试用例。

16、expected result 预期结果 含义:在特定条件下根据规格说明或其他资源说明,组件或系统预测的行为。

17、incident logging 事件日志 含义:记录在测试过程中所发生的事件的详细情况。

18、interface testing 接口测试 含义:一种集成测试类型,注重于测试组件/系统之间的接口。

19、release note 发布说明 含义:标识测试项、测试项配置、目前状态及其他交付信息的文档,这些交付信息是由开发、测试和可能的其他风险承担者在测试执行阶段开始的时候提交的。

20、load testing 负载测试 含义:通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。

21、stress testing 压力测试 含义:通过测试系统在资源特别低的情况下长时间连续运行给系统性能造成的影响,目的是找到系统在哪里失效以及如何失效的地方(临界点)。

22、memory leak 内存泄漏 含义:程序的动态存储分配逻辑存在的缺陷,导致内存使用完毕后不能收回而不可用,最终导致程序因为内存缺乏而运行失败(fail)。

23、milestone 里程碑 含义:项目过程中预定义的交付物和结果就绪的时间点。

24、precondition 前置条件 含义:对组件/系统执行特定测试或测试步骤之前所必须满足的环境和状态条件。

25、postcondition 后置条件 含义:执行测试或测试步骤后必须满足的环境和状态条件。

26、priority 优先级 含义:赋予某项(业务)重要性的级别,如,缺陷。

27、review 评审 含义:对产品或产品状态进行的评估,以确定与计划的结果所存在的误差,并提供改进建议。

28、risk 风险 含义:将会导致负面结果的因素。通常表达成可能的(负面)影响。

29、scenario testing(use case testing) 场景测试 含义:一种黑盒测试设计技术,所设计的测试用例用于执行用户场景。

30、smoke test冒烟测试 含义:冒烟测试是指在对一个新版本进行系统大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性。构建和冒烟测试是业界的最佳实践。

31、concurrency testing并发测试 含义:测试组件或系统的两个或多个活动在同样的间隔时间内如何交叉或同步并发。