【探索测试篇】探索无界，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、代码注入

提交死循环代码，测试是否进行过滤处理

 

十三、安全测试—短信轰炸

危害：

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）

 

持续更新——————————————————————————————