工作中容易被忽略的缺陷
经过软件测试课程及系统性学习之后,进入工作中,总是遇到一些遗漏的或没有考虑到的缺陷,自己记录一下,以后针对不同的系统可以套用这个模版。
目录
权限
- 浏览器直接访问url地址
- …
浏览器直接访问url地址
有时候,开发只考虑到正常登录后的权限,没有考虑到直接访问url地址的情况。包括未登录直接访问url地址和已登录但无页面权限直接访问url地址。
具体做法:
1. 登录系统后摘录所有页面的url,包括通过超链接跳转的子页面。(获取方式: 鼠标中键/ F12/ Fiddler)
2. 在未登录系统的浏览器上,直接粘贴摘录到的url地址。
3. 在已登录但无页面权限帐号的浏览器上,直接粘贴摘录到的url地址。
预期:
- 跳转至登录页面。
- 给予无权限提示。
健壮性
- 多个用户同时对一条记录进行操作
- 接口在并发请求下的健壮性
- …
多个用户同时对一条记录进行操作
工作中,经常发现开发对多个用户同时对一条记录进行操作的场景没有做约束。特别是有状态变更的业务场景,严重程度不低。例如:用户A对记录进入编辑页面,用户B此时将该记录删除,用户A再进行保存操作,这种情况下,很可能已经被删除的记录又”复活”了。
具体做法:
1. 使用用户A对一条记录进行编辑操作,保持在编辑页面。
2. 使用用户B对该记录进行删除操作。
3. 此时,使用用户A继续编辑,完成保存动作。
预期:
- 用户B操作时,给予友好提示,并且不可删除。
- 用户A完成保存动作时,提示记录已被删除。
接口在并发请求下的健壮性
工作中,曾经遇到一个缺陷。有一个退款接口,并发请求时,余额会被扣成负数。这并不是性能问题,而是接口的健壮性很差。在实际业务场景上不会发生,但是很可能被恶意用户用Fiddler获取接口参数后,产生异常数据,甚至获利(如果是充值接口存在此缺陷呢?)。
具体做法:
1. 开启Fildder抓包工具。
2. 使用系统完成一笔业务操作。(选择你认为会改写系统内数据的接口)
3. 在Fiddler中查看该操作请求的url地址和参数。
4. 使用Jmeter,在Sampler中填入url和参数,进行大量并发请求。
5. 查看Jmeter中监听器、系统内相关记录页面、系统日志来检查是否产生了异常数据。
预期:
无任何异常数据产生。
注意:
接口测试应该完全基于恶意用户也能获取到的信息来进行测试。就如同本格推理,你不应该比恶意用户知道更多情报来辅助测试。
安全性
- 交易接口是否有sign签名参数
- 帐号为手机号的系统,是否有接口会直接暴露用户库
- 多次登录失败后是否有防御机制
- …
交易接口是否有sign签名参数
经常网上看到有人说FD撸东西,什么1分钱买东西啦,这里FD指的就是Fiddler。有些电商网站或APP对创建订单的接口没有sign签名参数,这导致用户修改了金额一样可以被服务器接受。(签名的用处在于,将请求中的参数以某种形式排列后加盐再加密,然后作为参数一起发出。)
具体做法:
1. 开启Fildder抓包工具,开启breakpoints - before requests。
2. 使用系统发起一笔交易操作。
3. 在Fiddler中找到该请求,修改其金额后,点击run to completion。
4. 在Fiddler中查看响应结果。
预期:
- 订单创建失败,给予友好提示,例如”订单异常”。
多次登录失败后是否有防御机制
在网页上,普遍登录需要验证码。但在手机APP上,验证码由于输入麻烦,并不多见。但是仍然应该在一定次数登录失败以后,出现验证码或者冻结30秒等防御机制。如果没有防御机制,那么恶意人员就能使用密码字典来对帐号尝试硬破。
具体做法:
1. 使用手机APP进行登录操作,填入正确帐号和错误密码。重复10次。
2. 查看每一次的登录失败的提示信息。
预期:
- 登录一定次数后,提示”请输入验证码”或者”登录次数过多,请30秒后重试”。
登录帐号为手机号的系统,接口是否会暴露用户库
工作中遇到过一个APP,在登录和注册时,对于没有注册的手机号,会有一个友好提示。这本并无不妥,但是手机号是纯数字的,这很容易进行大量参数递增请求。恶意人员可以通过对11位数字进行递增循环来进行请求,从响应内容中筛选出系统注册用户。
具体做法:
1. 阅读接口文档,在不需要登录的接口中,查找有可能会暴露识别信息的接口。(如注册/ 登录等)
2. 使用Fiddler抓包工具,获取注册接口的url地址和参数。
3. 使用Jmeter,在Sampler中填入url和参数(正确手机号和错误密码),进行1次请求。
4. 使用Jmeter,在Sampler中填入url和参数(错误手机号),进行1次请求。
5. 查看Jmeter中监听器。
预期:
- 无法从响应内容中分辨是不是系统注册用户。