软件质量保证.docx
《软件质量保证.docx》由会员分享，可在线阅读，更多相关《软件质量保证.docx（13页珍藏版）》请在冰豆网上搜索。
软件质量保证
软件质量保证
篇一：
软件质量保证
如何保证软件设计的质量软件在没有发布之前的开发过程主要分为需求分析、设计、编码和验证四个阶段，最终的软件质量与这四个阶段的各自质量之间的关系是：
最终的软件质量=需求分析质量+设计质量+编码质量+验证质量
即，最终的质量来自于各阶段质量之总和，只要其中一个环节质量是差，则产品的整体质量都将是差。
由此看来每一个阶段的质量都起着决定性的作用。
对于如何保证软件设计的质量来说，可以先从软件设计意义来说。
设计是什么？
有人说设计是人类的思想，也有人说设计是模型，也有人说设计是规划人们完成工作的步骤。
在灵敏开发社区里挺直指出设计就是源代码！
其实上面所说的设计概念都只提到设计本身的某一个方面。
总结定义如下：
设计是人类为了完成某一项任务而对该任务的实现进行不同程度的抽象，这样使人类在有限的智力范围内更简单、更优美、更便捷的实现任务目标。
“思想”是一种对任务实现方法的抽象，“模型”是对任务实现结果的抽象，“规划的步骤”是对任务实现过程的抽象，“程序源代码”也是任务实现结果的一种抽象（这种抽象度比UML模型更低）。
其实只有“可以部署到客户环境中的可执行系统”才是任务的主要结果，也即软件产品。
因而，我们主要保证质量的产品就是：
“可以部署到客户环境中的可执行系统”。
设计的目的是降低任务的简单度，对目标系统进行不通层次抽象，把系统易变、简单的部分进行分别，解除不必要的偶合，使系统在满足功能需求的同时保证系统的可修改性、可重用性、牢靠性、易用性、性能等非功能需求。
对于实现的系统很小、很简洁，并且已经有胜利的实现阅历和案例，可以不需要做更高抽象层次的设计，源代码本省就是一种很精确的设计；对于中大规模的系统，或拥有简单规律的系统，一般需要采纳比源代码更高一级抽象层次的设计，比如UML类设计图等等来描述高层设计；假如系统特别简单浩大、开发周期很长、开发成员众多，那就需要一个更加有条理、更加规范和严谨的设计抽象来保证工作的有序和协调了，同时需要更多的设计层次来降低系统的简单性。
是不是只要做了设计，就能确保软件产品的质量达到要求呢？
大家知道这是不行能的！
但设计能从架构或结构方面促使系统的质量达到要求，系统详情问题是不能靠设计保证的，这需要严格的测试过程。
良好的设计能促进软件产品的质量提高，低劣的设计挺直造成软件产品的质量低劣。
所以说，为了保证开发出来的软件产品达到既定的质量要求或指标，我们需要依据这些质量要求，选择促进软件产品到达这些质量要求的设计策略，采纳业界多年已阅历证的设计原则和模式（比如大家熟知的有名的?
开闭原则?
等等），进行
恰当的抽象，制造出优良的设计结果。
同时在做这些设计的时候，也需要对设计进行复审，使其保证设计的方向不会偏离目标。
世界没有包治百病的灵丹妙药，软件也没有万能的解决方法，只有不断改进我们解决问题的思想、方法和过程，良好软件设计就是我们在提升软件质量方面一个重要的法宝！
软件设计是从软件需求规格说明书动身，依据需求分析阶段确定的功能设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法以及编写具体的代码，形成软件的具体设计方案。
软件设计把很多事物和问题抽象起来，并且抽象它们不同的层次和角度。
将问题或事物分解并模块化使得解决问题变得简单，分解的越细模块数量也就越多，它的副作用就是使得设计者考虑更多的模块之间耦合度的状况。
设计阶段是通过设计方法找出软件实现更好的方法，留意这里是“更好”两个字，而不是强调最好。
不良设计并不会像需求分析失误那样很简单暴露出其本质，相反，它所暴露出的更多是表象，比如规律简单、维护时举步为艰等等。
假如参加者不具备肯定的洞察力以发觉隐蔽在现象背后的不良设计本质，则很有可能身受其害却不能自拔，还以为“原来就有那么简单”。
项目的开发是一个逐步演进的过程，项目组成员对于需求的理解也是逐步加深的，一开头合适的设计到后面看来很有可能就不够全面或显得力不从心，假如仍沿用以前的设计则自然将暴露出它的不足，进而会消失需要更高的维护成本。
重构思想的提出，就是用于关心项目演进设计的，当然，在运用重构方法时，应尽可能保证项目有足够的单元测试用例，以预防重构时又引入新的缺陷。
重构不只是一个词，其核心应当是一个方法论，一个用于优化设计的方法论。
1、思想上重视
充分认识设计阶段的重要性，从思想上强调设计阶段质量保障工作的必要性与重要性。
关于软件设计的重要性前文已从几个方面作了总结，不再赘述。
项目团队成员与甲方都要充分理解并全都认同设计规范与设计评审等质量管理措施对整个项目的意义与重要性。
2、选用合适的设计思想、设计方法
设计开头，在充分了解需求与项目背景的前提下，结合项目状况采纳恰当的设计思想与设计方法，从设计的指导思想与方法上避开设计阶段的质量瑕疵。
我们在做软件设计时还要依据项目的具体状况与应用场景选用合适的设计思想作指导，选用合适的建模方法帮我们尽快理清系统的业务规律并理出思路。
从方法学的角度来讲，软件的设计与开发从最初的机器语言-汇编语言进展到面对过程的结构化设计方法，到现在应用较多的面对对象、面对组件进展到面对服务，每一步都体现了不断抽象、更加贴近业务实务的进展趋势。
不管采纳什么样的设计方法进行架构设计，设计都需要以充分满足项目需求为目的，任何分析与设计方法只有针对具体问题才有实际意义。
另一方面要考虑的是，采纳的方法要侧重满足项目或产品的质量需求，也就是非功能性需求。
确保设计阶段的质量无忧。
3、项目管理上避开
项目管理是贯穿整个项目生命周期的，80%的软件项目质量问题是由项目管理造成的。
软件设计阶段作为软件项目的一个重要环节，要做好质量保障自然离不开好的项目管理。
从设计团队组建到角色分工与权责确定，到设计规范的制定与流程梳理，全部这些工作都需要一个好的团队负责人去把控。
设计团队负责人还要重视设计评审，通过设计评审不断发觉问题，逐步完善细化设计架构与具体设计说明书，作为后期代码实现与测试用例编写的指导。
要重视项目经理的作用，项目经理的职责是进行沟通，促进沟通并建立沟通的渠道。
只有通过沟通才能在项目成员间建立起认同与理解，从而将设计思路有效实现。
4、引入专业的第三方质量保障服务机构指导
一般的项目建设，乙方自己充当质量保障的角色，部分软件企业为了降低成本，尽可能的削减质量保障环节的资源支出，致使设计质量无法保障，即使有部分软件企业视质量为生命，建立了良好的质量管理体系，但是囿于精力所限或赶工期或质量保障阅历上的限制，设计质量也是不能令人满足。
而从甲方看，一般囿于人员、技术、精力的限制，甲方很难有精力或技术力量去对项目的质量进行深化的关注。
更何况软件本身并不行见，布满简单的规律关系，模块之间的耦合关联度不易把握。
第三方质量保障服务机构靠技术与服务来赢得客户信任，因而更加重视项目的质量与最终用户体验。
从而会更加专业的对待项目过程中的质量管理。
篇二：
软件质量保证
p4质量的定义：
质量是一组固有特性满足要求的程度，这里要求是指明示的，通常隐含的或必需履行的要求或期望
P36软件缺陷的定义：
从产品内部看，软件缺陷是软件产品开发或维护过程中所在的错误，毛病等各种问题从外部看，软件缺陷是需要实现的某种功能的失效或违反
P43软件质量的定义：
软件产品满足规定的和隐含的与需求力量有关的全部特征和特性，它包括：
（1）软件产品质量满足用户要求的程度
（2）软件各种属性的组合程度
（3）用户对软件产品的综合反映程度
（4）软件在用法过程中满足用户要求的程度
P79软件质量掌握定义：
软件质量掌握是一系列为开发一个高质量的软件产品所应用的流程和方法
软件质量掌握的主要目的是为了获得更高的开发效率，避开返工，提高市场竞争力。
软件质量掌握也是一个流程，把组织全部活动的内容文档化，并不断地改进更新，能够产生更好的质量掌握方法
P84软件质量掌握模型：
（PDCA）方案，执行，检查，行动
方案：
分析当前现状，发觉问题，找出缘由和主要缘由，制定质量方针，质量目标，质量方案书和管理原则等，如管理原则有，过程方法，管理的系统方法和持续改进
执行：
是方案的履行和实现，主要按方案的去做，去落实具体对策，并实施过程的监控，使活动按预期设想前进，最终达到方案设定的目标
检查：
是对执行后效果的评估
行动：
重点在于检查完结果，要实行措施，及总结胜利的阅历，吸取失败的教训，实施标准化，以后依据标准执行
P85软件质量掌握模型要素：
产品，过程，资源
产品：
在质量掌握中应当明确的是，一个过程的输出产品不会比输入的产品质量更高
过程：
在质量过程中，一些过程是惊醒质量设计并将质量构造入产品，而另一些过程是对质量进行检查
资源：
指为了得到要求质量的软件产品，过程所用法的时间，资金，人和设备。
P106基线的概念：
已经正式通过符合审批的某种产品。
它因此可作为进一步开发的基础，并且只能通过正式的改变掌握过程转变
第六章软件质量度量
6.3.1软件质量度量的分类
软件质量度量一方面可以根据度量方式或手段来划分；另一方面也可以按其度量的对象来分，而且后者也是商量的重点。
从度量方式来看，度量可分为挺直的和间接的度量。
．挺直度量，包括某个阶段的软件缺陷数、程序代码缺陷密度、软件性能、软件所耗资源、所投入的成本所付出的的工作量等。
．间接度量，包括功能性、简单性、效率、牢靠性、可维护性和很多其他质量特性，必需通过度量其他产品特性（如类的耦合性、内聚力、接口开放性、模块性等）来实现软件质量基本属性的度量。
软件质量度量又可以按其度量对象来分产品质量和过程质量的度量，两者相辅相成，缺一不行。
软件产品质量度量
软件产品质量包括两个层次---产品质量和用户满足度，所以软件产品质量度量主要集中在以下几个方面。
．软件平均失效时间，即MTTF度量，方法用来测量失效之间的时间间隔的平均值。
．缺陷密度，基于软件规模（源代码行数、功能点数、对象点数等）来测量每个单位内的缺陷数或预报软件发表后潜在的产品缺陷。
．软件产品质量属性度量，如简单性度量、内聚力、耦合性、适用性、可用性、可维护性、可扩充性度量等。
．牢靠性度量。
．客户满足度度量。
软件过程质量的度量
软件过程度量主要包括3大方面的内容：
成熟度度量、管理度量和生命周期度量。
．过程成熟度度量，主要包括组织力量度量、培训质量度量、文档标准化度量、过程定义力量度量、配置管理度量等。
．过程质量管理度量，主要质量方案度量、质量审查度量、质量测试度量、质量保证度量。
．生命周期度量，主要包括需求分析度量、设计度量、编程和测试度量、维护度量等。
（P146-147）
第7章软件牢靠性度量和测试
7.1.2软件牢靠性定义
软件牢靠性是软件系统的固有特性之一，它表明白一个软件系统根据用户的要求和设计的目标，执行其功能的正确程度。
（P178）
第九章软件评审
9.1.1软件评审的定义
评审是对软件元素或者项目状态的一种评估手段，以确定其是否与方案的结果全都，并使其得到改进。
检验工作产品是否正确地满足以往的工作产品中建立的规范，如需求或设计文档。
（P214）
9.4.1评审的方法
1.临时评审
临时评审是不正式的一种评审方法。
2.轮查
轮查又称为安排审查方法。
将需要评审的内容发送给各位评审员，并收集他们的反馈看法，但轮查的反馈往往不太准时。
走查
走查也属于一种非正式额评审方法，它在软件企业中被广泛用法。
产品的将产品向一组同事介绍，并收集他们的看法。
在走查中，占主导地位，由描述产品的功能和结构以及完成任务状况等。
小组评审
评审是有方案的和结构化的，特别接近于最正式的评审技术。
评审的参加者在评审会议前几天就拿到了评审材料，并对该材料独立讨论。
同时，评审还定义了评审会议中的各种角色和相应的责任。
审查
审查和评审很相像，比评审更严格，是最系统化、最严密的评审方法。
一般的审查过程包括了：
制定方案、预备会议和组织会议、跟踪和分析审查结果等。
审查具有其他非正式评审所不具有的主要地位，在IEEE中提到：
．通过审查可以验证产品是否满足功能规格说明、质量特性以及用户需求等；
．通过审查可以验证产品是否符合相关标准、规章、方案和过程；
．供应缺陷和审查工作的度量，以转变审查过程和组织的软件工程过程。
（P222）
第10章软件全面质量管理
10.1.1全面质量管理
TQM是全面的、全过程的、全员的和科学的质量的指导思想。
也就是说，TQM是一套思想体系，指导各类组织开展质量管理活动。
（P234）
10.3软件质量管理模式：
目标驱动模式，顾客导向模式，价值驱动模式，标准衡量模式，Cerosys的运行模式
10.3.1目标驱动模式
目标导向模式也可以称目标驱动模式，是以组织事先设定的各项经营，管理等业绩目标为核心，全部活动围绕这目标绽开，其结果也可以目标衡量10.3.2顾客导向模式
以顾客为中心，将顾客的需求，期望和关怀作为组织管理的活动原则和价值准则，格外是质量方针和质量目标，充分体现了以顾客为关注焦点的原则10.3.3价值驱动模式
价值驱动的质量管理模式，就是强调质量成本的概念，以消退PONC或COPQ的质量改进过程。
它强化员工基于成本的质量意识，以价值评估来展现出质量改进的成果，以财务数据直观的显示企业的质量改进所带来的效益.P244-P246
10.3.4其他管理模式
1.标准衡量模式
标准衡量模式，以标准为准绳，全部活动在标准的框架内绽开，其开发的流程遵守标准的商定，其结果要通过标准的检验。
（P249）
2.Cerosys的运行模式
Cerosys是文化、效能、关系的质量管理运行系统的缩写，产生于零缺陷管理世界，所以也被称为零缺陷运行系统的过程模式。
（P250）
第12章软件质量方案
1、朱兰三部曲就是质量策划、质量掌握、质量改进
质量策划：
为建立有力量满足质量标准化的工作程序，质量策划是必要的。
质量掌握：
为了把握何时实行必要措施订正质量问题就必需实施质量掌握。
质量改进：
质量改进有助于发觉更好的管理工作方式。
P299
第16章软件测试的质量
2、软件测试的目的：
软件测试是为了发觉错误而执行程序的过程
一个好的测试能够在第一时间发觉程序中存在的错误
一个好的测试可以发觉至今尚未发觉的错误
P396
推断题
（√）1.在专业的软件开发、维护中，SQA环境是建立、执行SQA方法时必需首要考虑的问题。
（×）2.如何看待软件产品内部的缺陷，开发者和用户的立场是全都的。
（√）3.专家观点通过引进补充的外部力量到机构内部开发过程中来而支持质量评估工作。
（×）4.质量管理标准是专业标准，它们向开发组供应方法学指南。
（√）5.软件生命周期模型强调的是挺直开发活动，而没有指示出开发过程的顾客参加。
（×）6.规程具有机构范围的适用性，它的执行和具体执行的人或组织背景有着亲密关系。
（×）7.CAPA的目的在于检测、处理、改正软件缺陷。
（×）8.项目进展掌握SQA工具有Gatt图、日历、数据流图和活动网络图。
（√）9.IEEE、ISO、DOD、ANSI、EIA都是有名的SQA标准开发机构。
（√）10.在科学和工程中，假如没有度量，对一切都没有一个定量的了解，那么这种科学和工程既不是有效的，也不是实际的。
（×）11.软件故障是导致软件失效的必要和充分要素。
（√）12.同行评审的主要目标在于检测错误、核对与标准的偏离。
（√）13.在任何软件机构中，定期、不定期的培训、再培训都是必需而且是必要的。
（√）14.在整个机构中用法基础设施防护与改进部件的主要目标是在机构积累的SQA阅历基础上消退或至少降低出错率。
（×）15.全部SQA活动和项目里程碑的完成或项目里程碑的检验是同时发生的。
（×）16.DanielGalin等提在20世纪50年月建立的经典质量费用模型，供应了一种以经济学观点把与产品质量保证相关的费用非类的方法学。
（√）17.一旦更改过的SCI替换了前面的SCI，就认为完成了软件的一个新版本。
（√）18.软件质量成本是一个投资问题，而不是成本问题!
（×）19.SEICMM评估标准,ISO9001和ISO9000-3标准是典型的项目过程标准。
（√）20.软件质量保证的独特性是由软件产品不同于其他制造产品的本质决定的。
（×）21.在软件产品制定生产方案阶段,不必进行重大的SQA活动。
（√）22.软件故障是导致软件失效的必要，而非充分要素。
（×）23.只有客户才会有爱好透彻定义它的需求以确保他商定的软件产品的质量。
（√）24.软件质量系统之间各不相同，说明机构SQA系统构建存在固有敏捷性。
（√）25.质量管理标准指导软件开发、维护和基础设施的管理。
它的重点是需要什么，但没有指明如何达到标准要求的努力详情。
（×）26.通常，检查表的用法的是强制性的。
（×）27.CAPA的执行从根本上依靠于正确的指导和常常的培训。
（√）28.软件质量度量面临的特有困难根植于包含于软件质量度量的测量（参数）中。
（√）29.一旦更改过的SCI替换了前面的SCI，就认为完成了软件的一个新版本。
（×）30.SQA项目过程标准如CMM、ISO9000-3标准。
篇三：
软件开发质量保证方案
1软件开发质量保证方案
1.1质量管理内容
1.1.1编制和评审质量方案
制定质量保证方案：
依据项目方案及项目质量目标确定需要检查的主要过程和工作产品，识别项目过程中的干系人及其活动，估量检查时间和人员，并制定出本项目的质量保证方案。
质量保证方案的主要内容包括：
例行审计和里程碑评审，需要监督的重要活动和工作产品，确定审计方式，依据项目方案中的评审方案确定质量保证人员需要参与的评审方案。
明确质量审计报告的报送范围。
质量保证方案的评审：
质量保证方案需要经过评审方能生效，以确保质量保证方案和项目方案的全都性。
经过批准的质量保证方案需要纳入配置管理。
当项目方案变更时，需要准时更改和复审质量保证方案。
1.1.2“过程和工作产品”的质量检查
依据质量保证方案进行质量的审计工作，并发布质量审计报告。
审计的主要内容包括：
是否根据过程要求执行了相应的活动，是否根据过程要求产生了相应的工作产品。
本项目中对质量的掌握主要体现在不同阶段的审计当中。
1.1.3不符合项的跟踪处理
对审计中发觉的不符合项，要求项目组准时处理，质量保证人员需要确认不符合项的状态，直到最终的不符合项状态为“完成”为止。
1.2质量管理责任安排
我公司在开发项目上根据规范化软件的生产方式进行生产。
每个项目除配备了项目开发所需角色外，还特地配备了质量保证小组、配置管理小组、测试小组来确保质量管理的实施，下面针对这三种角色进行说明：
1.2.1质量保证小组职责
质量保证小组作为质量保证的实施小组，在项目开发的过程中几乎全部的部门都与质量保证小组有关。
质量保证小组的主要职责是：
以独立审查方式，从第三方的角度监控软件开发任务的执行，分析项目内存在的质量问题，审查项目的质量活动，给出质量审计报告。
就项目是否遵循已制定的方案、标准和规程，给开发人员和管理层供应反映产品和过程质量的信息和数据，使他们能了解整个项目生存周期中工作产品和过程的状况，提高项目透亮度，从而支持其交付高质量的软件产品。
质量保证人员依据质量保证方案，通过质量审计报告向项目经理及有关人员提出已经识别出的不符合项，并跟踪不符合项的解决过程，通过审计周报或者审计月报向项目经理供应过程和产品质量数据，并与项目组协商不符合项的解决方法。
质量保证小组的检测范围主要包括：
项目的进度是否根据项目方案执行，用户需求是否得到了用户的签字确认，软件需求是否正确的反映了用户的需求，是否将每一项用户需求都映射到软件需求；系统设计是否完全反映了软件需求；实现的软件是否正确的体现了系统设计；测试人员是否进行了较为彻底的和全面的测试；客户验收和交接清单是否完备；对于系统运行中消失的问题，维护人员是否记录了具体的维护记录；配置管理员是否根据配置管理方案建立了基线，是否严格掌握变更过程，是否对配置库进行了维护。
1.2.2配置管理小组职责
配置管理活动的目的是通过执行版本掌握、变更掌握、基线管理等规程，借
助配置管理工具的用法，来保证整个生命周期过程产生的全部配置项的完整性、全都性和可追溯性。
配置管理是对工作成果（阶段工作成果和产品成果、进展状态成果）的一种有效爱护形式，是反映项目及其工作产品的过去、现在、动态的资料和数据集中管理体现。
配置管理小组的主要职责包括：
依据项目方案制定配置管理方案，建立配置库，为项目组人员安排配置库权限，创建需求、设计、开发、测试、交付阶段的基线。
当纳入基线库的工作产品发生变更时，严格根据配置项变更掌握过程执行变更，变更后建立新的基线。
1.2.3测试小组职责
作为质量掌握的主要手段，犹如软件开发一样，测试在执行之前，测试小组制定软件测试方案、测试用例的编写和执行工作。
本项目中，测试可以分为如下几种类型：
代码走查、单元测试、集成测试、系统测试。
为了保证程序的质量，开发人员需要对同伴的代码进行代码走查，同时对自己编写的程序进行单元测试，确保程序编译、运行正确。
测试人员依据软件需求分析报告进行软件集成测试用例和系统测试用例的编写。
对编写完成的测试用例提交项目组进行评审，同时质量保证人员对评审过程和工作产品进行监测。
测试人员依据测试方案和测试用例执行测试用例，并对发觉的缺陷进行记录，只有这样才能确保项目组开发的软件产品满足用户需求。
在完成集成测试之后，可以进行软件系统测试，系统测试包括对软件进行功能测试、性能测试、平安测试、压力测试。
只有进行了系统测试软件测试才是完整的。
系统测试在本项目中占有重要的地位，性能要求有可能转变软件的设计，为避开造成软件的后期返工，测试在性能上需要较大的侧重。
1.3质量保证措施
通过质量管理责任的安排，通过如下几个方面来进行质量保证的实施过程：
1.3.1项目进度
项目方案的制定为工程项目实施、管理和支持工作、项目进度、成本、质量及过程产品的有效掌握打下了良好的基础，以便全部相关人员能够根据该方案有条不紊地开展工作；制定《项目方案》，必需获得相关干系人的认可，并以此作为项目跟踪的基础。
项目进度是项目进行是否顺当的最直观表现。
制定合理的项目方案首要前提是选择从事类似规模和类似业务项目的有阅历的项目负责人参与制定项目进度方案。
项目方案由项目负责人制定，由项目各小组组长、项目成员、干系人、质量保证人员参与一起进行评审。
评审过程主要商量项目方案的可行性，对其中不合理的地方提出修改看法，对方案中不合理的地方进行修改完善，并由质量保证人员对其结果进行跟踪处理，以确保项目方案完整性、可行性，项目方案评审通过后，交由配置管理人员进行配置管理。
在方案实施过程中，按项目方案中里程
升级会员 