如何缺陷预防提高软件的可靠性

         为什么在实验室测试完成后，在用户处总会出一些难重现古怪的问题，测试人员会困惑按需求进行了完整测试可为什么还会出现这些小概率的问题？究其原因，有多种根因导致软件在用户处会出现一些难重现的古怪问题（我需要另写一篇文章来分析和整理）。本文重点阐述其中一种常见根因——软件可靠性测试不足51Testing软件测试网{|qw.f C};I.IX

我先来介绍下常见软件可靠性测试的几个阶段：

1.0阶段：基于个人经验的发散异常测试——测试过程和结果随机，难管理，遗漏也很多51Testing软件测试网v'kvZ?

2.0阶段：使用压力测试来发现系统抗压的可靠性问题——物料和时间成本高

3.0阶段：基于用户应用反馈回来的问题逐个亡羊补牢——被动等待，产品稳定周期长

4.0阶段：基于失效模式的系统故障注入测试——针对关键模块提早进行容错测试发现软件系统可靠性实现的不足之处。

 51Testing软件测试网o$l+P#Eyewj3gXK

   前3种阶段应该是目前中国大部分企业的主流做法，这些方法对测试技术的储备和门槛要求较低，所以容易开展。但不足之处上面已谈到了：测试过程和结果缺乏确定性，物料成本高，测试时间（重现时间和定位时间）成本高，产品稳定周期长，还是会遗漏一些可靠性相关的问题到用户处。

显然问题所在的地方就是测试技术研究应该关注和投入的地方。因此经过业界的努力有了软件可靠性测试的4.0阶段：基于失效模式的系统的故障注入测试。51Testing软件测试网'i0X;PZ*[B#O6M

 51Testing软件测试网"P+`LH"T%hb

基于失效模式的系统的故障注入测试的好处：

——测试过程和结果具有确定性，可重复性

——几乎不增加物料，问题触发时间，重现时间和定位时间非常短

——主动尽早发现可靠性不足风险，实现尽早缺陷预防，缩短产品稳定周期

 51Testing软件测试网'} eb)JuLRjV1_

基于失效模式的系统故障注入的测试分类：51Testing软件测试网"b/YH.M }Pt!y3Jg

——网络传输层故障场景  （impossible or often ?）

——硬件平台故障场景                  （impossible or often ?）51Testing软件测试网3x;b sf_k

——运行软件平台故障场景         （impossible or often ?）51Testing软件测试网 i-W[&L'r+p0b

——人因差错故障场景    （impossible or often ?）51Testing软件测试网%}'`3B$JHG/l

在互联网时代任何软件只有对以上4个纬度的故障场景都进行了适度（对确实可能发生的失效模式）的可靠性实现，才算有了系统的可靠性保障，否则被动等待和大量亡羊补牢工作会等着大家。

 目前在网络传输层故障场景有比较完善系统的测试框架：网络中断；网络抖动（闪断）；丢包；数据包乱序是常见测试方案。

而人因差错故障场景因为不同软件用户的使用方式不同，所以难统一抽象。但还是可以借用场景分析法对每个用户场景进行分支路径和异常路径的发散分析，提前提取出用户可能的操作故障场景。

硬件平台故障场景：对于软件而言，硬件平台就是运行软件的CPU所在的硬件载体。最小抽象的硬件故障场景有：硬件平台断电；硬件部件不可用；硬件部件不稳定；51Testing软件测试网KXbl8B.i8E/T/H _'f

运行软件平台故障场景：软件所运行的驱动层、操作系统层或中间层软件。软件要正常运转需要通过调用运行平台所提供的资源接口API，然后运行平台也会有返回非成功值的场景，返回边界值的场景——而这是最容易被遗忘和最难测试实现的。如果软件对这些非日常场景（日常场景大部分都是返回正确值或中间值）没有对应的处理代码，则软件的可靠性就要大打折扣。51Testing软件测试网_hi|po&h

  想减少用户现场难重现的问题数，想减少可靠性测试成本，想缩短发现软件可靠性缺陷的时间，就尽早在组织中实践：软件可靠性测试4.0阶段——基于失效模式的系统的故障注入测试。51Testing软件测试网}1p-KY f0B

   在我新浪微博http://weibo.com/dongjietest中分享的如何导致Google浏览器、Firefox浏览器、百度浏览器、QQ客户端、360浏览器、百度影音播放器、阿里旺旺等软件崩溃的测试技术原理就是基于失效模式的系统的故障注入测试之运行软件平台故障场景，证明某些软件在这个区域的测试还需要继续完善。

 51Testing软件测试网l0QQA)Mx3zo

   任何意见欢迎邮件交流：                         dongjietest@163.com