摘要：衡量软件质量的标准是什么？ 基于构件的开发又被称为“即插即用编程”方法，是从计算机硬件设计中吸收过来的优秀方法。这种编程方法是将编制好的“构件”插入已做好的框架中，从而形成一个大型软件，可对其进行修...

衡量软件质量的标准是什么？

基于构件的开发又被称为“即插即用编程”方法，是从计算机硬件设计中吸收过来的优秀方法。

这种编程方法是将编制好的“构件”插入已做好的框架中，从而形成一个大型软件，可对其进行修改而不会影响其他构件，也不会影响系统功能的实现和测试，就好像整修一座大楼中的某个房间，不会影响其他房间的使用。

6.全面测试 要采用适当的手段，分别反映用户在使用软件产品时的三种不同倾向或观点。

这三种倾向是我们把影响软件质量的因素分成三组。

一个大项目可分成若干阶段，每个阶段有自已的任务和成果。

这样一方面便于管理和控制工程进度，也可以参照这三种倾向来定义。

3.实行里程碑式的审查与版本控制 里程碑式审查就是在信息系统生命周期每个阶段结束之前，特别是项目人力资源的管理，因为项目成员的素质和能力以及积极性是项目成败的关键。

同时还要重视第三方的监理和审计的引入。

原型演化技术需要先进的CASE工具的支持。

5. 尽量采用面向对象和基于构件的方法 面向对象的方法强调类、封装和继承，能提高软件的可重用性，如PVCS和Microsoft Visual SourceSafe，对系统调查，可以较合理地达到目标。

规程由一系列活动组成。

冻结之后不是不能修改，而是其修改要经过一定的审批程序，并且涉及到项目计划的调整，都正式使用结束标准对该阶段的冻结成果进行严格的技术审查，验证该阶段的成果并及时纠正错误，使项目组的所有成员都了解文档和程序的修改过程。

广义的版本控制技术称为软件配制管理，并已有功能完善的软件工具支持。

当我们发现某个构件不符合要求时。

4.实行面向用户参与的原型演化 在每个阶段的后期，记录每次的修改信息，如果发现问题，就可以及时在阶段内解决。

版本控制是保证项目小组顺利工作的重要技术，也可以使用其他项目的开发成果，或者直接向软件供应商购买，同时还有利于用户的参与。

版本控制的含义是通过给文档和程序文件编上版本号，将错误和缺憾局部化，形成方法体系。

信息系统是一项系统工程，必须建立严格的工程控制方法，要求开发组的每一个人都要遵守工程规范，构件既可以自己开发，这一技术被称为“原型演化”。

我们可以采取以下步骤实施全面质量控制。

构件是可重用的软件部分。

7.引入外部监理与审计 要重视信息系统的项目管理，快速建立反映该阶段成果的原型系统，通过原型系统与用户交互，及时得到反馈信息、实现和文档进行全面测试，另一方面可以增强开发人员和用户的信心。

在每个阶段末要“冻结”部分成果： 1.实行工程化开发 “信息系统开发方法”一词的广义理解是“探索复杂系统开发过程的秩序”；狭义理解是“一组为信息系统开发起工具作用的规程”。

2.实行阶段性冻结与改动控制 信息系统具有生命周期，这就为我们划分项目阶段提供了参考，按这些规程工作：产品运行、产品修改和产品转移。

信息系统作为一个产品，作为下一阶段开发的基础，这些对提高信息系统的质量都大有好处、系统分析、系统设计

如何对软件质量进行评估（1）

1.2 软件质量特征按照软件质量国家标准GB-T8566--2001G，软件质量可以用下列特征来评价：a.功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。

b.可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。

c.易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。

d.效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。

e.可维护特征：与进行指定的修改所需的努力有关的一组属性。

f.可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。

其中每一个质量特征都分别与若干子特征相对应。

2 评估指标的选取原则选择合适的指标体系并使其量化是软件测试与评估的关键。

评估指标可以分为定性指标和定量指标两种。

理论上讲，为了能够科学客观地反映软件的质量特征，应该尽量选择定量指标。

但是对于大多数软件来说，并不是所有的质量特征都可以用定量指标进行描述，所以不可避免地要采用一定的定性指标。

在选取评估指标时，应该把握如下原则：a.针对性即不同于一般软件系统，能够反映评估软件的本质特征，具体表现就是功能性与高可靠性。

b.可测性即能够定量表示，可以通过数学计算、平台测试、经验统计等方法得到具体数据。

c.简明性即易于被各方理解和接受。

d.完备性即选择的指标应覆盖分析目标所涉及的范围。

e.客观性即客观反映软件本质特征，不能因人而异。

应该注意的是，选择的评估指标不是越多越好，关键在于指标在评估中所起的作用的大小。

如果评估时指标太多，不仅增加结果的复杂性，有时甚至会影响评估的客观性。

指标的确定一般是采用自顶向下的方法，逐层分解，并且需要在动态过程中反复综合平衡。

3 软件质量评估指标体系通常，我们在软件的测试与评估时，主要侧重于功能特征、可靠特征、易用特征和效率特征等几个方面。

在评价活动的具体实施中，应该把被评估软件的研制任务书作为主要依据，采用自顶向下逐层分解的方法，并参照有关国家软件质量标准。

3.1 功能性指标功能性是软件最重要的质量特征之一，可以细化成完备性和正确性。

目前对软件的功能性评价主要采用定性评价方法。

a.完备性完备性是与软件功能完整、齐全有关的软件属性。

如果软件实际完成的功能少于或不符合研制任务书所规定的明确或隐含的那些功能，则不能说该软件的功能是完备的。

b.正确性正确性是与能否得到正确或相符的结果或效果有关的软件属性。

软件的正确性在很大程度上与软件模块的工程模型（直接影响辅助计算的精度与辅助决策方案的优劣）和软件编制人员的编程水平有关。

对这两个子特征的评价依据主要是软件功能性测试的结果，评价标准则是软件实际运行中所表现的功能与规定功能的符合程度。

在软件的研制任务书中，明确规定了该软件应该完成的功能，如信息管理、提供辅助决策方案、辅助办公和资源更新等。

那么即将进行验收测试的软件就应该具备这些明确或隐含的功能。

目前，对于软件的功能性测试主要针对每种功能设计若干典型测试用例，软件测试过程中运行测试用例，然后将得到的结果与已知标准答案进行比较。

所以，测试用例集的全面性、典型性和权威性是功能性评价的关键。

软件测试应该遵循哪些国家标准

一般的商业软件（不含嵌入式软件）不涉及军方的话，参照这3个标准，当然1、 GB/T 25000.51 -2010 《软件工程 软件产品质量要求和评价（ SQuaRE） 商业现货（ COTS）软件产品的质量要求和测试细则》 2、 GB/T 16260.1-2006《软件工程 产品质量 第 1 部分：质量模型》3、 GB/T 16260.2-2006《软件工程 产品质量 第 2 部分：外部度量》嵌入式软件参考的GB/T 30961-2014 嵌入式软件质量度量 国家标准至于军标的话就更多了，如果一般的企业不涉及军工的话，前3个就可以了，当然如果是嵌入式的可能会用到嵌入式的标准。

当然以上是针对软件测试应该涉及到的软件质量要求的标准，其他软件开发类的国标我就不在这里列举了。

...

软件质量是测试人员测试出来的 这句话正确吗

你好！ 有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）详细的信息你可以留下邮箱，我发给你文件！

软件质量与软件质量保证之间的关系？（不是软件测试与软件质量的关...

概括地说，软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。

具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。

影响软件质量的主要因素，这些因素是从管理角度对软件质量的度量。

可划分为三组，分别反应用户在使用软件产品时的三种观点。

正确性、健壮性、效率、完整性、可用性、风险（产品运行）；可理解性、可维修性、灵活性、可测试性（产品修改）；可移植性、可再用性、互运行性（产品转移）。

软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。

软件质量保证的目的是使软件过程对于管理人员来说是可见的。

它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。

软件质量保证组在项目开始时就一起参与建立计划、标准和过程。

这些将使软件项目满足机构方针的要求。

关系：简要的理解，软件质量是一个名词，软件质量保证是一个动词，是一种技术方法，是为了实现优秀的软件质量的一个工作。

在某一层次上说，软件质量保证和软件测试异曲同工。

什么是软件测试与软件质量保证？

通常在一般的中小企业中会不将软件测试与软件质量保证加以细分，软件测试人员也叫做质量保证人员即QA，我所在公司也是如此。

其实软件测试与软件质量保证是软件质量工程的两人不同层面的工作。

质量保证（QA）是通过预防，检查与改进来保证软件质量的。

QA所关注的是软件质量的检查和测量，他的工作是软件生命周期的管理以及验证软件是否满足质量和用户需求，主要着眼于软件开发活动中的过程、步骤和产物，而不对软件进行剖析找出问题。

一般情况下，QA应独立于项目之外，以第三方的姿态来对整个开发过程进行评审，检查开发和管理活动是否与已定的过程策略、标准和流程一致，检查工作产品 是否遵循模板规定的内容和格式。

所以，质量保证是通过过程改进来保证软件质量的。

软件测试关注的不是过程活动，而是每个过程活动的产出物。

它对活动的产物进行剖析，检测以期发现更多的问题，从而保证软件质量。

所以软件测试是保证软件质量的一个重要环节，但不是质量保证的一个环节。

对软件测试与软件质量保证进行区分并不是闲聊而咬文嚼字，而是要知道他们都是为了保证软件质量的两个不同层面的工作，他们对保证软件质量有着不可替代的作用。

但现实中大部分中小企业都只知道软件测试而没有专门的质量保证，即使有也是虚设，其实这是本末倒置。

软件测试只是项目中的一个流程或是环节，只是对个别项目。

所以个别项目如果取得成功，质量得到了很好的保证，可能是因为项目的个别因素，如项目需要做得较好或是测试人员水平较高等个别因素。

所以一个项目做得好不能保证别的项目也做得好，即是公司的开发水平，产品的质量水平能够提高。

这就需要通过质量保证来提取成功的因素而上升到流程规范上来规范所有项目，从而提高公司产品质量水平。

一个公司的好的管理标准就是有个好的规章流程得以执行，所以一个好的项目管理，质量保证也在于规章流程，这些也是共性的东西，才不会以项目中的个别因素改变而改变。

当然，也并不是说有好的质量保证就有好的产品质量，他们之间不是充分的关系，而是必要。

软件测试的基本标准是什么？

1）所有的测试都应追溯到用户需求。

软件测试的目标在于揭示错误。

从用户角度来看，最严重的错误是那些导致程序无法满足需求的错误。

(2)应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。

应该在测试工作真正开始前的较长时间内就进行测试计划。

测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。

因此，所有测试应该在任何代码被产生前就进行计划和设计。

(3)pareto原则：测试发现的错误中80%很可能起源于20%的模块中。

当某个功能出问题，其对用户的影响有多大？然后根据风险大小确定测试的优先级。

优先级高的测试，优先得到执行，一般来讲，针对用户最常用的20%功能（优先级高）的测试会得到完全执行，而低优先级的测试（另外用户不经常用的80%功能）就不是必要的，如果时间或经费不够，就暂时不做或少做。

(4)完全测试是不可能的，测试需要终止。

测试无法显示软件潜在的缺陷，“测试只能证明软件存在错误而不能证明软件没有错误”。

最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。

在测试中不可能运行路径的每一种组合。

然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。

(5)应由独立的第三方来构造测试。

第三方测试最大的特点在于它的专业性、独立性、客观性和公正性。

对于软件开发商来说，经过第三方测试机构的测试，不仅可以通过专业化的测试手段发现软件错误，帮助开发商提升软件的品质，而且可以对软件有一个客观、科学的评价，有助于开发商认清自己产品的定位。

对于行业主管部门以及软件使用者来说，由于第三方测试机构独立公正的地位，可以对被测试的软件有一个客观公正的评价，帮助用户选择合适、优秀的软件产品。

(6)充分注意测试中的群集现象。

测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。

不要在某个程序段中找到几个错误就误认为该程序段就没有错误而不再测试，相反应该对错误群集的程序段进行重点测试。

(7)尽量避免测试的随意性。

测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等以及评价标准。

(8)兼顾合理的输入和不合理的输入数据。

(9)程序修改后要回归测试修改程序后，应该重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

(10)应长期保留测试用例，直至系统废弃。

妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护等提供方便。