通用技术 异常测试实践与梳理之功能异常

小敏 · 2017年08月02日 · 最后由 fearless7n 回复于 2019年02月19日 · 3311 次阅读

异常测试,是指通过人为制造异常,检测系统的处理是否符合逻辑。我结合在A项目中的实践,梳理一下常见异常测试的类型、关注点及常用测试工具等。

A项目是一个典型的web前端+后台的项目,主要的业务是购买账号及注册账号。从实践来讲,我觉得一个项目的异常测试基本可以分为2大类:功能异常及服务端异常,功能异常按照先后执行顺序一般可以分为3种:单接口异常、web端异常及业务操作异常。下面来介绍一下功能异常,服务端异常在异常测试实践与梳理之服务端异常测试中介绍。

avatar

1、单接口异常测试

单接口异常测试主要的关注点是依赖服务调用异常时,业务代码能否容错及容错逻辑是否合理。

单接口异常测试一般也可以放到服务端异常测试阶段来做,但这个阶段常规功能测试已经做完,再回过头来对每个接口进行异常测试,还需要花一定时间去重新熟悉接口业务,且该阶段关注的重点是后台整体的异常,需要覆盖的异常点很多,从时间上来说一般会比较紧。所以,个人觉得单接口异常测试放在接口测试阶段比较合适,并且单接口异常测试可以为服务端异常测试做铺垫,把接口依赖分析都完成了。

单接口异常测试,主要包括输入异常、操作异常、依赖服务异常等,具体要视接口情况而定。输入异常及操作异常一般在接口测试时都会涉及,而依赖服务异常不一定。如果项目对可靠性要求比较高的话,且时间允许情况下,还是要争取覆盖一下。

在A项目的单接口异常中,依赖服务异常是重点。在执行测试之前,需要做一些准备工作。

  • 分析接口所有依赖的服务(需要咨询开发,或对业务和代码熟悉的可以直接看代码来了解) A项目中所有接口的依赖服务主要包括主系统(调用注册服务)、数据库(MySQL)、缓存(redis)等。
  • 了解各依赖服务的超时设置 如访问mysql、redis及http请求的超时时间。需要跟开发确认所有访问第三方依赖的http请求的连接参数设置是否相同。
  • 依赖第三方服务接口的异常返回码类型,及代码处理逻辑

A项目中有一个接口调用了主系统的注册接口,需要去了解,若注册接口调用失败而返回非200返回码,代码是否会进行重试,若重试依然失败,该接口最终的返回结果是什么?管理后台是否还有二次注册的接口?

avatar

在单接口异常测试执行时,只需要选择该接口对应的依赖服务进行测试就好。访问超时和丢包一般可以使用linux的tc命令来设置,服务挂掉一般通过改ip或端口来实现的,依赖第三方接口的异常返回码一般是用WireMock来模拟的。

2、web端异常测试

这里的web端异常测试,主要是指接口访问超时及返回异常返回码时的提示是否符合预期逻辑。

除了文字提示之外,一般通用的错误提示分为以下三种:toast(一段时间后自动消失)、错误页及alert(弹框提示)。

avatar

一般前端在开发时都会跟产品及交互定好每种异常情况下的文案规则,在UI测试阶段就对照这份规则来进行测试。下图就是A项目中页面初始化接口的文案规则:

avatar

有些异常情况只通过页面操作是不太好模拟,例如服务器异常、访问超时等等。一般UI测试是在接口测试完成之后才做的,异常返回码的模拟在接口测试阶段已经覆盖过,所以在UI测试阶段,推荐使用工具来进行异常返回码的模拟,而不需要进行复杂的后端操作来模拟,使用工具可以节省很多的时间。

windows的pc端推荐使用fiddler,这是一个http协议调试代理工具。在前端测试中,一般主要使用fiddler的2种功能,设置断点功能及请求自动重定向功能。下面简单介绍一下这两种功能,具体用法自行百度啊~~

1、设置断点
通过菜单栏“Rules/Automatic Breakpoints”给请求设置断点,可以选择Before Requests或After Responses。可以修改提交到服务器的数据信息(如:请求头或请求体等),也可以修改从服务器端返回的数据,还可以用来模拟请求超时。

2、请求自动重定向
这是fiddler最实用的功能,可通过自由设置规则,将符合条件的请求进行重定向,修改HTTP数据的特性。

3、业务操作异常测试

这部分一般是放在功能测试的后期,因为业务异常用例的设计需要对项目有一定的理解,是业务强相关的。
A项目是购买相关的,主要的业务操作异常集中在购买流程中,例如:购买时回退页面、支付超时、多人同时购买同一商品等等。一个人能想到的异常情况一般是有限的,所以在业务异常测试之前,测试人员可以先出一个大致的测试方案,然后跟开发同学一起开一个评审会,评估一下哪些异常测试用例是没有必要的,哪些是可能遗漏的,再对测试方案进行优化,保证测试的有效性。特别是对bug比较多的业务点要重点进行一些业务异常的测试,在进行bug发散的基础上,多分析和思考可能引起类似异常的操作。

以上是我个人在实践中总结出来的常见的功能测试中涉及的异常测试,服务端的异常测试涉及的内容比较多,就放到下篇文章中进行总结。不同的同学对异常测试的理解可能也不太一样,有疑问的地方欢迎大家一起多多交流和讨论~~~

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 13 条回复 时间 点赞
小敏 [该话题已被删除] 中提及了此贴 08月02日 20:09

写的挺棒,但是异常测试用的比较少,很少人会关注这方面的东西

busgade 回复

嗯,一般对质量要求比较高的项目才会去做。

你好,求问一下,上面有提到“依赖服务挂掉”的方法是改“ip/端口号”,是指比如A系统调用B系统,那么把A调用B系统的路径ip或者端口号写错,是这个意思吧?这样模拟出来的是不是404 notfund 能比较等同于服务挂掉的场景?

刘凯 回复

不好意思,回复晚了~~你的问题我是这样想得:
1、模拟服务挂掉,改host是其中一种方法,从我之前的实践来看,这种方式下程序会报错:java.net.ConnectException: Connection refused~
2、404是针对http服务,如果服务是数据库、redis的话,就肯定不会是404哈~
3、异常测试中,模拟依赖服务不可达,主要是为了看当前服务的容错处理,所以我就选择了最方便的一种,没太深究到底用哪种比较好~

小敏 [该话题已被删除] 中提及了此贴 12月27日 19:03
小敏 [该话题已被删除] 中提及了此贴 12月28日 15:17
小敏 2017,在跌跌撞撞中成长和蜕变 中提及了此贴 12月28日 16:25
小敏 异常测试实践与梳理 (下):服务端异常 中提及了此贴 12月28日 21:42

服务端异常在异常测试实践与梳理之服务端异常测试中介绍。

这个链接挂了

小敏 #11 · 2018年03月12日 作者

好的

提个建议,脑图有些乱,异常类型归异常类型,测试方法归测试方法。异常类型归类最好从异常原因去归类,而不是发生的地方。比如在单接口和web里面,都有接口传参的问题,这其实是一个异常。

另外异常测试其实就是为了考验系统的容错能力和恢复止血能力,这块篇幅几乎没有,不太过瘾。

学习了一个新的异常测试场景,依赖服务异常测试,楼主在异常测试领域挖得挺深,但确实归类有点凌乱,感觉大的分类上可以从前端UI和后端服务两个点进行切入,然后进一步细分

小敏 #14 · 2018年03月12日 作者
恒温 回复

嗯,了解,后期优化一下

小敏 #15 · 2018年03月12日 作者
许雯 回复

嗯嗯,功能异常里面确实有点乱

实际按B/S或C/S三层架构,共有的三层前端,服务,数据库,这种和开发实现架构来组织更好。各层有各层的异常情景和捕获手段工具。

小敏 #17 · 2018年03月13日 作者
小马 回复

后续重新梳理一下

simple 专栏文章:[精华帖] 社区历年精华帖分类归总 中提及了此贴 12月13日 14:44
simple [精彩盘点] TesterHome 社区 2018年 度精华帖 中提及了此贴 01月07日 12:08

变成你的小迷妹了,怎么办

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册