09月16, 2014

从业务角度理解接口测试

最近刚刚接触了接口测试,从自己的体验和看到的关于接口测试的知识总结了一点小小的心得。

接口包括系统之间的调用、服务之间的调用等。接口测试一般是对程序内部或外部的接口进行的测试,一个接口方法会有自己特定的业务定义,所以,做接口测试时更多需要从业务的角度去考虑如何测试这个接口。做接口测试先要了解是基于哪一种类型的接口测试,不同类型的接口测试方法可能是不一致的。http协议的接口测试,可以通过编写脚本或通过辅助工具fiddler、jmeter、loadrunner等,这些工具使得接口测试更为简单、方便;java接口的测试,则需要编写测试代码去测试,有点类似于单元测试。

接口测试也是主要依赖需求说明书,因此接口测试流程其实和功能测试类似。最初也是需求讨论,需求评审。需求确定以后,开发会根据需求进行接口设计,测试人员制定测试计划。完成接口定义之后,根据需求文档及接口定义进行测试用例设计,测试用例设计主要从业务场景、功能及异常测试几个方面考虑,,对测试用例进行评审,并准备测试环境。然后进行接口测试,并在测试结束后进行总结分析。

准备接口测试数据有两种方法。

第一种方法是准备动态的数据即调用程序准备数据的API接口。通过一系列的调用得到我们想要的过程数据。这个方法的优点是极易保证数据的准确性,尽量降低垃圾数据的产生;可以验证接口间的组合调用的正确性;代码重用率高。不足是不易准备异常数据,通过API调用参数基本为正常数据;接口之间依赖比较严重,比如测试CRM的删除白名单接口,需要该账号下存在订单,这时候就需要通过订单接口先创建订单创建数据。;当接口出现错误时,不能清楚地定位是要测试接口的问题。这种方法是目前最常用的方法。

第二种方法:准备静态的数据。可以使用Excel文件来准备数据或者通过数据库操作直接准备用例所需的所有数据。这种方法可以使得测试数据与脚本分开,结构清晰;生成的数据直观,可读性强。但是同时也需要对各个阶段数据的合法值,非常清楚,测试过程中经常会因为测试数据的问题,导致执行不通过;当出现大的变动时,数据更改的工作量比较大,灵活性较差,重用性差。

最后总结一下。接口测试,更注重从用户的角度设计用例,更偏向于功能测试,需要更多的考虑业务覆盖。通过业务的角度去设计测试用例。接口测试会减少功能测试的时间,因为接口测试会确保主要流程功能的正确性,接口测试更容易实现持续集成,从而减少回归测试的次数。

本文链接:http://blogs.360.cn/post/从业务角度理解接口测试.html

-- EOF --

Comments