日常工作中会有些容易被忽视的缺陷，如在权限、健壮性、安全性等如以下几个场景：
*权限——浏览器直接访问url
*健壮性——多个用户同时对一条记录进行操作
——接口在并发时候的健壮性
*安全性——交易交口是否有sign签名参数
——多次登录失败后是否有防御机制
——登录账号为手机号的系统接口接口是否会暴露用户库
权限-浏览器直接访问URL
有时候开发只考虑到正常登录后的权限，而忽略直接访问URL的情况，包括未登录直接访问url地址和已登录无权限访问URL地址。
操作：
step1：登录页面后摘录所有的URL地址，包括通过超链接跳转的子页面；
step2：在未登录系统的浏览器上，直接粘贴摘录的链接到url地址；
step3：在已登录无页面权限账号的浏览器上，直接粘贴摘录到url地址；
预期：
result1：跳转到登陆页面
result2：给予无权限提示
健壮性-多个用户同时对一条记录进行操作
工作中，经常会发现开发对多个用户同时对一条记录进行操作的情况，没有做约束，尤其是有状态变更的场景，如用户A对记录进行编辑，用户B此时对该记录进行删除，用户A再进行操作，这种情况下很可能被删除的记录又被“复活”。
操作：
step1：用户A对记录进行编辑，并保留在编辑页面；
step2：用户B对该记录进行删除；
step3：再使用用户A继续编辑，并保存动作；
预期：
result1：用户B操作时，给予友好提示，并且不可删除
result2：用户A操作保存时，提示已经删除
健壮性-接口在并发时的健壮性
工作中，曾经遇到一个缺陷。有一个退款接口，并发请求时，余额会被扣成负数。这并不是性能问题，而是接口的健壮性很差。在实际业务场景上不会发生，但是很可能被恶意用户用Fiddler获取接口参数后，产生异常数据，甚至获利（如果是充值接口存在此缺陷呢？）。
具体做法：
step1. 开启Fildder抓包工具。
step2. 使用系统完成一笔业务操作。（选择你认为会改写系统内数据的接口）
step3. 在Fiddler中查看该操作请求的url地址和参数。
step4. 使用Jmeter，在Sampler中填入url和参数，进行大量并发请求。
step5. 查看Jmeter中监听器、系统内相关记录页面、系统日志来检查是否产生了异常数据。
预期：
result：无任何异常数据产生。
思考：接口测试基于恶心用户获取也能获取到信息来测试
安全性-交易接口是否有sign签名参数
有人说FD（fiddler）撸东西，1分钱买什么啦，有些电商网站和app对创建订单接口没有sign签名参数，这会导致用户改了金额后可以被服务器接收，签名的作用在于将请求中的参数按某种形式排列后加盐再加密，然后作为参数一起发出。
具体做法：
step1. 开启Fildder抓包工具，开启breakpoints - before requests。
step2. 使用系统发起一笔交易操作。
step3. 在Fiddler中找到该请求，修改其金额后，点击run to completion。
step4. 在Fiddler中查看响应结果。
预期：
result： 订单创建失败，给予友好提示，例如”订单异常”。
安全性-多次登录失败后是否有防御机制
在网页上登录，会使用验证码，但是app上由于验证码输入麻烦，并不多见。但是仍然应该在一定登录次数失败后，出现验证码或者冻结30秒防御机制。如果没有防御机制，如果没有防御机制，那么恶意人员就会用密码字典对账号尝试强破。
具体做法：
step1. 使用手机APP进行登录操作，填入正确帐号和错误密码。重复10次。
step2. 查看每一次的登录失败的提示信息。
预期：
result： 登录一定次数后，提示”请输入验证码”或者”登录次数过多，请30秒后重试”。
安全性-登录账号是手机号时是否会暴露用户库
遇到一个app，在登录和注册时，对没有注册的手机号，有友好提示。这并无不妥，但是手机号是纯数字的，这很容易进行大量参数递增请求，恶意 人员对11位手机号递增循环来进行请求，从响应内容中筛选出系统注册用户。
具体做法：
step1. 阅读接口文档，在不需要登录的接口中，查找有可能会暴露识别信息的接口。（如注册/ 登录等）
step2. 使用Fiddler抓包工具，获取注册接口的url地址和参数。
step3. 使用Jmeter，在Sampler中填入url和参数（正确手机号和错误密码），进行1次请求。
step4. 使用Jmeter，在Sampler中填入url和参数（错误手机号），进行1次请求。
step5. 查看Jmeter中监听器。
预期：
result ：无法从响应内容中分辨是不是系统注册用户。
