【探索测试篇】探索无界，BUG无限，让程序猿头疼的测试技术
【探索测试篇】探索无界，BUG无限，让程序猿头疼的测试技术
探索无界，BUG无限
一、修改系统时间
当功能模块中存在倒计时、计时器、时间，与时间有关系时，尝试修改系统时间，测试系统时间是否参与计算，修改系统时间是否会影响到倒计时、计时、时间等与时间有关系的模块
例：1小时后秒杀商品，修改系统时间到1小时后，测试是否可以下单
二、断网、断网重连、服务器断开
1、断网，操作功能流程，是否报错、闪退、卡死、异常显示问题
2、断网重连，app内，测试功能是否可正常使
3、断网，进入app，重连网，测试部分接口是否未重新调用，导致功能数据缺失
4、服务器断开功能使用检测
三、弱网
模拟网络弱网场景（4g网络、地铁、机场、地下室、室外等）
弱网状态，重复提交操作，会导致接口调用错乱、业务重复调用、业务出错等BUG
弱网状态，测试响应超时导致的接口报错等
弱网状态，测试延迟导致的页面交互错乱等
弱网状态，测试接口超时，导致的前后端异常问题（状态变更错误、数据加减错误）
1、弱网下客户端要传参数给服务器。 例如：请求参数是index = 0 ，拿到服务器响应，我们就index++。若服务器500，我们下次请求，必须还 是index = 0，所以我们要做 --index，用减去1返回值发请求。如果不幸写成index--，很不幸，bug就来了， 因为此时index = 1。 2、网络异常，测试客户端重试策略，只有在弱网下才能看到效果。 例如：客户端经常做一种处理，请求对象发送返回失败，客户端会重试，请求必须是异步进行的，此时可 能会出现重试失败，仍然一直在发请求，重试策略有问题，如果是服务器爆了，你一直重试发请求，app 绝对被爆………… 3、开源网络框架，也许经不住弱网 例如：现在Android的http开源框架天多了，公司多数都会用这些二次封装的框架，类似于okHttp、volley， 用的比较多一些，免不得在弱网环境下，抛异常。就因为请求是在工作线程进行的，所以……，并发不是所 有人都能玩的转的，很容易出现bug。 4、弱网环境下，网络连接失败，抛异常 例如：弱网迟迟没有返回响应，此时网络连接抛异常，可能会没处理，响应实例对象没有拿到，是个null， 又没处理，又要抛异常………… 5、弱网环境下，ui可能出现问题 例如：网络请求还在异步进行中，一般UI我们都会有进度条告知用户，没有拿到响应后，我们要更新ui，提 示用户网络连接失败等等文案，此时可能会出现问题，View没有同步成功，或者忘记gone掉进度条…… 6、网络请求失败策略之用户主动再次发出请求 例如：弱网下，请求失败（抛出异常），提示用户重试再次发出请求，用户点击重试再次发出请求，此时 处理可能会出现问题
四、推送
1、已登录账号，删除app重装，进入登录页面，register_id未清空会收到推送
2、已登录账号，登录信息失效，踢出到登录页面，register_id未清空，会收到推送
3、已登录账号，账号再其它地方登录，踢出到登录页面，register_id未清空，会受到推送
五、修改请求参数、修改响应内容
1、用户购买会员的金额可以通过修改请求里的金额，进行购买---原因：后端的代码没有将拿到的用户的金额和实际的金额进行对比，再去发出下一步的支付流程。
余额1元，购买2元商品，修改请求金额为2元，测试是否可购买成功
余额1元，购买2元商品，修改请求金额为0.1元，测试是否可购买成功
2、实名认证请求：https://m.kaola.com/member/activity/valid/nameAuth.html，只需将请求里Response里code修改为：unknown200，以及将success的值修改为true，然后将这个请求发出去之后，我们的刷子用户就可以成功绕过这个围墙了，去购买参加我们试用会员了，从而可以享受我们的7天会员96折价格
六、并发
1、余额1元，并发提现1元100次，测试成功提现多次
2、创建订单A，对订单A进行并发100次付款，测试付款成功多次
3、抽奖系统，每人可抽一次，并发抽取100次，测试可抽取多次
4、1个红包、2个红包时，同用户并发提现100次，不同用户并发提现100次
七、越权
1、登录权限越权
token失效、账号被踢出，使用创建订单、充值、付款功能，对token检验进行测试
2、业务逻辑越权
<1>业务状态越权
新建的订单、已付款的订单、已发货的订单、已收货的订单、已完成的订单、已评价的订单，进行付款操作测试
<2>业务终结越权
已实名认证成功，再次实名认证、再次实名认证其它身份证
<3>业务上下层越权
已实名认证，进入提现业务，库里改状态为未未实名认证，提现检测
<4>业务资源占用越权
A身份证被A用户占用，B用户绑A身份证检测
3、垂直越权未授权功能
主管有修改权限，客服有查看权限，主管账号更换为客服账号，进行修改操作测试
4、水平越权其它用户、团队资源
通过修改URL链接上的参数来进行一些非对应账号信息的查看和操作。
例1：修改URL上的订单号为别人的，查看、修改、删除、评价、操作别人的订单进行测试
例2：修改URL上的订单参数为不存在的，查看、修改、删除、评价、操作别人的订单进行测试
例3：主管有修改权限，A团队主管修改B团队成员信息
5、非归属关系越权
例：转移会员给已锁定的BD，转移成功，应不可转移
八、重复提交
重复提交业务会处理多次，业务逻辑会错乱
例1：新建订单、每次签到、领取奖励，重复提交多次，导致业务创建多次检测
例2：实名认证成功，业务结束，再次实名认证，业务处理检测
九、假设法
1、假设列表字段为0、空、null值、超长、超大，测试异常、报错、溢出问题
2、假设因为BUG导致绑定了别人的卡，提现测试
3、假设列表数据10w条，大量数据测试
4、假设接口返回跳转链接字段空，点击跳转，APP闪退，需异常处理
接口应该返回：
{"code":0,"msg":"成功","data":{"status":true,"url":"http:\/\/activity-h5.st1.test.lanxinka.com\/interview-report?target=watch_c&id=JyNHWjwVbm"}}
但是返回：{"code":0,"msg":"成功","data":{"status":true,"url":""}}
5、假设页面1接口还未返回数据时，进入页面2，页面2需用到接口字段，会报错
例：页面1是商品列表，点商品进入商品详情页面，进入商品伤情页面需传商品id
解决：页面1还未加载完成时，无法拿到商品id，前端判断，无法进入商品详情
6、假设页面接口字段还未返回时，触发页面功能，导致出错
例：接口返回手机号字段，显示到页面上，点拨打电话，可拨打电话
解决：前端还未拿到手机号字段时，不显示拨打电话按钮或点拨打电话，弹出提示
十、内存溢出、内存泄露
1、内存泄露，长时间操作功能或模块，感觉越来越卡、越来越慢，测试内存泄露问题
2、内存溢出，长时间操作功能或模块，感觉越来越卡、越来越慢，直至报错、闪退等问题，测试内存溢出问题
3、操作功能，观察内存使用情况，测试后端代码是否存在内存泄露问题
十一、超时、失败、接口异常报错
超时
1、接口响应超时，测试超时后的处理
因网络慢、服务器压力大、数据量大，导致处理时间过长超时，调用支付中心，业务方失败，支付中心处理成功，钱已发出去
例1：发佣金2000条，点审核通过，处理结果为发送失败（应该是超时了），但支付中心处理成功，实际金额已发到用户账户
2、前端请求超时，测试超时后的处理
3、第三方系统维护中，测试维护中处理
4、服务器断开，测试功能使用的异常处理
失败
1、失败结果处理
充值失败，冲入和冲出账户回退检测
接口异常报错
1、接口报错500，前端处理检测
2、接口返回格式错误，前端处理检测
3、接口未获取到数据，前端处理检测
十二、SQL、代码注入
1、表单类注入
登录时SQL是这样：select * from user where username='chengzi' and password=md5('123456');
我们现在需要构建一个比如：在用户名输入框中输入: ’ or 1=1#,密码随便输入，这时候的合成后的SQL查询语句为：
select * from user where username='' or 1=1 #' and password=md5('123456');
等价于
select * from user where username='' or 1=1;
就可以登录成功了
2、url传参注入
首先应测试是否存在注入漏洞，简单的：’ 或 and 1=1 and 1=2之类的SQL语句。
如果没有检测，直接运行SQL语句，说明有机会注入。
举例：
从参数注入，简单的测试方法是：
① http://www.xxx.com/index.php?id=2
② http://www.xxx.com/index.php?id=2' and 1=1
③ http://www.xxx.com/index.php?id=2' and 1=2
可以注入的表现：
① 正常显示（这是必然的，不然程序就有错）
② 正常显示，内容基本与①相同
③ 提示BOF或EOF（程序没做任何判断时）、或提示找不到记录（判断了rs.eof时）、或显示内容为空（程序加了on error resume next）说明未进行特殊字符过滤处理，存在SQL注入漏洞
3、代码注入
提交死循环代码，测试是否进行过滤处理
<script> for(i=0;i<1;i--) { alert("msg") } </script>
十三、安全测试—短信轰炸
危害：
1、批量给用户发100w条短信，造成用户骚扰和公司短信费用损失
2、批量给非正常手机号码发短信
语预防方案：
1、对手机号做验证，正确的手机号才可发短信成功
2、同一个手机号不能连续获取短信验证码，如设置1分钟仅允许使用1次
3、同一手机号，一天设置最大发送验证码次数，如同一手机号一天最多发十条
4、设置每日总成功短信上限
5、当同一个手机号码或者ip重复连续不断发起请求时，将手机号码或者ip拉黑处理
十四、多触点控
1、测试页面交互错乱问题
十五、接口status字段
1、接口各种status，功能页面显示检测
2、接口各种status，操作功能提示信息检测
十六、数据初始化修复
1、因表结构发生变化原因，老数据需做初始化修复
2、因表版本功能变更原因，老数据需做初始化修复
3、因操作失误原因，老数据需做初始化修复
4、因BUG原因，老数据需做初始化修复
十七、接口字段（一般不能删减）或字段值，修改、删减
1、新版本原字段检测
2、新版本原字段值检测
十八、未来状态/不存在的关联传参
1、如果status有1：招聘 2：非招聘
考虑0和3测试，程序如何处理的？是否会=<1统一处理成招聘,>=2统一处理成非招聘，如果这样处理了，下个版本如果加了status 3：急招，新版本后端先上线，app审核阶段，0会显示招聘，3会显示非招聘，这样是错误的，所以当时就应该非1和2，统一处理为不存在的状态
2、支付不存在的订单号检测
十九、优选资源少校验
因为优先校验资源少的，校验不通过，避免校验资源大的，造成服务器资源浪费消耗
例如：手机号和验证码登录，优先校验验证码是否正确，再校验用户登录信息是否正确，如果验证码不正确，避免用户信息查询校验
二十、外部事件
断网、断网重连、关闭定位权限、关闭通知、关闭相机相册权限、关闭电话权限
电话、短信、视频、重启手机
安卓（返回键、清缓存、清数据、转移应用）
IOS（锁屏、HOME）
持续更新——————————————————————————————