目录
一、什么是测试用例
二、写测试用例的好处
1. 理清思路、避免遗漏
2. 跟踪测试进展
3. 历史参考
4. 重复性
三、测试用例的等级
四、测试用例设计八大条件
五、测试用例设计万能公式
万能公式:
万能公式简解:
栗子:
六、测试用例设计的具体方法
1. 等价类划分法
2. 边界值法
3. 判定表法
判定表法设计测试用例的步骤:
栗子:
a. 明确输入条件和输出条件:
b. 找出输入条件和输出条件之间的关系:
4. 场景设计法
5. 错误猜测法
6. 正交法(很少用)
第一步,找出因素和水平
第二步,使用 allparis 生成正交表
第三步,根据正交表编写测试用例
第四步,补充可能存在的遗漏但是很重要的测试用例
测试用例是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境、操作步骤、测试数据、预期结果等。它的作用其实就是为了测试是否满足某个特定需求。测试用例是指导测试进行的依据。
这是非常重要的一点,如果测试的项目属于大而复杂的,我们就可以将项目功能细分,然后针对每一个功能通过编写测试用例的方式来整理我们测试系统的功能点。
通过编写测试用例,执行测试用例,我们可以清楚的知道我们的测试进度。
在我们所做的项目中,也许会有很多功能是相同或相近的,我们对于这类功能设计了测试用例,那后面将会便于我们遇到类似功能的时候作以参考。
测试系统并不是一个人测一遍就算测完了,是需要多人反复进行测试的,那也就说明我们需要测试用例来规范和指导我们的测试行为。
“测试用例还有等级哇?”,相信部分初学的小伙伴也有和我一样的疑惑,第一次被问到测试用例的等级是什么的时候,L 我也是很懵呐,不过没关系,咱可以学噻,哈哈,现在我们一起来探索下究竟什么是测试用例的等级呢?
测试用例的等级是用来表示测试用例的重要性或优先级的。不同的测试用例可能针对不同的功能、模块或场景,根据它们的重要性和业务影响,可以给它们分配不同的等级。常见的测试用例等级包括:
1. P0(Critical):
- 一般针对核心功能或关键路径的测试。
- 如果存在 P0 级别的问题,通常会阻止软件发布。
2. P1(High):
- 重要但不是核心功能的测试。
- 如果存在 P1 级别的问题,可能会推迟软件的发布或需要快速发布修复补丁。
3. P2(Medium):
- 普通功能的测试,不会对业务产生重大的影响。
- P2 级别的问题通常会在下一个正常的发布周期中得到修复。
4. P3(Low):
- 低优先级的功能或很少遇到的场景的测试。
- 这些问题可能会被列入待办列表,根据资源情况在未来的某个时间点修复。
5. P4(Trivial or Cosmetic):
- 针对非功能性或仅仅是外观、样式问题的测试。
- 这些问题可能不会立即得到修复,但会在后续版本中考虑。
测试用例等级的设定有助于测试团队,开发团队和管理团队确定哪些问题需要首先解决,以及如何分配资源。这也有助于确保关键功能得到适当的关注,而低优先级的问题不会消耗过多资源。
以上就是测试用例等级的概述,你了解了嘛?了解了那可太棒啦!还迷糊的,罚你多看几遍哈哈。
在我们测试人员进行测试用例设计时通常需要满足的八大条件包括以下几点,但根据实际情况和需求,这些条件可能有所变化或差异:
- 明确性:测试用例的描述应该简洁、清晰,不给予任何歧义的机会。
- 可靠性:每次执行测试用例时,都应该获得相同的结果。
- 有效性:测试用例应该是有效的,即能够验证被测系统的某个特定功能或特性。
- 独立性:各个测试用例应该是相互独立的,一个测试用例的执行不应依赖于另一个测试用例的结果。
- 可追溯性:测试用例应能追溯到相关的需求或规格说明书,以确保所有的需求都被测试到。
- 完整性:测试用例集合应该全面,覆盖所有可能的应用场景、边界条件等。
- 可重复性:测试用例应该在不同的环境和条件下都能被重复执行。
- 维护性:随着软件需求和设计的变化,测试用例应该容易被修改或更新。
以上就是常见的八大测试用例设计条件。在实际工作当中,可能还需要根据项目和团队的具体需求来调整或添加其他条件哦~
诶~上面都是概念呀,还是不知道设计测试用例该从何下手哇,哎呀,莫慌莫慌,记住以下万能公式,不怕关键时刻设计不出傻傻紧张~
功能测试 + 性能测试 + 界面测试 + 兼容性测试 + 易用性测试 + 安全测试
- 功能测试:在日后的工作当中功能测试用例来自于需求文档,而我们面试的时候嘞,功能测试用例来源于生活经验;
- 性能测试:考虑一些极端情况,如高并发量,响应时间等;
- 界面测试:工作中的话参考设计图,面试的时候,我们可以对颜色、形状、文字、材质、大小、输入框、图片、下拉框...所有我们可以看到的元素都可进行分析;
- 兼容性测试:考虑不同的浏览器、不同的版本、不同的系统、不同数据的兼容性;
- 易用性测试:软件是否具备简单上手的属性;
- 安全测试:隐私数据是否加密,例如:接口参数是否为明文、数据库对隐私数据是否加密、SQL 注入、用户密码在界面是否隐藏展示、越权(水平越权:你访问到了你同事的隐私信息;垂直越权:你访问到了你上级的隐私信息)。
诶嘿,说这么多给大家举个示例:下面是针对好游快爆 APP 里的贴子发布 + 草稿箱交互功能的测试用例(个人初学时做的哈,欢迎提出问题~):
到这里啊,又有问题来咯,有时候测试范围还是蛮大的,那我们该如何下手呢?这时候,就得我们设计测试用例的具体方法“隆重登场”了,一起来看!
该方法简单来说就是分块 / 分区检测,从每一个区块选择一个进行测试,以代表这个区块的结果,这个所说的区块就是等价类,该方法可以用较少的测试用例达到尽可能多的功能覆盖,解决不能穷举测试的问题。等价类分为两种:有效等价类和无效等价类。
有效等价类:对于需求文档有意义的集合
无效等价类:对于需求文档无意义的集合
具体我们可以通过一个栗子来理解:测试用户密码为 6 ~ 18 位
有效等价类:6 ~ 18 位
无效等价类:小于 6 位,大于 18 位
测试用例:
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。
边界值指的是有效边界 + 无效边界
还是上面的栗子:测试用户密码为 6 ~ 18 位
有效边界:6、18
无效边界:5、19
如果还是不太理解,可以看下图:
判定表是因果图的另一种形式,判定表法和因果图画法的步骤差不多(后者就是多了个“画因果图”,这个一般人画不出来< 二班人除外哈 > ,也没有什么明确的画法),这里我们学习判定表法,它一般用于输入条件的组合对应不同的结果。
- 明确输入条件和输出条件
- 找出输入条件和输出条件之间的关系
- 画判定表
- 根据判定表编写测试用例
双十一或其他购物节(悄悄问一句:大家抢到优惠了嘛哈哈),当订单使用红包或者订单金额大于 300 ,则该订单就是优惠订单,否则就为不优惠订单。
输入条件:红包(A)、金额大于 300 (B)、订单已提交(C);
输出条件:有优惠(1)、无优惠(2).
(括号里为它们各自编号,便于进行后续步骤)
确定输入输出之间所有可能的组合关系,最后根据组合(编号)给出对应的结果,如下:
c. 画判定表:
d. 根据判定表编写测试用例:
- 有红包,订单金额小于 300 元,不提交订单,则该订单为无优惠订单;
- 无红包,订单金额大于 300 元,不提交订单,则该订单为无优惠订单;
- 无红包,订单金额小于 300 元,提交订单,则该订单为无优惠订单;
- 有红包,订单金额小于 300 元,提交订单,则该订单为有优惠订单;
- 无红包,订单金额大于 300 元,提交订单,则该订单为有优惠订单;
- 有红包,订单金额大于 300 元,提交订单,则该订单为有优惠订单;
- 有红包,订单金额大于 300 元,不提交订单,则该订单为无优惠订单;
- 无红包,订单金额小于 300 元,不提交订单,则该订单为无优惠订单。
场景设计法可以比较生动地描绘出事件触发时的情景,有利于测试设计者进行测试用例的设计,使得测试用例更容易被理解和引导。该方法将事件分为基本事件流和备选事件流。
基本事件流:原本按计划要进行的事情
备选事件流:一些意外情况
栗子:银行 ATM 机取钱
编写测试用例:
基本事件流:插卡,输入正确的密码,选择取款功能,输入金额,取钞,退卡;
备选事件流:
错误猜测法是依据对被测试软件设计的理解、过往经验以及个人直觉,推测出软件可能存在的缺陷,从而针对性的设计测试用例的方法。
该方法主要依赖测试人员的工作经验和积累,它的缺点就是难以系统化,并且过度依赖测试人员的个人能力。
比如对登录功能进行测试,一般就是:密码是否隐藏加密、密码是否以明文进行传输、考虑 SQL 注入的问题......
正交法就是指从大量的实验中挑选出适量的、有代表性的点,依据“正交表”进行合理的测试用例设计。
正交表的特性:
根据正交表设计测试用例的步骤:
栗子:测试下面的这个注册页面:
因素:用户名、密码、确认密码、验证码;
水平:填写、不填写。
生成步骤:
1. 将因素和水平写入 Excel
2. 在 allparis 同级目录下创建一个新的 txt 文件,复制刚刚 Excel 表中所写的信息,粘贴到你创建的 .txt 文件中,保存
3. 在 cmd 中使用 allparis 工具生成正交表
其中 kaiyuanxi.txt 为咱们自己创建的 txt 文件;kaiyuanxitf.txt 为要生成的正交表文件
4. 在目录中可以看到刚刚生成的正交表
生成的正交表:
其中“ ~填写 ” 的意思是:这里的水平可以任意填写
补充重要测试用例:用户名、密码、确认密码、验证码全部不填写
Okay~测试用例的介绍就到这里了,都要学会昂,不会的,罚刷阅读量,会了为止哈哈哈,再见,下次再一起学习哈!