我那个 GUI 使用了 jquery. 后端使用 java 做了公用方法进行解析，基于数据驱动，对于接口基本信息采集有一定工作量，用例也是基于 Gui 去配置完成。

—— 来自 TesterHome 官方 安卓客户端

总结的不错

恒洁细心到爆了 手工点赞😁

—— 来自 TesterHome 官方 安卓客户端

总结很好,没有做过接口测试,有时间找你学习了解一下

登录只为手动点赞！！

#3 楼 @xushizhao 谢谢～你提到的内容我已更新到帖子里面了，你看下有没有不对的地方？
#5 楼 @nickli 谢谢～

恒洁总结的太到位了，手动点赞

#7 楼 @75281920 谢谢～看来分析回帖内容自动点赞的功能要加入 手动点赞 这个文字了，哈哈

不得不说，对我帮助很大，谢谢

#6 楼 @chenhengjie123 哎不过还是有很多坑， 回公司好好和你聊聊

—— 来自 TesterHome 官方 安卓客户端

其实我发现 retrofit 真心比较好用：

可以参考:http://square.github.io/retrofit/

retrofit+Cucumber 的方式应该是比较方便的，但是我没有去深入研究，对 java 这块也不熟悉，我只会点 python

还有个人还是喜欢用 js 和 python 来弄个接口测试框架，一直弄不出"好用的"，功力太浅了

#11 楼 @284772894 这个不错，谢谢分享。把它的文档过了一遍，主要是把 http 操作简化到了可以直接用 annotation ，优势应该是快速构建不同的 http 操作，但对于参数组合和后续的断言还需要再封装，这个工作量还是不少的。

接口成为了手段，验证点其实是功能。

在做接口测试也遇到很多问题，一个功能点要想怎么设计好测试 case，通常一个接口可能很多的错误返回码，每次都要把这些个返回码都走一遍，工作量真是很大，也在找快速的方法。谢分享总结。

说一下我做过的比较 Low 的手动接口测试 (项目里面叫的是 web service 测试)，开发给一个 service 地址，页面上展示的是一系列 service 列表链接，点击每个链接都有相应的界面 (如果有传参，那就有相对应参数名和对应的文本框 (textbox),反之，没有，当然还会列出以 xml 格式的 service request, service response 的相关参数）. 而我做的是测试需要传参的。把各种可能业务场景，各种参数的最大值，最小值，最大长度，空值等等情况输入以此确认响应是否达到预期。最后的测试参数以及测试结果是以表格形式放在邮件，邮件，邮件里面发送给大家。主要是由于手动测试，费时，费力还不讨好。诶。。。看了文章后，发现需要改进的地方有太多了。谢谢 LZ 的分享。

#13 楼 @face_south 你有把用例做成自动化的吗？返回码都走一遍这个从我的角度看来还是需要的，不过也要看你具体情况。有些业务上基本不会出现的也许可以跳过。

#14 楼 @rocker 建议把这个做成自动化的吧。接口的东西做成自动化比 UI 方便很多。

@chenhengjie123 这个我就在这么多，尽量都走一遍，因为这边现在没有要求我具体什么时候做完，时间上还好，但是可悲的是，公司不给测试看开发代码的权限，所以每次都是测试功能的时候抓包再去准备测试 case。

#17 楼 @face_south 这个应该找开发取文档。正常来说前后端协作的时候应该有个接口文档，如果没有再去抓包。抓包有个不好的地方是有些不常用的参数可能不会出现。

@chenhengjie123 恩 最好是这样 不过这小公司 是没有文档的

感觉非常好，刚开始接触接口测试，大致有个方向了，谢谢

在项目中用了 rest-assured，感觉也是挺好用的

大赞，最近也在研究接口测试，拜读一下。
我是参考这个的http://www.ispenn.com/2015/08/interface-test-automation-scheme-details

#22 楼 @taurus 这个不错，赞一个。不过感觉遇到有业务关联的接口时不大好做。
testly 那个和这个比较类似，不过他有一些针对数据传递的特殊处理。

核心其实就是测试用例如何设计的问题。

楼主真是太赞了~~
我这边的业务并没有进行接口测试，也想学习学习。

1、首先目的性 接口测试 其实测试的是服务端 这块为什么要 app 测试来做呢
如你举的发朋友圈的例子，比如文字、图片，这些其实在 app 的功能测试方就有全覆盖。
而 app 开发应该把无图片无文字这条用例的错误直接就返回给用户，否则也是代码逻辑上的问题。
其他几种情况应该是服务端开发自己代码进行处理。

在实际项目中，可能根本没有给接口测试的时间，开发联调接口一下午就搞定了。
也不会产生 服务端开发——》接口测试——》APP 开发这样的流程。
如果联调完成之后才有足够的时间给你，这样的意义在什么地方呢？

2、同上的说法，如果是已经很稳定的业务了 接口测试的必要在哪？
3、如果是 HTTPS 的请求怎么办 差距大不大

可能我的说法略显狭隘，希望大家鞭策一下~

#25 楼 @blink hmmmmm，我还是很想回复下的

1. 接口测试是服务端的，但是为什么 app 的测试就不能做呢？也是质量的一部分。 另外我问一个逻辑，比如你服务器有 100 个 api，然后服务器那边的测试完全覆盖了 100 个 api，那么是不是说就 app 调用的 api 都全部正确了呢？这是不对等的，所以本身就不分的那么细

如果连调完成之后才有足够的时间给你，这样的意义在哪里？如果我们思考问题这样的话，那么我想问，每次都是最后开发才开发完毕所有的功能，那么测试的意义在哪里呢？人总归会死，那么活着的意义在哪儿呢？所以说，我们不能这样去思考问题。不是有没有时间来决定有没有意义的

1. 同样的回答，业务很稳定了。不代表 api 测试没有必要。毕竟还有回归测试这个说法，毕竟还有 regression 这个说法。另外，也不见得有千年稳定的业务

2. 这个我就不回答了。。。

鞭策完毕了。。。

产品大小不同，质量要求不同，测试的意义自然也不同。
小团队，APP 的接口考虑一下用单元测试替代？
PS：然而现实是单元测试我也推动不了，所以我索性去跟开发改 BUG 去了。。。写代码说实话还是比测代码有成就感点，就是稍微累点。

#25 楼 @blink 我说下我的理解吧。

1. 很多时候服务端压根就没人做测试（我们这服务端的东西一个人搞定，因为不需要做界面，纯做接口就好，单测这些在开发的时间都不够的情况下谁去）
2. 实际流程不会像你所说那样分三步走，而是同步走。服务端会先给个 Mock 服务器让 app 可以调节，接口测试会跟着服务器开发进度走，app 则是一直跟着 mock 的结果和设计的逻辑走，直到服务端说接口搞定了再开始联调。

这个过程中为什么要有接口测试呢？主要是为了保证开发过程中能比较高频率得跑测试，最好做到服务端一提交代码接口测试就自动跑。同时接口测试也能在后续每次服务端更新代码的时候跑一遍，保证没有出什么重大问题。自动化本身的优势之一不就是能大幅度提高测试效率嘛。

至于你说业务稳定为啥要测接口，这个我的观点和 monkey 一样，为了回归。而且接口有个好处，定位问题简单，一出问题基本都是服务端的问题，而且肯定是和这个接口相关的代码，不用花时间再去抓包->分析（->撕逼）

https 的话建议你了解下 https 和 http 区别是什么吧，相信你了解后也就知道答案了。

谢谢楼主科普。
没有做过接口测试，想请教几个问题，如果楼主有空，且能耐心回复，不甚感激：

1、楼主在帖子那里说到：“每一个用例测试一个点，发布成功这个返回值是否正确由一个单独的用例来覆盖就足够了。” 如果只验证返回值，是否代表着这个接口的功能完全 OK，或者接口测试不去管这个接口的具体功能实现？那，如果不管这个功能是否 OK（这个返回值研发也可以直接 return 一个正确值即可），那么这个功能就要在其他阶段再进行详细的测试？

2、 貌似测试一直都在说：不要相信研发人员。我也一直在矛盾，之前还是挺信任研发人员的，但是研发人员手抖弄错了点东西，出过一点问题后，对研发人员就越来越不信任了。对于楼主说的：“有些东西开发可以很方便地给到我们，那么我们没有必要那么艰难地自己去计算出来，而是直接让开发增加一个接口让我们能直接获取到数据就好。让接口测试做得更好，开发的协助是分不开的。“如果这些便于测试的接口，由研发人员提供，我们是否需要检查接口的具体实现（貌似也要消耗一点时间），还是说就直接拿过来用就行了？

最后，谢谢楼主无私的奉献，帖子内容对我帮助挺大的！！！

#29 楼 @4amla 首先澄清一点，我这个不是科普贴，是个人感悟贴。不敢说我的观点一定正确，只能说是我个人的个人感悟。

那我表达一下对你这几个问题的观点吧：

如果只验证返回值，是否代表着这个接口的功能完全 OK，或者接口测试不去管这个接口的具体功能实现？

首先，我这里关于接口测试的观点都基于一个前提：你有比较完备的功能测试。而且我是因为条件所限按照一个用例一个接口的规则只能检查到返回值，如果你有条件应该还要同时检查数据库内容，这样完整性好一些。

那，如果不管这个功能是否 OK（这个返回值研发也可以直接 return 一个正确值即可），那么这个功能就要在其他阶段再进行详细的测试？

我的其中一个用例就发现了这样的一个问题，A 用户无权删除 B 用户的帖子，但接口却返回操作成功（当然实际上还是没有成功删除的）。对于这样的情况，如果可以获取到数据库那就可以调用单个接口完成，因为数据是否成功修改可以直接通过数据库知道。如果不能，而是需要调用其他 API 才能知道，那更建议把这个部分放到功能测试里做，毕竟功能测试里这个基本是必测的。当然你也可以根据功能的优先级考虑专门为这个功能做个接口层面的校验，但这个更多的是补充，而非接口测试本身的目的。

如果这些便于测试的接口，由研发人员提供，我们是否需要检查接口的具体实现（貌似也要消耗一点时间），还是说就直接拿过来用就行了？

肯定不是直接拿来用。。。而且检查接口的具体实现也不现实，如果某一次研发错改了这个接口呢？我觉得有两种方式吧，一种是为这个接口也做一个用例，用于保证这个接口的返回值正确，另一种是直接通过数据库来计算得出这个数据。我这里说的艰难特指模拟用户操作来逐个翻页，导致翻页次数不确定，因此应该有更合适的办法保证一次性能翻到最后一页。

很开心我的分享能帮助到你，也欢迎你以后在接触接口测试，或者其他新的事物的时候把感悟分享出来。如果只是单纯感悟我发到自己博客给自己以后看就好，产生思维碰撞才是我把这个帖子发在 Testerhome 的目的。因为我有感觉，我目前的观点仍然不完全正确。

yeah，update 部分非常赞同的。
当时我做接口的时候设计也是分三层。

底层 util
这一块放啥就不废话了

中层 business
每个接口的单个封装，对传入的参数不同，有不同的逻辑进入各自的 assert 点

比如 接口http://api.xxx.xxx.com/id={1}/type={2}
business 层包装的方法会根据业务，针对传入不同的 type 值，进行业务上的 assert 校验；
比如 type=1 的时候就应该是返回可用，type=2 的时候就是返回过期；

上层 testcase
用例部分其实只是调用了 business 的单个接口的方法，不同的用例传入的参数和期望值会不一样。
需要多个接口间数据传递交互的时候，无非是一个用例内，调用了多个接口方法。

#30 楼 @chenhengjie123

感谢解答，对于我这种不懂接口测试的人来说的确是科普贴，哈哈。

#1 楼 @xushizhao 可否有资料分享？

#30 楼 @chenhengjie123 写的很棒！ 最开始做接口时，也的确只是测试接口字段的不同组合，然后也逐渐的增加了关联接口之间的相互验证。但是现在回想起来感觉这样的接口测试还是缺少点什么，可能是你说的修改 python 代码支持 excel 作为用例吧。赏

很好

为啥你放弃了第 8 点 Jmeter 呢？为什么你会说他们都不是好路呢？能否解答下？

#36 楼 @momoyue 我放弃的原因是我觉得不好维护。不过这是个人观点啦。

我当时用 Jmeter 一共写了 100 个用例左右吧，然后觉得太多地方使用 copy paste ，并且有些特殊需求（如通过 md5 校验上传的图片是否正确）用 Jmeter 来做不如直接写代码方便，所以后面就放弃了。

至于纯 Java 代码，其实也不是不行，只是需要比较好的分层，例如 @anikikun 前面说的把 business 层封装起来，否则用例写起来代码量比较大，编写速度会慢不少。

总结得很好，感觉测试理念很重要 ，否则方向就容易错了

你为啥没尝试使用 soapUI 做接口测试呢，我觉得他还挺好呢，最后形成脚本也可以达到持续集成的状态，也是很方便

#39 楼 @zyl911_1012 因为收费。。。灵活一点的 assert 都需要用收费版，而且大部分它能做的 Jmeter 也能做吧。

我个人认为【代码 +execl】表是很好的，代码直接从 execl 表中提取用例，用例修改起来也方便多，省了很多码代码时间

#37 楼 @chenhengjie123 你说的 copy paste 是指用例复制粘贴，有什么影响吗？ 然后你说的 md5 校验图片上传，你可以用自带的 MD5 函数，不行吗？

#42 楼 @momoyue 你指的是 Jmeter 里面的 copy paste 是吧？我指的主要是断言的复制粘贴。用例会复制粘贴是正常的吧，同一个接口的用例复用度应该会很高。

Jmeter 有自带参数是文件路径/url，输出 md5 的函数？

soapUI 这个专业工具反而没有被提到,python+excel 也是个不错的选择；

#44 楼 @oneway 主要是因为我只是浅尝了一下就没用了，所以没写在里面。表格本身主要是总结一下近期论坛关于接口测试的帖子的，并非工具合集。

总结的不错，接口参数与业务结合

#40 楼 @chenhengjie123 Soap UI free 版本也是可以的，用 groovy 做 data driven 和 dynamic response check，或者你可以先用 Java 做好扩展，在 soap ui 上用 groovy 简单调用就行

#43 楼 @chenhengjie123 就是函数助手里面有 MD5 啊

赞，很多东西目的性不一样，过程确实应该不一样

#48 楼 @momoyue 看了下，那个 md5 函数只是加密字符串，不是提取文件的 md5 值。不一样的。

有用过 fitness 的吗？

针对【通过 git 统计了一下我每天的代码量，大概在 1000 左右，但用例数还是每天 15 个左右。】
试试：数据驱动（步骤基本一致只变参数的，将参数数据化）+ 关键字驱动 (发现有代码内聚性 + 复用性极强的尝试封装为关键字函数)，

#52 楼 @rambo 木有。求科普。

#53 楼 @coffeecatyao 其实有做过，把每个接口的常用操作封装起来，步骤一致的参数提取出来做 for 循环。但步骤一致的实在太少，而接口封装后其实重用性没有那么大，因为我会用到这个接口的用例数量不多。

很赞 ，找个时间再细读，昨天刚开始做接口测试，最初想的跟你开始差不多，jmeter 或者纯 java、python，最后选择了 jmeter。希望以后能多交流

#25 楼 @blink 说的很有道理，客户端功能测试可以覆盖接口测试很多场景，接口再做这种非常全面的遍历感觉费力不讨好。

@chenhengjie123 还有个问题想请教下，咋个管理测试数据的呢？尤其对于接口逻辑较复杂，数据依赖较强，涉及到的表较多，这种情况如何管理测试数据呢？

#58 楼 @momoyue 这种可以让每个用例用到的数据在 setUp 的时候清空数据库然后写入需要的数据吧？
我们要测试的是代码的逻辑是否正确，数据这类外部条件可以根据需要自己去创造。

@chenhengjie123 如何管理和业务相关的测试参数，如搜索功能，测试搜索存在的数据，结果是否正确。如何知道已存在的搜索关键字？去数据库搜索吗？

#56 楼 @dancingcat_ 也可以交流，我现在也考虑对公司的项目做接口测试，我也是考虑用 jmeter+java,因为我一直没有人带，目前涉猎除了安全，全部都有做，都是自己做，可能出各种问题，希望多多交流，QQ1033154755，回答问题，请说 testerhome

给楼主的总结点个赞

我现在做的和你的类似，就是对响应结果处理以及报告这块，还有不少坑 -。-

你这个有做界面化设计么？在界面上操作，比如增测试接口，测试用例，巡检，报告查看

#64 楼 @success 没。因为出发点不是做平台，只是做一个小项目的接口测试。

总结的很好！我现在的情况跟楼主差不多：代码框架和 jmeter（是压测写的接口业务脚本）之间游行 奈何我码代码的效率更低（不过这好解决）

关于楼主说到的发朋友圈的业务 设计的是两个接口

我现在的想法是：

• 关于用例设计：

1. 单个接口（上传图片接口，本地发朋友圈接口）的用例排列组合列出来

2. 考虑关联接口的业务 -->【上传图片 + 本地发朋友圈】（还是排列组合，就是楼主的用例）

但这样用例设计又有点繁琐了?

• 关于数据校验：

1. 查询接口 + 检查数据库记录，我觉得应该是可以同时存在的

因为我们的接口数据这块有中间件 redis，数据删除时数据库的数据是没有变化的，只能通过查询接口来 check。所以也有了我 1 的方法校验。

理一理，我想得去改我小项目的用例去了

这大半年接触接口测试，我的感知是业务分析真是很重要，单个接口不能漏，关联接口业务也要想详细，说简单了就是输入输出两头抓好，说难就多的去了。这些也都是个人的感受而已。学习 ing

mark 一下，下周开始接触接口测试，到时来看看

感觉楼主总结的很好～ 点个赞～～ 同时有个问题想要咨询下，如果用 excel 记录测试用例的时候，预期结果会写在里面吗？
假如返回结果是 json，不同测试用例得到的 json 的结构不同，然而其中有一些部分内容是动态变化如时间戳是不需要对比正确性的，应该要如何处理呢？

#69 楼 @jennyli90 一般会写在里面。不过具体也看情况啦。

一般动态变化的部分不需要对比正确性的话，可以考虑用 jsonPath 部分校验，或者用 jsonScheme 来做校验规则，甚至自己自建一种简单的语法说明这部分不需要校验。

请问下 LZ 多接口的业务测试有什么思路做呢？

#71 楼 @defias 就按业务测试用例的流程做吧。这块我也没做太多，没什么经验，仅供参考。

感谢楼主，顺便问一下 有没有用 restclient 做接口测试的？刚接触这一块，而且我们小组在组织学习 restclient 做接口测试，有没有趟过的前辈们说一下是否可行？

#73 楼 @silent_8 我没用过。。。

刚接触接口测试，和你前期的想发基本雷同，有的地方理解也有偏差，就此纠正下，感谢 LZ

#75 楼 @ling 不客气，这个帖子也是为了相互交流嘛~

很细心的总结，学习力，赞赞赞，同时知道了自己之前摸索的测试方式（初期用 jmeter+jenkins 提高接口测试效率）有人在用

接口测试，用 httpclient 上传一个图片 还有一些字符串 遇到一些问题 您能指点一下吗

#78 楼 @woshizuimeili 你说明下您具体的问题？

#79 楼 @chenhengjie123

第一张图是传入的数据 第二张图是我写的方法 但是总是出现问题

翻了楼主 11 月之前的帖子，写的很好。分析的不错，不知道楼主现在 api 测试的方式有木有固定下来。

最近在做接口测试，也是掉到用客户端验证功能的逻辑 去写测试代码，看了你写的学习了~

你这个没有设置 content-type 每种 http 请求都需要 content-type

楼主写的非常好 我现在也自己定义了一套接口自动化框架 其实也就是你所说的 乱入的方式 java+httpclient+sql+testNG 测试报告我自己写了一套 html 的页面 丑的不行。。。。我想知道 你是如何做到将参数的边界值覆盖的？

这个其实我也没做好。当时是通过设计用例的方式做的，不同边界值写不同用例覆盖。后面想了下，其实可以做成小工具，根据协议规则自动生成一组边界值数据，然后把这组边界值数据里的每个数据遍历一下。

嗯 这个方法不错 写个 StringUtil 类 参数给个特殊的符号标记 然后根据标记进行 random 创建 你们的测试数据是存储在 excel 里的么？ 我现在雏形是有了 但是测试数据存储在 mysql 数据库里面 因为本人数据库基础薄弱 不知道定义哪些表 才能让接口自动化测试能够覆盖所有的边界值 以及 异常值

不是，我的数据是写在单独的 Java 脚本里。后面没有继续做了。

额 行吧 我自己再摸索摸索 有料了 再分享出来哈

看了楼主的帖子，才发现自己也是犯了将接口测试用来测试功能的错误，还要回去整理初衷。

前提是看你实现的是哪一种接口测试，楼主说的是单个接口的测试，目前就拿我们公司项目来说，之前还对单个接口做设计过用例，后面觉得意义不是特别大，就算发现一小部分提示问题，开发也不愿意改，测试这边重视度也不够，索性目前只做基于业务逻辑的覆盖测试，这样即测试到了 API 接口（当然，这里纯碎是验证一种传参的情况，不考虑异常等情况），也覆盖到了相应的逻辑，我觉得这样也是可以的，关键还是得结合自己的实际业务和项目。

确实，我现在写了一部分接口的代码后，也发现了这个问题。每个接口单独可用的用例很少，开发也不愿意修改看上去比较微小的问题。这个可能和公司有关，有的公司更注重接口的规范性（比如本身就会有对外的接口提供出去）。
我准备写完所有的接口再来看看怎么办，是否编写更复杂的用例（包含多个接口调用的）来覆盖业务流程。不过相信现在写的底层的都会有用的。

你好！看完这篇文章，让我对接口测试又有了新的认识。最近换了工作，要求要做基于 http 的接口测试，也就是 API 吧。在读到这篇文章以前，我也一直以为接口测试就是没有界面的业务测试，
目前我们几个测试人员都没有人接触过接口测试，所以我现在都打算是先用 soapUI 或者 jmeter 来做接口测试，感觉上 jmeter 似乎更容易操作一些，但是 soapUI 可以直接从 swagger 导入 URI，这点又比较方便。。所以目前有一点犹豫不知道选哪个好。。

另外，还想向你请教一下，后期要做到接口自动化测试，怎么做会比较好呢？怎么能实现 excel 里面设计了数据组合，自动跑这些测试数据呢？如果是这样，校验点要怎么去设计呢？

开发提交代码后，接口测试脚本就自动跑起来，这个是要怎么去实现呢？？

接口小白，，，问题比较多，，还请指教！

你好，看了你的帖子，最新工作也遇到和你类似的问题，麻烦问一下，你是怎么解决的呢 ？能简单介绍一下吗，谢谢

不好意思，之前没看到消息。

1. 不大了解 soapUI 从 swagger 导入 URI 可以做到什么程度，如果可以做到自动生成部分用例内容，那么选这个可能更能提高工作效率。
2. 实现 excel 设计了数据组合后自动跑，如果是 java 可以用到 testng 的 dataprovider ，jmeter 的话可以直接用它读取 csv 的功能。其它工具就不大了解了。
3. 校验点的设计是个学问，可以先从 response 中是否包含指定内容开始，然后后期成熟后扩展到数据库的校验。
4. 开发提交后自动跑起来，可以用 jenkins 建一个 job 来跑自动化，job 的触发条件是开发代码仓库有 push 操作或者代码有改动。

非常感谢～最后我们还是选择了 jmeter，配合 csv 和部分数据库校验。

最后我们选择了 jmeter，配合 csv 和部分数据库校验。

总结的很详细，赞

学习了，有空大家一起交流

你最后的思路不是和之前一样了吗？还是一个接口很多用例啊，有什么实质性的改变吗

一个接口很多用例这个没有变化，变化的是这些用例的编写成本（适当使用数据驱动，减少代码量），以及通过调整设计，这些用例和后续功能测试的重合度降低，减少重复劳动。

当然，当功能测试效率比较低的时候，适度的重合也是可接受的。

感觉将会是我进一步遇到的问题，收藏了，主要是看到答主一个帖子回了 3 年，特地登录账号进来感谢

赞，方向很重要！

看完后，更晕了

哪里晕？

楼主，你好。我目前根据推荐的文章搭建了一个基于 python+excel+pymysql+pytest+allure 的测试框架，现在想要优化框架，希望可以支持：根据 excel 的数据自动生成测试用例代码，还没有一个好的实现方向，特此留言请教一下楼主，谢谢

可以详细说说你的整体情况（比如是基于什么具体应用场景需要做自动生成用例代码，手上有什么数据可以作为自动生成的数据依据等），然后说说你的初步想法，我们再共同探讨？

目前不知道你的完整情况，不好提出意见建议。

大佬有接触过 yapi 这块的接口测试嘛，想学习学习，目前公司在搞这个，之前没有接触过

能分享下你们公司是如何使用 yapi，mock 数据、设计测试用例、自动化执行测试集合，这一条龙的吗？个人觉得需要一些使用经验进行指导，不然好工具用不好也是枉然

楼主，我是在另一个接口讨论帖子看的你的回复，然后来到这里的，上面讲的很多也是我目前遇到过得问题。
顺带，想咨询一些新的问题，希望能得到楼主回复。
1.一些一次性的数据使用完后，如何重复使用（看到过还原数据库的操作，但目前测试环境领导不允许这样做；如果执行 sql 删除的话，是在什么时候处理，最后处理可能技术有限， 总达不到太好的效果）

2.还有一些接口拿的是如地区 id，订单 id 类似的，这种情况是写死数据吗？一部分数据确实是固定不变的，但还有一些可能存在过期或被删除的情况，这种我想了解怎么处理（数据关联我是有做的，但感觉类似这种接口关联不强的不太需要这样处理，目前打算的是从数据库中查找现存的数据然后去使用，但考虑到接口较多，每次执行 sql 不一致可能会导致不稳定，目前只进行了一个小模块的尝试，也不知这种是否合理）

希望大佬解惑，谢谢

虽然是很久远的文章，但是看一遍觉得写得很棒，忍不住评论一下。
目前我就职于一家金融类解决方案的公司，主要给银行做系统，包括同业，外汇的 web 解决方案。
目前公司的接口文档混乱 (有的是文档，有的用 yapi，有的干脆没有)，想尝试做接口自动化实践，但是需要让领导协调规范这方面的规则，但是又怕接口自动化产生的效益不如预期，有点矛盾，不知道应不应该走这一步。

建议先解决你说的文档问题再做接口的测试，接口测试比较顺了再做自动化。规范接口文档需要的不是说 “我做自动化需要用到”，这样是推不动的，因为这是你的问题，不是开发或者领导的问题，自动化收益再高都没用。要改为说前后端没有接口文档出现过多少联调方面的问题导致返工，和进度相互卡住（前端等服务端）资源无法释放问题，这个才是开发或者你领导都要解决的问题——提高开发效率问题。然后要做文档方法不是加重开发负担额外多写，而是用 swagger 等工具做到基于代码自动生成，这样开发才喜欢和愿意配合。

接口文档混乱，你会因为没有文档导致自动化成本很高（只能通过抓包知道接口具体内容，问人知道各个字段含义和要求，也只能通过看代码知道大部分异常代码），导致你时间都花在确认文档上，而非真的发现接口问题上。准备工作成本比后面执行收益高，容易变成大家累但感觉没啥收益。

虽然是 15 年的文章，但是现在看对测试新人还是有帮助的

感谢支持

感谢分享

太真实了 点赞