，是指通过人为制造异常，检测系统的处理是否符合逻辑。结合在A项目中的实践，梳理一下常见异常测试的类型、关注点及常用测试工具等。
A项目是一个典型的后端+后台的项目，主要的业务是订购帐号及注册帐号。从实践来讲，我认为一个项目的异常测试基本可以分为2大类：功能异常及服务端异常，功能异常根据先后执行次序通常可以分为3种：单插口异常、web端异常及业务操作异常。下面来介绍一下功能异常，服务端异常在异常测试实践与梳理之服务端异常测试中介绍。
1、单插口异常测试
单插口异常测试主要的关注点是依赖服务调用异常时，业务代码能够容错及容错逻辑是否合理。
单插口异常测试通常也可以放在服务端异常测试阶段来做，但这个阶段常规早已做完，再回过头来对每位插口进行异常测试，还须要花一定时间去重新熟悉插口业务，且该阶段关注的重点是后台整体的异常，需要覆盖的异常点好多，从时间上来说通常会比较紧。所以，个人认为单插口异常测试置于阶段比较合适，并且单插口异常测试可以为服务端异常测试做铺垫，把插口依赖剖析都完成了。
单插口异常测试，主要包括输入异常、操作异常、依赖服务异常等，具体要视插口情况而定。输入异常及操作异常通常在接口测试时还会涉及，而依赖服务异常不一定。如果项目对可靠性要求比较高的话，且时间容许情况下，还是要争取覆盖一下。
在A项目的单插口异常中，依赖服务异常是重点。在执行测试之前，需要做一些打算工作。
·分析插口所有依赖的服务（需要咨询开发，或对业务和代码熟悉的可以直接看代码来了解） A项目中所有插口的依赖服务主要包括主系统（调用注册服务）、()、缓存(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发散的基础上，多剖析和思索可能导致类似异常的操作。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立刻处理
