接触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 而惊喜!