接口测试用例储存在哪里（接口测试用例的检查点）

本篇文章给大家谈谈接口测试用例储存在哪里，以及接口测试用例的检查点对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享接口测试用例储存在哪里的知识，其中也会对接口测试用例的检查点进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、Jmeter实现接口测试
• 2、测试工程师面试，接口测试问题总结
• 3、yapi平台--接口自动化实施
• 4、关键字驱动能在接口测试里面用吗
• 5、【经验分享】软件测试用例管理

Jmeter实现接口测试

利用Jmeter做接口测试怎么做呢？过程真的是超级简单。

明白了原理以后，把零碎的知识点填充进去就可以了。所以在学习的过程中，不管学什么，我一直都强调的是要循序渐进，和明白原理和逻辑。这篇文章就来介绍一下如何利用Jmeter做接口测试的流程，主要针对的是功能测试。暂不涉及到自动化测试和性能测试的内容。

一把来说，主要的步骤都大差不差。

第一步：通过分析API文档和需求文档提取接口清单 。

也就是说，接口测试工作人员工作的开始就是从API文档和需求文档开始的。所以进入公司的第一件事情就是要拿到API文档和需求文档来了解，来看，来分析。从其中提取接口清单的话，主要是因为API文档中有很多冗余，不必要的信息。这些信息可能对于开发人员是有用的，但是对于我们测试人员是没有用的，所以要去除冗余，提取关键信息。

那么怎么提取呢？方法也很简单，从功能模块和方法模块对API文档中的内容进行提炼，提炼的关键是接口三要素：url+方法+参数+返回值。我的建议是可以先将所有的url提取出来，基本上一个url就是对应一个接口的，这样一条线把整体拎起来，就感觉混乱的局面清晰多了。

当然工作中，有的时候我们是可以直接拿到接口清单的，因为清单这个事情一个团队做一份就好了，并不是说要每个人都做一份。但是我们自己得会，得有这个能力。之前看到过一个面试题，问的是，如果没有API文档，怎么做接口测试？

其实问的就是如果没有API文档，应该怎么提取接口清单的问题。很简单，根据需求文档和原型图来提取。有的公司不正规，确实是没有API文档的。或者有的公司API文档写的不规范，那提取的时候，就很考验测试人员的经验和能力了。所以如果能找到遵循restful风格写的优秀API文档，那就好了，提取的时候很方便。

第二步：针对接口清单，做单接口测试和关联接口测试。

在实际测试过程中，单接口测试和关联接口测试的时间是不一样的，这涉及到业务逻辑测试和功能点测试等。但是在测试的时候，他们的逻辑和方法是类似的。

当然这里主要介绍的是单接口测试，因为单接口测试时会考虑各种可能的情况，而关联接口测试一般是建立在单接口没有问题的前提下的。换个角度来说，就相当于是两个层次，单接口测试是基础，而关联接口测试是拔高。

那么具体应该怎么做呢？比如我们这里已经选定而来某一个接口来测试。

首先，根据选定的接口来搭建测试框架 。

接口不是什么大不了的事情，无非就是url、方法、参数、返回数据这四块。这样就意味着，一个接口的框架是固定的，只不过每次传输的数据和返回的数据可能会不一样而已。所以我们要做的第一步就是搭建测试框架。

那么怎么搭建呢？这里就要用到从API文档中整理出来的接口清单和Jmeter了。从接口清单里，可以拿到当下接口的url+方法+参数+预期返回数据。这就是我们搭建测试框架的依据。接下来用Jmeter搭建。

首先需要打开Jmeter，然后基于测试计划，创建线程组，基于线程组创建HTTP请求。考虑到单接口测试，一个框架，要测试N多个数据，而且后面的接口可能也要用到同样的ip地址、同样的content-type，所以一般会先创建一个HTTP请求默认值，将一些可能会重复用到的信息填进去，比如说端口号、协议之类的。如有必要还需要添加HTTP信息头管理器，放一些user-agent、content-type等内容。

好的，有了这两个基础就可以来创建HTTP请求。在新的请求里，已经填写的端口号呀、ip地址呀之类的就无需填写了，只需要填写方法之类的即可。那么搭建框架在哪里搭建呢？一般会考虑para或者body里。比如说，要提交一段json格式的数据，那么就要用body（消息体）来提交，如下图所示。

将从接口清单里拿到的json数据填写到消息体数据里，然后将需要不断传入的数据进行参数化设置，那搭建测试框架就算是完成了。接下来只需要把数据一条一条传入进行测试即可。

那么如何把数据进行传入呢？

其实我们在下面的这篇文章里已经介绍了，传入数据的方法有四种，但主要使用的还是csv data set config 和函数。做功能接口测试，用csv就足够了。那么具体怎么用呢？

星空下：软件接口测试工具Jmeter使用核心详解12 赞同 · 0 评论文章

基于当前的线程组或者请求创建CSV数据文件配置组件。如果这份数据只有这一个请求会用，那么就基于请求创建即可。如果这份数据会被这个线程组里的多个请求使用，那么就基于线程组创建。

创建了以后就需要填入文件了呢？可是文件在哪里呢？这个时候就要稍微停一下jmeter的操作，先去针对当前接口设计测试用例并形成有关文档了。有关于功能接口测试的用例设计，我们之后会专门用一篇文章来介绍，这里先带过。这是因为设计测试用例是做测试过程中最核心的一步。

在测试用例设计完之后，可以将其保存在一个txt文档里，采用utf-8编码，保存到Jmeter脚本的同一父目录下。然后按照上面那篇文章里的设置方法进行设置即可，注意路径可以采用相对路径，便于数据文件的拷贝和使用。

csv组件设置好以后，数据源有了，变量名有了，变量名的赋值也有了，接下来就只剩引用参数就可以了。在测试框架里需要引用参数的地方引用，引用的格式是${参数名}。到这里，针对于某一个接口的测试工作就准备完成了。

然后在Jmeter里面添加查看结果树组件，执行请求，依次查看结果 。看一看返回的数据和我们的预期结果是否一致，不一致，那可能就是一个bug。

做一个小小的总结吧，用jmeter做功能接口测试，其实很简单的。逻辑和原理都是类似的，如果遇到新的项目，可能说会用一些新的组件而已，那百度一下几分钟的事情。在学习软件测试的时候，最重要的就是不要怂，不要看起来说怎么要学的东子这么杂这么多，只要能够拎出其中的线索和主干，然后把一些零碎的点给组装上去，就会感觉，哇，忽然之间，好有条理。

测试工程师面试，接口测试问题总结

1、什么是接口？

2、什么是接口测试？

3、接口组成的要素有哪些？

4、Python 的 requests 包是干什么的？

5、如何使用 Python 的 requests 包？

6、为什么开展接口测试？

7、为什么要写接口测试用例？

8、接口测试用例设计主要考虑哪些？

9、接口测试用例包含哪些内容？

10、接口测试如何设计用例？

11、通用接口用例设计？

12、接口测试报告包含哪些内容？

13、测试指标范围包含哪些？

14、做接口测试运用过哪些测试工具？

15、抓包工具用过哪些？

16、为什么进行抓包测试？

17、TCP/IP 参考模型有哪几层？

18、常用协议的端口号？

19、常见的状态码有哪些？

20、你们公司的接口测试流程是怎样的？

21、请详细阐述接口测试和 UI 测试在测试活动中是如何协同测试的？

22、接口测试注意事项？

23、接口测试执行中对比数据库吗？

24、请简述一下 cookie、session 以及 token 的区别？

25、谈谈你对 HTTP 协议的了解？

26、你对 http 请求跟 webservice 请求的了解？

27、在接口测试中关联是什么含义？如何使用 Postman 设置关联？

28、接口自动化测试框架一般分为几层？

29、测试框架里如何做到数据和代码分离？

1、什么是接口？

接口就是 API，意思是应用程序编程接口。

接口本质上是程序开发的函数和方法，提供参数和返回值。

2、什么是接口测试？

接口测试是测试系统组件间接口的一种测试，接口测试主要用于检测外部系统和内部系统之间以及各个子系统之间的交互点。测试的重点是检查数据的交换、传递和控制管理的过程，以及系统间的相互逻辑依赖关系等。

3、接口组成的要素有哪些？

接口访问的地址、请求的方法、参数、返回值

（1）接口访问的地址 协议://IP 地址或域名:端口号/应用名/功能名

（2）请求的方法 get、post 等

（3）参数 用户使用接口时，需要向接口提供的数据。

（4）返回值 接口给用户的反馈结果。

4、Python 的 requests 包是干什么的？

requests 是一个 HTTP 库，作用是发送 HTTP 请求，获得响应，往往使用在网络爬虫，接口自动化测试中。

5、如何使用 Python 的 requests 包？

（1）安装 Python

（2）安装 requests 模块

（3）创建.py 文件

（4）导入 requests 模块

（5）编写 Python 代码

（6）调用 requests 方法

6、为什么开展接口测试？

接口测试属于集成测试、测试接入越早，就越能在项目早期发现问题，修复问题成本降低。

接口测试非常快速，UI 自动化执行一个测试用例 10s 左右，接口用例执行一般毫秒级。

7、为什么要写接口测试用例？

（1）理清思路，避免漏测和重复测试。

（2）提高测试效率、跟进测试进度、告诉领导做过、跟进重复性工作。

（3）更好的记录问题、发现问题、复现问题、同时这也是接口测试流程中的一个产物。

8、接口测试用例设计主要考虑哪些？

（1）功能是否正常。

（2）功能是否按照接口文档实现、是否依赖业务、异常情况（参数异常、数据异常）、安全测试等。

9、接口测试用例包含哪些内容？

用例名称、接口地址、请求方式、前置条件、描述、请求头部、请求参数、状态码、预期返回结果

10、接口测试如何设计用例？

接口测试一般考虑入参形式的变化和接口的业务逻辑。

一般设计接口测试用例采用等价类、边界值、场景法居多。

接口测试用例设计思路：

（1）接口业务逻辑测试，接口逻辑测试是指根据业务逻辑，输入参数，输出值的描述，对正常输入情况下所得输出值是否正确的测试，也就是测试对外提供的接口服务是否正常。

（2）模块接口测试，模块接口测试是为了保证数据的安全及程序在异常情况下的逻辑正确性而进行的测试模块，接口测试主要包括以下几个方面

a.鉴权码 token 异常（为空、没有、错误、过期）

b.其他参数的异常，必填项的检查，参数的长度、类型、格式异常。常规的参数有数字，字符串，日期；参数长度，位数、身份证、电话的长度；参数的类型，数字精度，字母，中文，带空格的参数，特殊字符；日期格式，日期年月日，年月日时分秒，日期格式（包含/-:等）

c.错误码异常覆盖

11、通用接口用例设计？

（1）通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。

（2）参数组合：现在有一个操作商品的接口，有个字段 type，传 1 的时候代表修改商品，商品 id、商品名称、价格有一个是必传的，type 传 2 的时候是删除商品，商品 id 是必传的，这样就要测参数组合了，type 传 1 的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。

（3）接口安全：绕过验证，比如说购买了一个商品，它的价格是 300 元，那我在提交订单时候，我把这个商品的价格改成 3 元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功。参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。密码安全规则，密码的复杂程度校验。

（4）异常验证：所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是 10 的，传 11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。

12、接口测试报告包含哪些内容？

系统接口概况、测试目的与范围、测试工具与资源、测试记录及结果分析（单场景接口、混合场景接口）、测试结论

13、测试指标范围包含哪些？

（1）被测接口接收请求和返回报文。

（2）被测接口返回状态、被测接口对应业务逻辑处理、涉及数据沉淀的处理、复杂场景下多个接口串联交互。

14、做接口测试运用过哪些测试工具？

（1）Postman

（2）JMeter

（3）SoapUI

（4）Python + requests

（5）Java + HttpClient

（6）Java + OkHttp

15、抓包工具用过哪些？

（1）Fiddler

（2）Charles

（3）Wireshark

16、为什么进行抓包测试？

有些时候公司没有标准的接口文档，测试人员只能抓包来获取接口信息。

抓包可以迅速找到请求，通过抓包可以查看整个请求过程，以及响应过程，可以通过抓包来分辨前台还是后台 bug。

通过抓包，可以查看是否有敏感信息泄露，比如用户密码和个人账号信息等数据。

通过抓包进行测试，拦截请求，修改请求数据，查看对应响应结果，抓包本身就是接口测试的一部分。

17、TCP/IP 参考模型有哪几层？

应用层、传输层、网络层、网络接口层

18、常用协议的端口号？

（1）21/tcp FTP 文件传输协议

（2）22/tcp SSH 安全登录、文件传送（SCP）和端口重定向

（3）23/tcp Telnet 不安全的文本传送

（4）25/tcp SMTP Simple Mail Transfer Protocol（E-mail）

（5）69/udp TFTP Trivial File Transfer Protocol（微型文件传输协议）

（6）80/tcp HTTP 超文本传送协议（WWW）

（7）110/tcp POP3 Post Office Protocol（E-mail）

（8）443/tcp HTTPS used for securely transferring web pages

（9）3389/tcp 远程访问 5631/tcp

（10）5632/udp pcanywhere 端口号

（11）1433 SqlServer 服务端口号

（12）1521 Oracle 服务端口号

（13）3306 Mysql 服务端口号

（14）8080 Tomcat 默认服务端口号

19、常见的状态码有哪些？

（1）1XX 信息提示，用于指定客户端相应的某些动作。

（2）2XX 成功，用于表示请求成功。

（3）3XX 重定向，用于移动的文件并且常被包含在定位头信息中制定的新的地址信息。

（4）4XX 客户端错误，用于指出客户端的错误。

（5）5XX 服务器错误，用于指出服务器的错误。

20、你们公司的接口测试流程是怎样的？

（1）从开发中取得接口文档，了解接口业务，主要包括接口地址、请求方式、入参、出参、返回格式等信息。

（2）使用 Jmeter 进行接口测试，创建一个线程组，然后建立一个 http 请求默认值，再新建很多 http 请求，一个请求是一个用例，输入相应接口路径、访问方式、参数等，创建断言和察看结果树。

（3）最后调用并执行测试用例，编写测试报告。

（4）在做接口测试的时候遇到过很多问题，都是自己独立解决的，比如返回值乱码（修改 Jmeter 的配置文件为 UTF-8）。

21、请详细阐述接口测试和 UI 测试在测试活动中是如何协同测试的？

接口测试和 UI 测试这两块其实是有一部分是重叠的，UI 测试是通过前端写的界面来调用接口，而接口测试是直接调接口。所以排除前端的处理的逻辑和调用的正确性，在理论上接口测试是可以覆盖所有的 UI 测试。但实际过程中，如果只是在接口层覆盖所有的业务流，在 UI 上只测试前端的逻辑，最终的结果可能会是忽视很多原有的功能点，导致了 UI 测试的不充分。所以存在多人分工且时间充分的时候可以尝试接口去做业务流的全覆盖，否则不要轻易尝试。

22、接口测试注意事项？

（1）改变请求参数，看响应结果是否和接口文档一致。

（2）查看参数是否有敏感信息（比如个人账户信息，资金信息）。

（3）查看是否对关键参数进行加密处理（密码信息）。

（4）所有列表页接口必须考虑排序值。

（5）接口返回的图片地址能否打开，图片尺寸是否符合需求。

（6）接口有翻页时，页码与页数的异常值测试。

（7）当输出参数有联动性时，需要校验返回两参数的实际结果是否都符合需求每个接口入参的默认值、异常类型、非空校验。

（8）入参支持多个值时，要考虑传的值的个数多的情况下，接口会不会报错。

23、接口测试执行中对比数据库吗？

肯定要对比，因为接口返回值的数据来源于数据库，接口对数据的操作还要进行深层次的数据库检查。

24、请简述一下 cookie、session 以及 token 的区别？

cookie 数据存放在客户的浏览器上、session 数据放在服务器上、token 是接口测试时鉴权码，一般情况下登陆后才可以获取到 token，然后在每次请求接口时需要带上 token 参数。

cookie 不安全，别人可以分析存在本地的 cookie 并进行 cookie 欺骗，考虑到安全应当使用 session 可以将登录信息等重要信息存放为 session，其他信息可以保存在 cookie。

25、谈谈你对 HTTP 协议的了解？

超文本传输协议，端口为 80，是由请求和响应两部分组成的。

请求是由请求头，请求行，请求正文组成；响应是由响应头、响应行、响应正文组成。

面向安全的话使用 https。

26、你对 http 请求跟 webservice 请求的了解？

（1）http api 接口：是走 http 协议，通过路径来区分调用的方法，请求报文都是 key-value 形式的，返回报文一般都是 json 串，有 get 和 post 等方法，这也是最常用的两种请求方式。可以使用的工具有 postman、RESTClient、jmeter、loadrunner 等。

（2）webservice 接口：是走 soap 协议通过 http 传输，请求报文和返回报文都是 xml 格式的，都是通过工具才能进行调用与测试。可以使用的工具有 SoapUI、jmeter、loadrunner 等。

27、在接口测试中关联是什么含义？如何使用 Postman 设置关联？

关联就是把上一个接口返回值的部分截取出来，作为下一个接口的参数，能让接口串联运行。

在 Postman 中设置关联的步骤如下：

（1）通过正则表达式提取的方式或 json 取值的方式把下一个接口需要的信息从上一个接口截取出来。

（2）使用设置全局变量的代码把取出来的值保存到全局变量里。

（3）在下一个接口中，使用(全局变量)代替要替换的静态值。

28、接口自动化测试框架一般分为几层？

自动化测试框架一般分为 5 层（配置层，脚本层，数据层，测试报告层，驱动层）

接口项目工程规划大致可分为几类，首先是测试结果类，比如说叫 test_rusult，里面存放一些比如日志文件，测试报告。然后是测试用例 testcase，里面分模块存放测试用例。接下来是公共方法类，比如说叫 public，或者是 tools，里面存放一些，读取 excel 数据的方法，发送 http 请求的方法，收集 log 日志的方法，发送邮件，操作数据库等方法。还有就是配置文件类，比如说叫 config，里面存放一些指定运行部分用例的配置文件，连接数据库的配置文件。最后是写一个 run 方法，运行所有的用例。

29、测试框架里如何做到数据和代码分离？

第一种：写在 excel 表格里，像这种主要是读取 excel 数据有点麻烦，常用的用来读取 excel 的第三方库有 openpyxl，xlrd 等。当然读取 excel 数据最好用的还是用来做数据分析的 pandas 模块，不用写那么多 for 循环。

第二种：数据存放到 yaml 文件里，一个模块或者是一个功能写一个 yaml 文件，最后写个读取 yaml 文件的公共方法就行了。yaml 格式的文件比较简单。

第三种：存放在数据库里面。

第四种：数据存放在 json 文件里。

yapi平台--接口自动化实施

1--分组
2--项目
3--接口
4--测试集合

鼠标选中测试合集，右侧四个按钮分别为克隆合集，导入接口，编辑合集，删除合集

勾选测试的接口并点击【确定】，所选择的接口即显示在测试集合中，然后可编辑接口测试用例

如上图，编辑用例可以进行用例名称，用例执行环境，接口参数及请求数据的填充，编辑完成后点击保存，则用例保存成功

点击“发送”，可以以当前填写的请求数据对此接口进行请求。

对用例执行结果进行断言，首先需要开启。
yapi提供快捷的断言方式，点击即可生成对应的断言。

以上断言方式可以自行根据需要进行编辑和优化，基本可以满足我们日常测试所用。

如果接口数据固定写死，只需要正常填写保存即可

{{global.变量名}}

如果连续的测试场景，后面的接口需要用到前面接口请求的数据或者返回的数据，这种场景需要进行接口间的参数传递
Yapi接口传递格式：

点击测试集合，展示的测试用例列表中，会展示key

通过接口请求或者抓包获取到请求数据和返回数据

对数据进行分析，找出自己所要的字段，通过层级关系获取到表达式
例：假设key为100返回的body

假设我们想要获取到 "plate_number"的值，那么写法就为：$.100.body.data.orders[0].plate_number
层级关系用.表示，列表取对应数据用[n]下标指定。

yaip也提供了可视化的界面操作，实现接口参数传递
1、PATH PARAMETERS或者QUERY PARAMETERS
点击参数后面的编辑按钮，弹出高级参数设置弹框：
选中具体字段后生成表达式，点击插入即可填入

2、请求BODY
与PARAMETERS一样的操作，但是表达式必须要用双引号包裹起来

tips:
如果想要通过可视化的高级参数设置来进行参数传递，气体条件需要在接口中将完整的返回body导入，这样才能在高级参数中找到对应的字段
路径：接口--编辑--返回数据设置--导入json--?保存

如果接口中我们需要动态生成一些随机参数数，可以使用mock占位符
操作与接口参数传递一致，唤起高级参数设置弹框后选择mock数据

常用占位符：

占位符更多相关内容可参考： 《yapi中使用json-schema mock数据》 .

用例执行有两种方式，一种是直接执行，另外一种是服务端执行，调试时可以用直接执行，如果需要集成或者需要生成测试报告，选择服务端执行

用例编写完成后，点击测试集，右侧中点击【开始测试】即可运行所有测试用例：
路径如图所示

运行完成后通过的用例会有绿色标识，未通过的用例会有黄色或红色标识。
点击单个用例右侧的测试报告，会展示完整的执行请求，response以及断言结果

服务端执行，项目路径直接执行一致，只不过选择服务端测试即可

配置根据自己需要填写：

如果一个用例集合中每个用例的断言和接口请求状态码可以设置为一样时，我们可以在通用规则配置中整体设置

关键字驱动能在接口测试里面用吗

关键字驱动可以在接口测试里面用。使用的是关键字驱动。同样，Python做接口自动化测试的时候，也可以使用关键字驱动。但是这里并不是叫关键字驱动，而是叫数据驱动。而接口测试的关键字是什么呢？ 我们数据驱动的载体是Excel，那么excel里存放的数据是接口测试用例数据，一个接口数据里有常量和变量。变量就是一些参数对应的值，而常量就是接口的：host、path、method和data等等。而这些常量是固定不变的，我们可以将接口测试用例这些常量封装到一个类中，每次执行测试的时候，调用类中某个方法来读取excel中接口关键字对应的值。这些就称之为——关键字数据。
接口关键字封装
众所周知，Excel中第一行字段的值都为固定的值，即常量。可以用这些常量来定位每一个测试用例不同字段的坐标值，将获取到的值传递给接口。

【经验分享】软件测试用例管理

本文涉及到测试用例接口测试用例储存在哪里的编写规范，以及用例管理的分享，因此，无论是对于初级测试工程师，还是质量团队的管理者，都有一定的参考意义。文中涉及到的方法和工具并不是唯一解决方案，希望大家收获到的不仅仅是文字表面，而是文中分享的一些思路。

有人说接口测试用例储存在哪里：测试用例还不知道？不就是描述测试步骤吗？

这么回答确实没什么错，只是如果内心上也仅仅这么认为的话，只能说并未理解测试用例。

测试用例除了作为测试行为的描述，更多的是作为被测目标是否达到需求的验证，主要还是考验了一个测试工程师的组织归纳能力，其输入来源往往是承诺书、用例(Use Case) 以及自身对业务领域知识的经验，一个软件测试工程师的专业度往往体现在接口测试用例储存在哪里他设计的测试用例上。

专业的工程师设计出的测试用例集，不仅能够描述自己的行为，还能指导别人实施，不仅强调深度，还具有优秀的用户思维。

虽然从格式上来说，基本就定型了：

关于这部分，网络上的教程只多不少，就不赘述了。

只不过要强调的重点是， 格式只能保证测试用例明晰，并不能提升测试用例的设计能力 。因此，测试用例该怎么写？还是要从结构化设计开始。这里需要提到一个概念 HLTD [ High Level Test Design ]，可以简单粗暴的理解为测试大纲的设计。

就如同我们写文章一般，提笔正文之前，会先拟个草稿，列出中心思想及段落提纲，然后再攥写润色。

写测试用例也是类似的套路，先列出测试点作为大纲，并且具有结构化布局。通常以大的功能或模块进行分类，再细化二级甚至三级类别，最终列出具体的测试点。该阶段的设计，笔者倾向于利用思维导图（脑图），相较于传统的文档软件工具，思维导图的展现更直观。

由于最终会是一张大图，所以硬伤也随之体现，只适合用于思路梳理，不适合用于文档化管理。

把这些结构化好的测试点文档化，就是我们所说的测试用例了。

所以从这里我们可以看出，每一条测试用例的目的很明确，是验证一个或一类测试点，颗粒度需要根据公司实际情况权衡，太粗不利于对于测试点覆盖的总结，拆太细会消耗更多的精力。

测试用例其实是一个非常详尽的文档，必然会消耗测试工程师相当一部分的精力。在传统软件开发时代，甚至作为 KPI 的一项指标。

但随着敏捷时代的兴起，有一种声音开始冲击这种认知。

早期的敏捷实践者，对敏捷宣言的解读仅仅停留在了文字表面，认为“只需要软件，不需要文档”。这直接导致了这一时期，大量的团队缺失了详尽的文档，甚至连一些基本的文档都没有。

如今，越来越多的敏捷实践者认识到，敏捷宣言所宣扬的并不是“不用详尽的文档”，恰恰相反， 敏捷宣言认同了“详尽的文档很重要”这件事，并且提出了更高的要求 —— “工作的软件更重要”

对于测试用例文档化工具的选择，很多团队仍然停留在传统的办公软件，如 Word、Excel

但如今凡事比快的市场环境下，团队成员高效协作、团队信息实时共享的需求越来越高，测试用例平台化管理必然还是最终归属，除了文档化，还利用平台制定计划，展示进度和结果。

事实上，在传统时代，大一些的软件公司就已经使用平台来管理测试用例了，这再一次证明了敏捷时代并不意味着推翻过去的经验和成果，而是提出了更高的要求。

如今，相对知名的管理平台有基于 Jira 做插件的，如：Zephyr、Xray、synapseRT、TM4J，也有独立的开源平台: 如：TestLink，或收费的独立平台: 如：TestRail

我们主要从其生态、推行成本、可扩展、费用角度去综合考虑。

Zephyr 的名气一直都很大，但实际上并不太符合国人使用的习惯，使用起来诸多不便。用例直接使用 Jira issue，功能比较简单，用例管理主要在计划和循环的关联上。由于其是 Jira 插件，因此能很好的跟 Jira 上其他 issue (需求、任务、缺陷) 进行关联。但其用例管理的可视化不是很好，没有用例集的概念。迁移方面，数据导入支持类型有限。扩展方面，若要使用其 API，还需要另外装一个插件。其费用中等。

Xray 算中规中矩，也是使用 Jira 的 issue 来创建测试用例。但其新增的 issue 类型多达 5 类，显得极其复杂。关联能力与 Zephyr 相同，数据导入支持类型有限，本身有 API 可供使用。其费用中等。

synapseRT 是国人开发，汉化效果最好，功能强大。有用例集的概念，用例也是用的 Jira issue 来扩展。数据导入支持了 TestLink、Zephyr 这样的其他平台。关联能力同 Zephyr，数据导入支持类型依旧有限，其本身也有 API 可使用。而费用相对较低。

TM4J 使用独立页面管理测试用例，脱离复杂的 Jira issue 页面，上手难度低。数据导入功能强大，覆盖很多类型及一些知名平台。关联能力与上述插件一致，本身也有 API 可使用。但费用相对较高。

TestLink 作为独立的测试管理平台，功能全面，开源免费。可以关联 Jira 这样的知名平台，但由于不是 Atlassian 体系，所以生态体验不高。硬伤是界面丑陋，容易影响工程师的心情。笔者曾经使用其本身的 API 进行 UI 美化。

TestRail 是一个强大的商业平台，笔者接触不多，不乱作评论。

综合考虑，虽然 TestLink 作为免费开源用例管理平台中的 TOP，在用例管理上做得非常科学，一直值得学习，但笔者所在公司已经在使用 Jira，并在落地 DevOps，外加笔者常受 Atlassian 中国社区研究院副院长的支持，TM4J 成为最终选择：

出品方还是挺强的，除了 TM4J，Zephyr 其实也是其下产品，Swagger 也已经是目前认知度很高的产品了。

从官网介绍上可以看出，TM4J 还是比较现代化的：

首先我们看看利用 TM4J 如何来编写测试用例。

层级结构上，我们根据 HLTD 来创建目录以及子目录，以方便所有人理解和阅读，最后的测试点则实例化为一个测试用例，它拥有全局唯一的 Key。

点击 New 按钮创建新测试用例，默认在 Details 标签页，在这里定义用例名称、目的、前提条件，详情中可以设置状态、优先级、所属组件，并可以添加一些便于管理的标签。

切换到 Test Scripts 标签页，默认是 Step-by-Step 类型，按照 STEP - TEST DATA - EXPECTED RESULT 添加每一个测试步骤。

另外值得一提的是，在 Traceability 标签页，可以关联 Jira issue、Confluence page

通常我们针对每次产品发布交付，需要制定范围，因此计划管理是必不可少的。

计划管理推荐按照发布版本来制定顶层目录，然后针对测试类型创建二级目录，如回归、新功能、端到端、接口、性能等等。

测试计划的创建本身操作倒并不复杂，除了定义计划名称、目的、状态、责任人，外加一些标签。

还需要关联一下需求或者 Confluence 页面。测试周期在刚创建测试计划的时候可能并不存在，可以在之后创建测试周期的时候，会双向关联。

测试周期是一个承上启下的关键，往上关联测试计划，往下关联具体的测试用例。

通常一次发布交付会经历 3-5 次冲刺，每轮冲刺的范围不一定完全相同。

在新建完测试周期名称、描述以及详情之后。

进入 Test Cases 标签页，点击 + Add test cases 添加已经编写好的测试用例。

这一步操作使得测试用例具备了项目属性。

最后在测试周期的 Traceability 标签页点击 Test Plans 后面的放大镜。

通过查找来关联已经做好的测试计划。

创建完测试周期，就可以进入该周期浏览到分配到自己名下的测试用例了，这是所有测试执行者都需要用到的界面，还可以通过 Group by 根据不同规则进行归类，比如根据测试周期中制定的不同目录。

对于用例步骤的执行，TM4J 提供了一些快捷按钮，可以直接标记通过、失败、阻塞，并且可以点击齿轮按钮，快速创建、查找 Jira issue 进行关联，当然，除了对于步骤关联 issue，也可以针对该用例标记 issue，点击 Issues 后面的 + ▼ 可进行操作。统一平台的好处便是在此了。

虽然我们在查看测试周期列表的时候可以看到测试的进度，但更多数据展示可以通过测试报告来体现。

TM4J 的 Reports 功能给我们提供了丰富的模板，方便一些经验不足的测试质量管理者。

最后，笔者想说， 测试工作不能作为一个独立的业务，应该更多的与其他角色协作 ，特别是在现在的敏捷时代，测试用例的执行可以要求开发工程师关注，测试的状况可以要求产品经理随时介入，因此，强烈建议我们软件测试工作者尽量选择一些跨职能协作平台。

关于接口测试用例储存在哪里和接口测试用例的检查点的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 接口测试用例储存在哪里的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口测试用例的检查点、接口测试用例储存在哪里的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。