异常测试实践与梳理

原文链接：点击打开链接

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

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

1、单接口异常测试

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

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

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

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

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

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

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

2、web端异常测试

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

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

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

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

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

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

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

3、业务操作异常测试

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