项目 10 天投产，测试仅剩 2 天，如何处理？

看到这篇文章的同学们一定在各种地方看到过“接口测试”这个词，那么接口测试到底是测什么?相信每个人可能都有自己的答案。

接口测试对于不少测试新手来说不太容易理解，接口测试关注的是一个函数、类（方法）所提供的接口是否可靠。接口测试也可以是 url 的形式进行传递，例如，我们通过 get 方式向服务器发送请求，那么我们发送的内容作为 URL 的一部分传递到服务器端。

下面，我们从实际案例中了解一下接口测试效率。

一个项目，规定 10 天投产，预估 5 天开发 5 天测试（这里估计的是手工测试），那么接下来因为各种环境或者开发技术原因导致开发时间延长至 8 天，测试时间只剩 2 天，作为本项目的测试你只有 2 天的时间进行测试。此项目为紧急项目，必须保证到期投产。请问如何处理？

手工测试的流程：

手工测试在未提测前的准备：先根据需求编写用例和数据准备，然后就是等待提测。每天了解下开发进度，到第四、五天的时候通知可能要延期，然后真的延期了，第九天提测了，请速度测试。

因为是人力来执行，执行效率有限，原预估五天手工执行速度不会一下缩减到两天，还有修复缺陷和复测时间（如果真的达到了请在留言区留下联系方式让我瞻仰下手速达人），所以会导致以下几种结果：

砍掉测试用例，保证主流程，测试不够充分，到期带 bug 投产；
无限加班、决战到天亮，到期投产；
项目延期。

我相信做测试的人都会遇到以上这种问题，那么，做自动化接口测试能否改善这种情况呢？

自动化接口测试的运行场景：

测试前置、开发自测：一个新的自动化接口测试案例开发完成后，直接发给接口对应的开发，安排在开发本地环境执行，一旦开发确认完成接口开发，就开始执行接口测试案例，基本上可以实时拿到测试结果，节省时间的同时又方便开发快速做出判断。

回归测试：开发本地测试通过后，或整个需求手工测试通过后，把自动化的接口测试案例做分类整理，挑选出需要纳入到回归测试中的案例，在持续集成环境重新准备测试数据，并把案例纳入到持续集成的 job 中来，这些用于回归的接口测试案例需要配置到持续集成平台自动运行。例如每日晚上 11 点执行脚本，执行完成会发给相关人员。

接口测试的优势体现在下面的三个方面：

接口测试节省了测试成本，根据数据模型推算，底层的一个 Bug 大概能够引发上层的八个 Bug，而且底层的 Bug 很容易引起全网的死机。相反接口测试能够提供在系统复杂度上升情况下的低成本高效率的解决方案。
接口测试不同于传统开发的单元测试，接口测试是站在用户的角度对系统接口进行全面高效持续的检测。
接口测试是自动化并且持续集成的，这也是为什么接口测试能够低成本、提高收益的根源。

举这个例子是想更直观的看下自动化执行效率，但并非所有的项目都适合接口自动化，这里只是提出一种更有效的测试方法，还是需要测试人员根据自己所处的实际情况判断哪种更高效。

以上就是我想和大家分享的关于自动化测试的想法，最后附上一张我在实践中总结的接口自动化测试时需要覆盖的内容给大家作为参考。

———————————————————————分割线—————————————————————————

我是小微，专注微服务技术分享，致力挖掘更多“高、精、全”的微服务知识分享给大家。

我的微信：weiweiweiblack （备注：v2ex ）

微信公号：黑少微服务，“分享技术，热爱生活”，欢迎关注