酷客网可靠性测试介绍
可靠性测试的目的之一是监控软件成熟度在时间上的统计度量指标，并将其与既定目标比较。该度量指标可以选用平均失效间隔时间（Mean Time Between Failures，MTBF）、平均修复时间（Mean Time To Repair，MTTR）或其他失效强度度量（如每周特定的严重程度的失效数量），监控得到的值在时间上的分布可以表示为可靠性增长模型。
软件的可靠性和硬件的可靠性不同，软件产品不会运行一段时间后出现老化现象，也不会出现可靠性逐渐降低的情况。如图所示。
通常来说，如果软件开发人员不断修正软件中的错误，软件产品会随着时间的推移其可靠性会不断增强。如果因为软件的修复而带来更多的问题，则其可靠性可能出现反复震荡的情况。
可靠性测试可以有两种形式：重复进行预定测试和随机测试（可以从测试用例库中选择或由统计模型产生测试用例）。无论采用何种形式，都将非常耗时。
软件成熟度在时间上的度量指标分析可以作为出口准则（如何时发布产品），特定的度量指标，如MTBF和MTTR可以设立为服务水平协议并在实际系统运行中监控。可靠性测试基本上基于不同的使用模式（也称为“运行概况”）或风险状况执行的，可以使用随机或伪随机方法产生测试数据。
在可靠性测试过程中需要合理选择可靠性成长曲线，可以通过工具的支持分析一组故障数据，从而确定最切合现有有效数据的可靠性成长曲线。
可靠性测试可以专门针对内存泄漏，此类测试的规格说明要求重复地执行特定的内存存取行为，并保证占用的内存能够被正确地释放。
可靠性测试的另一个关注点是评估软件系统按照规定方式从软硬件故障中恢复至正常状态的能力，也称为“可恢复性测试”，又分为故障转移测试和备份/恢复测试。
如果软件故障可能引发严重后果，那么被测系统需要采取专门的软硬件措施以保障系统即使在出现故障时仍能运行，此时就需要执行故障转移测试。该测试适用于金融损失风险极高或存在关键安全隐患的情况，这种对于灾变性事件引发故障的可恢复性测试也被称为“灾难恢复”测试。
通过硬件方式也可以实现故障转移，典型的硬件措施包括平衡各个处理器负载、集群化服务器、处理器或硬盘，其他设备可以接管失效设备（如磁盘冗余阵列RAID）；典型的软件方面的措施则可在一个所谓的非相似冗余系统（Redundant dissimilar system）中实现多个独立软件系统实例（如航空飞行控制系统）。冗余系统一般结合了上述软件和硬件措施，根据独立实例的个数（2、3或4个）可以分别称为“二重”、“三重”或“四重”系统。软件非相似性的实现要求两个（或多个）互不相关的开发团队按相同的软件需求开发不同的软件来提供相同的服务，因而使非相似冗余系统在相似缺陷输入情况下不至于导致相同的后果。这些增强系统可恢复性的措施会直接影响其可靠性，应在可靠性测试中予以考虑。
故障转移测试模拟故障模式或将其在受控环境中执行。可以保证数据不至丢失或缺损且系统保持原有服务水平（如功能可用性和响应时间）。关于故障转移测试的更多信息，请访问www.testingstandards.co.uk。
备份/恢复测试以不同形式备份被测系统，并评估在数据丢失或缺损时恢复的（通常写入手册）过程。测试用例的设计要保证能够覆盖该过程的关键路经，可通过技术评审预想场景并针对实际的安装过程验证各类手册，运行验收测试（OAT）在产品环境或类似环境中实施以验证其实际效用。
备份/恢复测试的指标如下。
（1）完成各类备份（如全备份或增量备份）所需时间。
（2）恢复数据所需时间。
（3）承诺的数据恢复水平（如24小时内数据的恢复或1小时内恢复特定传输数据）。
软件可靠性工程测试
软件可靠性工程测试（Software-Reliability-Engineered Testing，SRET）是可靠性测试的系统方法，这种方法可以用于正在开发中的软件和商业离岸软件。它最初来自贝尔实验室，后来在业界被广泛使用。SRET过程主要包括5个活动，如图所示。
通常来说，SRET过程中的后面3个活动（准备测试用例、执行测试和分析失效数据）主要由系统测试人员完成，而定义可靠性和开发运行概况由系统工程师和架构师完成。注意最后的执行测试和分析失效数据是交替发生的，并不是串行关系。5个活动说明如下。
（1）定义必须的可靠性
针对每个系统，为了能够定义其必须的可靠性，必须完成3个具体的活动，即识别运行模式、定义系统失效和设定失效强度（failure-intensity，也译为“故障强度”）目标。
- 识别运行模式：运行模式代表系统的一组独特的行为，每种运行模式下系统的运行方式有所不同。例如，软件系统在工作和非工作时间的不同运行模式，系统在运行和待机状态的运行模式等。但是识别的运行模式越多，测试的工作量越大。
- 定义系统失效：此处需要分清缺陷和失效之间的关系，所有代码、系统和文档中都可能会存在缺陷，但是存在缺陷的系统并不一定会发生失效。只有当存在缺陷的代码被执行时，系统才可能无法执行期望的指令（或者执行不应该执行的指令），而引起软件失效。失效是软件缺陷的外部反映，根据失效影响的范围和程度不同，可以将其分成不同的等级。
- 设定失效强度目标：失效强度是单位执行时间内发生的失效次数，设定该目标要根据用户需要，可以为不同的运行模式设定不同的失效强度目标。
（2）开发运行概况
运行（Operation，有时也称为“操作”）是一个主要的系统逻辑任务，运行结束后将控制权返还给系统。运行可能是跨机器的，也可能是在非连续的时间段内执行。例如，在图书馆信息系统中，“借书”可以称为一个“运行”或者“操作”。运行概况是一组运行的集合及其发生的可能性。为了获得运行概况，首先需要识别运行的发起者，可以是用户、外部系统或被测试系统本身。然后分类每个发起者的运行，具体的分类可以参考系统需求规格说明、用户手册和工作流程文档等。最后判断每个运行发生的可能性，这个判断通常都有一定难度，可以从已经上线的相似系统的现场数据判断各个运行发生的可能性。运行概况的案例参见下表。
（3）准备测试用例
在准备测试用例过程中首先要估算测试用例的数目，估算时必须考虑不同运行模式的测试用例不同，当然也可能有些测试用例可以用于不同的运行模式。然后是编写测试用例，编写过程中应该参照上面识别出的多种运行及其发起者。最后准备测试规程规格说明，明确测试用例执行的顺序及其数量，测试规程规格说明必须参考各个运行的发生概率来安排测试执行。
（4）执行测试
按照测试规程规格说明执行测试，要及时报告测试过程中发现的失效，并根据组织对于失效等级的定义为报告的失效赋予正确的失效等级。应建立一个失效管理系统管理所有发现的失效，这样能够提高失效管理的效率。
（5）分析失效数据
根据失效数据计算出失效强度，并定期分析失效强度。对比实际的失效强度和计划中定义的失效强度目标，以判断系统的可靠性是否满足用户需要。
软件可靠性度量
可靠性是软件产品的一个重要质量特性，并且面向用户，它关注的是系统失效的频率。软件产品中的缺陷数目通常是未知的，尤其是在当今软件产品越来越复杂的情况下。为了更好地理解软件产品的可靠性，可以先从下面两个问题开始。
（1）最近发生的两个失效之间的时间间隔是多少？
（2）在一个特定的时间周期内发现了多少失效？
最近发生的两个失效之间的时间间隔越小，说明软件产品发生失效的频率越高，进而说明系统的可靠性越低。3 个常用的基于时间间隔的度量指标可以用于可靠性的度量，它们分别是平均无故障时间（Mean Time To Failure，MTTF）、平均修复时间MTTR和平均失效间隔时间MTBF。当失效发生后，需要占用一定的时间修复系统，所有失效的修复时间的平均值就是MTTR。假设系统在修复期间无法正常运行，从失效修复后系统再次正常运行起，到下一个失效发生的平均时间为MTTF。这3个度量指标之间的关系如图所示，可以表达为MTBF=MTTF+MTTR。从图中可以很容易地验证3者的关系。
在系统测试级别，通常在开始测试时发现的失效很多，连续两个失效之间的时间间隔很短，甚至只有几分钟。而随着系统测试的不断进行，很多发现的失效已经被修复，连续两个失效之间的时间间隔越来越长，这个时间间隔的增加就可以作为产品可靠性增强的证据。
在软件产品测试过程中，尤其是未发布之前的测试过程中会发现大量的失效，跟踪每个失效及连续的两个失效之间的时间间隔的工作量很大，而且从监控的角度也没有必要如此精确。这种情况下可以统计特定时间间隔内的失效数量，将这些特定时间间隔内发现的缺陷数目进行比较也可以判断产品的可靠性。例如，在系统测试时可以统计每周发现的失效，在系统测试的后期每周发现的缺陷数目通常会比高峰时期少很多，这也能够证明系统的可靠性在增强。此时可以采用失效强度分析和评估可靠性，失效强度是指单位时间内发现的失效的数目，这里的单位时间可以是CPU的运行时间或测试人员的工作时间。
在测试过程中由于在不同时期运行的测试用例不同，发现的失效的分布也可能有所不同。虽然在系统测试的末期单位时间发现的缺陷比较少，除了系统可靠性提高以外，也可能是因为执行的系统测试用例不容易发现缺陷所致。系统测试开始时，测试人员首先执行基本的功能测试，每天执行的测试用例数比较多，而且容易发现问题。到了系统测试后期，可能会执行一些效率测试等非功能测试。这时每个测试用例的执行时间比较长，导致单位时间发现的缺陷很少；另一个原因可能是在系统测试后期执行回归测试的测试用例，从而导致单位时间内发现的缺陷数目减少。为了更好地获得系统的可靠性数据，在测试可靠性过程中需要定义运行概况（参见软件可靠性工程测试）。在同样运行概况下得到的可靠性数据更加具有可比性，也能更准确地反映产品的信息。
酷客教程相关文章：
评论前必须登录！
注册