异常场景测试

什么是异常测试？

异常测试是有别于功能测试和性能测试的又一种测试类型，通过异常测试，可以发现由于系统异常、依赖服务异常、应用本身异常等原因引起的系统问题，可以帮助我们改善以后的设计方案，提高系统的稳定性。

为什么要做异常测试？

常规的功能测试过程中，主要关注的是业务的正常逻辑是否能够走通，以及在正常逻辑多并发运行过程中是否有潜在的性能问题，往往忽视了各种异常情况对服务造成的影响。随着产品规模的扩大以及业务的不断迭代，我们无法预料每个应用可能出现的异常情况。所以在测试过程中不但要关注正向测试也需要关注异常场景测试。

如何展开异常测试？

从异常测试的定义来看，想要开展异常测试，首先需要知道怎么去设计异常用例，应该使用哪些测试方法来模拟异常场景？接下来我将以保卖业务为例从接口异常和业务操作异常两个维度进行具体的介绍。

一、接口异常测试

接口异常测试可能会与业务操作异常有部分重叠，但个人觉得接口异常测试放在接口测试阶段比较合适，并且接口异常测试可以为后续业务操作异常测试做铺垫。

• 整体流程：了解产品需求，分析需求特点-》了解接口实现逻辑-》设计接口用例-》确定测试方法

• 关注重点：依赖服务调用异常和输入异常时，业务代码能否容错及容错逻辑是否合理。

• 测试内容：主要包括输入异常、操作异常、服务异常等。

• 接口类型：http 接口、scf 接口

1、http 接口测试

保卖回收估价平台为后台系统，存在很多新增、删除、修改模板等操作，业务逻辑会要求在新增修改等操作时不允许为空或重复等校验，一般像这类操作前端和后端都会做校验，单纯从页面只能测试前端校验逻辑是否正确，无法测试后端校验是否正确，通过 http 接口测试就可以覆盖到后端的校验逻辑。所以基于业务逻辑在进行接口测试时会重点关注以下异常情况，其中主要包括：

• 重复和非空校验：名称重复、必填项字段为空等

• 异常参数：参数不完整、参数重复等

• 异常查询：缺少分页信息、缺少品类 id\型号 id 等

• 数值校验：设置参数为非数值类型、包含特殊字符等

测试工具主要使用 Yapi 平台：在设计接口 case 时通过异常参数的传参，可以清楚的验证异常场景下接口的返回值。

2、scf 接口测试

在测试保卖订单流程时，会重点关注订单状态的流转。以参拍接口为例，为避免出现超卖，会针对接口进行并发测试，来校验后端在参拍时是否对回收单状态进行了校验。

测试方式：使用注解的方式对 TestNg 线程池和执行次数进行配置

invocationCount：表示执行的次数

threadPoolSize：表示线程池内线程的个数

二、业务操作异常测试

业务操作异常测试一般是放在功能测试的后期，因为业务异常用例的设计需要对项目有一定的理解，是业务强相关的。整体流程主要分为以下四步：

结合业务需求，确定业务重点-》了解开发实现逻辑-》设计异常场景用例-》确定测试方法

1、基于业务的异常场景测试

以保卖估价器业务为例，估计器系统为后台操作系统，每个模块都存在新增、编辑、删除等功能，映射逻辑的上传都是通过导入 excel 的方式。所以在测试期间会重点关注页面异常操作和 excel 上传异常。

（1）页面异常操作

• 思路：由于在接口测试阶段已经将对应模块的接口异常 case 覆盖到，所以在功能测试阶段只需要重点关注页面层面的异常操作。

• 异常测试点：提交时快速多次点击、频繁添加/删除

• 测试方法：主要通过页面频繁操作对系统并发情况进行验证

（2）excel 上传

• 思路：了解对应上传功能校验逻辑，针对校验逻辑设计异常 case

• 异常测试点：上传内容包含特殊字符、文件格式不正确、非空校验、最大条数限制、表头顺序是否一致、业务内部逻辑

• 测试方法：主要通过修改上传的 excel 文件中的内容，来模拟异常数据的上传

2、通用性异常场景测试

（1）幂等校验

• 消息重发：目前很多提交都是异步提交，如短信发送，一般点击发送就会提示发送成功。但实际是否发送成功，后续会有系列处理机制，根据消息的一些本身机制，后续处理过程中会进行重发机制。

  测试方法：可在终端最后一步，或中间环节人为触发多次发送。如：在消息队列中重发，多次补收同一内容的报文等。

• 业务间的重试：有些业务特意设置在连接超时或者失败时需重试，这时候就需要验证幂等性处理。

   测试方法：可以通过模拟网络连接超时或服务超时等触发重发机制。

（2）缓存测试

为提升效率，很多系统应用了缓存机制，那么对于缓存测试以下三点在测试过程中需重点关注。

• DB 同步性： 如对商品重要属性进行了新增、编辑（价格、库存等重要信息）、删除时，如果应用了缓存机制，那测试过程中就需要关注 DB 的修改是否同步到缓存中、数据库的字段进行更新缓存中的存储结构是否进行更新等。

  测试方法：

  ①了解缓存内容，对数据进行操作，操作后缓存相应展示页面查看

  ②如数据库结构发生变化，需测试缓存中数据的存储

• 缓存失效性：有些关键数据放缓存中是有失效性的，需根据具体业务去了解相关失效性，还是永远存储。

  测试方法：根据业务关键性数据的缓存设置时间来测试业务的失效性。

• 缓存异常时系统处理：缓存溢出或丢失时，系统的业务是否能正常处理。一般的处理逻辑：重试机制、数据获取切换到 DB。总之，不能因缓存异常，影响业务。

  测试方法：模拟缓存溢出

3、与第三方交互

与第三方的交互一般都是 mq 交互或服务调用，所以在测试过程中会重点关注幂等校验以及服务调用超时的情况。

测试方法：

• 重复发送 mq

• 使用 Yapi 平台对接口进行 mock 、修改服务超时响应时间、模拟第三方服务返回异常

总结与展望

整体来说前期的接口测试，测试过程中的功能测试，测试后期的异常测试基本可以组成一个完整的测试方案，覆盖整个测试周期。

未来我们还会继续探索新的测试方法，持续完善测试方案，做好质量把控的最后一道关。

作者：洪渺

转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。

关注公众号「转转技术」（综合性）、「大转转 FE」（专注于 FE）、「转转 QA」（专注于 QA），更多干货实践，欢迎交流分享~