|
|
知识路径： > 测试技术的分类 > 可靠性测试 > 软件可靠性测试 >
|
|
相关知识点：4个
|
|
|
|
|
在进行应用软件的可靠性测试前有必要检查软件需求与设计文档是否一致，检查软件开发过程中形成的文档的准确性、完整性以及与程序的一致性，检查所交付程序和数据以及相应的软件支持环境是否符合要求。
|
|
|
|
这些检查虽然增加了工作量，但对于在测试早期发现错误和提高软件的质量是非常必要的。
|
|
|
|
软件可靠性测试必须是受控测试，在运行此类测试时，为了保证统计数据的有效性，测试过程中的每个测试用例必须施加于相同的软件版本，新的软件版本意味着新测试的开始。
|
|
|
|
在有些情况下，不能进行纯粹的可靠性测试。因为客户的要求、合同的规定或者标准的约束，需要补充其他形式的非统计测试。这时的最佳选择是既执行可靠性测试，也执行非统计测试（如覆盖测试）。如果非统计测试在可靠性测试之前完成，由统计测试产生的统计数据仍然有效。但是在可靠性测试之后执行非统计测试，可能会影响软件可靠性评估的准确性。
|
|
|
|
软件可靠性测试同样依赖于软件的可测试性。可靠性测试难点就在于判断测试用例的运行是成功还是失败。在控制系统及类似的软件中，失效由详细说明、时间（通常是CPU时间或时钟时间）来客观地定义。而在一般应用系统中，失效的定义更主观些，它不仅依赖于程序是否符合规格说明的要求，也取决于指定的性能是否能够达到用户的期望，但是否达到期望没有确定的标准。在一些科学计算中，计算结果只能由计算机给出，在这种情况下，如果软件只是输出了错误的结果而不是整个系统发生失效，错误就不可能被发现。此时可以将测试分成两个阶段进行。第一阶段运行较少量的测试用例，并对照规范进行仔细检查。第二阶段再运行大量测试用例。第二阶段不用人工检查输出的每项内容，而是找失效现象，包括错误信息、断电、崩溃和死机。也可把输出记录到文件中，采用搜索或过滤方法进行处理。如果软件有足够的可测试性，这种方法不会漏掉很多的严重失效。如果计算的正确性无法验证，就需要对软件进行一些形式化的证明。
|
|
|
|
开发方交付的任何软件文档中与可靠性质量特性有关的部分、程序以及数据都应当按照需求说明和质量需求进行测试。在项目合同、需求说明书和用户文档中规定的所有配置情况下，程序和数据都必须进行测试。
|
|
|
|
软件可靠性数据是可靠性评价的基础。为了获得更多的可靠性数据，应该使用多台计算机同时运行软件，以增加累计运行时间。应该建立软件错误报告、分析与纠正措施系统。按照相关标准的要求，制定和实施软件错误报告和可靠性数据收集、保存、分析和处理的规程，完整、准确地记录软件测试阶段的软件错误报告和收集可靠性数据。
|
|
|
|
用时间定义的软件可靠性数据可以分为4类，具体如下。
|
|
|
|
. 失效时间数据，记录发生一次失效所累积经历的时间；
|
|
|
|
. 失效间隔时间数据，记录本次失效与上一次失效间的间隔时间；
|
|
|
|
. 分组时间内的失效数，记录某个时间区内发生了多少次失效；
|
|
|
|
. 分组时间的累积失效数，记录到某个区间的累积失效数。
|
|
|
|
|
|
在测试过程中必须真实地进行记录，每个测试记录必须包含如下信息。
|
|
|
|
|
|
|
|
|
|
|
|
测试活动结束后要编写《软件可靠性测试报告》，对测试用例及测试结果在测试报告中加以总结归纳。编写时可以参考GJB 438A-97中提供的《软件测试报告》格式，并应根据情况进行剪裁。测试报告应具备如下内容。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
把可靠性测试过程进行规范化，有利于获得真实有效的数据，为最终得到客观的可靠性评价结果奠定基础。
|
|
|
|
对于软件可靠性测试用例的设计，有关更详细的内容可以参照本书中“黑盒测试用例设计”部分。
|
|
|
