个人网站代做,wordpress 自定义后台登录页面,网站备案 信息查询,wordpress局域网说到自动化测试#xff0c;或者说接口自动化测试#xff0c;多数人的第一反应是该用什么工具#xff0c;比如#xff1a;Python Requests、Java HttpClient、Apifox、MeterSphere、自研的自动化平台等。大家似乎更关注的是哪个工具更优秀#xff0c;甚至出现“ 做平台的 或者说接口自动化测试多数人的第一反应是该用什么工具比如Python Requests、Java HttpClient、Apifox、MeterSphere、自研的自动化平台等。大家似乎更关注的是哪个工具更优秀甚至出现“ 做平台的 写脚本的 用工具的 ”诸如此类的鄙视链但却很少有人去关注接口测试用例的设计问题。
在我看来工具并没有高低贵贱之分只能说哪个更适合适合当前的业务以及适合当前的团队协作。
自动化测试的本质还是测试自动化只是为了提高测试的效率而测试的基础是测试用例因此我们不应该忽略接口自动化测试用例的设计问题。换言之当你掌握了自动化测试用例的设计思想以及方法无论用什么工具都能得心应手因为工具的东西多练多操作肯定能学会而思维认知的东西则需要在学习他人好的方法的基础上自己琢磨领悟并形成一套自己的经验总结。
想象一下回归测试的时候成百上千的接口执行下来没有报错我们真的对系统放心吗我们又是怎样衡量自动化脚本是否合理的呢
所以今天就来聊聊接口自动化测试用例如何设计。
接口信息来源
与界面功能测试相比除了要明确需求和测试目标之外接口测试还需要有针对性地去设计测试数据和接口的组合确定接口信息通常有两条路径一是通过接口文档获取二是通过接口抓包获取。
接口文档
开发人员一般不喜欢写接口文档同时也讨厌别人不写接口文档就像程序员一般不喜欢写注释同时也讨厌不写注释的代码所以测试人员想要获取一份相对完善的接口文档有时是比较麻烦的这就需要驱动开发人员提供这对于开发人员来说并不困难。
统一的接口文档管理方式也是比较多的比如在wiki上创建一个接口文档目录空间专门用于维护接口信息、系统后台管理中有专门的接口文档模块、在需求单子下面备注、使用apifox工具进行接口文档的维护管理等。同时现在也有很多插件或工具能够帮助开发人员自动生成接口文档比如swagger、apidoc、yapi。
作为测试人员需要关注接口文档的有效性和及时性包括Request URL、Request Method、Content-Type、请求参数、响应结果、请求示例等。
抓包
如果没有接口文档那就只能自己动手丰衣足食通过抓包分析的方式来获取接口信息常见的抓包工具比如浏览器F12、Fiddler、Charles等还可以把Fiddler抓到的接口导出通过工具转成接口平台可识别的脚本进而提高效率。
在获取到接口信息后还需要与开发人员多进行交流明确接口参数的含义和来源以便于我们有针对性地进行用例的设计有不明确的点应当直接找开发同学问清楚而不应该自己过多的猜想避免自己的猜想有误造成后续用例设计的错误。在此阶段还需梳理接口的优先级和重要程度根据优先级顺序进行用例设计在有限的时间内做最大价值的事。
单接口测试
单接口测试主要验证接口的请求地址、请求类型、请求格式、请求参数、权限、返回值等为主目的是保证接口能跑通这类用例一般在接口设计完成后定稿使用过程中可配合Mock服务完成用例编写。
场景逻辑验证
场景逻辑验证是以用户场景为基础验证接口间的参数传递和业务流程是否能够正常流转比如用户注册接口 -- 用户登录接口 -- 修改用户信息接口使得业务流程形成闭环。
这个阶段的用例复杂度较高需要非常熟悉业务与接口之间的关系同时也是接口测试的核心部分、最有价值的部分。
异常测试
与界面功能测试类似除了测试各种正常场景外还需要验证各种异常情况主要验证参数异常比如某个参数的类型是String当你传入其他类型时是否会报错并给出提示某个参数的长度限制200个字符当超过200个字符时是否给出提示某个参数是必填当不传为空时是否有非空判断。还需要验证逻辑异常等情况下接口是否能够处理并给出友好的提示信息、提示是否准确清晰以及返回的信息是什么。通常情况下关注参数的异常场景会比较多可以用等价类、边界值等方法进行传参的设计。
尽量自动化
所有用例应该是非交互式的能自动化就不要手动去获取。最常见的就是token的获取获取token的方法也有很多种最常用的就是通过调用登录接口获取返回值中的token用于后续接口的鉴权还有一些开放平台接口token有特定的生成规则就可以将其写成脚本自动生成token而不是每次执行测试用例之前需要手动生成token再复制粘贴到脚本中特别是分环境测试时就会很麻烦而且token一般是有有效时间的写成自动化脚本每次都获取都是最新的就不用担心token过期的问题了。
独立性
用例之间相互独立不能有依赖需要在每一个用例里处理好前置条件而不是多个用例相互依赖。
可重复性
用例测试应该是可以重复执行的因此需要注意参数的生成方式。
合理的断言
黑盒测试的重点是输入和输出其实集成后的接口测试也属于黑盒测试也许我们不需要关注内部的代码是如何实现的更多的是关注请求参数和响应结果因此在设计用例时需要重点关注断言的设计好的断言能够帮助我们发现问题没有断言的用例或者脚本就是在耍流氓完全没有意义如果没有断言全部用例都是pass那我们也无法真正对系统放心无法确保一定没有问题。
从接口层面上看我们至少需要关注两方面的验证一是数据结构验证二是核心数值验证。
数据结构验证就是校验接口返回的数据结构是否与事先约定好的一致调用方在处理数据时肯定是按照事先约定好的数据结构来解析数据如果数据结构发生了变化那么对调用方来说无疑是灾难性的事故也就是说之前已经开发完成的程序在对接时就会出错导致需要重新开发。
核心数值的验证需要根据不同的业务场景有针对性地验证某些键值是否与预期一致同时可以结合数据库查询的方式来验证比如用户注册接口调用成功后会返回一个用户ID此时就可以使用SELECT * FROM user_table WHERE user_id ;以判断是否真的注册成功这个比较依赖于测试人员对于业务的了解程度根据实际情况灵活设计即可。
除此之外还有一些额外的验证点在需要的时候也可以进行校验比如返回的URL是否能访问、涉及到数据流转的、返回的数据是否真的有必要避免返回数据量过大导致意外情况发生。
通过添加合理的断言才能让接口自动化用例有一定的业务价值能够真正帮助到团队提升效率这样的测试结果才能让人安心。
公共参数
接口自动化测试中一个很重要的环境就是测试数据的准备要想让脚本可以在多套环境中运行那么测试数据就不能写得太死需要根据具体环境去自动获取一些数据值。
公共参数就是通过不同作用域或标识的区分有一个专门的模块来处理一些公用数据的存放比如不同环境的账号密码不同环境的URL等。
数据集合
通过特定的API或数据库SQL事先生成一些所需的数据作为前置条件然后存放到一个特定的集合中需要的时候再从数据集合里面取。
数据模板
由于测试环境一般会有多套为了方便环境的切换我们不应该把太多的数据信息写死而是通过填写一些简单的信息再调用基础接口自动生成一整套业务数据比如用户信息包含用户名、手机号、邮箱、注册时间等此时我们不应该把这些信息都写死而是通过用户id去调用用户信息查询接口获取一整套用户信息数据。
对于接口自动化测试用例的设计可能不同的人有不同的思路和想法我们要做的就是取其精华把一些好的思路和方法在具体项目中实践并形成一套自己的经验总结。
