集成测试实践之浅谈api的分类

转载自： http://www.ltesting.net/ceshi/ceshijishu/csgl/jccs/2013/0115/205907.html

接触api测试已经有半年了，也算是小有心得。所以谈谈我眼中的api。

　　想从理论的角度了解，请访问http://qa.corp.anjuke.com/?p=59。我师父写的扫盲贴，适合不知道神马是api，也不知道怎么测试api的入门阶段的童鞋。

　　按照我个人的理解，我接触到的api大概可以分成那么几类：

　　1.纯读取数据接口，返回的数据基本是固定的，很少改变。这类api通常比较好测。

　　比如：获取城市信息。

　　2.通过筛选条件得到结果。这类api是基于第一种分类的api的，因为筛选条件都在第一个分类的api里面，有一定的逻辑，多样的筛选条件测起来会有点头晕。所以要事先规划测试用例。

　　比如：房源列表。

　　3.有复杂逻辑的接口。需要分析用户的行为，然后根据行为获得相应内容。这样的接口特别头疼，因为它的逻辑最复杂，在测试之前一定要和产品确认好逻辑，任何小问题都要确认，最好是能和开发也确认一遍逻辑，因为在逻辑很复杂的情况下，开发和产品理解的可能不是同一个意思，这种情况我已经遇到过多次。在确定逻辑后，一定准备好测试用例测试数据。

　　比如：推荐。

　　4.写数据接口。这类接口就是你发一个请求，服务器相应会写入你传的数据。由于基本没什么逻辑，也比较好测试，只需要上服务器查看就可以了。

　　比如：发送日志信息。

　　5.操作类接口。这类接口往往是几个小接口互相关联的。这类接口的复杂程度不是绝对的，要根据是否有业务逻辑划分。

　　比如：收藏和取消收藏，这类接口测试就比较简单，你可以用收藏接口收藏一套房子，然后去收藏列表查看，然后再取消收藏，再去查看取消收藏列表。需要注意的地方就是收藏数量上限，以及收藏或者取消收藏不存在房源或者过期房源时，返回不会出错。

　　但例如一些涉及复杂业务逻辑的接口，就往往没那么简单了。我就不一一举例了。

　　最后，我给api测试的八字真言：多测，多想，熟悉业务。

　　光说那么一大堆其实很枯燥，如果真的想了解api，那就动手实践吧!

　　为找到每一个api bug 而惊喜!