背景
由经验可知,由于时间成本和经济成本,人们是无法穷尽所有可能的测试组合来发现系统里所有未知的缺陷,而是采用基于风险驱动的模式来侧重地选择测试范围和设计测试用例,以此来寻求缺陷风险和研发成本之间的平衡。
如何设计测试用例?
测试用例的设计需要从两方面展开,即显式功能性需求和非功能性需求。显式功能性需求指的是需求说明书中所写到的需求描述,比如“用户输入正确的账号和密码可以成功登录”,而非功能性需求主要涉及安全性、性能和兼容性。
一、功能性测试用例
对于大多数的软件测试而言,功能性测试用例的设计,综合使用 等价类划分,边界值分析 和 错误推断 就足够了。
实践:对下图的设计图(来源于:有赞)和给出的需求描述来设计测试点,然后根据测试点使用以上三种方法来设计测试用例。
用户填写已注册的手机号后获取短信验证码并填写,设置密码后点击确认修改按钮后密码重置成功。
序号 | 测试点 |
---|---|
1 | 手机号栏位输入平台不存在的手机号,验证短信验证码是否获取成功 |
2 | 手机号栏位输入为空,验证短信验证码是否获取成功 |
3 | 手机号栏位输入为空,其他栏位输入不为空,验证表单是否提交成功 |
4 | 手机号栏位输入平台已注册的手机号,验证短信验证码是否获取成功 |
5 | 手机号栏位输入平台已注册的手机号和新密码前提下,输入错误的短信验证码,验证表单是否提交成功 |
6 | 手机号栏位输入平台已注册的手机号和新密码前提下,输入失效的短信验证码,验证表单是否提交成功 |
7 | 手机号栏位输入平台已注册的手机号和新密码前提下,短信验证码栏位输入为空,验证表单是否提交成功 |
8 | 手机号栏位输入平台已注册的手机号和有效的短信验证码前提下,新密码栏位输入为空,验证表单是否提交成功 |
9 | 手机号栏位输入平台已注册的手机号和有效的短信验证码前提下,新密码栏位输入与旧密码相等,验证表单是否提交成功 |
10 | 手机号栏位输入平台已注册的手机号和有效的短信验证码前提下,新密码栏位输入长度不正确,验证表单是否提交成功 |
11 | 手机号栏位输入平台已注册的手机号和有效的短信验证码前提下,新密码栏位输入其他特殊字符,验证表单是否提交成功 |
12 | 手机号栏位输入平台已注册的手机号和有效的短信验证码前提下,新密码栏位输入与旧密码不等,验证表单是否提交成功 |
13 | 全部栏位输入为空,验证表单是否提交成功 |
序号 | 前置条件 | 操作步骤 | 预期结果 |
---|---|---|---|
1 | 无 | 1.手机号栏位输入平台不存在的手机号 2.点击“获取验证码”按钮 |
1.获取验证码失败 2.提示用户“请输入正确的手机号” |
2 | 无 | 1.手机号栏位输入为空 2.点击“获取验证码”按钮 |
1.获取验证码失败 2.提示用户“请输入手机号” |
3 | 已成功获取短信验证码 | 1.手机号栏位清空输入 2.短信验证码栏位正确输入已获取的有效验证码 3.新密码栏位输入有效 4.点击“确认修改”按钮 |
1.密码修改失败 2.提示用户输入“请输入手机号” |
4 | 无 | 1.手机号栏位输入国内已注册的手机号 2.点击“获取验证码”按钮 |
1.获取验证码成功 |
5 | 无 | 1.手机号栏位输入国际已注册的手机号 2.点击“获取验证码”按钮 |
1.获取验证码成功 |
6 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入错误的6位数字 3.新密码栏位输入有效 4.点击“确认修改”按钮 |
1.密码修改失败 2.提示用户“请输入正确的验证码” |
7 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入5位数字 3.新密码栏位输入有效 4.点击“确认修改”按钮 |
1.密码修改失败 2.提示用户“请输入正确的验证码” |
8 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入7位数字 3.新密码栏位输入有效 4.点击“确认修改”按钮 |
1.密码修改失败 2.提示用户“请输入正确的验证码” |
9 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入失效的验证码 3.新密码栏位输入有效 4.点击“确认修改”按钮 |
1.密码修改失败 2.提示用户“验证码已失效,请重新获取验证码” |
10 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入为空 3.新密码栏位输入有效 4.点击“确认修改”按钮 |
1.密码修改失败 2.提示用户“请输入验证码” |
11 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入有效的验证码 3.新密码栏位输入为空 4.点击“确认修改”按钮 |
1.密码修改失败 2.提示用户“请输入密码” |
12 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入有效的验证码 3.新密码栏位输入与旧密码相等 4.点击“确认修改”按钮 |
1.密码修改成功 2.页面自动跳转至个人中心页面 |
13 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入有效的验证码 3.新密码栏位输入数字和字母的组合且长度为7 4.点击“确认修改”按钮 |
1.密码修改失败 2.提示用户“请输入正确的密码” |
14 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入有效的验证码 3.新密码栏位输入数字和字母的组合且长度为8 4.点击“确认修改”按钮 |
1.密码修改成功 2.页面自动跳转至个人中心页面 |
15 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入有效的验证码 3.新密码栏位输入数字和字母的组合且长度为9 4.点击“确认修改”按钮 |
1.密码修改成功 2.页面自动跳转至个人中心页面 |
16 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入有效的验证码 3.新密码栏位输入数字和字母的组合且长度为19 4.点击“确认修改”按钮 |
1.密码修改成功 2.页面自动跳转至个人中心页面 |
17 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入有效的验证码 3.新密码栏位输入数字和字母的组合且长度为20 4.点击“确认修改”按钮 |
1.密码修改成功 2.页面自动跳转至个人中心页面 |
18 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入有效的验证码 3.新密码栏位输入数字和字母的组合且长度为21 4.点击“确认修改”按钮 |
1.密码修改失败 2.提示用户“请输入正确的密码” |
19 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入有效的验证码 3.新密码栏位输入长度为18且包含空格及其他特殊字符 4.点击“确认修改”按钮 |
1.密码修改失败 2.提示用户“请输入正确的密码” |
20 | 无 | 1.手机号栏位输入国内已注册的手机号 2.短信验证码栏位输入有效的验证码 3.新密码栏位输入与旧密码不等 4.点击“确认修改”按钮 |
1.密码修改成功 2.页面自动跳转至个人中心页面 |
21 | 无 | 1.手机号栏位输入为空 2.短信验证码栏位输入为空 3.新密码栏位输入为空 4.点击“确认修改”按钮 |
1.密码修改失败 2.提示用户“请输入手机号” |
以上的测试用例示例基本已覆盖显示功能性需求了,但是还可以再根据实际使用经验、个人理解或者类比平台来进行扩充。测试点如下:
序号 | 测试点 |
---|---|
1 | 新密码栏位是否区分大小写 |
2 | 页面上的密码框是否加密显示 |
3 | 刷新页面是否会重新提交表单 |
4 | 页面默认焦点是否定位在手机号输入框中 |
5 | Enter 键是否可以正常使用 |
二、非功能性测试用例
如果软件系统的质量要求过硬,那么非功能性需求的验证就必不可少。而非功能性需求主要涉及到了安全性、性能和兼容性这三方面。以 用户登录 为例,分别列举测试点。
1.安全性测试点
序号 | 测试点 |
---|---|
1 | 验证存储在数据库中的用户密码是否加密 |
2 | 验证前端在提交用户密码时是否进行加密处理 |
3 | 验证用户密码是否具有时效性,到期后是否提示用户修改密码 |
4 | 未登录前提下访问登录后的URL,验证码是否会重定向至登录页面 |
5 | 验证密码输入框是否支持使用粘贴 |
6 | 密码输入框中输入常见的“SQL注入攻击”字符串,验证系统返回的页面 |
7 | 密码输入框中输入常见的“跨站脚本攻击”字符串,验证系统的行为是否被篡改 |
8 | 验证系统是否会阻止暴力破解密码 |
9 | 同一用户先后在同一终端的多种浏览器上登录,验证登录功能的互斥性 |
10 | 同一用户先后在不同终端上登录,验证登录功能的互斥性 |
2.性能压力测试点
序号 | 测试点 |
---|---|
1 | 验证单用户登录的响应时间是否小于3s |
2 | 验证高并发场景下用户登录的响应时间是否小于5s |
3 | 验证高集合点并发场景下,是否存在资源死锁和不合理的资源等待 |
4 | 同一时间大量用户连续登录和登出,验证服务器端是否存在内存泄漏 |
3.兼容性测试点
序号 | 测试点 |
---|---|
1 | 验证不同浏览器下登录页面的功能和显示是否正常 |
2 | 验证相同浏览器的不同版本下的登录页面的功能和显示是否正常 |
3 | 验证不同移动设备终端的不同浏览器下登录页面的功能和显示是否正常 |
4 | 验证不同分辨率的界面下登录页面的功能和显示是否正常 |
结论
大体上看,以上已经覆盖了大部分的测试需求,但是随着互联网的发展和变化,还需要从实践中不断总结自己的经验,不断借鉴和对比其他平台来放大自己的眼界,不要局限于当前的需求说明书,要持续探索未知来弥补自己的不足。只有这样,测试用例这张大网才能越织越密。