51Testing软件测试论坛
标题:
优秀的测试用例是如何设计的?
[打印本页]
作者:
lsekfe
时间:
2023-6-21 11:25
标题:
优秀的测试用例是如何设计的?
这篇文章我们主要聊一下测试工程师最通用的也是最根本的技能,测试用例的设计能力。
测试用例
测试用例是通过使用在测试计划中确定的
测试技术
,对于已确定的测试条件进行逐步推敲,精炼而设计出来的重点说明如何具体操作产生何种结果的文档。
通俗的话就是要把想要测试的动作变成在什么情况下,做什么动作,用什么数据方式去做,最后想得到什么样的结果归集成一条测试用例。所以,每个测试用例应该有它的前置条件,应该有它的事件和对应的参数,最后有期望结果。这样就是一条合格的测试用例了。
比如登录功能,现在基本每个网站、
APP
等都有登录功能,也是面试中问的比较多的,找一个已经存在的用户,在界面上输入正确的用户名和密码,点击一下登录按钮,看看有没有登录成功。这是一个最最简单的操作,也构成了我们的第一个最正常的测试用例。也包含了前边说的几个要素:
·
前置条件:一个已经存在的用户
·
动作和参数:输入正确的用户名、密码,点击登录
·
期望结果:登录成功
这当然是一个完整的测试用例,但是对于一个登录模块来说,当然不够,这只是这个模块里合格的测试用例之一。那该怎么写出更多的测试用例呢?这时候就要去看我们的动词了:设计。设计其实对应的是一套方法,只有有正确的方法,才能设计出合格的测试用例。
用例设计
法
比较常用的测试用例设计方法
·
等价类划分法
·
边界值法
·
因果图设计法
·
判定表设计法
·
正交实验法
·
错误推测法
·
场景法
至于其中的原理、原则、怎样去使用,网上的资料一大堆,这里就不再说了。这多方法,那在设计的时候,该怎么去选择呢。这里借用网上流传的一个段子
输入分类选等价,给定范围加边界,条件组合出因果,条件孤立想判定,无限穷举取正交,业务复杂场景法,错误推测靠经验,测试充分全覆盖。
这么多方法都能用的到么?答案是否定的,在我的测试认知里,用的最多的就是边界值、等价类、场景法和错误推测这样几个方法。所以归纳总结一下,真正工作中我们设计的思路大概是:
·
用等价类划分方法划分大部分场景设计测试用例
·
任何情况下都必须使用边界值分析方法,经验表明用这种方法设计出测试用例发现程序错误的能力最强
·
程序业务复杂度比较高,则适当使用场景法补充一部分测试用例
·
如果你对该业务非常熟悉,可以根据经验在容易出错的地方补充一些测试用例
基于这样的设计方法,同样还是当初的那个登录界面,我们大体可以设计出下边的测试用例:
1. 已存在的用户,输入正确的用户名和密码,点击登录,验证是否登录成功;
2. 不输入任何内容,直接点击登录,验证是否登录失败,提示信息正确;
3. 已存在的用户,输入正确的用户名和错误的密码,点击登录,验证是否登录失败,提示信息正确;
4. 已存在的用户 A 与 B,输入 A 的用户名和 B 的密码,点击登录,验证是否登录失败,提示信息正确;输入不存在的用户名和任意密码,点击登录,验证是否登录失败,提示信息正确;
5. 已存在但状态异常的用户(如停用、冻结、锁定),输入正确的用户名和密码,点击登录,验证是否登录失败,提示信息正确;
6. 已存在的用户,用户名为小写,输入大写的用户名及正确的密码,点击登录,验证是否登录失败;
7. 已存在的用户,密码为小写,输入正确的用户名及大写的密码,点击登录,验证是否登录失败;
8. 密码是否自动加密显示或包含隐藏 / 显示功能,验证是否可以正常使用;
9. 用户权限是否区分,管理员及普通用户登录成功跳转是否正确;
10. 用户名及密码输入框是否具有长度限制,与注册时长度要求是否一致;
11. 登录失败到达一定次数,是否会自动显示验证码;
12. 有验证码情况下,输入正确的用户名密码及正确的验证码,验证是否登录成功;
13. 有验证码情况下,输入正确的用户名密码及错误的验证码,验证是否登录失败;
14. 有验证码情况下,点击验证码图片(或换一张按钮)是否更换验证码,更换后的验证码是否可用;
15. 有验证码情况下,点击验证码图片(或换一张按钮)更换验证码,使用更换前验证码登录,验证是否登录失败;
16. 刷新页面验证码是否跟随刷新;
17. 验证码超过可用时效,输入当前验证码,验证是否登录失败;
18. 登陆失败后,用户名是否保存,密码为空;
19. 是否有记住用户名功能和记住密码功能,是否可用;
20. 快捷键是否可用,密码是否不可以通过粘贴粘入;
21. TAB、ENTER 是否可以自动跳转控件及自动提交;
22. 是否支持第三方登录(微信、支付宝、QQ、微博等),登录验证是否正确;
23. 是否支持
手机
验证码登录,手机是否可以收到短信,是否可以登录成功;
24. 手机验证码超时,使用已超时验证码登录,是否可以登录成功;
25. 用户 session 失效后是否重新跳转登录页;
26. 用户登出后,通过后退按钮,是否可以继续操作;
27. 是否具有忘记密码功能,是否可用。
OK,简单列出了一些,但是如果这时候要我给这套用例打个分的话,那我可以打个 80 分。一定有小伙伴要实名 diss 我了,已经这么全面了,还要什么?为什么只有 80 分?这就涉及我们今天讨论主题的第三个维度了,形容词 “优秀的”。
谈优秀的测试用例
对于一组测试用例来说,只有完备的、可重复的、可验证的、需求覆盖全面的测试用例才是最优秀的测试用例。
数据日志测试
所谓的数据日志测试主要包含我们在前端,在页面或者 APP 上看不到的测试项,我举几个例子:
·
数据库
密码字段验证是否加密
· 登录失败次数是否
记录
在数据库、缓存中,逻辑是否正确
·
登录失败冻结等场景数据库是否正确修改状态
·
错误日志是否完备,是否便于排查问题
·
对象是否容易定位,便于自动化
·
是否有增加埋点,进行用户行为分析
界面 UI 测试
日常测试来说,界面和用户体验的测试也是非常必要的,像我们前边关于 TAB 和 ENTER 的使用其实就是用户体验的一种,所以如果要更全面地进行测试覆盖,就一定也要考虑到界面的测试。
·
布局是否合理,是否对齐
·
界面设计是否与需求、UI 设计文档一致
·
是否有错别字、标点错误缺失
·
页面颜色搭配是否得当
·
错误文字是否明确易懂
·
界面视觉效果是否恰当,界面动画展示是否流畅
兼容性测试
·
不同
操作系统
下,是否可以兼容(
Windows
、MAC OS、LINUX)
· 同一操作系统不同版本下,是否可以正常显示及功能正确性
· 不同
浏览器
下(Chrome、IE、FireFox 等)下是否可以兼容
·
同一浏览器不同版本下是否可以兼容
·
移动端是否兼容
·
放大缩小界面时是否兼容展示
·
不同语言下,界面展示是否正确
·
是否具有高对比读模式(为视力不好的人准备)
性能测试
性能测试又可以分为服务端性能和前端性能,也需要综合考虑,同时,针对性能的指标和场景也伴随着不同模块、不同企业、不同需求而有所不同,我在这里简单举几个比较通用的例子:
·
用户登录接口的最大并发数(响应时间 3s 内)
·
特定负载测试下服务器的性能指标
·
压力测试
过程中服务的稳定性和性能指标
·
服务的分布式处理逻辑,负载均衡逻辑、缓存及队列的使用
·
能够支持的接口最大并发量
·
GC 处理,是否有内存溢出等情况
·
高并发下数据库是否有慢
[url=]SQL[/url]
和死锁
·
页面加载速度
·
页面资源大小,是否应用雪碧图
·
YSLOW 分析,静态性能
安全测试
最后,也是我们最容易忽略的安全测试。很多时候我们容易忽略安全带来的威胁,但是实际上一旦发生安全问题,产生的损失会远远大于某一个
Bug
带来的影响。我们先就登录界面简单介绍一下应该采取的安全检测措施,后边有机会我们再细致聊一下安全测试的方方面面。
·
验证关键数据通过 HTTP 还是 HTTPS 传输
·
是否包含弱密码
·
是否容易被暴力破解
·
是否使用多因子认证
·
登录是否采用互斥性验证
·
产生的会话令牌(sessionID)强度
·
传输中是否存在会话令牌泄露情况
·
是否包含越权
漏洞
·
使用万能密码是否可以登录成功
·
是否可以进行 SQL 盲注
·
密码存储加密安全性
·
是否具有 XSS(跨站脚本)攻击防御
·
是否包含 CSRF 攻击漏洞
·
Token 或密码传输中防中间人攻击
写在最后,测试用例的执行还要和实际项目的紧急程度挂钩,明明项目很紧急要上线,难道要执行上面所有方面的用例,那啥都够不到了,所以测试用例的优先级要明确,在合适的时候执行相对合适的优先级的用例,保证产品质量。
作者:
花岗岩大炮
时间:
2023-7-7 09:50
说的太好了,有关于兼容性测试跟性能测试里面一些问题,实际工作中真的碰到过,当然也跟时间因素有关,但是也是发生了问题后才对部分因素有了新的认识,比如浏览器版本,高并发下服务器执行sql导致降级、死锁等系列问题
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)
Powered by Discuz! X3.2