为什么要做接口测试?
近几年随着业务迭代速度加快,以及测试行业的不断发展,像测试左移、敏捷测试等理念开始被更多的人认可。从软件工程的角度来说,越早介入发现问题和风险,修复的成本越低,最终交付的质量也越高。
道测试金字塔模型,见下图:
按照某些理论或者大厂的最佳实践,UI:API:UNIT层的自动化测试占比应该是1:2:7。
原因如下:
UI:维护成本高,介入时间较晚,收益最小;
API:维护成本适中,可以尽早介入,覆盖的场景也较多;
UNIT:维护成本最小,可以更早介入,测试粒度最小,收益最高(至于谁来写单元测试,当然是开发啊);
技术要求的提升
国内大部分测试同学在技术上来说相比于开发,是要弱上不少的。
为了不断提升软件系统的交付质量,需要尽可能的扩大测试覆盖的场景和测试的深入程度,这对测试同学的技术有了更高的要求。
随着系统复杂度提升,同时像微服务、云原生、server mesh等新技术的应用,为了了解被测对象以便更好的开展工作,测试这个岗位的技术要求也越来越高。
从一开始的UI层面的测试,开始不断向下探,API层的测试在日常工作中的占比越来越高也是演进的一个必然趋势。
API测试还有2个特性:
相比于UI层测试可以更早介入,向上可以不断加大UI层的覆盖广度;
相比于UNIT层测试难度更低点,向下可以逐渐覆盖一些公共接口的单元测试;
接口和接口测试?
如何理解接口?
简单来说,接口就是一个中介,负责界面层的业务场景和代码层的实现逻辑交互转化。
接口遵循一定的规则和约束,输入特定的数据会返回特定的数据,输入和输出的逻辑需要事先约定。
接口之间互相调用也需要遵循一定的规则,这个规则就是网络协议,如:http协议、tcp协议,rpc协议。
如何理解接口测试?
接口测试就是对约定好的输入输出逻辑进行测试和校验,和功能测试一样也需要设计测试用例。
设计测试用例的方法和功能测试没太多区别,同样需要考虑等价类边界值判定表法以及异常场景。
当然,接口测试还需要考虑性能、安全等因素,不过这就是其他细分测试领域了,这里暂且不表。
学习一些接口测试相关的工具,业内常用的工具如下:
抓包工具:Fiddler、Charles
测试工具:Jmeter、Postman
接口生成管理工具:Yapi、Swagger
UI/API/UNIT测试的区别:
UI、API、UNIT测试有各自不同的特点,概括总结的话区别如下:
UI测试:业务流程测试;
API测试:业务数据流测试;
UNIT测试:业务实现逻辑测试;
如何落地接口自动化测试?
在讨论新手从零到一落地接口自动化测试之前,我想先抛出我的几点建议:
从零开始,不要直接去学习所谓的自动化框架;
学习框架之前,很有必要学习网络协议和编码知识;
为什么这么说?
新手一般技术基础不太扎实,且没有太多编码实践,直接学习框架特别容易一步一个坑。
见过太多新手直接学框架,出现了诸如安装失败,报错看不懂,不会调试等等很多现象。还有部分同学对代码编辑器不会用,看不懂日志,不会封装等问题。
从零开始学习落地接口自动化,或者说其他自动化测试,我更建议从易到难的去落地实践,这样一方面可以在日常工作中优先保证工作的完成,提升工作效率;
另一方面就像打怪升级一样,从易到难去学习提升自己,并不断优化自动化测试在工作中的实践。
从一到难落地实践接口自动化测试,大概可以遵循如下几个步骤:
学会用工具进行接口测试(如jmeter/postman);
学会用持续集成工具(如jenkins)将接口测试脚本批量执行;
学会诸如git/gitlab等版本和源代码管理的工具,便于团队多人协作;
学习一门编程语言,利用自动化测试框架将工具脚本转化为代码脚本;
学习将公共部分封装,优化代码结构,提高写代码脚本的效率,降低维护成本;
学习数据参数化管理的方法,可以从Excel——配置文件——数据库——造数工厂这个方向迭代;
尝试按照业务线和测试场景区分脚本集合,然后引入mock,降低服务间的调用依赖,提高执行效率;
…
下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
不要让过去的失败束缚你,不要让困难挡住你的脚步。只有坚持奋斗,才能拥抱美好的未来。相信自己的力量,勇敢前行,你将开启辉煌的人生篇章。
追寻梦想的路上,只有拼尽全力才能抵达胜利的彼岸。困难是临时的,坚持是永恒的。相信自己,勇敢追逐,你将创造属于自己的奇迹!
不要因为起点落后而放弃追逐,每一步努力都是靠近梦想的距离。坚持不懈,才能绽放辉煌;奋斗不息,方能创造人生奇迹。相信自己,勇往直前!