本文主要介绍以下的内容：API文档提供了预测客户成功的关键路径；在代码附近的文档上进行协作可以更好地检查代码和文档文件，提高自动化效率，并专门针对文档进行质量测试；提供通用文档框架，标准，自动化和工具，以提高团队效率。详情请查看全文。
前言
本文主要介绍了一种新的开发思路：通过反转开发顺序，直接从API文档中阅读代码。作者认为通过这种开发方式，你可以更清楚地知道文档表达出什么以及它应该如何实现。
根据百度百科的定义，mock 测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。这个虚拟的对象就是mock对象，mock对象就是真实对象在调试期间的代替品。
在瀑布流开发模式中，如果前端开发人员需要进行页面对接，需要后端先完成 API 的开发工作，如果没有mock，那么前后端开发的进度会互相影响。通过 Mock API 事先编写好 API 的数据生成规则，由工具动态生成 API 的返回数据。开发人员通过访问 Mock API 来获得页面所需要的数据，就可以轻松地完成对接工作。
这就是 Mock API 的定义，本篇文章将通过具体的场景示例介绍 Mock API 的定义及实践（使用 EOLINKER 实现）：
当前强人工智能已经有初步成果，甚至在一些视频识别、语言分析、棋类游戏等等单方面的能力达到了超越人类的水平，当前有大量的工具应用了人工智能，其中包括搜索和数学优化、逻辑推演。本文将介绍人工智能的基本概念和应用，以及如何快速调用相关API文档完成 API 自动化测试脚本。
业内通常用多少9来衡量网站的可用性，例如QQ的可用性是4个9，也就是QQ能够保证在一年里，服务在99.99%的时间是可用的，只有0.01%的时间不可用，大约最多53分钟。
对于大多数网站，2个9是基本可用；3个9是叫高可用；4个9是拥有自动恢复能力的高可用。
实现高可用的主要手段是数据的冗余备份和服务的失效转移，这两种手段具体可以怎么做呢，在网关里如何体现？
上一篇文章我们讲述了微服务转型前的考虑与注意事项，接下来我们可以探讨过渡到微服务的策略与其他一些需要注意的问题。
迁移架构前，你需要想明白：从整体代码库创建或分解哪些服务；你的架构设想是什么样的；你希望服务的粒度是多大；以及服务间如何通信。我们可以从那些比较不易分离的服务开始着手，例如那些部署频率或更新频率较高的服务。
迁移到微服务本质上是一种重构，因此我们平时重构所遵循的法则在这里也适用。
本文为 EOLINKER 官方关于 《进行接口测试的最佳路径》 下半部分文章，主要介绍测试脚本如何执行和报告生成，以及测试项目人员如何协作。
本文为 EOLINKER 官方关于 《进行接口测试的最佳路径》 上半部分文章，主要介绍如何使用 EOLINKER-AMS 进行测试脚本管理和编写测试脚本。