可恢复测试.doc

不容忽视的软件可恢复测试（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）确保测试过程和文档的一致性软件可恢复测试工作还包括：验证应用程序不同环境下的表现、书面需求分析文档、联机帮助、界面资源等。因此，当进行可恢复测试活动时，应确保测试手册、联机帮助、测试分析报告和应用程序测试需求的完整性和一致性。您的位置： 首页 文章精选 软件测试技术 其他相关 查看资讯 窗体顶端搜索 窗体底端最新更新谈软件测试 如何实施Build验证测试 黑盒白盒的对比 回归测试漫谈 自动化测试基本策略 QTP加载外部文件函数，. RFT 测试框架的核心(图) 测试的基本认识 全面系统测试模型 针对Web程序的MUI测试 优秀博文软件测试的最高境界 论测试工作的选择 Loadrunner中web_reg_s. 深入手工测试 一个测试架构师的blog 让测试敏捷起来【段念】 自动化测试框架模型(图) 缺陷管理工具之一J. Web 测试总结(2) 论坛热帖北京性能测试职位（5k-. 【无锡招聘】数名中高级. 跪求参数化问题 【上海】招聘Automatio. 头文件和函数文件的使用. LR中的SQL Server性能计. LR测试EJB接口问题 报错的描述是什么意思 故障转移和恢复测试发布时间: 2008-10-17 17:59 作者: 未知 来源: 网络转载字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿 | 每周一问，答贴有奖 故障转移和恢复测试可确保测试对象能成功完成故障转移，并从硬件、软件或网络等方面的各种故障中进行恢复，这些故障导致数据意外丢失或破坏了数据的完整性。故障转移测试可确保：对于必须始终保持运行状态的系统来说，如果发生了故障，那么备选或备份的系统就适当地将发生故障的系统“接管”过来，而且不会丢失任何数据或事务。恢复测试是一种相反的测试流程。其中，将应用程序或系统置于极端的条件下（或者是模仿的极端条件下），以产生故障，例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字。启用恢复流程后，将监测和检查应用程序和系统，以核实应用程序或系统是正确无误的，或数据已得到了恢复。测试目标：确保恢复进程（手工或自动）将数据库、应用程序和系统正确地恢复到了预期的已知状态。测试中将包括以下各种情况：1、客户机断电2、服务器断电3、通过网络服务器产生的通信中断4、DASD 和/或 DASD 控制器被中断、断电或与 DASD 和/或DASD 控制器的通信中断5、周期未完成（数据过滤进程被中断，数据同步进程被中断）。6、数据库指针或关键字无效7、数据库中的数据元素无效或遭到破坏测试方法：应该使用为功能和业务周期测试创建的测试来创建一系列的事务。一旦达到预期的测试起点，就应该分别执行或模拟以下操作：1、客户机断电：关闭 PC 的电源。2、服务器断电：模拟或启动服务器的断电过程。3、通过网络服务器产生的中断：模拟或启动网络的通信中断（实际断开通信线路的连接或关闭网络服务器或路由器的电源）。4、DASD 和 DASD 控制器被中断、断电或与 DASD 和DASD 控制器的通信中断：模拟与一个或多个 DASD 控制器或设备的通信，或实际取消这种通信。一旦实现了上述情况（或模拟情况），就应该执行其他事务。而且一旦达到第二个测试点状态，就应调用恢复过程。在测试不完整的周期时，所使用的方法与上述方法相同，只不过应异常终止或提前终止数据库进程本身。对以下情况的测试需要达到一个已知的数据库状态。当破坏若干个数据库字段、指针和关键字时，应该以手工方式在数据库中（通过数据库工具）直接进行。其他事务应该通过使用“应用程序功能测试”和“业务周期测试”中的测试来执行，并且应执行完整的