API，即：应用编程接口，就是软件系统不同组成部分衔接的约定。由于近年来软件的规模日益庞大，常常需要把复杂的系统划分成小的组成部分，编程接口的设计十分重要。
创新互联建站主营延寿网站建设的网络公司,主营网站建设方案,app开发定制,延寿h5微信小程序定制开发搭建,延寿网站营销推广欢迎延寿等地区企业咨询程序设计的实践中，编程接口的设计首先要使软件系统的职责得到合理划分。良好的接口设计可以降低系统各部分的相互依赖，提高组成单元的内聚性，降低组成单元间的耦合程度，从而提高系统的维护性和扩展性。
API测试是针对系统所提供的API做各方面的验证。API的性能和安全测试根据测试策略的不同，会是一个可选测试项。这个可以作为两个单独的问题来讨论。
API的功能测试类似于UI功能测试，都是在已知输入内容和期望结果的前提下，使用这个功能/调用这个API并且验证是否能返回期望的结果。不同的是API测试在返回结果被呈现给客户前就完成了，从而对测试环境的依赖会比较小。
还记得曾经在课堂上学过的测试金字塔吗？
简单来讲就是说越往上层走的测试，需要投入的成本会越高，而且会越难以维护。在这个结构下，因为UT已经覆盖了绝大部分的代码，所以其上层的集成/API测试和UI测试可以去除重复测试的部分，从而量也会越来越少，并且会有不错的覆盖率。
所以理想中的自动化测试结构应该是： 大量的UT+适量的集成测试(或者API测试)+少量的UI测试。
☞ 测试覆盖率。UT关注点是各个单元是否能够完成期望工作，只覆盖一个单元内部工作情况；集成/API测试关注点是各个模块/单元之间协同工作，它所覆盖的场景也会比单元测试更多。而UI测试会更加关注e2e，模拟用户行为，在所有的程序依赖环境准备完成后再进行操作。相比之下API测试不依赖环境，测试成本会比UI测试更低，而且覆盖率比UT更高。
☞ 快速反馈。API测试速度比UI测试更快(因为无需界面加载/响应)，短时间内能跑很多用例。API测试也能精确的揭露是软件中哪个组件除了问题，如果把你的API测试放到CI里面，一旦代码修改破坏了现有的功能，就能够快速反馈到团队中。还可以把测试中发现的BUG也写到API测试里面，让测试成为一堵墙，从而能更好的能保证产品质量。
☞ 可复用。API测试由于不需要浏览器、GUI等环境，所以可以更加灵活的在各个环境中复用。例如你可以在产品环境中、测试环境、研发环境中使用，你需要做的只是修改下测试数据而已。另外如果是在TDD模式下工作的话，API测试可能会在产品完成前就写完了，后续的工作也会减少很多。
API功能测试的主要手段是使用工具/软件调用待测API，然后验证是否返回期望的output。这个output通常可能是:
♡ 返回成功或者失败的status
♡ 是一段数据或者information
♡ 或者是跳转到其他API
工具
市面上常见的API测试工具我知道的可以分成几大类：
开源纯代码类，比如基于nodeJS的 supertest；基于Java的 rest-assured等。这类工具易于学习，易于和CI集成，但是需要使用者有一定的编码能力。商用工具，比如：SoapUI，功能强大操作简单，还提供免费社区办可以试用。各类插件工具，比如Chrome插件Postman，也有收费版可以用。工具的选择见仁见智，根据不同的环境选择不同的工具。
测试
在正式开始测试之前，你得先搞清楚几个问题：
待测API的目的是什么？谁是使用者？
待测API会在什么环境下使用？
待测API在异常环境下会不会有非期望响应？
这个测试需要测什么功能点？
各个功能点的测试优先级？
如何定义期望返回的结果是成功还是失败？
待测API会不会和其他系统有交互(修改代码后影响其他系统)？
这些问题会影响到你的测试结果是否符合客户需求，或者说这些潜在的风险会影响到这个项目是否成功。如果你选的是必须得自己写点儿代码的工具，那么接下来得根据选择的工具和项目代码，去setup测试环境，让工具能够成功跑起来。
设计测试框架
接着是设计你的测试框架，最好是要满足可复用性强，高内聚低内聚什么的原则，记得要有输出测试报告的模块。
用例
上面你已经想好了需要测哪些功能点，针对这些点我们用脑图之类的工具把需要测试的场景记录下来。
脚本
接着是脚本设计和测试数据设计。脚本和数据最好可以分开，这样的话可以复用测试脚本，用不同的测试数据输入去获取不同的期望结果。
验证
验证的过程大致包含下面这些：
检查API是不是根据你输入的数据返回期望的结果；验证API是不是不返回结果或者返回异常结果；验证API是不是正确触发其他even；收否正确调了其他API；或验证API是不是正确更新了数据等等。
最后，强烈推荐把测试集成到CI中去，加速异常反馈，创建强有力的质量体系。
