一 、为什么要做接口测试?
对于一个小型的web系统而言,通过界面的手工测试,可渗透到系统的各层,达到测试整个系统功能的目的。但随着产品功能的不断丰富,访问量不断增加,传统的MVC架构已经不能满足快速研发的需求,系统不断向着分布式、业务中心化和高可用性的方向发展而分为多个子系统,各个子系统之间通过接口契约相互提供服务,这些接口又会被上层应用调用,调用关系错综复杂,下图展示了淘宝某子系统跟其他子系统的交互关系。
通过上图可以看出,随着系统的不断复杂,通过界面测试保证整个系统功能的做法不再有效或成本巨大,同时底层及业务中心对外提供服务的接口变得很关键,一旦这些接口出现bug,将影响到大量的上层业务甚至使系统宕机。如何保证这些接口的功能正确性?一个有效的手段就是通过模拟上层调用场景对系统接口进行测试,保证接口对外提供的服务是正确的。接口测试的另外一个价值在于回归测试,一旦某个系统代码改动影响了接口服务契约,回归系统会马上发现报告给相关人员,避免了线上bug的发生。
既然接口测试如此重要,那么如何进行接口测试?下面从流程、框架选型和持续集成方面做些阐述。
二 、接口测试的一般流程
接口测试需要在项目何时介入,具体要做哪些工作,在研发过程中接口测试工程师怎么跟开发工程师互相配合?下面的流程图展示了接口测试在项目中的重要活动。
……………………
查看全文请点击下载:http://www.51testing.com/html/02/n-227802.html
四 、Junit+DbUnit--扩展的数据管理
接口测试往往很难避开数据问题,要在测试前使数据库处于已知状态,在测试后清理相关数据给下个运行一个干净的数据环境。举个简单的例子,要测试某个接口的查询功能,需要在执行测试前向数据库插入一批已知数据,然后用特定的参数查询验证结果,在测试完成后需要清理之前插入的数据,恢复数据库到原有状态。Junit提供了@Before和@After注解解决了流程上的问题,但直接用Sql操作解决此类数据问题就会使代码很难编写和维护,DbUnit很好的解决了此类问题。使用DbUnit管理数据的一般思路如下:
1、将数据定义为数据集存放在Excel文件或XML文件里。
2、在测试执行前将数据集文件里的数据同步到数据库。
3、在测试执行后删除数据库里跟数据集文件匹配的数据。
DbUnit支持Excel数据集和XML数据集,Excel数据集的sheet名为表名,第一列为数据库字段名,其他列为数据,其格式示例如下。
XML数据集以dataset为根节点,子节点名为表名,子节点属性名称和值对应数据库字段名称和值,其格式示例如下
<?xml version='1.0' encoding='UTF-8'?> <dataset> <top_api ID="99999999" SESSION="1" BINDING_TYPE="1"/> <top_api ID="99999998" SESSION="1" BINDING_TYPE="1"/> <top_api ID="99999997" SESSION="1" BINDING_TYPE="1"/> </dataset> |
NONE:什么也不做 UPDATE:根据数据集内容更新表中数据 INSERT:将数据集内容插入表,可能会违反主键唯一约束 REFRESH:如果表中存在数据集中对应的数据则更新,不存在则插入 DELETE:从表中删除数据集中对应的内容 ---------下面三条在公用数据库中慎用---------------------- DELETE_ALL:删除表中所有数据 TRUNCATE_TABLE:执行truncate table指令 CLEAN_INSERT:先执行DELETE_ALL,再执行INSERT |