我们常接触到的接口测试,主要用于检测外部系统和所测试系统之间的交互,重点是检查数据交互,传递和系统之间的相互依赖关系。
我们常常很重视接口测试中的功能点,测试数据,测试执行和预期结果。在测试用例设计中,很容易将功能点和测试数据的用例设计完整,而对测试环境则很容易忽视掉,或者不够重视。
有些接口的代码设计逻辑实现了我们内部接口所要求的功能,在环境一切正常的情况下,功能没有问题。但在环境异常时,例如与接口相关的服务不存在,或相关的服务超时,该接口竟然功能正常!
我个人在日常测试中碰到2个类似的问题:
1、直通车广告计划上下线(需要更新数据库,且发送通知引擎消息,且这两个操作是在同一个事务完成的),在接口所调用的notify-hsf服务不存在的前提下,数据库更新成功,但却没发送通知引擎消息。
但在notify-hsf服务正常的前提下,广告计划上下线操作是完全ok的。
2、直通车删除宝贝且通知淘宝该宝贝退出直通车,在同步服务不存在的前提下,更新数据库失败,但却可以成功发送通知引擎消息
但在同步服务正常情况下,删除宝贝接口功能正常。
以上两种情况的bug都是在环境异常情况下出现的,在系统正常服务期间,基本发现不了。究其原因是:在接口的代码逻辑不变的前提下修改了接口实现方式,导致系统服务异常时,接口捕捉不到异常信息,在后台的log中查不到出现异常的错误log,很难查到问题之所在。
所以我们在日常测试中,对测试环境的设计用例一定不能少,并多考虑点测试环境的多样性可能给功能带来哪些问题。尤其是系统异常(虽然这种现象在生产环境几乎很少出现)情况下,数据,消息,log,及log的级别都需重视一下。