接口测试框架

参考文章：https://testerhome.com/topics/10525

接口测试框架选型

　　1.目前接口测试框架的选型，最常见的方法是采用jmeter,soapUI,postman,robotframework等UI化的接口测试框架来做。
好处是业务测试人员可以不用或很少写测试代码，入门门槛低，前几年有很多公司都曾经开发过类似的测试框架，有前端有后端，专职的测试开发人员维护，业务测试人员只需要知道怎么操作而不需要参与具体coding。
这种方法看起来非常高大上，但实际的问题是执行过程中主要的工作变成了测试框架的维护，非常依赖专职测试开发人员的设计和开发能力，每增加一种新的接口协议（比如dubbo、hessian或者内部自定义的协议）就需要在框架上增加支持；更致命的是一旦核心测试开发人员出现流动，就很容易造成整个接口测试体系的崩塌；另外对业务测试人员的技能成长也并不公平，个人已面试过太多只会使用某大公司XXX测试框架却完全不了解具体实现方式的工程师。
《google软件测试之道》中早已有过预言，保密和私有化的基础测试设施并不能获得想象中的好处，这种方式意味着昂贵和迟缓，即使在公司内部的不同项目之间也很难做到复用。未来的测试基础设施必然是建立在共享代码和开源框架的基础上，测试开发人员需要更多的利用开源项目并为之贡献。
最近重读了一次这本四五年前几乎改变软件测试行业的书籍，发现里面的预言都是如此准确，当然也可以认为国内整个行业都正参照google的方式在进行演变。

 

　　2.使用junit、testng等java接口框架，直接编写测试代码去测试，同时对一些重复性的工作抽象建立基础库或方法。
有点类似于单元测试，这种方法扩展性好实现灵活，作为程序员可以用代码实现灵活的场景组织和功能，只要稍微二次开发一下，但需要测试工程师有一定的编码基础。　 
这种方式在前几年实施的难度还是比较大，因为在市场上要找到懂java代码的测试工程师都寥寥无几，但在对测试工程师开发能力要求越来越多的今天实施难度已没有想象中困难，java/python等语言的编码能力也已成为我们团队招聘时的基本要求。
另外提下，这里使用java而不用其他语言的原因，主要是团队的技术储备java是强项,拥有丰富的开源测试库，而且一般互联网公司的产品基本都是采用java框架进行开发，和开发团队技术栈保持一致非常有必要性。

　　3. groovy语言开发的基于JVM的开源测试框架 rest-assured，原因有以下几点，

　　　1）链式调用，语法简明易懂；

　　   2）开源框架易于扩展；

　　　3）我们的APP加密加入了时间戳，这种用成熟的工具不能满足；

　　4. 开源接口框架rest-assured的内部实现原理；

　　　　待补充，简洁的图表示；

 

封装的接口测试框架

　　　　此处画一个框架的整体流程图

数据准备

　　数据源

测试用例执行流程

测试用例的分级

断言

测试代码规范

　　1.测试项目命名规范
接口测试：
一般需要独立测试项目，测试项目的命名规则为：“test-“+被测试的项目名，如test-kano
单元测试：
不需要重建独立测试项目，和开发代码放在同一项目即可。
　　2.测试目录定义规范
测试代码统一放在测试项目的“src/test/java”下。
测试配置文件统一放置在“src/test/resources”下。
　　3.包名定义规范
与被测试项目中的包名一致
　　4.测试类命名规范
测试类的命名规则是：以Test开头，以它要测试的对象的名称结尾，例如
Test+被测试的业务、Test+被测试的接口、Test+被测试的类
另外一种方式是：以Test结尾，以它要测试的对象的名称开头，例如
被测试的业务+Test、被测试的接口+Test、被测试的类+Test
视个人习惯而定，为了case定位方便，目前测试团队一般用第一种。
　　5.测试用例命名规范
测试用例的命名规则是：test+用例操作_条件状态，统一使用lowerCamelCase风格，必须遵从驼峰形式。
单词的约定与测试类命名同
　　6.接口测试代码常见约束
（1）数据清理和构造
@BeforeClass @Before中做数据准备等相关操作
--加载测试类以前需要加载所有测试用例共同的场景数据，同时在运行单个测试用例的时候加载特别的测试数据
@AfterClass @After中做测试数据清理等相关操作
--在执行完相关测试以后清理用例现场 
（2）断言
--不要做无谓的断言
在测试模式下, 有时会情不自禁的滥用断言. 这种做法会导致维护更困难, 需要极力避免. 仅对测试方法名指示的特性进行明确测试,因为对于一般性代码而言, 保证测试代码尽可能少是一个重要目标
--使用显式断言方式
应该总是优先使用 assertEquals(a, b) 而不是 assertTrue(a == b), 因为前者会给出更有意义的测试失败信息. 在事先不确定输入值的情况下, 这条规则尤为重要
--断言的参数顺序要合适
（3）测试用例保持独立
--确保测试代码独立于项目代码之外
--为了保证测试稳定可靠且便于维护, 测试用例之间决不能有相互依赖, 也不能依赖执行的先后次序.
（4）测试代码要考虑错误处理
--如果前面的代码执行失败, 后续语句会导致代码崩溃, 剩下的测试都无法执行. 任何时候都要为测试失败做好准备, 避免单个失败的测试项中断整个测试套件的执行
--不要写自己的catch代码块，即只有test失败的情况，不应该存在catch情况

结语

 　　接口测试是一个非常庞杂的体系，很难用一篇文章阐述清楚，在持续交付体系中扮演着非常重要的角色。
其他实践如接口测试覆盖率统计、标准协议页面化测试平台（提供给没有编码能力的产品或测试人员使用）、maven项目骨架建立标准化测试工程、dubbo/hessian/restful/webservice等接口协议具体实现等等限于篇幅也没有做具体阐述。