接口测试的那些事（一）

restful接口的用途？

如何实现一个restful接口，想必这个问题对于会点代码的人来说，简直太简单了：springmvc ，Jersey，Spark Framework等等。1）但是如果进一步提高要求：实现一个提供restful接口配置的框架，即输入任意的URL 和 期望返回的json串，配置完成后就可以立刻使用该restful接口了，想必这样的框架还是需要一点精力的。之前曾经写过一个restful接口的框架，专门用来配置接口：

页面配置URL ，期望返回的json/字符串---> 点击配置按钮--->restful接口生效

2）进一步延伸，后端API接口尚未开发出来前，如何对前端代码进行测试？ 这个问题便可以通过1）中的restful接口框架完美的解决。

整个流程如下：

step 1： restful框架中配置期望的restful接口（根据前后端开发事先定义好的接口文档），并使其生效

step2 :    前端以某种方式调用step1中 已经生效的restful接口进行测试。测试期间，可以不断修改restful接口的返回值，进行不同场景的测试。注意，这里之所以说“前端以某种方式调用restful接口”，是因为 需要根据前端的具体技术来决定，怎么调用restful接口。例如

如果前端是以ajax方式调用后端接口，那么测试人员便可以通过类似fiddler的代理，重定向host来 实现，此时不需要前端开发修改任何代码； 但是如果前端使用的是非ajax形式的话，那么就需要前端开发将 接口 修改为 restful接口 的域名后，方可实现测试。

step3:    后端开发接口完成后，前后端真正联调测试时，便只需要走一遍功能检查就好了

ps : 使用restful接口 测试 针对block 点在后端接口的项目 可以很好的提高整个项目的开发上线效率

接口自动化测试的方案选择？

这里具体的应用场景：众多的接口需要测试，如果进行测试 和上线之后的快速回归测试（纯手工的测试这里不做考虑）

可选的方案：

• 已有的框架/程序包下，手工配置用例后，自动化验证

例如，可以选择 Junit， testng  等框架 来手工写 自动化用例， 然后使用 rest-assured ，json解析包 来对返回的json 进行验证。

坏处：每次修改用例（增删改）都要手动修改测试代码，再次运行，耗时麻烦

好处：由于测试人员完全控制接口的请求和接口返回的验证，可以对任何复杂的接口验证（QA能力允许情况下），特别是当QA使用的接口返回验证方法 也完全自己封装时，结果验证将不局限于任何框架。

• 封装较为通用的框架

“通用”指的是：将接口的检查点统一形成通用的规则，这样每次只需要添加接口就OK了，之后按照配置好的规则对接口进行检查，避免了每次对不同的接口都需要重复编写类似的代码检查了。

例如，有若干http接口，均需要检查某个字段值的大小，那么就可以将检查某个字段值大小配置成一个规则，接着添加完若干接口后，就可以实现对这些接口跑一遍检查了。

下面是个人实现的一个简单框架：

这里之所以说是"较为通用"的框架，是因为 类似规则1~规则9是事前配置好的检查规则，所以，接口要进行这些规则的检查是木有问题的了。 但是，如果要检查的规则不在这些规则中，或者要检查接口的点过于复杂的话，这样的检查点通用性不太强，那么没必要形成规则了。 此时，还是需要手动在junit或testng中写脚本的。

ps: 上图中的自动化框架是基于testng下的报告的，可以发HTML测试报告出来，测试报告结果未存入DB。

其实，接口自动化的实质是：对接口的返回进行检查。如何检查，能更快验证接口，发现更多接口存在的问题，才是接口自动化测试QA的价值所在。个人认为，接口自动化测试分为2个层面：

1） 较为通用的检查case, 使用接口自动化框架实现；

2） 较为个例，或者检查过于复杂的case,QA可以专门写脚本来检查。

关于接口自动化效果的评估，项目中往往更偏向使用代码覆盖率来评价。因而，当接口自动化加入之后，后续补充自动化case的动力往往来自代码覆盖率了。结合项目中的实际应用，接口自动化效果做的好不好，可以从下面几个方面入手：

1） 代码覆盖率（受项目代码量，项目本身是不是有不可自动化的代码，case编写细化粒度等影响）

2） 发现问题数（受项目本身稳定程度，case编写细化粒度等影响）

3） 推动项目质量提升（受项目本身，case编写细化粒度等影响）

线上和线下系统对接口自动化/接口监控的不同要求

这里结合自己项目中使用的经验，摘录出了一些具体的思考侧重：

侧重/思考点线上系统线下系统

数据需要定时从上游系统更新
且更新可能存在延迟项目中尚未遇到延迟

可能存在延迟时，无论接口自动化还是接口监控，都应该将检查数据延迟的这部分case单独拆分出去，否则影响通过率/经常报警case的粒度接口自动化：细化case检查点（方便case后续维护），并充分让case能动态参数变更，全局参数配置（方便修改）

接口监控：同样要考虑接口自动化类似的问题，但区别在于，监控的case检查点要覆盖主要检查点，而非全部检查点（因为监控更倾向于接口本身的可用性，而非功能性）同线上系统执行频率接口自动化：依据项目本身要求而定，但一般来说，执行频率较低，每天1~2次，并且会加入持续集成

接口监控：执行频率很高，几乎要求时时。曾经一个项目设置成每分钟执行一次，以此来保证，接口不可用时，可在1分钟之内发现并报警处理
接口自动化：同线上系统
接口监控：执行频率要考虑接口可承受的访问压力，计算量很大的类似报表统计的项目，可能需要设置的频率小些对访问量的统计影响线上访问量的量级很大，基本可以忽略掉自动化测试/监控带来的影响可能需要特别忽略监控带来的【虚假】访问量，可IP过滤或URL中额外附带参数过滤带来的价值取决于线上服务的稳定性相对线上服务，线下服务可能较为不稳定，这也正体现了做自动化/监控的根本目的