接口自动化测试用例如何计划
说到自动化测试，或者说接口自动化测试，多数人的第一反应是该用什么工具，好比：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去调用用户信息查询接口获取一整套用户信息数据。
对于接口自动化测试用例的计划，可能不同的人有不同的思绪和想法，我们要做的就是取其精华，把一些好的思绪和方法在具体项目中实践，并形成一套自己的履历总结。
末了： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取 【包管100%免费】
https://img-blog.csdnimg.cn/ed4627a964d644e285a28f9b5dd81dae.png#pic_center
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战堆栈，这个堆栈也陪伴上万个测试工程师们走过最艰巨的旅程，希望也能帮助到你!
https://img-blog.csdnimg.cn/b960161d38074fed96baf6932ad02407.gif#pic_center
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]