29、OSPF配置实验之被动接口
319
2022-07-12
当你准备给自己所负责的项目搭建接口自动化测试时,面对市面上多种多样的工具或者框架,是否遇到不知该选哪个工具的困惑?本片文章通过对时下使用广泛的接口自动化工具进行对比来介绍自动化工具或者框架选择策略,协助处于困惑中的小伙伴选择适合项目的接口自动化工具。
在讲工具选择策略前,我们先思考一下这三个问题
搭建自动化的价值是什么?
覆盖接口的哪些内容?
如何降低接口自动化测试维护成本?
对于以上三个问题,你有自己的答案了么?以下是笔者对以上三个问题的思考。
搭建自动化的价值
搭建自动化的目的是覆盖全面且能快速反馈被测应用质量。想像一下对于一个功能复杂的系统,开发在上线前刚刚修复了几个bug,测试问开发影响范围,开发可能会说“不好说,都测试一遍吧”。如果你遇到这样的答案是不是要抓狂,实际项目中这样的情况不仅存在,而且可能还比较频繁。此时如果有个覆盖全面的自动化脚本该多好,让自动化脚本跑起来,茶水间喝杯咖啡回来就知道质量结果了。
接口覆盖策略
1. 系统自己使用的接口覆盖测试场景而不是单个接口的response。
比如一个更新用户个人信息的接口,试想一下如果是手动测试,你会如何做?肯定是在页面上更新某个信息或某几个信息,然后查看对应的数据字段是否更新或者页面是否显示新的内容。你会单独查看接口的response是否和需求文档一致么?大部分情况下都不会。所以在搭建接口自动化测试时建议覆盖测试场景以此保证业务功能是否正确。
2. 对外提供的接口重点检查接口的response body和response schema。
有些小伙伴读到这里是否会犯迷糊,第二点似乎和第一点矛盾了呢?实际不矛盾,对于对外的接口,因为接口使用方是第三方,对于第三方在哪些业务场景下如何使用该接口不是接口提供方的测试范畴,故接口提供方只需保证接口返回的内容与格式与之前定义的一致即可。
3. 只要提供接口的地方就尝试进行覆盖,保证接口测试足够全面。
降低维护成本策略
1.管理测试数据,保证测试case独立性。即每一个测试案例需要的测试数据在案例运行前自动准备,案例运行完后自动清理。任何用例的执行不依赖其他用例是否执行成功。
2.管理配置信息,保证多环境运行无障碍。即当测试环境切换后,能通过环境变量简单快速切换到所测环境,无需任何手动介入,相同的一套测试脚本DEV环境能运行,切换到UAT环境同样能全部正常运行。
3.已实现的自动化脚本能快速重用。例如一个系统有3个角色,已经完成了“初始化用户为系统任意角色”的测试脚本,假设此时新增了一个功能,此功能只有系统某个角色才能操作,那么在准备测试数据时就可以调用之前的代码快速初始化所需用户。
4.清晰的代码分层。让新上项目的人也能快速上手开始自动化脚本编写。
5.默认等待机制,解决数据延迟问题。例如调用一个接口到数据全部落入数据库需要时间,如果没有默认等待机制,调用接口后立刻查询数据库数据可能出现错误假象。对于微服务,这类问题可能更突出。
6.Retry机制,对于部分不稳定的接口,适当的retry机制可以保证自动化用例成功率。
7.管理接口reqeust body,接口的request body修改频繁,要尽量引入其他工具协助更好的维护接口的request body,否则接口body的任何修改可能都会引起自动化的大面积修改。
8.集成到CICD平台,定时运行持续优化。
9.详细的日志打印,流水线上清晰知道错误原因。
10.测试工具是否支持脚本语言,是否有完善的帮助文档,github上start数量,是否还在持续维护。
首先需要明确你的项目需要完成怎样的自动化,然后再查看市面上的工具,看看这些工具以及支持的语言是否满足你的需求,只要有了明确的目标,选择就不再困难。比如要搭建覆盖全面且较低维护成本的接口自动化,选择工具时首先需要考虑是否能轻松获取到接口response body和校验response schema,另外还需考虑能否实施“降低维护成本”中提到的10个策略,如果都能实施,那就用它了。
自动化测试,算是近几年比较火热的一个话题,当然,更是软件测试未来的一个发展趋势。未来,功能测试等非核心的测试工作,都将被外包。
想要在软件测试这个行业继续前行,就必须拥有核心竞争力,掌握自动化测试技术,是必不可少的一个技能。
在《Google软件测试之道》一书中有介绍到:在Google,70%的自动化测试工作集中于单元测试,20%集中于接口测试,剩下10%才是UI测试。
诚然,我们没有Google那么完善的机制和工程师文化,没必要一切照搬Google,但Google作为互联网2.0时代最耀眼的一个公司,它的技术发展方向,流程管理等可以说是不久的将来,我们也要到达的方向。选择适合自己的,落地应用,是当下我们应该做的。
目前国内的互联网行业,大环境来说,还处在一个快速发展,需要流程化标准化的时期,如何跟上不断变幻发展的节奏,除了不断了解接触新的东西,还需要不断学习,提升自身,以内在的驱动力,去紧跟时代浪潮。即使做不了弄潮儿,也不能变成时代淘汰的那一批。说到这里,推荐2本书:吴军的著作《浪潮之巅》、《硅谷之谜》,感兴趣的童鞋可以去看看。。。
接口,即API,应用程序编程接口,关于接口的介绍,之前的博客就有详细介绍过,感兴趣的童鞋可以去看看:https://blog.csdn.net/A_Kaka/article/details/107410497
这里主要说说接口测试的必要性和意义:
接口测试实施在多系统的平台架构下,有着极为高效的成本收益比(当然,单元测试收益更高,但实施单元测试的成本投入更大,技术要求更高,所以应该选择更适合自身的才是最好的方案)。
接口测试天生为高复杂性的平台带来高效的缺陷检测和质量监督能力,平台复杂,系统越庞大,接口测试的效果越明显。
总的来说,接口测试是保证高复杂性系统质量的内在要求和低成本的经济利益驱动作用下的最佳方案,主要体现在如下三个方面:
1、节省了测试成本
根据数据模型推算,底层的一个程序BUG可能引发上层的8个左右BUG,而且底层的BUG更容易引起全网的死机;接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。
2、接口测试不同于单元测试
接口测试是站在用户的角度对系统接口进行全面高效持续的检测。
3、效益更高
将接口测试实现为自动化和持续集成,当系统复杂度和体积越大,接口测试的成本就越低,相对应的,效益产出就越高。
业务流:了解系统及内部各个组件之间的业务逻辑交互;
数据流:了解接口的I/O(input/output:输入输出);
协议:包括http协议,TCP/IP协议族
工具:工具可以辅助我们更好更高效的完成工作,常用的接口测试工具有:jmeter、loadrunner、soapui、postman等;
数据库知识:无论是从数据库获取知识,还是确认数据落地,抑或接口对数据执行了哪些操作,都需要确认,因此数据库知识(其实就是增删改查)就很有必要;
补充:接口文档的几个必要点:完整性、一致性、容错性;
1、如何开展
首先,调试单个接口,保证单个接口的正确和通畅(类似于性能测试中的基准测试);
其次,明确数据流,业务流;
最后,将N个接口测试脚本串起来,执行即可;
最重要的一点,别想太多太复杂,先把最基础最简单的做起来,就成功一大半了,至于扩展性的第三方接口、https、定时任务、自动出测试报告、自动发邮件等等功能,这都是不断累计和优化的,
行动起来就行,想太多不如行动起来,让接口自动化测试落地,才是我们首先需要考虑的!
2、开展之前需要知道的
现在的测试对象包含几个页面?
每个页面涉及几个接口?
分别在哪一步调用?
每个接口包含哪些字段?
各个字段对应数据库哪张表?
每个表中各个字段是什么意思?
各个接口对表产生了怎样的操作?
3、自动化框架
什么是框架?你可以理解为一个完整的环,也可以理解为让接口测试脚本运行的一整套环境,平台,随便什么都可以;一般一个自动化测试框架包含以下几点:
数据池:即测试数据的存储管理,一般集成为一个data包,其中包括:
log(日志文件)、report(测试报告文件,一般为xml格式)、case-data(单个接口的测试数据,一般为json格式)、server-data(接口业务串联的数据,可以用excel管理)
脚本管理中心:接口测试脚本的统一管理、存储、调度中心,常用的工具有maven、ant等,或者可以使用编程语言中的单元测试框架提供的功能,选择自己适用的即可;
运行平台:一般是借助工具来运行这些测试脚本,工具可以使用上面提及到的几种(jemter、loadrunner、soapui等),同样,选择合适的很重要;
持续集成工具:最常见的就是Jenkins,它的作用就是监控外部程序的调用执行,定时或者触发调度任务,测试脚本执行等功能;
通信服务:dubbo、spring_boot、thrift等RPC、REST同步调用服务;
测试结果统计管理中心:比如testlink,目的是为了测试结果自动更新上传,更好的统计测试结果,以便后期的优化;
上面说了这么多,实际上它的意义就是:数据与脚本分离,测试结果自动提交通知,提高测试脚本和测试数据的维护便利等等。。。
关于接口自动化测试,基本就是上述的内容,当然,选择适合自身实际情况的框架,落地实施,才是重点,行动起来,才能咸鱼翻身。。。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~