测试用例的基本要素
回顾一下测试用例的概念:
测试用例是为了实施测试而向被测试的系统提供的一组集合, 这组集合包含: 测试环境, 操作步骤, 测试数据, 预期结果等要素.
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试.
评价测试用例的标准: 对比好坏用例的评价标准.
用例表达清楚, 无二义性.
用例可操作性强.
用例的输入和输出明确, 一条用例只有一个预期结果.
用例的可维护性好.
用例对需求的覆盖率高.
测试用例给我们带来的好处
测试执行者的依据.
使得工作可重复, 自动化测试的基础.
评估需求的覆盖率.
用例的复用
积累测试方法思路以供后续借鉴
使用中带来的困扰:
测试用例的设计是费时费力的工作, 往往设计测试用例所花费的时间比执行所花费的时间还多
解决如下问题:
不知道是否较全面的测试了所有功能, 测试的覆盖率无法衡量, 对新版本的重复测试很难实施, 存在大量冗余影响测试效率.
测试用例的设计方法
基于需求进行测试用例设计
基于需求设计测试用例是测试设计和开发测试用例的基础, 第一步就要分析测试需求, 验证需求是否正确, 完整, 无二义性, 并且逻辑自洽. 在需求正确的基础上细化测试需求, 从测试需求中提炼出一个个测试点或者测试项, 然后根据每一个测试点进行测试用例的设计.
在分析测试需求时, 一般分为功能测试需求和非功能测试需求.
功能需求测试分析
对于功能测试中, 可以借助功能框图来帮助我们进行测试的需求分析. 概括起来, 功能测试需求通常包括以下几个方面:
(1)系统各个功能界面的验证.
(2)借助业务把功能串起来进行测试.
(3)功能的一致性, 交互性(多功能互操作)的测试.
(4)系统的不同输入, 结果输出的业务数据测试.
(5)功能的错误操作, 异常操作的测试(属于负面测试).
(6)功能实现用到的算法验证, 有时需要用代码评审.
(7)用户操作的易用性, 用户体验, 往往结合功能测试同时验证.
针对具体的需求, 可以根据业务分类, 用户角色(餐厅的会员系统)或者用户操作区域等将系统功能分解成若干个功能模块, 然后按照功能模块分别进行测试用例分析. 按照功能模块划分, 业务模块划分是最常见的做法.
非功能需求测试分析
非功能测试需求主要涉及性能, 安全性, 可靠性, 兼容性, 易维护性和可移植性等. 从测试需求分析来看, 每一类非功能特性测试都需要根据需求单独分析. 它们之间可能会存在相互影响, 如安全性越高, 就越有可能给易用性, 性能带来更大的挑战.
这里要说明的是对于每一个应用软件系统, 非功能特性的质量需求都是存在的, 但是针对不同项目类型对各个非功能特性的要求是不一样的, 这个需要根据具体项目, 具体需求和不同产品应用的特点进行分析.
(1)纯客户端软件(就没有服务器支持的): 这类软件对系统的功能测试要求是最低的, 但是对于兼容性和稳定性, 可移植性有一定要求.
(2)企业内部的客户端/服务端系统: 比如电子邮件, 即时通信系统(企业QQ)等, 在系统功能测试需求上比纯客户端更复杂, 要求功能正确, 稳定性良好. 但是整体上看, 对性能, 安全性, 兼容性要求不高.
(3)外部大型复杂网络应用系统: 比如电子商务, 网上银行等, 除了有复杂的系统功能测试需求以外, 在系统的性能, 安全性, 兼容性, 容错性, 可靠性都有很高的要求.
具体的设计方法 -- 黑盒测试
介绍
定义: 数据驱动的测试或输入/输出驱动的测试.
核心: 测试目标和结构完全无关, 重点集中在程序不按其规范正确运行的环境条件.
判定标准: "穷举输入测试" 缺点: 经济, 时间, 无法实现.(因为测试投入的目标在于通过有限的测试用例最大限度地发现问题的数量.)
等价类
因材施教的栗子:
原则上讲, 老师应该依据每个学生的自身情况, 制定符合的学习方案. 但是实际上太多老师管不过来, 只能分成几类: 优等生强调知识面的扩展和综合能力的提升; 中等生强调夯实基础, 查漏补缺; 差等生强调先掌握重点, 暂时跳过难点.
思路: 输入的集合是无穷的, 不能全部覆盖到.
依据需求将输入(特殊情况下会考虑输出)划分为若干个等价类, 从等价类中选出一个测试用例, 如果这个测试用例测试通过, 则认为所代表的等价类测试通过, 这样就可以使用较少的测试用例达到尽可能多的功能覆盖, 解决了不能穷举测试的问题.
有效等价类: 对于程序规格说明书是合理的, 有意义的输入数据构成的集合, 利用有效等价类验证程序是否实现了规格说明书中所规定的功能和性能.
无效等价类: 根据需求说明书, 不满足需求的集合.
等价类只考虑输入域的分类, 没有考虑到输入域的组合, 需要其它的设计方法和补充.
eg: 超市买水果
有效等价类: 苹果, 梨, 橘子.
无效等价类: 电锯, 初音未来手办, iPhone 15 promax远峰蓝1TB.
eg: 登录账号:
| 用户名 | 必填, 录入用户名 | 6至15(用户名长度由6-15位字符串组成) |
测试用例设计:
有效等价类: 6-15位字符串
无效等价类: 0-5位字符串/ 16位及以上位字符串.
边界值
我们知道, 代码往往在边界值那里是容易出现问题的,边界值分析法就是对输入或输出边界进行测试的一种黑盒测试方法. 通常边界值分析法是作为对等价类划分法的补充, 这种情况下, 其测试用例来自等价类的边界.
示例:
1. 输入框长度1-11. 取边界值:1, 11, 12, 0.
2.运动员参赛项目为1-3项, 取边界值为: 0, 1, 3, 4项
3.查询页面由999行, 每50行为一页, 取边界值为: 0, 1, 50, 51, 999, 1000行
边界值的取法:
1.上点: 边界上的点就是上点.
2.内点: 边界内的点(不管范围是开区间还是闭区间). (取一个即可^-^)
3.离点: 如果区间是开区间, 是取区间内最靠近上点的点. 如果是闭区间, 是指区间外最靠近上点的点.
举个栗子:
上点: 50, 55 内点: 53 离点: 51, 56.
错误猜测法
错误猜测法是对被测试软件设计的理解, 过往经验以及个人直觉, 推测软件中可能出现的缺陷, 从而针对性地设计测试用例的方法.
这个方法强调的是对被测试软件需求理解以及设计实现的细节把握, 还有个人经验的直觉.
错误推测法和目前流行的"探索式测试方法"的基本思想一致, 这类方法在敏捷开发模式下的投入产出比很高, 被广泛地运用于测试.
这个方法的缺点是难以系统化, 并且过度依赖个人能力.
场景设计法
现在的软件几乎都是用事件来触发控制流程的, 事件触发时的情景便形成了场景, 而同一事件不同的触发顺序和处理结果就形成事件流. 该方法可以比较生动地描绘出事件触发时的场景, 有利于测试者设计测试用例, 使测试用例更容易理解和执行.
典型的应用是用业务流把各个孤立的功能点串起来, 为测试人员建立整体业务感觉, 从而避免陷入功能细节忽视业务流程的错误倾向.
案例(注册):
想象注册的场景来设计测试用例, 这与根据需求的业务流来设计的差不多. 主要是想象各种业务流设计用例. 例如我们可以想象以下场景:
1.用户激活后再次点击邮件激活链接?
2.已注册用户再次注册?
