通常，我们在软件的测试与评估时，主要侧重于功能特征、可靠特征、易用特征和效率特征等几个方面。在评价活动的具体实施中，应该把被评估软件的研制任务书作为主要依据，采用自顶向下逐层分解的方法，并参照有关国家软件质量标准。功能性是软件最重要的质量特征之一，可以细化成完备性和正确性。对软件的功能性评价主要采用定性评价方法。
a.完备性完备性是与软件功能完整、齐全有关的软件属性。如果软件实际完成的功能少于或不符合研制任务书所规定的明确或隐含的那些功能，则不能说该软件的功能是完备的。
b.正确性正确性是与能否得到正确或相符的结果或效果有关的软件属性。软件的正确性在很大程度上与软件模块的工程模型（直接影响辅助计算的精度与辅助决策方案的优劣）和软件编制人员的编程水平有关。对这两个子特征的评价依据主要是软件功能性测试的结果，评价标准则是软件实际运行中所表现的功能与规定功能的符合程度。在软件的研制任务书中，明确规定了该软件应该完成的功能，如信息管理、提供辅助决策方案、辅助办公和资源更新等。那么即将进行验收测试的软件就应该具备这些明确或隐含的功能。对于软件的功能性测试主要针对每种功能设计若干典型测试用例，软件测试过程中运行测试用例，然后将得到的结果与已知标准答案进行比较。所以，测试用例集的全面性、典型性和权威性是功能性评价的关键。根据相关的软件测试与评估要求，可靠性可以细化为成熟性、稳定性、易恢复性等。对于软件的可靠性评价主要采用定量评价方法。即选择合适的可靠性度量因子（可靠性参数），然后分析可靠性数据而得到参数具体值，最后进行评价。
经过对软件可靠性细化分解并参照研制任务书，可以得到软件的可靠性度量因子（可靠性参数）。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）指软件失效后恢复正常工作所需的平均统计时间。对于软件，其失效恢复时间为排除故障或系统重新启动所用的时间，而不是对软件本身进行修改的时间（因软件已经固化在机器内，修改软件势必涉及重新固化问题，而这个过程的时间是无法确定的）。易用性可以细化为易理解性、易学习性和易操作性等。这三个特征主要是针对用户而言的。对软件的易用性评价主要采用定性评价方法。
a.易理解性易理解性是与用户认识软件的逻辑概念及其应用范围所花的努力有关的软件属性。该特征要求软件研制过程中形成的所有文档语言简练、前后一致、易于理解以及语句无歧义。
b.易学习性易学习性是与用户为学习软件应用（例如运行控制、输入、输出）所花的努力有关的软件属性。该特征要求研制方提供的用户文档（主要是《计算机系统操作员手册》、《软件用户手册》和《软件程序员手册》）内容详细、结构清晰以及语言准确。
c.易操作性易操作性是与用户为操作和运行控制所花的努力有关的软件属性。该特征要求软件的人机界面友好、界面设计科学合理以及操作简单等。3.4效率特征指标效率特征可以细化成时间特征和资源特征。对软件的效率特征评价采用定量方法。
a.输出结果更新周期输出结果更新周期是软件相邻两次输出结果的间隔时间。为了整个系统能够协调工作，软件的输出结果更新周期应该与系统的信息更新周期相同。
b.处理时间处理时间是软件完成某项功能（辅助计算或辅助决策）所用的处理时间（注意：不应包含人机交互的时间）。
c.吞吐率吞吐率是单位时间软件的信息处理能力（即各种目标的处理批数）。未来的社会情况复杂、信息众多，软件必须具有处理海量数据的能力。吞吐率就是体现该能力的参数。随着信息的泛滥，要求软件的吞吐率应该达到数百批。
d.代码规模代码规模是软件源程序的行数（不包括注释），属于软件的静态属性。软件的代码规模过大不仅要占用过多的硬盘存储空间，而且显得程序不简洁、结构不清晰，容易存在缺陷。因为这些参数属于软件的内部表现，所以需要用专门的测试工具和特殊的途径才可以获得。将测试数据与研制任务书中的指标进行比较，得到的结果可以作为效率特征评价的依据。随着计算机技术、数据融合技术、网络技术和通信技术的飞速发展，对软件功能提出的要求也越来越高，如何评估软件质量已成为一个迫切需要解决的课题。
选择合适的指标体系并使其量化是做好软件质量评估的关键。当然，由于软件的评估具有其特有的规范和要求，其评估指标涉及面广、不确定性因素较多、量化困难，至今还没有统一的标准。
软件质量量化指标2篇摘要：软件已成为人们工作和生活必不可少的助手和伴侣。软件的质量好坏直接影响了人们工作的效率和生活的水平。为确保软件的质量，需要一个系统的软件质量评估指标体系，本文参考了业内软件质量评估指标，并结合多年软件开发和运维经验，设计了一个通用的软件质量评估指标体系，根据此评估体系，我们可以对各种软件的质量进行较系统和全面地评估，从而有助于为软件开发和维护工作提供参照，有助于全面保证和提高软件的质量。
关键词：软件；软件质量；评估指标
中图分类号：TP311.52文献标识码：ADOI：10.3969/j.issn.1003-6970.2015.03.012
本文著录格式：翁秀木，一个通用的软件质量评估指标体系[J].软件，2015，36（3）：59-63
0.引言
随着IT技术，尤其是软件技术的迅猛发展，软件已成为人们工作和生活密不可分的一部分。例如本地PC办公软件、远程网站、手机本地App等等。然而，软件的质量不佳也已成为影响人们工作和生活质量的严重问题，例如，对于组织而言，例如金融机构，软件的质量差，造成客户资料流失，不仅形象受损，也还可能要遭受业界监管部门的巨额罚款。而对于个人而言，软件的质量差，不仅会影响正常使用，甚至会危及个人的安全，例如个人帐号安全，个人隐私泄露等。尤其在移动互联网蓬勃发展的今天，这个问题尤其突出。
因此，如何确保软件的质量，是一个业内一直以来都十分重视的问题。而软件的生命周期与人的生命周期有许多相似之处，软件的质量评估与人的体检也有许多相似之处。人的体检会借助一个的健康评估指标体系，而软件的质量评估也需要一个全面的质量评估指标体系。本文根据作者多年从事软件开发和维护工作的实践经验，并借鉴业内相关的研究成果，设计出了一个通用的软件质量评估指标体系，该体系由两个维度组成：软件的运行和软件的修改。
1.软件质量评估体系
1.1软件的运行
软件的运行指的是当软件的设计、编码和单元测试的工作完成后，进入系统集成测试、用户测试、甚至上到生产环境上运行时，如何去评估软件的质量。可以分为5个指标：正确性、可靠性、效率性、可用性和安全性。
1.1.1正确性
正确性指的是评估软件是否能够正确地反映业务功能的要求，是否能够正确地为用户提供基本的业务服务。
该指标的主要评估方法是，通过端对端的黑盒测试，根据测试用例，检查软件的功能是否符合需求规格说明书的要求。而在软件编码阶段，可以通过运行单元测试脚本来进行正确性检验。
这是最基本的软件质量的评价要求。但在实际项目中，这往往会或多或少出现软件在系统集成测试、用户测试、甚至在生产环境上才发现软件的功能与业务的要求不符。主要原因是双方面的：一是业务方（包括业务分析师，即BA）没有正确地描述需求。二是软件的设计、代码实现和测试方没有正确地理解需求。
保证正确性的主要方法：（1）是业务方和软件的设计和代码实现方要强化沟通的有效性。例如极限编程思想提出的，双方应该尽可能地面对面的沟通，其他形式的电话、电邮或即时通讯工具的沟通，都不如面对面沟通准确和有效。（2）是要有一份严谨而清晰的需求规格说明书，软件设计、代码实现和测试方的对需求的理解主要是以该需求规格说明书为准，需求规格说明书不严谨、不清晰势必影响软件的正确性。（3）是要有一套科学的需求管理流程和工具。在很多情景下，需求方对需求难以做到一开始就是十分准确的，需求的变更在整个项目的过程中都可能存在，尤其是根据迭代式开发和极限编程的思想，需求的变更是非常正常的，我们不能抗拒需求的变更，反而要拥抱需求的变更，要做到这点，就有必要有一套有效的需求管理流程和工具。
1.1.2可靠性
可靠性指的是评估软件在如下三方面的表现：容错性、出错后的恢复能力、可伸缩性（scalability）。其中：（1）容错性，评估软件运行出错时，可否自动纠错，而不影响在线用户的使用，不影响后台程序的继续运行。（2）出错后的恢复能力，评估软件运行出错后，要耗费多少时间和其他资源才能恢复运行。（3）可伸缩性，评估软件在负载大，尤其是用户剧增时，是否还能继续保证正常运行。另外，在负载小时，软件是否可以在足以支撑高质量服务的前提下，使用尽量少的资源。
可靠性指标的常用评估方法是：（1）容错性，模拟出错情景，观察软件的反映。例如，模拟将某个主文件删去，看当软件找不到主文件时，是否可以自动找其备份文件代替。（2）出错后的恢复能力，可从流程（Process）、人（People）和技术（Technology）三个方面来衡量，流程方面，是否存在着合理的、有效的出错恢复流程。人方面，是否存在着拥有扎实运维知识的工程师队伍。技术方面，是否存在着支持快速、完整地恢复错误的技术，例如备份数据库。（3）可伸缩性，在测试阶段，常常利用压力测试工具来模拟软件负载剧增时的情境，如LoadRunner和WinRunner。借此检测软件系统的抗压能力。
因此，要提高可靠性，（1）在容错性上，从代码级别来看，不仅要保证软件在“正常”情境下可运行，而且要考量各种“异常”情境，若软件是可以恢复的，就应该有健全的异常处理代码，使软件能从异常中自动恢复，而不影响前台用户的使用或后台程序的继续运行。从系统级别来看，软件若能有多个备份，例如Web应用同时部署在多个Web服务器上，若某个Web服务器上的应用访问失败，系统会自动切换到其他Web服务器上的应用，这个切换对用户是透明的，从而提高了容错性。（2）出错后的恢复能力。从流程、人和技术上看。既要有一个科学的应错流程，又要有一支出色的排错工程师队伍，还要有一套完善的监错、查错和纠错软硬件技术。（3）可伸缩性。可以用实现负载均衡的软硬件技术，提高软件系统的可伸缩性。1.1.3效率性
效率性指从时间和空间（内存、磁盘和网络带宽）两方面来评估软件的效率。
软件运行的时间效率也可以通过端对端的黑盒测试来评估，例如选取最复杂的业务功能模块，测量用户发出请求后，要多长时间，该功能才可执行完毕。空间方面的测试，需要在客户端和服务器端，衡量软件运行时的内存和磁盘占用量，而网络带宽测试可以使用专门的网络测速工具。
要提高软件的时间和空间效率。（1）从时间上说，可以提高算法的时间复杂度，用优良的算法来减少复杂模块的时间消耗，另外，一般而言，磁盘读写的时间会远慢于内存读写的时间，过多的磁盘读写势必会降低软件的时间效率，因而若能尽可能把磁盘读写转换为内存读写，就可以大大提高时间效率。另外，对于有网络调用的软件而言，过多的网络调用也必然会降低时间效率，因而尽量减少网络调用，就可大大提高软件的时间效率。并且，对于高耗时的动作，可以考虑用多线程的技术来实现，当然也可以用多进程来实现，但多进程之间的通信会比多线程慢。（2）从空间上说，磁盘和内存的空间占用，后者对软件的效率影响更大，尤其是在资源有限环境下的运行的软件对内存空间占用更加敏感，如智能家居、智能穿戴等软件。一方面注意合理地管理内存，一方面要尽量优化算法，使得内存空间占用量尽可能少。而对于有网络调用的软件，网络带宽的占用也是影响效率的重要因素，应该尽可能地减少通过网络的数据传输量，例如用各种缓存技术。
1.1.4可用性
可用性指从用户体验上来评估软件的可操作性、易学性、可理解性等。
软件的用户界面美观是重要的，但可用性高是更重要的，如何提高软件的可用性。正如雅各布尼尔森所说，可以从十个方面来衡量：（1）系统状态的可见性。软件系统应该始终让用户知道当前正在做什么，这可通过在适当的时间内得到适当的反馈来实现。（2）系统和真实世界的匹配。软件系统应该采取用户的语言与用户交互，即用户熟悉的词句、概念等，而尽量不要用系统术语。同时要遵循真实世界的习惯，使得信息能以自然的、符合逻辑的顺序来呈现。（3）用户控制和自由。用户时常会错误地选择了某个系统功能，进入某个不期望的状态，这时需要有一个清晰的出口，使得用户能够简便地退出。例如支持撤销和重做功能。（4）一致性和标准。要确保软件系统的整体风格一致性，不要让用户对不同的词句、状态和动作是否代表同一件事情而困扰。（5）错误避免。清晰而准确的错误消息是必要的，但最好能通过细心的设计避免错误的发生，比如消除错误发生的前提条件，或者在用户确定提交请求之前，检验用户将要提交的信息是否合法，并提供一个确认页面让用户再次确认将要提交的信息。（6）识别而非回想。也就是说，有关系统使用的提示信息应该是可见的、或可适时获得的，从而，用户可以快速识别该怎么做，而不需要费时回想过去是怎么做的。（7）使用的灵活性和效率性。对于软件系统的高级用户，应该有些渠道使之能快速地进行某些操作，如快捷键。并且，能让用户可以自定义一些经常性操作的快捷访问方式。（8）简约式的设计。与用户的任何交互界面都尽量剔除不相干的、或者极少需要的信息。（9）帮助用户辨别和诊断错误，并从错误中恢复。错误信息要以自然的语言来表述（不要用代码），要精确地描述错误，建设性地提出解决方法。（10）帮助和文档。虽然最好软件系统能够不需要文档即可使用，但是提供足够的帮助和文档也是需要的。并且，应该让用户可以较容易地查到帮助信息，帮助信息应该关注于用户的任务，列出具体的执行步骤，但也不要太繁琐。
1.1.5安全性
安全性指从机密性（confidentiality）、完整性（Integrity）和可访问性（Availability）三方面来评估软件的质量。机密性，指的是避免信息或数据被未授权用户获取。完整性指的是避免信息或数据被未授权用户篡改。可访问性指的是保证信息或数据在需要时可以被访问。
为提高软件的安全性，（1）应确保信息和数据的机密性，从整体系统设计来看，要有完善的认证和授权机制。从代码级别来看，代码编写要可以防止为了获取非授权信息的常见代码安全攻击，例如，主要针对Web应用软件的SQL注入攻击和跨站点脚本攻击，这可以通过恰当的代码来避免。（2）应确保信息和数据的完整性。例如信息和数据的传播渠道要有足够的安全级别，例如客户端访问服务器端的认证模块应该用安全级别更高的https协议，而不要用简单的http协议。（3）应确保信息和数据的可访问性。一方面可从硬件上来提高，例如使用高访问性的服务器集群。另一方面可从软件上来提高，例如可以通过合理的代码设计，避免恶意客户多次反复提交请求而导致的内存溢出等错误。
1.2软件的修改
软件系统的生命周期通常包括初始化、计划、需求分析、设计、测试、实施、运营和维护、乃至终止下线等多个步骤。在这其中，软件运营和维护的成本是最高的。常占软件生命周期总成本约七成。因此，评估软件的质量，不单要衡量软件运行时的指标，还要看软件进入维护阶段时软件修改的指标。可分为6项：可维护性、可测试性、可读性、简单性、可移植性和可重用性。
1.2.1可维护性
维护往往是软件生命周期中成本最大的阶段。软件必须强调可维护性，努力做到修改现有代码时，尽量少影响其他代码，增加新功能时，尽量少影响现有功能。例如，遵循开闭原则，Softwareentities（classes，modules，functions，etc.）shouldbeopenforextension，butclosedformodification，即软件应追求只需较少修改、甚至无需修改，就可扩展。
软件要提高可维护性，就要尽量提高软件实体（包括类、模块和函数等）的内聚性，一般而言，若能做到单一实体只承担单一职责，就可有较高的内聚性。提高了软件实体的内聚性，并尽可能降低实体之间的耦合性，软件维护时，就能更好地实现“增加新功能实体时，不修改旧功能实体”。另外，对于遵循面向对象思想的软件而言，在设计时遵循面向接口、依赖倒转等原则，也可以提高软件的可维护性，容易扩展且基本无需修改原代码。1.2.2可测试性
可测试性指在对软件进行黑盒或白盒测试时的难易程度。因为当软件在运维期需要查错、修改时，常常需要对软件进行测试。软件的易测性直接决定了是否能在有限的生产环境维护时间窗内快速地纠错，直接决定了软件修改项目进行阶段的成本。因此，如何提高软件的可测试性，也是软件设计阶段必须谨慎考量的一个重要方面，因为它影响了软件修改时的效率，影响了软件的质量。
1.2.3可读性
可读性指软件的需求、设计架构、源码、测试用例、运行时所依赖的软硬件平台，是否容易被理解，被读懂。有完善易懂的软件需求相关资料，软件修改时才能更好地理解当前需求。有科学合理的设计架构，软件修改时才能更快地掌握当前架构。有简约明了的源码（包括代码风格和注释），软件修改时才能更有效地读懂、修改源码。有清晰规范的测试用例等有关测试的资料，软件修改时才能更好地避免改动对原有功能的影响。有全面详细的软件硬件平台资料，软件修改时才能更准确地将改动部署上线。
1.2.4简单性
简单性指软件的设计和编码、包括其他的需求、测试和部署文档，是否能遵循简约的风格。正如极限编程思想所倡导的：Thesimplestthingthatcouldpossiblywork，即让软件能用最简单的方式保证正常运作。Spring框架的发明者RodJohnson也说过：好的工程实践并不一定非要用复杂的方法来实现。只有这样，才能让现有的软件设计架构、源码、需求规格说明书、测试用例文档、部署文档等更容易被理解，从而才能更好地降低软件修改时的成本。
1.2.5可移植性
可移植性指软件在不同软硬件环境中迁移时，是否能做到迁移成本低，且各种功能和性能指标也不受影响。让橘生于淮南为橘，生于淮北也须为橘，而不能为枳。例如，当软件在迁移到不同的操作系统平台时，是否需要重新编译，甚至重新编码。或者迁移到不同的数据库管理系统时，是否需要重新编码。尤其是所处软硬件环境较复杂的软件系统，可移植性更为重要。
1.2.6可重用性
可重用性指软件实体（如类、模块和函数）能否被其他软件实体重用，并且能以较低成本重用。甚至是软件本身，能否作为一个整体的服务，被其他软件系统直接调用。
要做到软件实体的可重用性高，同样也要遵循“单一职责”的设计思想，提高软件实体的内聚性，降低耦合性，就可以较好地实现重用现有实体。
2.小结
以上从软件运行和修改两个维度，设计了一个软件质量评估体系，即软件运行时的正确性、可靠性、效率性、可用性、安全性，软件修改时的可维护性、可测试性、可读性、简单性、可移植性、可重用性。这个质量评估体系是通用的，软件不论基于何种业务功能，不论基于何种技术环境，都可采用这个评估体系对质量进行系统的全面评估。未来的研究，还需要对如何衡量这些指标、如何提高软件的质量做更深入的分析，期望能对软件的设计、编码、测试、实施和运维等工作有一定帮助。
查看全文
false