基于功能的测试用例设计

一般功能测试指的都是黑盒测试。就是测试工程师基于需求文档,对开发完的功能进行测试。也就是说,功能测试都是基于需求的黑盒测试。而需求主要归为两大类:

  • 显式功能性需求:指的是需求中明确规定且用户可以感知到的需求,比如“访客用户访问管理员页面时会跳转到登录页”。
  • 非功能性需求:指的是用户无法直接体验到的,非具体功能性的需求,但这种非功能性需求在做功能性测试的时候也会涉及到,因为很多非功能性的需求会影响到功能的可用性与用户体验,比如性能测试。

显式功能性需求

对于显式功能性需求我们最长用到的方案主要有三种:

  • 等价类划分法
  • 边界值分析法
  • 错误推断法

等价类划分

•在软件测试中,穷举法虽然是最安全最保险的一种方法但成本代价高,一般是不可取的。我们可以通过等价类划分方法花费最小的代价来完成最高效的测试。
•等价类划分是把程序输入域划分成若干子集,然后从子集中选取少数具有代表性的数据进行测试。在子集集合中,各个输入数据对于揭露程序中的错误是等价的。
•等价类分为有效等价类和无效等价类。
•  1.1有效等价类-----正常流
   对于程序规格来说合理的、有意义的输入数据的集合,检验程序是否实现了规格说明中的功能和性能。
•  1.2无效等价类-----异常流
不合理的、无意义的输入数据集合,验证程序处理意外数据的能力。至少应有一个,也可能多个。

划分等价类的标准

•1)完备测试、避免冗余;
•2)划分等价类重要的是:集合的划分,划分为互不相交的一组子集,而子集的并是整个集合;
•3)并是整个集合:完备性;
•4)子集互不相交:保证一种形式的无冗余性;
•5)同一类中标识(选择)一个测试用例,同一等价类中,往往处理相同,相同处理映射到相同的执行路径

等价类划分方法

掌握必须使同类数据的处理过程及处理结果完全一致的大原则,可参考以下划分方法

•  1) 输入条件规定了取值范围或值的个数的情况下,可以确定一个有效等价类和两个无效等价类,如合格成绩取值范围为[60,100],则范围内取值为有效等价类,范围外<60和>100为无效等价类
•  2) 输入条件规定了输入值的集合或“必须如何”的情况下,可以确定一个有效等价类和一个无效等价类,如:规定数据库类型必须选择oracle,则选择oracle时为有效等价类,否则为无效等价类
•  3) 输入条件是一个布尔量的情况下,可以确定一个有效等价类和一个无效等价类
•  4) 输入条件规定必须遵守某种规则的情况下,可以确定一个有效等价类和若干个无效等价类(从不同角度违法规则),如:规定输入必须为非0正整数,则无效等价类可以分为空、0、负整数、小数、字符等
• 5) 在规定了输入数据的一组值(假定N个),并且程序要对每个输入值分别处理的情况下,可以确立N个有效等价类和一个无效等价类。例:输入条件说明 学历可为:专科、本科、硕士、博士四种之一,则分别取这四种这四个值作为四个有效等价类,另外把四种学历之外的任何学历作为无效等价类。
•  6) 在确知已划分的等价类中各元素在程序处理镇南关的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类

等价类表

•在确立了等价类后,可以建立等价类表,列出所有划分出的等价类

输入条件 有效等价类 无效等价类
合格成绩取值范围为[60,100]之间的整数 [60,100]之间的整数 大于100;小于60小数位,如96.3含有字母的字符串;含特殊字符的字符串 空

等价类划分实例1

•设有一个档案管理系统,要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月,并规定日期由6位数字字符组成,前4位表示年,后2位表示月。现用等价类划分法设计测试用例,来测试程序的"日期检查功能"。

等价类划分实例1:结果

•1)划分等价类并编号,下表等价类划分的结果

输入等价类 有效等价类 无效等价类
日期的类型及长度 ①6位数字字符 ②有非数字字符③少于6位数字字符④ 多于6位数字字符
年份范围 ⑤在1990~2049之间 ⑥小于1990⑦大于2049
月份范围 ⑧在01~12之间 ⑨等于00⑩大于12

2)设计测试用例,以便覆盖所有的有效等价类在表中列出了3个有效等价类,编号分别为①、⑤、⑧,设计的测试用例如下:
测试数据 期望结果 覆盖的有效等价类
200211 输入有效 ①、⑤、⑧
3)为无效等价类设计测试用例,设计结果如下:
测试数据 期望结果 覆盖的无效等价类
95June 无效输入 ②
20036 无效输入 ③
2001006 无效输入 ④
198912 无效输入 ⑥
200401 无效输入 ⑦
200100 无效输入 ⑨
200113 无效输入 ⑩

使用等价类划分法测试的实例(续)
在这里插入图片描述

•实例2 保险公司计算保费费率的程序
某保险公司的人寿保险的保费计算方式为:

投保额×保险费率

其中,保险费率依点数不同而有别,10点及10点以上保险费率为0.6%,10点以下保险费率为0.1%;而点数又是由 投保人的年龄、性别、婚姻状况和抚养人数来决定,具体规则如下:
在这里插入图片描述
计算保费费率的程序
(1)分析程序规格说明中给出和隐含的对输入条件的要求,列出等价类表(包括有效等价类和无效等价类)。

•年龄:一位,两位或三位非零整数,值的有效范围为1~130
•性别:一位英文字符,只能取值‘M’或’F’
•婚姻:字符,只能取值‘已婚’或‘未婚’
•抚养人数:空白或一位非零整数(1~9)
•点数 :一位或两位非零整数,值的范围为1~99
(2)根据(1)中的等价类表,设计能覆盖所有等价类的 测试用例。
在这里插入图片描述

边界值分析方法

•1.定义:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
以往的测试经验表明,由于需求界定不准确、设计不严密、程序书写手误等等原因,对于这些数据范围边界的判断是软件极容易出错的地方。大量的错误往往发生在输入或输出范围的边界上,因此针对各种边界情况设计测试用例,可以检查出更多的错误。

•2.怎样用边界值分析法设计测试用例?
1)边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据
2)边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。
3)首先确定边界情况。通常输入或输出等价类的边界就是应该着重测试的边界情况,因此在等价类的边界上以及两侧的情况设计测试用例。

•3.边界值适用场景

  1. 输入(输出)条件规定了取值范围

  2. 输入(输出)条件规定了值的个数

  3. 程序规格说明书中提到的输入或输出是一个有序的集合

  4. 程序中使用了一个内部数据结构

  5. 边界值取值应当选取正好等于、刚刚大于最大边界值和刚刚小于最小边界值最为测试

边界值选择测试用例原则

•1) 如果输入条件规定了值的范围,则应取刚达到这个范围的边界值、以及刚超越这个范围边界的值作为测试输入数据。 例如,如果程序的规格说明中规定:“重量在10公斤至50公斤范围内的邮件,其邮费计算公式为……”。作为测试用例,我们应取10及50,还应取10.01,49.99,9.99及50.01等。
•2) 如果输入条件规定了值的个数,则选取最大个数、最小个数、比最大个数多一、比最小个数少一的数作为测试数据。
•比如,一个输入文件应包括1~255个记录,则测试用例可取1和255,还应取0及256等。
•例如,某程序的规格说明要求计算出"每月保险金扣除额为0至1165.25元",其测试用例可取0.00及1165.24、还可取一0.01及1165.26等。
再如一程序属于情报检索系统,要求每次"最少显示1条、最多显示4条情报摘要",这时我们应考虑的测试用例包括1和4,还应包括0和5等。
•5) 若输入域是有序集合,则选取集合的第一个元素和最后一个元素作为测试用例
•6) 如果程序使用了一个内部数据结构,则应当选择内部数据结构上得边界值作为测试用例
•7) 分析规格说明,找出其他可能的边界条件

错误推断法

•错误推断法一般基于以往的测试经验和直觉,参照以往的软件系统出现的错误,推测程序中可能存在的各种错误,列出程序中所有可能有的错误和容易发生错误的情况,有针对性的设计测试用例。
•  单元测试用例中列出许多在模块中常见的错误、以前产品测试中曾经发现的错误等
•  例如, 输入数据和输出数据为0的情况;输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。各种情况在产品说明中常常被忽视,也可能被程序员遗忘,但在实际使用中却经常发生。测试人员要站在用户的角度,考虑他们要输入的信息,而不管这些信息看起来是合法的输入还是非法的输入。

因果图法

•因果图法产生的背景:
等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。

如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)

因果图法的简介

•因果图法是基于这样的一种思想:一些程序的功能可以用判定表(或称决策表)的形式来表示,并根据输入条件的组合情况规定相应的操作。
•因果图法的定义:是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。
•采用因果图法设计测试用例的步骤:
(1)根据程序规格说明书描述,分析并确定因(输入条件)和果(输出结果或程序状态的改变),画出因果图。

(2)将得到的因果图转换为判定表。

(3)为判定表中每一列所表示的情况设计一个测试用例

因果图

•因果图中用来表示4种因果关系的基本符号:
因果图中的4种基本关系

在因果图的基本符号中,图中的左结点ci表示输入状态(或称原因),右结点ei表示输出状态(或称结果)。ci 与 ei 取值0或1,0表示某状态不出现,1则表示某状态出现。

Ø恒等:若 c1 是1,则 e1 也为1,否则 e1 为0。
Ø非:若 c1 是1,则 e1 为0,否则e1为1。
Ø或:若 c1 或 c2 或 c3 是1,则 e1 为1,否则 e1 为0。
Ø与:若 c1 和 c2 都是1,则 e1 为1,否则 e1 为0。

因果图
•因果图中的约束
在实际问题中输入状态相互之间、输出状态相互之间可能存在某些依赖关系,称为“约束”。对于输入条件的约束有E、I、O、R四种约束,对于输出条件的约束只有M约束。

ØE约束(异):a和b中最多有一个可能为1,即a和b不能同时 为1。
ØI 约束(或):a、b、c中至少有一个必须为1,即 a、b、c不能同时为0。
ØO约束(唯一):a和b必须有一个且仅有一个为1。
ØR约束(要求):a是1时,b必须是1,即a为1时,b不能为0。
ØM约束(强制):若结果a为1,则结果b强制为0。

因果图
•因果图中用来表示约束关系的约束符号:
。。。。。。
判定表
•因果图法最终生成的是判定表。
•在所有的黑盒测试方法中,基于决策表(也称判定表)的测试是最为严格、最具有逻辑性的测试方法。
•决策表的概念:决策表是分析和表达多逻辑条件下执行不同操作的情况的工具。

•决策表的优点:能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用决策表能够设计出完整的测试用例集合。
•在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。决策表很适合于处理这类问题。

“阅读指南”判定表
在这里插入图片描述
决策表的组成

•决策表通常由以下4部分组成:
Ø条件桩—列出问题的所有条件
Ø条件项—针对条件桩给出的条件列出所有可能的取值
Ø动作桩—列出问题规定的可能采取的操作
Ø动作项—指出在条件项的各组取值情况下应采取的动作
将任何一个条件组合的特定取值及相应要执行的动作称为一条规则。在决策表中贯穿条件项和动作项的一列就是一条规则。

决策表的生成

•构造决策表的5个步骤:
(1) 确定规则的个数。

Ø有n个条件的决策表有2n个规则(每个条件取真、假值)。
(2) 列出所有的条件桩和动作桩。

(3) 填入条件项。

(4) 填入动作项,得到初始决策表。

(5) 简化决策表,合并相似规则。

Ø若表中有两条以上规则具有相同的动作,并且在条件项之间存在极为相似的关系,便可以合并。
合并后的条件项用符号“-”表示,说明执行的动作与该条件的取值无关,称为无关条件

测试方法的选择

•通常,在确定测试方法时,应遵循以下原则:
Ø根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点。
Ø认真选择测试策略,以便能尽可能少的使用测试用例,发现尽可能多的程序错误。
•通常在确定测试策略时,有以下5条参考原则:
(1)在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强。

(2)必要时采用等价类划分法补充测试用例。

(3)采用错误推断法再追加测试用例。

(4)对照程序逻辑,检查已设计出的测试用例的逻辑覆盖 程度。如果没有达到要求的覆盖标准,则应当再补充更多的测试用例。

(5)如果程序的功能说明中含有输入条件的组合情况,则应一开始就选用因果图法。

非功能性需求

在测试工程师测试完显示功能需求之后,还要考虑到系统的非功能性需求。这种需求可能在文档中有明确提到,也可能并没有明确的提出。但是我们的测试工程师在测试的时候却必须要关注到。

2.1 兼容性测试
兼容性指的是开发的软件是否在各种平台都可以使用。比如我们开发一个网站,我们的用户可能会用到各种不同的浏览器访问我们的网站。这样我们在测试的时候,就不能只考虑到某一种浏览器。我们需要考虑到多种浏览器的兼容性。

兼容性测试可能会涉及到:

  • 不同厂商的浏览器及相同厂商不同版本的浏览器。
  • 不同的设备终端及操作系统
  • 不同的屏幕分辨率
  • 不同的用户软件环境(比如是否禁用了cookie、是否可以连接外网等)

2.2 安全性测试
我们的测试人员还需要关注到开发软件的安全性。这涉及到:

  • 用户隐私信息是否加密

  • 需要权限的资源是否有没有权限也可以被拿到的风险

  • 会不会受到跨站脚本的攻击

  • 会不会受到sql注入攻击等等

2.3 压力测试
测试人员也需要考虑的软件是否能够承载其需求所需的压力,例如:

  • 软件是否能在合理的时间内响应用户行为

  • 软件是否可能承载足够的请求

  • 软件在处理大数据量时会不会产生资源锁死等等

总结

在这里插入图片描述

用户登录界面测试用例设计:

•  1、用户名、密码正确登录
• 2、默认页面直接提交
•  3、用户名、密码错误的检测
•  4、用户名不存在的检测
•  5、TAB键的检测
•  6、Enter键的检测
•  7、被删除的用户名是否能够登录
•  8、被禁止的用户名是否能够登录
• 9、用户重复登陆
•  10、用户名大小写的敏感检测
•  11、用户名、密码对复制粘贴内容的敏感检测

发布了79 篇原创文章 · 获赞 321 · 访问量 4万+

猜你喜欢

转载自blog.csdn.net/qq_43107323/article/details/105098980