# 前言
API,就是软件系统不一样组成部分衔接的约定。因为近年来软件的规模日益庞大,经常须要把复杂的系统划分红小的组成部分,编程接口的设计十分重要。
程序设计的实践中,编程接口的设计首先要使软件系统的职责获得合理划分。良好的接口设计能够下降系统各部分的相互依赖,提升组成单元的内聚性,下降组成单元间的耦合程度,从而提升系统的维护性和扩展性。
换句话说,API也能够看作程序/资源/组件的集成点。它的功能会跟UI有些相似,经过某些特定指令、参数等可让后台的一堆代码运行起来,最后获得想要的结果。不一样的是它不提供可视的按钮文本框之类的界面,而一般是由一个直接和底层代码打交道的连接构成。node
# API功能测试的概念
API测试是针对系统所提供的API作各方面的验证。API的性能和安全测试根据测试策略的不一样,会是一个可选测试项。这个能够做为两个单独的问题来讨论。
API的功能测试相似于UI功能测试,都是在已知输入内容和指望结果的前提下,使用这个功能/调用这个API而且验证是否能返回指望的结果。不一样的是API测试在返回结果被呈现给客户前就完成了,从而对测试环境的依赖会比较小。编程
# 构建API测试的价值
测试覆盖率。UT关注点是各个单元是否可以完成指望工做,只覆盖一个单元内部工做状况;集成/API测试关注点是各个模块/单元之间协同工做,它所覆盖的场景也会比单元测试更多。而UI测试会更加关注e2e,模拟用户行为,在全部的程序依赖环境准备完成后再进行操做。相比之下API测试不依赖环境,测试成本会比UI测试更低,并且覆盖率比UT更高。
快速反馈。API测试速度比UI测试更快(由于无需界面加载/响应),短期内能跑不少用例。API测试也能精确的揭露是软件中哪一个组件除了问题,若是把你的API测试放到CI里面,一旦代码修改破坏了现有的功能,就可以快速反馈到团队中。还能够把测试中发现的BUG也写到API测试里面,让测试成为一堵墙,从而能更好的能保证产品质量。
可复用。API测试因为不须要浏览器、GUI等环境,因此能够更加灵活的在各个环境中复用。例如你能够在产品环境中、测试环境、研发环境中使用,你须要作的只是修改下测试数据而已。另外若是是在TDD模式下工做的话,API测试可能会在产品完成前就写完了,后续的工做也会减小不少。浏览器
# 为何要作API功能测试——测试金字塔
还记得曾经在课堂上学过的测试金字塔吗?
简单来说就是说越往上层走的测试,须要投入的成本会越高,并且会越难以维护。在这个结构下,由于UT已经覆盖了绝大部分的代码,因此其上层的集成/API测试和UI测试能够去除重复测试的部分,从而量也会愈来愈少,而且会有不错的覆盖率。
因此理想中的自动化测试结构应该是:大量的UT+适量的集成测试(或者API测试)+少许的UI测试。安全
# 工具
市面上常见的API测试工具我知道的能够分红几大类:
开源纯代码类,好比基于nodeJS的supertest;基于Java的rest-assured等。这类工具易于学习,易于和CI集成,可是须要使用者有必定的编码能力。
半商用工具,好比Eolinker,功能强大操做简单,有高级功能收费版,免费版也足够我的及中小团队使用。
各种插件工具,好比Chrome插件Postman,也有收费版能够用。
工具的选择见仁见智,根据不一样的环境选择不一样的工具。我进了如今的公司后用的是Eolinker
框架
怎么作API功能测试?
API功能测试的主要手段是使用工具/软件调用待测API,而后验证是否返回指望的output。这个output一般多是:
a.返回成功或者失败的status
b. 是一段数据或者information
c. 或者是跳转到其余API工具
# 设计测试框架
接着是设计你的测试框架,最好是要知足可复用性强,高内聚低内聚什么的原则,记得要有输出测试报告的模块。
a.用例
上面你已经想好了须要测哪些功能点,针对这些点咱们用脑图之类的工具把须要测试的场景记录下来。
b.脚本
接着是脚本设计和测试数据设计。脚本和数据最好能够分开,这样的话能够复用测试脚本,用不一样的测试数据输入去获取不一样的指望结果。
c.验证
验证的过程大体包含下面这些:
检查API是否是根据你输入的数据返回指望的结果;验证API是否是不返回结果或者返回异常结果;验证API是否是正确触发其余even;收否正确调了其余API;或验证API是否是正确更新了数据等等。
完了就是输出测试报告了,好的测试报告能够帮助你轻松定位到出错的地方,使修复流程更加顺畅。
最后,强烈推荐把测试集成到CI中去,加速异常反馈,建立强有力的质量体系。性能
# 思惟
在正式开始测试以前,你得先搞清楚几个问题:
a.待测API的目的是什么?谁是使用者?
b.待测API会在什么环境下使用?
c.待测API在异常环境下会不会有非指望响应?
d.这个测试须要测什么功能点?
e.各个功能点的测试优先级?
f.如何定义指望返回的结果是成功仍是失败?
g.待测API会不会和其余系统有交互(修改代码后影响其余系统)?
虽然问题会影响到你的测试结果是否符合客户需求,或者说这些潜在的风险会影响到这个项目是否成功。若是你选的是必须得本身写点儿代码的工具,那么接下来得根据选择的工具和项目代码,去setup测试环境,让工具可以成功跑起来。单元测试