故障测试

近期所在项目把故障测试作为这两个迭代的重点内容，于是乎作为新入行菜鸟的我不得不承担起设计故障测试用例这个让人头大的任务。个人认为要做好故障测试（此处主要讨论网络服务相关的故障测试），必须具备以下两个条件：一是对被测系统（系统的架构、环境部署、功能、业务逻辑等）非常熟悉，二是具备深厚的计算机及网络相关背景知识。恰好，目前我在这两方面都还很欠缺，因此接到任务时深感压力山大。

    通过和组内同学及开发人员的讨论，初步明确了故障测试的思路和方向，现整理出来和大家分享一下：

    首先，故障测试可以大致分为两大类：业务逻辑相关故障、服务器相关故障。这样的分类不一定准确，因为很多业务逻辑方面的错误是由服务器故障引起的。水平所限，先勉强这样分类吧。。。

    业务逻辑相关的故障主要考虑：

A、 各模块依赖的下层模块发生故障

B、 数据库相关故障

C、 各子模块的高可用

  服务器相关的故障则比较复杂多样：

A、 服务器关机、重启

B、 进程被kill、进程僵死无响应

C、 CPU、内存

D、 断网、网络异常（带宽满、DNS异常、丢包率高等）

E、  磁盘异常（IO高、磁盘挂掉、磁盘满、磁盘不可写/读）

  其中CPU、内存、网络异常、磁盘IO高等也属于系统性能瓶颈问题，放在这里可能有点牵强，但是本人认为也算是被测系统的异常情况。

  其次呢，需要考虑一下各种故障如何模拟。在服务器资源紧张的情况下，可以利用云计算项目的云主机作为测试机，云主机可以轻松实现服务器断电、重启、断网等场景，是做故障测试的理想工具（当然，云主机本身不能有太多bug）。因此，可以利用云主机来方便的模拟服务器关机重启、断网等服务器异常情况，而各模块依赖的下层模块发生故障的情况可以考虑用mock的方式模拟。

  最后，本人认为故障测试有两个重点方面需要关注：各模块故障恢复后能否正常提供服务，故障发生及恢复后的资源回收、清理是否彻底。

  好了，啰嗦了一堆，方向算是基本定了，不过具体设计测试用例还是得具体情况具体分析。在整理这篇博客的时候，我的故障测试用例算是已经定稿了，接下来的测试执行才是真正的挑战

 

转：http://qa.blog.163.com/blog/static/190147002201311765946487/