一提到接口测试,通常大家会有这样的疑问:前端测试不是已经覆盖到各种业务逻辑了吗?为什么还要做接口测试,接口测试和前端测试是不是重复了?对于这个问题,可以从下面几个方面来解释:
什么是接口测试?
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。
为什么要做接口测试?
现在很多系统前后端架构是分离的,从安全层面来说,只依赖前端进行限制已经完全不能满足系统的安全要求,需要后端同样进行控制,在这种情况下就需要从接口层面进行验证。
如今系统越来越复杂,传统的靠前端测试已经大大降低了效率,而且现在我们都推崇测试前移,希望测试能更早的介入测试,那接口测试就是一种及早介入的方式。例如传统测试,你是不是得等前后端都完成你才能进行测试,才能进行自动化代码编写。 而如果是接口测试,只需要前后端定义好接口,那这时自动化就可以介入编写接口自动化测试代码,手工测试只需要后端代码完成就可以介入测试后端逻辑而不用等待前端工作完成。
接口测试实战案例分享
一、测试需求描述
1、 本次测试的接口为http服务端接口
2、 这里我们举例2个保存数据的接口,因为这两个接口有关联性,比较有代表性;
注:这个保存逻辑在接口开发设计文档中可能没有写或写的不详细,这时要与开发接口人员或产品人员多多沟通去熟悉接口逻辑
二、使用工具测试
为什么选择Jmeter进行http接口测试?
在进行网页或应用程序后台接口开发时,一般要及时测试开发的接口能否正确接收和返回数据,对于单次测试,Postman插件是个不错的Http请求模拟工具。
但是Postman只能模拟单客户端的单次请求,而对于模拟多用户并发等性能测试,就必须借助其他的工具了,这里推荐功能强大的JMeter自动化测试工具,Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试,它最初被设计用于Web应用测试但后来扩展到其他测试领域。
它可以用于测试静态和动态资源例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库, FTP 服务器, 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载,来自不同压力类别下测试它们的强度和分析整体性能。
下面我就简单的介绍下使用Jmeter进行接口测试的方法。
如何使用Jmeter进行接口测试?
1、首先邮件添加一个线程组,这里我们重命名InterfaceTest
2、在线程组上添加一个Http默认请求,并配置服务器的IP地址和传输编码
在线程组中添加一个HTTP请求,这里我们重命名“增加 信用卡账户信息接口 ”
配置接口请求信息,这配置示例如下:
在保存信用卡账单接口请求,示例如下:
注:由于Jmeter请求线程组内的请求时从第一个开始执行,所以我们将需要最先执行的请求放在前面
6、在线程组上添加监听器,察看结果树和聚合报告
点击启动,运行结束后查看,结果树和聚合报告
8、去数据库中核对数据
9、大批量数据制造
思路:
1、可参数化的参数,保存信用卡账户信息接口( clientNo,cardNo ),保存信用卡账单接口( clientNo,cardNo, billMonth,paymentDate)
2、两个接口的依赖关系,保存信用卡账单接口( clientNo,cardNo)要和信用卡账户信息接口( clientNo,cardNo )的两个相同,也就是说这两个要用一个参数,且还不能重复。
根据上面两个接口的特点,( clientNo,cardNo) 我们选取使用计数器,每循环一次计数器加1,那么我们将线程组设置循环执行1万次; billMonth,paymentDate,这两个日期我们是使用随机函数${__Random(1,9,)},将月份参数化;
信用卡账户接口传入参数
args={
“clientNo”:“${add}434343556”,
“alias”: “**信用卡2”,
“cardName”: “长城*****卡2”,
“cardNo”: “${add}25622356788251”,
}
账单接口传入参数
args={
“clientNo”:“${add}434343556”,
“accountName”: “测试”,
“billDate”: “08”,
“billMonth”: “20150${__Random(1,9,)}”,
“cardNo”: “${add}25622356788251”,
“currentPayment”: “欠款459.80”,
“paymentDate”: “2015-0${__Random(1,9,)}-25 09:00:00”,
}
简单的性能测试
性能分析:
测试结论:
当前测试环境下,TPS峰值为317.6次/秒。根据业务预期的客户日常访问量50次每分钟,按照每客户访问一次调用全部13个接口计算,则业务预期为50*13=650次/分=10.83次/秒。测试结果表明系统的业务处理能力符合业务预期。
由响应时间来看,保存XXXX这个接口的响应时间明显较慢,在50线程并发的时候,90%响应时间为7.7秒,而75线程并发的时候则达到了24秒,建议进行优化。
由点击率,响应时间,TPS统计图可知,整个稳定性测试期间,系统反应很稳定。
详细测试结果:
场景运行测试时间:10分钟
总体测试结果
场景运行时间:1小时
根据上面的几个步骤,得到测试结果,分析系统存在的瓶颈,然后采用各种方法提出解决方案或优化建议,最后对本次性能测试进行一个完整的总结,这样,一次性能测试就完成了。
在整个过程中,费时较长一般是在测试数据准备和测试执行、监控调优阶段。
最后吐槽一句:性能测试水太深,想潜水的做好准备,别稀里糊涂扎进来,太刺激。。
如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。
这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,点下方小卡片进群即可自行领取。