[
目前，对于软件的功能性测试主要针对每种功能设计若干典型测试用例，软件测试过程中运行测试用例，然后将得到的结果与已知标准答案进行比较。所以，测试用例集的全面性、典型性和权威性是功能性评价的关键。
3.2 可靠性指标
根据相关的软件测试与评估要求，可靠性可以细化为成熟性、稳定性、易恢复性等。对于软件的可靠性评价主要采用定量评价方法。即选择合适的可靠性度量因子（可靠性参数），然后分析可靠性数据而得到参数具体值，最后进行评价。
经过对软件可靠性细化分解并参照研制任务书，可以得到软件的可靠性度量因子（可靠性参数）。
a.可用度
可用度指软件运行后在任一随机时刻需要执行规定任务或完成规定功能时，软件处于可使用状态的概率。可用度是对应用软件可靠性的综合（即综合各种运行环境以及完成各种任务和功能）度量。
b.初期故障率
初期故障率指软件在初期故障期（一般以软件交付给用户后的三个月内为初期故障期）内单位时间的故障数。一般以每100小时的故障数为单位。可以用它来评价交付使用的软件质量与预测什么时候软件可靠性基本稳定。初期故障率的大小取决于软件设计水平、检查项目数、软件规模、软件调试彻底与否等因素。
c.偶然故障率
指软件在偶然故障期（一般以软件交付给用户后的四个月以后为偶然故障期）内单位时间的故障数。一般以每1000小时的故障数为单位，它反映了软件处于稳定状态下的质量。
d.平均失效前时间（MTTF）
指软件在失效前正常工作的平均统计时间。
e.平均失效间隔时间（MTBF）
指软件在相继两次失效之间正常工作的平均统计时间。在实际使用时，MTBF通常是指当n很大时，系统第n次失效与第n+1次失效之间的平均统计时间。对于失效率为常数和系统恢复正常时间很短的情况下，MTBF与MTTF几乎是相等的。
国外一般民用软件的MTBF大体在1000小时左右。对于可靠性要求高的软件，则要求在1000~10000小时之间。
f.缺陷密度（FD）
指软件单位源代码中隐藏的缺陷数量。通常以每千行无注解源代码为一个单位。一般情况下，可以根据同类软件系统的早期版本估计FD的具体值。如果没有早期版本信息，也可以按照通常的统计结果来估计。“典型的统计表明，在开发阶段，平均每千行源代码有50~60个缺陷，交付后平均每千行源代码有15~18个缺陷”。
g.平均失效恢复时间（MTTR）
指软件失效后恢复正常工作所需的平均统计时间。对于软件，其失效恢复时间为排除故障或系统重新启动所用的时间，而不是对软件本身进行修改的时间（因软件已经固化在机器内，修改软件势必涉及重新固化问题，而这个过程的时间是无法确定的）。
3.3 易用性指标
易用性可以细化为易理解性、易学习性和易操作性等。这三个特征主要是针对用户而言的。对软件的易用性评价主要采用定性评价方法。
a.易理解性
易理解性是与用户认识软件的逻辑概念及其应用范围所花的努力有关的软件属性。该特征要求软件研制过程中形成的所有文档语言简练、前后一致、易于理解以及语句无歧义。
b.易学习性
易学习性是与用户为学习软件应用（例如运行控制、输入、输出）所花的努力有关的软件属性。该特征要求研制方提供的用户文档（主要是《计算机系统操作员手册》、《软件用户手册》和《软件程序员手册》）内容详细、结构清晰以及语言准确。
c.易操作性
易操作性是与用户为操作和运行控制所花的努力有关的软件属性。该特征要求软件的人机界面友好、界面设计科学合理以及操作简单等。
3.4 效率特征指标
效率特征可以细化成时间特征和资源特征。对软件的效率特征评价采用定量方法。效率特征分解如图2所示。
图2 效率特性分解图
a.输出结果更新周期
输出结果更新周期是软件相邻两次输出结果的间隔时间。为了整个系统能够协调工作，软件的输出结果更新周期应该与系统的信息更新周期相同。
b.处理时间
处理时间是软件完成某项功能（辅助计算或辅助决策）所用的处理时间（注意：不应包含人机交互的时间）。
c.吞吐率
吞吐率是单位时间软件的信息处理能力（即各种目标的处理批数）。未来的社会情况复杂、信息众多，软件必须具有处理海量数据的能力。吞吐率就是体现该能力的参数。随着信息的泛滥，要求软件的吞吐率应该达到数百批。
d.代码规模
代码规模是软件源程序的行数（不包括注释），属于软件的静态属性。软件的代码规模过大不仅要占用过多的硬盘存储空间，而且显得程序不简洁、结构不清晰，容易存在缺陷。
因为这些参数属于软件的内部表现，所以需要用专门的测试工具和特殊的途径才可以获得。将测试数据与研制任务书中的指标进行比较，得到的结果可以作为效率特征评价的依据。
4 结束语
随着计算机技术、数据融合技术、网络技术和通信技术的飞速发展，对软件功能提出的要求也越来越高，如何评估软件质量已成为一个迫切需要解决的课题。选择合适的指标体系并使其量化是做好软件质量评估的关键。当然，由于软件的评估具有其特有的规范和要求，其评估指标涉及面广、不确定性因素较多、量化困难，至今还没有统一的标准。
我们相信，通过建立科学合理的软件质量评估指标体系，充分考虑到软件的特殊性，借鉴其他学科的质量评估理论，是可以全面真实客观地评估软件质量的。
[本文共有 2 页，当前是第 2 页] <<上一页 下一页>>
]
您的位置：
