不容忽视的软件可恢复测试(转)

上一篇 / 下一篇  2008-12-18 16:01:19 / 个人分类:Testing

随着软件系统应用环境的复杂性,软件出错的机率越来越大了,软件面临着一个非常关键的需求就是在系统出错后能进行恢复。我是公司软件开发测试组负责人,今天老板在测试会议上批评我说,目前用户最大的抱怨是我们的系统缺少自动恢复功能,出现错误后许多的恢复过程都要人工干预来完成,说明我们的可恢复测试仍然很混乱,而且可恢复测试是完全失败的。

  不容忽视的软件可恢复测试

  (1)什么是软件可恢复性

  随着软件应用的日益普及,对软件质量的要求也不断提高。软件质量是指软件产品中能满足给定需求的各种特性的总和。ISO/IEC 9126中规定了软件的6个质量特性,即功能性(Functionality)、可靠性(Reliability)、易用性(Usability)、效率性(Efficiency)、维护性(Maintainability)和可移植性(Portability),每个特性包含若干子特性。

  可靠性是指在规定的一段时间和条件下,软件产品维持规定的性能水平的能力。3个子特性分别为:成熟性(Maturity)、容错性(Fault tolerance)、可恢复性(Recoverability)。其中容错性是指与在软件错误或违反指定接口的情况下,维持指定的性能水平的能力有关的软件属性。而可恢复性是指在故障发生后,重新建立其性能水平并恢复直接受影响数据的能力,以及为达到此目的所需的时间和努力有关的软件属性。

  一般来说,许多基于计算机的软件系统必须在一定的时间内从错误中恢复过来,然后继续运行。也就是说在某些情况下,一个软件系统应该是在运行过程中的出现错误时能自动或人工进行恢复,不能使整个系统的功能都停止运作,否则就会造成严重损失。因此,软件可恢复失败包括两个方面:一是软件系统没有自动的恢复到原来的性能,这意味着恢复需要人工干预;二是即使是人工干预后,也不能恢复到原来设计性能,例如软件所涉及的数据出现某种程度的失效和损坏。

  (2)什么是可恢复测试

  软件测试是发现软件中的大部分缺陷的一种技术。软件测试大体上划分为三大阶段:单元测试、集成测试、系统测试。系统测试是检验整个系统是否满足《需求规格说明书》所提出的所有需求。其中系统测试的非功能性测试包括可靠性测试、容错测试和恢复性测试等。

  可恢复测试(Recovery testing)是测试一个系统从灾难或出错中能否很好地恢复的过程,如遇到系统崩溃、硬件损坏或其他灾难性出错。可恢复测试一般是通过人为的各种强制性手段让软件或硬件出现故障,然后检测系统是否能正确的恢复(自动恢复和人工恢复)。简单的说,可恢复测试是一种对抗性的测试过程。在测试中将把应用程序或系统置于极端的条件下或是模拟的极端条件下产生故障,然后调用恢复进程,并监测、检查和核实应用程序和数据能否得到正确的恢复。

  可恢复测试通常需要关注恢复所需的时间以及恢复的程度。例如,当系统出错时能否在指定时间间隔内修正错误并重新启动系统。对于自动恢复需验证重新初始化(Reinitialization)、检查点(Checkpointing mechanisms)、数据恢复(Data recovery)和重新启动(Restart)等机制的正确性;而对于需要人工干预的恢复系统,还需估计平均修复时间,确定其是否在可接受的范围内。

  因此,随着网络应用、电子商务、电子政务越来越普及,系统可恢复性也显得越来越重要,可恢复性对系统的稳定性、可靠性影响很大。但可恢复性测试很容易被忽视,因为可恢复测试相对来说是比较难的,一般情况下是很难设想得出来让系统出错和发生灾难性的错误,这需要足够的时间和精力,也需要得到更多的设计人员、开发人员的参与。

  (3)容错测试与可恢复测试的区别

  容错测试一般是输入异常数据或进行异常操作,以检验系统的保护性。如果系统的容错性好的话,系统会给出提示或内部消化掉,而不会导致系统出错甚至崩溃。而可恢复测试是通过各种手段,让软件强制性地发生故障,然后验证系统已保存的用户数据是否丢失、系统和数据是否能很快恢复。因此,可恢复测试和容错测试是互补的关系,可恢复测试也是检查系统的容错能力的方法之一,但不能只重视其中之一。

  (4)故障转移测试和可恢复测试的关系

  故障转移测试(Failover)指当主机软硬件发生灾难时候,备份机器是否能够正常启动,使系统可以正常运行,这对于电信,银行等领域的软件是十分重要的。因此,故障转移是确保测试对象在出现故障时,能成功地将运行的系统或系统某一关键部分转移到其它设备上继续运行,即备用系统将不失时机地顶替发生故障的系统,以避免丢失任何数据或事务,不影响用户的使用。

  故障转移测试和可恢复测试也是一种互补关系的测试,它们共同可确保测试对象能成功完成故障转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。因此,他们两者的关系一个是测试备用系统能否及时工作,另一个是测试系统能否恢复到正确运行状态。

可恢复测试主要内容和步骤

  (1)恢复性测试的基本内容

  通过可恢复测试,一方面使系统具有异常情况的抵抗能力,另一方面使系统测试质量可控制。因此,可恢复测试包括以下几种情况:

  硬件及有关设备故障。测试对于硬件及设备故障是否有有效的保护及恢复能力,系统是否具有诊断、故障报告及指示处理方法的能力,是否具备冗余及自动切换能力,故障诊断方法是否合理和即时。例如,设备掉电后(如客户端和服务器端断电)的可恢复程度。

  软件系统故障。测试系统的程序及数据是否有足够可靠的备份措施,在系统遭破坏后是否具有重新恢复正常工作的能力,对系统故障是否自动检测和诊断的功能。故障发生时,是否能对操作人员发出完整的提示信息和指示处理方法能力,是否具有自动隔离局部故障,进行系统重组和降级使用使系统不中断运行。还有,若系统局部故障可否进行占线维护,而不中断系统的运行。最后,在异常情况时是否记录故障前后的状态,搜集有用信息供测试分析。

  数据故障。是测试数据处理周期未完成时的恢复程度,例如数据交换或同步进程被中断,异常终止或提前终止的数据库进程,最后还有操作异常等情况。

  通信故障和错误。测试有没有纠正通信传输错误的措施,有没有恢复到与其他系统通信发生故障前原状的措施,还有对通信故障所采取的措施是否满足运行要求等。

  (2)可恢复测试的基本流程

  首先需要制定可恢复测试计划,并准备好可恢复测试用例和可恢复测试规程。其次,是要对照基线化软件等级和基线化需求分配。第三,进行软件可恢复测试。在此过程中,要用文档记录好在可恢复性测试期间所出现的问题并跟踪直到结束。然后,将可恢复测试结果写成文档,说明测试所揭露的软件软件能力、缺陷和不足,以及可能给软件运行带来的影响。最后,说明能否通过测试和测试结论,并提交可恢复测试分析报告。

  可恢复测试经验总结与分享

  从测试技术和测试管理的角度来看,目前对高可靠性软件测试特别是可恢复测试方案,许多测试人员还缺乏真正的认识。因此,对需要高可恢复的软件如何实施可恢复测试,在技术和经验上仍是一个颇不成熟的领域,更缺少一种体系化的方法。

  (1)必须从认识上有足够的重视和关注

  让人非常遗憾的是在可恢复测试上,许多测试人员还缺乏足够的重视和关注。例如,许多测试人员认为只要我们有制定可恢复测试方案,有获得所需的硬件和软件,配置了系统,然后也有测试故障转移和灾难恢复响应系统,一切按照预期计划进行就OK了。但是大多数的测试人员只会在常规环境下进行可恢复测试,并没有想尽一切可能的办法在更多的不同环境下的进行可恢复测试,结果是他们并没有确保自己进行了足够的可恢复测试。

  (2)必须制定明确的测试计划和测试制度

  如果没有制定明确的测试计划和需要遵循的测试制度,那么测试就会马虎了事,根本无法满足可恢复测试的要求。那么完成测试目标也成了空中楼阁,软件可恢复性质量也无从谈起了。

  (3)必须要用真实数据进行测试

  用真实数据进行真实测试是可恢复测试中最棘手的部份。因为在没有用真实数据测试的时候,就很难评价系统进行可恢复或故障转移过程中的各种技术指标的有效性。我在可恢复测试中得到的宝贵经验是,用真实数据进行测试会得到让人难以接受的事实,但这是提高软件测试质量的关键之一。

  (4)确保测试过程和文档的一致性

  软件可恢复测试工作还包括:验证应用程序不同环境下的表现、书面需求分析文档、联机帮助、界面资源等。因此,当进行可恢复测试活动时,应确保测试手册、联机帮助、测试分析报告和应用程序测试需求的完整性和一致性。


TAG: Testing

引用 删除 dhyxmm   /   2009-01-21 11:11:17
看来在以后的测试过程得关注这方面的测试,顶一下!
 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

日历

« 2021-01-23  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 3411
  • 日志数: 16
  • 建立时间: 2008-09-10
  • 更新时间: 2010-03-31

RSS订阅

Open Toolbar