如何衡量软件测试过程的质量

Ⅰ 如何对软件质量进行评估(1)

1.2 软件质量特征
按照软件质量国家标准GB-T8566--2001G，软件质量可以用下列特征来评价：
a.功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。
b.可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。
c.易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。
d.效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。
e.可维护特征：与进行指定的修改所需的努力有关的一组属性。
f.可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。
其中每一个质量特征都分别与若干子特征相对应。
2 评估指标的选取原则选择合适的指标体系并使其量化是软件测试与评估的关键。评估指标可以分为定性指标和定量指标两种。理论上讲，为了能够科学客观地反映软件的质量特征，应该尽量选择定量指标。但是对于大多数软件来说，并不是所有的质量特征都可以用定量指标进行描述，所以不可避免地要采用一定的定性指标。
在选取评估指标时，应该把握如下原则：
a.针对性即不同于一般软件系统，能够反映评估软件的本质特征，具体表现就是功能性与高可靠性。
b.可测性即能够定量表示，可以通过数学计算、平台测试、经验统计等方法得到具体数据。
c.简明性即易于被各方理解和接受。
d.完备性即选择的指标应覆盖分析目标所涉及的范围。
e.客观性即客观反映软件本质特征，不能因人而异。
应该注意的是，选择的评估指标不是越多越好，关键在于指标在评估中所起的作用的大小。如果评估时指标太多，不仅增加结果的复杂性，有时甚至会影响评估的客观性。指标的确定一般是采用自顶向下的方法，逐层分解，并且需要在动态过程中反复综合平衡。
3 软件质量评估指标体系通常，我们在软件的测试与评估时，主要侧重于功能特征、可靠特征、易用特征和效率特征等几个方面。在评价活动的具体实施中，应该把被评估软件的研制任务书作为主要依据，采用自顶向下逐层分解的方法，并参照有关国家软件质量标准。
3.1 功能性指标功能性是软件最重要的质量特征之一，可以细化成完备性和正确性。目前对软件的功能性评价主要采用定性评价方法。
a.完备性完备性是与软件功能完整、齐全有关的软件属性。如果软件实际完成的功能少于或不符合研制任务书所规定的明确或隐含的那些功能，则不能说该软件的功能是完备的。
b.正确性正确性是与能否得到正确或相符的结果或效果有关的软件属性。软件的正确性在很大程度上与软件模块的工程模型（直接影响辅助计算的精度与辅助决策方案的优劣）和软件编制人员的编程水平有关。
对这两个子特征的评价依据主要是软件功能性测试的结果，评价标准则是软件实际运行中所表现的功能与规定功能的符合程度。在软件的研制任务书中，明确规定了该软件应该完成的功能，如信息管理、提供辅助决策方案、辅助办公和资源更新等。那么即将进行验收测试的软件就应该具备这些明确或隐含的功能。
目前，对于软件的功能性测试主要针对每种功能设计若干典型测试用例，软件测试过程中运行测试用例，然后将得到的结果与已知标准答案进行比较。所以，测试用例集的全面性、典型性和权威性是功能性评价的关键。

Ⅱ 软件质量评估的软件质量评估指标体系

通常，我们在软件的测试与评估时，主要侧重于功能特征、可靠特征、易用特征和效率特征等几个方面。在评价活动的具体实施中，应该把被评估软件的研制任务书作为主要依据，采用自顶向下逐层分解的方法，并参照有关国家软件质量标准。 功能性是软件最重要的质量特征之一，可以细化成完备性和正确性。对软件的功能性评价主要采用定性评价方法。
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.代码规模
代码规模是软件源程序的行数（不包括注释），属于软件的静态属性。软件的代码规模过大不仅要占用过多的硬盘存储空间，而且显得程序不简洁、结构不清晰，容易存在缺陷。
因为这些参数属于软件的内部表现，所以需要用专门的测试工具和特殊的途径才可以获得。将测试数据与研制任务书中的指标进行比较，得到的结果可以作为效率特征评价的依据。 随着计算机技术、数据融合技术、网络技术和通信技术的飞速发展，对软件功能提出的要求也越来越高，如何评估软件质量已成为一个迫切需要解决的课题。选择合适的指标体系并使其量化是做好软件质量评估的关键。当然，由于软件的评估具有其特有的规范和要求，其评估指标涉及面广、不确定性因素较多、量化困难，至今还没有统一的标准。

Ⅲ 如何评估软件质量

Q：最近我们组想自己审视一下软件质量，但是缺少相关的经验知识（组内没有qa)。 想向你了解一下，现在常用的软件质量评估方法? 你有关于软件质量相关的文章推荐吗？ 或者有哪些书籍推荐?

A：软件质量评估，我暂时还一时想不起来。对于软件质量（测试）相关的书籍我这有基本，具体的可以参考我之前参加的播客： https://music.163.com/#/program?id=903513756 和 http://codetimecn.com/episodes/test ，里面有书籍的介绍。

单纯的评估这块，我之前做过一个软件测试成熟度模型，可以用于评估团队的测试能力。

Q： 其实我有一个问题，软件质量该如何体现。感觉测试何软件质量有区别，但是我说不出来。特别是现在客户非常依赖手动测试，有专门的测试部门

A： 首先，质量是个很大的概念，本质是一种主观感受。我们通常所指的狭义质量为可靠性，软件的可靠性可以通过线上bug数来衡量（或者数量的变化趋势）。 更加准确的计算为线上bug数/开发中的bug数。
这个指标是量化可靠性的其中一种理论，由于业界本身对于软件质量的度量还没有统一的结论，我们可以采用这个值作为相对值进行对比。例如当比率很大时，可靠性质量很不好。
还有一个评估方法是工业界的的质量体系。也就是说，你的开发流程需要符合一定的标准，我就认为你的质量是有保证的。但是这个方式比较复杂而且不好量化
线上bug数属于简单粗暴型，用比例会准确一下是因为产品的规模不同，线上bug数是不同的。

在回答了上述问题后，我对自己的答安并不十分自信，因为我的观点是来源于自己的经验加上一些碎片话的知识。

为了更加准确的找寻关于“软件质量” 的概念，我再次查阅了维基网络： https://en.wikipedia.org/wiki/Software_quality 。

如上所示软件质量的定义与软件测试一样，并没有统一的定义。大的有三个维度的定义：

这段话的最后部分也指出了最早的质量定义是主观的感受。后面还提到了用户满意度。

总之，准确的定义软件质量依然是困难的，不过，我们还是有一些可以依据的定义，他们采用的是质量模型：

如 ISO/IEC 9126的定义的： https://en.wikipedia.org/wiki/ISO/IEC_9126
以及 CISQ's quality model

由于软件质量定义暂时难已统一，并且是主观的感受。那么评估它也就显得比较主观了。

当然，最简单的非软件测试莫属，那么Bug数毫无疑问的成为了一种可行的评估方式，因为软件测试最早的定义即是，“为了发现错误而执行程序的过程”，其中的错误，我们就可以狭义的理解为Bug。那这里又会存在一个问题，什么bug才有测量意义呢？
根据上述软件质量的定义，“用户”，“客户”，这些真正使用软件的人的感受才是最能反应质量的，所以说，“用户”， “客户”遇到的bug 才是更加符合质量的定义的可用于反应软件质量的Bug类型。（也就是我们所说的线上Bug）

另外，我们可以参考IT界的一些常用的定义来评估质量，例如：
ISO 9126-3
所提到的质量模型，我们可以通过检查软件开发过程中，以及软件自身是否具备某些特质，以及对应于该特质相关的用于评估的属性来评估软件的质量是好是坏。例如：
我们通过右侧的属性来评估左侧的质量特性：

从而得到一个综合的质量评估结果。

尽管上面给出了很多属性，但是相信大家读完了，依然疑惑，即便是有了这些属性，每个属性本身也并非都是标准化，且容易度量的，如coding practices即是典型的例子，里面提到了compliance with OO，可是这一点却是评估的人不同，显然量化的结果是不同，假如OO compliance的满分是10分，对于某OO设计，打6，还是7分，还是8，就仁者见仁，智者见智了。

假如我们狭义的理解质量为质量模型中的可靠性，需要check的点：

尽管已经有了这么多点，上面最后一句依然表明了可靠性的衡量需要考虑被评估软件本身的架构以及使用的第三方库，然后通过自定义的check点来做。也就是说，这个需要可靠性的评估标准，需要因地制宜，看情况而定。显然这种措辞依然表达出了主观标准的意思。

也正是如此，我们身边的日常用品的质量往往会打着IOS9001/IOS9002质量体系认证，来表明其质量是保证的，也就是说，我的产品是在质量保证的流程体系下生产出来的。这样以来，貌似这种评估定义，跟上述定义大体类似，实际上都是难以准确度量的，更大的意义也许是跟没有质量保证的产品去分开吧。

总之，度量软件质量是如此的复杂，且不一定真的能够准确量化质量。那倒不如就在开发过程中时刻按照这些check list约束开发过程，让开发过程是在有保证的情况下交付软件。让真正的质量交给时间，交给我们的线上去体现吧。这也想汽车界的着名质量杂志的JD Power的做法，用线上故障数来评估质量吧（对于汽车，准确的是每百辆故障数）。

Ⅳ 如何保证软件测试质量

我认为高质量的软件产品是一个软件团队所有成员都负责任的完成自己任务以后的必然产物。
首先说说团队，这其中涉及的需求人员、设计人员、开发人员、测试人员都应该真切的视自己为团队的必不可少的力量，都应该为了项目或产品的成功竭尽所能的去工作，只有团队真正的拧成一股绳的时候才具备了产出高质量软件的基本条件。这是我要说的第一点：团队认同感、归属感。
高质量的需求调研文档是软件成功必不可少的条件，但是不同的人对同一句话的理解往往会有差异，因为立场不同。所以想要保证需求的质量，需求人员必须把自己置身到用户的立场去感受、去调研、去理解目标用户反馈的信息。对于不确认的信息要想尽办法搞清楚。所以需求调研人员最好是行业专家。需求文档整理出来后，必须经过客户方代表和公司设计、开发、测试的共同评审才能最终定稿，并最终进入软件设计流程。这是我要说的第二点：软件需求必须用“心”去做，并且监督评审必须到位。
接下来就进入了软件的生产流程，在设计阶段，设计人员是主角，开发人员、测试人员、需求人员要可以及时获得设计文档。设计人员必须在实现需求的情况下，站在用户的立场上去设计功能，实现最好的用户体验。在设计评审时，开发、测试、需求要从用户的角度去评判设计，根据需求从用户的角度去评审设计，这真的很重要。问题如果能在设计阶段就发掘出来会极大的减少资源的浪费，缩短产品或项目周期。这是我要说的第三点：设计要注重用户体验，同时监督评审也必须到位。
软件进入开发测试流程后，实际的开发人员应该站在用户的角度上去开发每一个功能，如果有比设计更好的实现方法，应及时和设计、测试、需求人员沟通，共同确认是否更改设计。每一个功能完成后，必须进行完整的自测，然后及时送测给测试人员，测试人员也要在用户的角度进行测试，发现问题或建议及时反馈、沟通和处理。还有很重要的一点，测试必须要有测试用例。测试开始前，测使用例必须经过评审，当然评审粒度根据公司资源确定。这是我要说的第四点：开发是软件的制造者，测试是软件质量的保证者，两者相辅相成，荣辱与共。
高质量的软件是一个软件团队共同努力的结果，任意一个环节出问题都可能造成团队的灾难。团队领导者必须要想办法、尽全力将自己的团队凝结在一起，使大家具有团队荣誉感和使命感。软件生命周期的各个阶段都有工作重点，团队领导必须把握好。团队领导不能轻视任何一个环节的工作，否则高质量的软件只能是一句空话。古人说“三人行，必有我师焉”。任何一个团队，所有人的力量都发挥出来肯定比所谓几个精英累死累活搞出来的结果要好。人们说的“兵熊熊一个，将熊熊一窝”也是说团队领导的重要性。
呵呵，总结完了。最后再说一下自己的看法：高质量的软件是软件团队共同努力的结果，用户体验是软件质量很重要的方面，软件的需求、设计、开发和测试都应该是从用户的角度出发去工作。

Ⅳ 软件测试中对软件质量进行度量的指标常用的有哪些

你好！

有N多种指标：
缺陷统计数据的度量(I)
所有缺陷数量的时间走势或趋势统计 (Bug Trends By Time)
未被处理的缺陷按照严重程度的统计 (Active Bugs By Severity)
未被处理的缺陷按照优先程度的统计 (Active Bugs By Priority)
未被处理的缺陷数量的时间走势或趋势统计 （Active Bugs Over Time）
已发现缺陷的数量和已修复的缺陷的数量的比率 (Fixed/Found)。也被称为修改率或纠错率(Fix Rate)
未处理的缺陷数量和已处理的的缺陷数量的比率 (active/resolved)
已处理的被修复的缺陷数量和已处理的缺陷数量的比率（Resolved as Fixed/resolved）
重新被激活的已修复的缺陷数量(Bug re-activation rate)
通过测试找到的缺陷的统计(Bugs opened by testing activity)
所有的缺陷按照严重程度的统计(All Bugs By Severity)
新被发现的缺陷按严重程度的统计 (Opened Bugs By Severity)
已处理的缺陷按照严重程度的统计 (Resolved Bugs By Severity)
被修复的缺陷按照严重程度的统计 (Fixed By Severity)
不同语言版本缺陷数量的统计(Bugs opened by Language version)
被报告存在缺陷的各功能统计(Where your bugs were found)
处理缺陷的平均时间的统计(Average Time to Resolve)
关闭缺陷的平均时间的统计(Average Time to Close)
被处理缺陷的不同结论统计(Resolved Bugs By Resolution)

详细的信息你可以留下邮箱，我发给你文件！