七分钟教会你如何编写一个合格的测试用例

服务器 0

目录

1、测试用例的基本要素

2、根据测试用例去测试带来的好处

3、测试用例的设计方法

3.1、等价类

3.2、边界值

3.3、错误猜测法

3.4、场景法

3.5、因果图法

 3.6、正交排列

4、怎样判断一个测试用例是好的测试用例


1、测试用例的基本要素

        测试用例是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境、操作步骤、测试数据、预期结果等要素

万能公式:

功能测试 + 性能测试 + 界面测试 + 兼容性测试 + 易用性测试 + 安全性测试


2、根据测试用例去测试带来的好处

2.1、思路清晰,避免遗漏

        有了测试用例,我们就需要将大的项目细细划分,根据每个不同的功能来编写不同的测试用例,来整理我们对整个被测试项目的思路,避免遗漏要测试的功能点

2.2、重复性——自动化测试的基础

        我们测试一个系统不是一个人测一遍就算结束了,而需要多人进行反复测试,因此我们可以利用测试用例来规范和指导我们的测试行为

2.3、跟踪测试进展

通过编写测试用例,执行测试用例,我们可以清楚的知道我们的测试进度

2.4、历史参考

        我们在测试中,必然是会遇到很多功能相同或相近的,而他们的测试用例也就大同小异了,我们可以利用以前对这类功能设计的测试用例,便于我们遇到类似功能的时候作参考        


3、测试用例的设计方法

3.1、等价类

        根据输入(特殊情况下才考虑输出),把输入划分成若干个等价类)从每一个等价类当中选择测试用例进行测试,如果这个测试用例测试通过,我们就说这个测试用例代表的等价类测试通过。
等价类帮助我们解决测试用例无法穷举的情况。

举例:

利用等价类:

 另外,等价类还可以进行分类:

  • 有效等价类:对于程序的规格说明书是合理的、有意义的输入数据结构的集合,利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
  • 无效等价类:根据需求说明书,不满足需求的集合

3.2、边界值

        边界值分析法就是对输入或者输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界

  • 等价类和边界值往往结合起来使用,边界值分析使用与等价类划分法相同的划分,只是边界值分析假定错误更多地存在于划分的边界上,因此在等价类的边界上以及两侧的情况设计测试用例;
  • 将软件的输入或者输出参数进行等价类划分;
  • 在等价类的基础之上进行边界值分析。一般情况下,假如边界值已经由等价类划分覆盖,则可以不予考虑;
  • 将边界值进行组合,作为测试用例的输入数据;

        细心的小伙伴会问,为什么我们要用边界值去设计测试用例呢?这个是由大量的测试实践经验得出,大量的Bug往往发生在输入定义域或者输出值域的边界上,而不是在内部。因此,我们针对边界情况设计测试用例,一般能发现更多的问题

3.3、错误猜测法

  • 错误猜测法是对被测试软件设计的理解,过往经验以及个人直觉,推测出软件可能存在的缺陷,从而针对性地设计测试用例的方法。
  • 这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握,还有个人的经验和直觉。
  • 错误推测法和目前流行的“探索式测试方法”的基本思想一致,这类方法在敏捷开发模式下的投入产出比很高,被广泛应运于测试。
  • 这个方法的缺点是难以系统化,并且过度依赖个人能力。

3.4、场景法

        很多软件不同的场景,是基于不同的事件的触发,不同事件的触发,导致场景走向不同的事件流。不同的功能点串起来形成一个场景。不同的功能点又有不同的输出,不同的输出导致不同的测试场景。 

设计方法:

  • 理解需求,确定业务基本流程、备选流程、异常流程
  • 绘制流程图,再次确认流程路径
  • 根据业务流程图,抽取测试路径
  • 细化路径,利用等价类边界值方法细化路径,抽取测试用例
举例:

ATM取款情景:
插卡 —> 输入密码 —> 输入取款数 —> 取款 —> 退卡

1)插卡

  • 插错卡 (公交卡,会员卡等等)
  • 卡插反
  • 卡损坏
  • 停电吞卡
  • 卡号冻结,账号锁死
  • 网络不好,无法识别卡号

2)输入密码

  • 输入正确的密码
  • 输入错误的密码(密码格式不正确)不输入密码,直接点击确认
  • 密码输入错误超过三次,账户锁定
  • 密码第一次输入错误,第二次或第三次输入正确密码
  • 输入框是否支持删除输入操作
  • 测试密码是否加密
  • 是否支持不同字符的输入

3)输入取款钱数

  • 输入小于卡余额的钱数
  • 输入等于卡余额的钱数
  • 输入大于卡余额的钱数
  • 输入非整百的数
  • 不输入直接按取钱按钮(取钱按钮置灰)
  • 多久不操作超时

4)取款

  • 输入小于等于银行卡余额的钱数时,取款成功
  • 输入大于银行卡余额的钱数,取款失败,并提示“余额不足”
  • 超过每日取款余额的上线
  • 超过每日取款次数的上线

5)退卡

  • 取钱后正常退卡
  • 操作超时,吞卡

6)ATM机

  • ATM机不正常
  • ATM一切正常
  • ATM余额不足
  • ATM断网,断电,硬件故障软件系统崩溃
  • 发生异常情况ATM机是否支持事务回滚

3.5、因果图法

因果图是一种逻辑图,恒等,与或非,用因果图来设计测试用例,叫做因果图法

 用于被测程序有多输入,且程序的输出依赖输入的情况,一般分析程序如下:

  • 找出所有的输入条件
  • 明确所有的输出条件
  • 明确所有条件之间的制约关系以及组合关系,哪些条件不能组合在一起,哪些条件可以组合在一起
  • 明确所有输出之间的制约关系以及组合关系,哪些条件不能组合在一起,哪些条件可以组合在一起
  • 找出什么样的输入条件组合会产生哪种输出结果
  • 根据因果图,写出判定表
  • 根据判定表设计测试用例
     

 3.6、正交排列

        根据正交性设计测试用例,从大量的实验数据中根据正交原则取出最优的数据组合,根据最优数据组合试验的结果,来分析整个测试结果。

        正交法的目的就是为了减少测试用例数目,用尽可能少的用例覆盖输入的两两组合,设计方法如下:

  • 确定因素,对软件运行结果有影响的软件
  • 确定因素的取值范围
  • 确定每个因素的水平,采用等价类,边界值,在每个因素内跳出最具有代表性的测试值
  • 选择正交表设计测试用例

正交表概念:一种特别的表,一般的正交表记为  Ln(m的k次方)

  1. n是表的行数,也就是要测试组合的次数
  2. k是表的列,表示控件的个数(因素的个数或因子个数)
  3. m是每个控件包含的取值个数(各因素的水平数,即各因素的状态数)

  如:L12(211)

    有11个控件

    每个控件有2个取值,

    12为需要测试的组合数

    叫11因素2水平

正交表使用步骤:

  • 根据索测程序中使用的控件的个数(因素)以及每个控件的取值个数(水平),选取一个合适的正交表
  • 把控件及其取值列举出来,并对齐编号
  • 把控件机器取值映射到正交排列表中
  1. 把正交排列表中的ABCD(因子)分别替换成4个控件
  2. 把每列中的123(状态)分别换成这个控件的3个取值(水平),排列顺序按表中的顺序排列
  • 根据映射好的正交排列表编写测试用例

案例1:

  字符属性设置

  

案例2:

  对某人进行查询,假设查询某个人时有三个查询条件:

  • 根据“姓名”进行查询
  • 根据“身份证号码”查询
  • 根据“手机号码”查询

  考虑查询条件要么不填写,要么填写,此时可用正交表进行设计:

  ①因素数和水平数。有三个因素:姓名、身份证号、手机号码。每个因素有两个水平:

  姓名:填、不填

  身份证号:填、不填

  手机号码:填、不填

 ② 选择正交表:

  • 表中的因素数>=3
  • 表中至少有三个因素的水平数>=2
  • 行数取最少的一个
  • 结果:L4(2^3)

 ③ 变量映射

  姓名:1→填写,2→不填写;

  身份证号:1→填写,2→不填写;

  手机号码:1→填写,2→不填写;

 ④ 用L4(2^3)设计的测试用例

  测试用例如下:

  1:填写姓名、填写身份证号、填写手机号

  2:填写姓名、不填身份证号、不填手机号

  3:不填姓名、填写身份证号、不填手机号

  4:不填姓名、不填身份证号、填写手机号

 ⑤增补测试用例

  5:不填姓名、不填身份证号、不填手机号

  测试用例减少数:8→5

3.6-、混合正交表

1、正交表生成工具:

使用步骤:

  1. 在excel制作取值表:
  2. 复制取值表的数据到txt文本中:
  3. 把文本文档放到allpairs中
  4. win+r后输入cmd进入控制台
  5. 进入alllparis文件夹
  6. 在控制台输入allpairs.exe cc.txt>dd.txt (dd是自己起的名字,用来存放生成的用例,可以自当生成,不必提前建好) ——注意,cc.txt要放在allpairs文件夹下,否则运行不成功
  7. 最后生成的dd.txt 保存在allpairs文件下,生成后:

4、怎样判断一个测试用例是好的测试用例

  •  用例表达清楚,无二义性

  • 用例可操作性强

  • 用例的输入与输出明确【一条用例只有一个预期结果】

  • 用例的可维护性好

  • 用例对需求的覆盖率高

  • 用例的检索BUG能力强

好的测试用例是一个不熟悉业务的人也能依据用例很快的进行测试

本期结束啦!下期见~ 

也许您对下面的内容还感兴趣: