服务端测试=接口测试?!No!

服务端测试 != 接口测试

  1. 从系统架构方面分析:分析开发文档+接口文档+需求文档,确认系统架构及数据逻辑,包括服务、资源等,设计测试用例正常+异常流等,将其形成组合场景,检查执行结果。
  2. 性能测试、安全测试、线上监控、接口测试
  3. 需要进行错误推测或者测试敏锐度,一些特殊场景可能出现的问题需要提前做测试预警,比如并发场景需要格外注意数据库的约束条件有无、资金相关唯一资金单据作为不可重复转账的保障等等

以红包测试为例:红包系统+数据平台系统+资金系统

需求:有多个环境,每个环境的用户并不相通。用户A在环境a发红包、抢红包,借助数据平台系统,其他本环境、非本环境的用户都可抢。

系统分析
(1)C端:iOS、Android;
(2)B端:后台、工作台;
(3)Server端:红包系统+数据系统+资金系统+相关核心业务系统+用户基础系统;
(4)数据库:Oracle
(5)redis+lua脚本利用redis + lua解决抢红包高并发的问题
(6)消息中间件:activemq

逻辑分析

发红包:A环境用户创建红包作为触发点,请求数据平台创建红包接口,在redis创建大红包,且根据红包算法拆成相应个数的小红包,写入数据平台系统,同步到A环境红包系统创建红包–初始状态,生成资金单据,到账务系统转账,转账成功通知红包系统、数据平台系统修改红包状态,发送红包成功。

抢红包:A环境用户抢红包,根据抢红包算法,经过redis+lua脚本处理大红包、小红包相关数据:已抢红包、待抢红包队列等,再修改数据平台大红包、小红包数据,同步到红包系统。同时,在数据平台创建一条抢红包记录,Oracle写入操作;之后同步数据到子环境红包系统,创建记录,Oracle写操作;根据抢红包记录生成的单据调用account转账接口,进行转账,同时记录account日志,Oracle写操作;最后修改红包系统、数据平台系统的红包状态为FINISH。

测试点分析

  • 测试发红包算法、抢红包算法;
    (1)发红包算法(以拼手气红包为例):主要是拆成若干小红包算法。第一方面:拆分结果个数、金额总和等需要满足大红包的要求,可以进行大量发红包试验,根据SQL语句校验拆分结果是否满足条件。第二方面:拆分算法解析,拆分额度已经在算法要求范围内,比如0.01-~之间,设计满足红包阈值的极值情况、正常情况、线上用户常见情况,比如:0.02拆2个红包、0.01拆1、0.03拆2、10拆2、8888拆666、100000拆10000,查看拆分情况是否正常。需要注意的点:金额的小数范围是两位;查看最大金额相同的时候,手气最佳的规则是最先抢到的用户;红包拆包数量较大的情况,拆包是否正常,是否可以正常抢包成功。
    (2)抢红包算法:首先需要知道抢红包的需求是先抢后抢拿到红包的大小的期望是大致相等的,可以设定500元红包,30用户同时去抢,200次、500次、更多,观察n次抢红包的总和结果,将趋于一致的结果与开发、产品确认,无误之后可使用。

  • 根据时序图,设计每一个环节的正常流、异常流的组合场景用例。且如系统重启后的消息重试机制、异步通知是否有效、是否有调单恢复机制、定时任务、Redis缓存定时刷新等、事务回滚机制、数据表字段并发场景的唯一约束等也要根据实际开发做相应的测试;

  • 性能测试:有库存的高并发抢红包;

  • 对账机制辅助:(1)红包发抢对账(2)account对账

  • 用户体验方面:因为数据流较长,对于客户端的用户实时体验问题。发红包后在界面的响应时间,解决方法【不一定非要是技术方面】

  • 线上监控情况+排错:错误排查+Task执行测试

    1.Linux监控日志查看【最具有参考依据】可转到日志相关文章

    2.数据库数据流追踪【数据库数据流是必不可少的测试点,是服务端测试用例执行的检验结果之一】

    3.接口返回响应报错【有些接口的响应结果相对笼统,不具个性】

    4.界面抛错–客户端根据服务端的返回错误信息作出相应的反应【在服务端测试不充分的情况下,结果不可信,客户端测试会提及,且客户端经过再次开发,结果不明显,也可能存在有bug的风险】

确认接口请求逻辑,进行Api接口层面的测试:包括基础测试+安全测试。接口测试是针对模块或系统间接口进行的测试。

  • 根据接口参数组合,设计测试用例。输入参数类型:数值型、字符串类型、数组或链表、结构体;结合各种测试方法:等价类、边界值等
  • 根据响应结果判断接口逻辑是否正确。从约束条件、操作对象、状态转换、时序分析等方面考虑
  • 返回码验证
  • 接口之间的关联关系验证
  • 接口安全:XSS注入、水平权限、垂直权限、SQL注入
    水平权限:用户操作非本人业务
    垂直权限:权限是否真正控制到功能,而非单纯菜单的展示与否
    SQL注入–or条件,跳过真实验证:进行权限之外的数据查询及接口操作。
    比如:
  	登陆接口:'or 1=1 --

  	查询接口:1 'or '2'='2

JS注入【XSS】:关注数据库层面的xss注入,写入数据库,数据能否正常返回及交互展示。

   	"/><script>alert(document.cookie)</script><!--

   	<script>alert(document.cookie)</script><!--

   	"οnclick="alert(document.cookie)
  • 已废弃的接口测试
  • 接口设计合理性分析

接口测试发现的典型问题

  1. 传参处理不当,导致程序crash
  2. 类型溢出,导致数据读出与写入不一致
  3. 因对象权限未进行校验,可以访问其他用户敏感信息
  4. 状态处理不当,导致逻辑出现错乱
  5. 逻辑校验不完善,可利用漏洞获取非正当利益等

接口测试工具很多,只要是可以对接口相关信息进行修改的都可以:postman、charles、jmeter


若有不同意见或补充建议,欢迎指正

发布了16 篇原创文章 · 获赞 0 · 访问量 590

猜你喜欢

转载自blog.csdn.net/LittleGirl_orBoy/article/details/104580961