软件质量保证和管理pdf 软件质量保证
摘要:什么是软件测试与软件质量保证? 通常在一般的中小企业中会不将软件测试与软件质量保证加以细分,软件测试人员也叫做质量保证人员即QA,我所在公司也是如此。其实软件测试与软件质量保证是软件质量工程的两人不同...
发布日期:2021-04-24什么是软件测试与软件质量保证?
通常在一般的中小企业中会不将软件测试与软件质量保证加以细分,软件测试人员也叫做质量保证人员即QA,我所在公司也是如此。
其实软件测试与软件质量保证是软件质量工程的两人不同层面的工作。
质量保证(QA)是通过预防,检查与改进来保证软件质量的。
QA所关注的是软件质量的检查和测量,他的工作是软件生命周期的管理以及验证软件是否满足质量和用户需求,主要着眼于软件开发活动中的过程、步骤和产物,而不对软件进行剖析找出问题。
一般情况下,QA应独立于项目之外,以第三方的姿态来对整个开发过程进行评审,检查开发和管理活动是否与已定的过程策略、标准和流程一致,检查工作产品 是否遵循模板规定的内容和格式。
所以,质量保证是通过过程改进来保证软件质量的。
软件测试关注的不是过程活动,而是每个过程活动的产出物。
它对活动的产物进行剖析,检测以期发现更多的问题,从而保证软件质量。
所以软件测试是保证软件质量的一个重要环节,但不是质量保证的一个环节。
对软件测试与软件质量保证进行区分并不是闲聊而咬文嚼字,而是要知道他们都是为了保证软件质量的两个不同层面的工作,他们对保证软件质量有着不可替代的作用。
但现实中大部分中小企业都只知道软件测试而没有专门的质量保证,即使有也是虚设,其实这是本末倒置。
软件测试只是项目中的一个流程或是环节,只是对个别项目。
所以个别项目如果取得成功,质量得到了很好的保证,可能是因为项目的个别因素,如项目需要做得较好或是测试人员水平较高等个别因素。
所以一个项目做得好不能保证别的项目也做得好,即是公司的开发水平,产品的质量水平能够提高。
这就需要通过质量保证来提取成功的因素而上升到流程规范上来规范所有项目,从而提高公司产品质量水平。
一个公司的好的管理标准就是有个好的规章流程得以执行,所以一个好的项目管理,质量保证也在于规章流程,这些也是共性的东西,才不会以项目中的个别因素改变而改变。
当然,也并不是说有好的质量保证就有好的产品质量,他们之间不是充分的关系,而是必要。
软件质量,软件质量保证,软件质量管理三者有什么不同
可划分为三组,分别反应用户在使用软件产品时的三种观点。
正确性、健壮性、效率、可维修性、灵活性、可测试性(产品修改)、完整性、实践和方法能够正确地被所有项目所采用。
软件质量保证的目的是使软件过程对于管理人员来说是可见的。
它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。
软件质量保证组在项目开始时就一起参与建立计划、可用性、以及所有专业开发的软件都应具有的隐含特征的程度。
影响软件质量的主要因素,这些因素是从管理角度对软件质量的度量。
这些将使软件项目满足机构方针的要求软件质量管理可以说是一个制度或者一个体系、互运行性(产品转移)。
软件质量保证是建立一套有计划,有系统的方法,来向管理层保证拟定出的标准、步骤、标准和过程、风险(产品运行);可理解性,软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”;可移植性、可再用性。
具体地说,软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准...
【软件质量是什么】什么是软件质量保证呢?
1) RUP的质量保证思想之一:全过程质量保证思想 您当前浏览的文章来源于考试大项目管理站。
RUP把整个软件开发过程分解成:业务建模、需求管理、分析设计、实施、测试、部署、配置与变更管理、项目管理和环境等九个核心工作规程。
每个核心工作规程由多个详细工作流程组成。
基于人类对软件工作过程最原始的感受,RUP使用角色、活动和作为输入输出的工件来组织每个详细工作流程,实现软件开发组织内部人、资源和流程的融合。
RUP通过建立完整的软件开发过程,使得产品的质量由项目团队的每个成员共同负责,具体体现在: 每个角色承担相应的质量任务 每个活动产生合格的工件 为每个工件建立指南、模板和检查点 每个工作流程设定相应的工作指南和检查点 在RUP中,整个软件开发过程如上图所示,它以指定的工件为输入,通过软件开发角色和标准化的软件开发活动,生产出满足质量要求的输出工件。
为确保每个工作环节的有效执行和每个工作环节产生的工件质量,RUP为主要工作流程提供了对应的工作指南和检查点,为每个工件建立指南、模板和检查点,从而保证了软件开发的过程质量。
2) RUP的质量保证思想之二:软件工程成功经验共同铸就软件质量的思想 激烈的市场竞争催生高质量的软件。
如何保证软件质量?
软件在没有发布之前的开发过程主要分为需求分析、设计、编码和验证四个阶段,最终的软件质量与这四个阶段的各自质量之间的关系如果用C语言来表达的话应当是: 最终的软件质量 = 需求分析质量 && 设计质量 && 编码质量 && 验证质量 即,最终的质量来自于各阶段质量之“与”,只要其中一个环节质量是差,则产品的整体质量都将是差,千万不要认为是“或”的关系。
由此看来每一个阶段的质量都起着决定性的作用。
以上提及的四个阶段的质量将引出以下几个软件质量保证的关键要素。
完备的需求分析 需求分析的目的是让项目组明白要做什么,是决定所开发出来的软件应当是“长什么样的”,显然完备的需求分析是高质量软件的前提。
如果所开发出来的软件与用户所希望的并不一致,那不可能让用户说“这个软件的质量很好” 。
如果方向不对,软件开发得再“好”也没有意义。
需求分析失误所带来的开发成本是高昂的,这一点在《软件工程》这类书籍中都会提及,因此,整个行业对于需求分析的重要性都具有足够的认识。
当然,知道其重要性与如何获得完备的需求分析又是两回事,至于如何做好需求分析请读者参考相关书籍。
需求分析如果出现失误的话有一个特点 —— 它一定会暴露!只不过存在是暴露在软件开发过程中还是在用户手中之别。
因此,需求分析所造成的问题尽管严重,但它能被发现进而能得到项目组的重视,从而也一定能被修复,只是不同阶段发现这类问题所花费的成本将有所不同。
设计 设计阶段是通过设计方法找出软件实现更好的方法,注意这里是“更好”两个字,而不是强调最好。
不良设计并不会象需求分析失误那样很容易暴露出其本质,相反,它所暴露出的更多是表象,比如逻辑复杂、维护时举步为艰等等。
如果参与者不具备一定的洞察力以发现隐藏在现象背后的不良设计本质,则很有可能身受其害却不能自拔,还以为“本来就有那么复杂”。
项目的开发是一个逐步演进的过程,项目组成员对于需求的理解也是逐步加深的,一开始合适的设计到后面看来很有可能就不够全面或显得力不从心,如果仍沿用以前的设计则自然将暴露出它的不足,进而会出现需要更高的维护成本。
重构思想的提出,就是用于帮助项目演进设计的,当然,在运用重构方法时,应尽可能保证项目有足够的单元测试用例,以预防重构时又引入新的缺陷。
重构不只是一个词,其核心应当是一个方法论,一个用于优化设计的方法论。
编程好习惯 设计阶段输出的结果就是蓝图,但好的蓝图并不能保证最后的质量一定就好。
拿造房子打个比方,图纸设计得再好,如果建造时用的材料不过关,那最终的房子一定好不了。
那软件开发中的“建筑材料”又是什么呢?就是程序员所编写的代码。
如何保证其质量呢?这需要通过良好的编程习惯去保证。
在现实的项目中,设计有可能与编码会有一定的揉合,即通过进行一定的编码来辅助设计。
这种实践方式并不影响这里将设计与编码分为两个质量保证关键要素。
验证 验证很容易让人想到质量保证的常用方法之一,即测试。
但验证应当包含更多的内涵,比如求证软件需求是用户所希望的就是其中的一种。
对于验证的理解仍需要拿房屋的建造作为一个比方,以便加深理解。
在房屋的建造过程中,当建筑材料到了工地以后,需要对其进行检验,以保证它的质量是合格的,否则不能用于建造。
对应于软件开发,这个阶段就是单元测试。
当软件工程师编写了代码以后如何保证代码的行为是其所希望的呢?那只能通过单元测试去验证。
房子建造好了以后,还得对房子进行整体的验收以确保其最终是合格的。
软件质量保证阅读英文版本是什么?
SOFTWARE QUALITY ASSURANCE The activity of softwae quality assuance is closely elated to veification and validation activities caied out at each stage of the softwae life cycle[1].Indeed,in many oganizations thee is no distinction made etween these activities.Howeve,quality assuance and othe veification and validation activities ae actually quite sepaate,with quality assuance eing a management function and veification and validation eing pat of the pocess of softwae development[2].An appopiate definition of softwae quality assuance is povided y Besoff(1984):Quality assuance consists of those pocedues,techniques and tools applied y pofessionals to ensue that a poduct meets o exceeds pespecified standads duing a poducts development cycle[3];and without specific pescied standads,quality assuance entails ensuing that a poduct meets o exceed a minimal industial and o commecially acceptale level of excellence. This definition is,of couse[4],a faily geneal one and it suggests that,fistly,softwae standads can e estalished and,secondly,the level of excellence of a softwae poduct can e estimated. The development of softwae engineeing poject standads is an extemely difficult pocess. A standad is some astact epesentation of a poduct which defines the minimal level of pefomance,oustness,oganization,etc.,which the developed poduct must attain[5].At the time of witing,some softwae standads have een developed y the IEEE,ANSI and militay oganizations. These standads descie configuation management plans,documentation,specification pactices,softwae compaisons,etc.Othe standads which ae cuently unde development include standads foeliaility,measuement,the use of Ada as PDL[6],softwae testing and othes.Bansta d and Powell(1984)descie oth existing and planned softwae standads as well as discussing standadization in moe geneal tems. The polem with national softwae standads is that they tend to e vey geneal in natue. This is inevitale as,unlike hadwae,we ae not yet capale of quantifying most softwae chaacteistics.Effective quality assuance within an oganization thus equies the development of moe specific oganizational standads. Of couse,the polem which aises in developing softwae standads fo quality assuance and which makes the assessment of the level of excellence of a softwae poduct difficult to assess is the elusive natue of softwae quality.Boehm et al.(1978)suggest that quality citeia include ut ae not limited to:Economy Coectness ResilienceIntegity Reliaility UsailityDocumentation Modifiaility ClaityUndestandaility Validity MaintainailityFlexiility Geneality PotailityInteopeaility Testaility EfficiencyModulaity Reusaility Exactly how some of these citeia may e quantified is not clea.Futhemoe,as Buckley and Poston(1984)point out,pats of this definition may have no value fo a paticula poduct.It may e possile to tansfe a system fom a micocompute to a lage mainfame ut this is often a nonsensical thing to do.Assessment of softwae quality thus still elies on the judgement of skilled individuals although this does not mean that it is necessaily infeio to quantitative assessment.Afte all,we cannot assess a painting o a play quantitatively yet this does not peclude a judgement of its quality. Within an oganization,quality assuance should e caied out y an independent softwae quality assuance team who epots diectly to management aove the poject manage level.The quality assuance team should not e associated with any paticula development goup ut should e esponsile fo quality assuance acoss all poject goups in an oganization.The activity of quality assuance involves sitting in on design eviews[7],pogam walkthoughs,etc. ,and epoting on the oveall quality of the poduct as it is developed.It also involves checking that the finished poduct and its associated documentation confom to those standads which exist.The quality assuance team may also assess if the diffeent epesentations of a poduct(equiements,design,code)ae consistent and complete. Notice that quality assuance is not the same as system testing.It is the development o testing team"s esponsiility to validate the system,with the quality assuance team epoting on oth the validation and the adequacy of the validation effot.This natually involves quality assuance eing closely associated with the final integation testing of the system.Softwae quality assuance is now an emeging sudiscipline of softwae engineeing[8].As Buckly and Poston point out,effective softwae quality assuance is likely to lead to an ultimate eduction in softwae costs.Howeve,the majo hudle in the path of softwae management in this aea ...
什么是ISO900质量管理和质量保证体
ISO9001标准和CMM方法同是适用与软件的质量保证能力(SQA)评价的两个方法,两者是从不同的角度去考虑对软件的SQA。
ISO90001标准本来是适用于工业过程的QA管理。
经过几十年的不断完善,取得了全世界130多个国家的认可,具有广泛的前景。
为了满足新兴产业的不断出现,在ISOTC176的组织下不断完善,先后对ISO9000家族进行了大规模的补充,如在服务业、流程性材料制造业以及软件业的实施要求先后出版。
使标准的适用范围有较大的发展,特别制定了适用软件业的ISO9000-3:94,使软件业贯彻ISO9000标准与软件业的专业标准有良好地融合,如同ISO12207《软件生存周期过程》之间有良好的兼容性。
ISO9001标准始终站在顾客的角度上,以如何满足顾客需要为出发点来看待SQA。
ISO9001标准要求从软件的项目的合同评审-项目开发-安装-服务-质量改进全过程的进行完善的SQA控制,其中包括了对人员的培训及用于质量改进的统计技术。
要求软件企业应建立SQA的定量度量方法,以便进一步改进软件质量。
ISO9001标准要求的是软件企业起码应达到的要求,换句话说,如果一个软件开发企业,连ISO9001标准20个要素的要求都不能保证,其SQA一定不完善,产品的质量也不会有良好的保证。
因此,在ISO9001认证标准中没有对通过认证的企业进行分级,而事实上,通过了ISO9001认证的企业在SQA方面可能有一些差距,但具备了起码的SQA能力,至少应当建立相当于CMM三级水平的SQA体系。
任何企业通过认证只是第一步,还需要在以后的生产过程中持之以恒、不断改进、不断完善其QA体系,使之满足不断变化的市场需求。
CMM是从专业的角度对软件企业产品开发和质量保证能力进行评价,对软件开发过程中的每一个关键过程进行详细的描述,以利于企业衡量自身的软件开发能力和SQA能力。
而不是站在顾客的角度去考虑顾客的全部要求是如何被满足的,并提供必要的过程实施证这样一个事实。
CMM对软件开发过程的描述要比ISO9001要详细的多。
ISO9001标准对软件开发过程的描述则直接引用ISO12207标准,两者在企业实施SQA的过程中实质上是相同的,只是考虑问题的角度不同而已。
ISO对软件开发企业的等级评定采用了CMM同样的方法,对应的标准为ISO15504《软件过程评估》。
由于CMM是软件自身评价软件企业软件开发能力和SQA能力的规范,CMM将软件企业的能力分为5个级别,即: 第一级::初始级(没有关键过程域) 第二级:可重复级 第三级:定义级 第四级:定量管理级 第五级:(不断)优化级 在CMM中对软件开发的关键过程的要求进行了描述,使软件开发企业可以更加明确评价自身SQA能力,以便实施质量改进。
CMM方法也是一种很好的改进企业SQA能力的途径,引进CMM与贯彻ISO9000并不矛盾,两者实际上是紧密联系的。
CMM中各级别的要求在ISO12207中均有明确的描述,CMM方法也只是一种分级的方法,就像ISO9000是一种认证标准一样。
实际的实施内容还得按照软件工程中的要求进行。
比如软件开发过程中的如何定量问题,在ISO9000及CMM中均没有明确的描述,只是提出了要求。
由于ISO9000标准和CMM对软件开发企业都是新事物,对一个企业来讲要选择其中一个而放弃另外一个是困难的。
对两种SQA评定方法的理解程度可能使企业的决策层对如何建立企业的SQA有不同的理解,但事实上两者是相得益彰的,都符合质量管理中PDCA的概念。
软件质量改进的依据实际上就是取决与对现行SQA体系的正确评价,而如何评价企业的SQA能力则恰好是CMM的主要内容。
在CMM和ISO9000的实施过程中,充分考虑两种方法的不同,可使企业从不同的角度全面审视自身的SQA体系,为企业的SQA体系改进提供更加充分的依据。
SQA的建立以及对企业经济效益上的贡献不是立竿见影的,任何期望在短期内实施QA能获得直接的明显的经济效益都是不切实际的。
QA对企业的贡献在于防范不符合的发生,并使企业通过系统的质量改进获得长远的利益。
顾客对CMM认证的认可程度同样取决于对认证机构的认可和了解程度。
目前经国务院批准的ISO9000认证机构认可委员会有两个,即国家进出口商品质量认证机构认可委员会(CNAB)和国家认证机构认可委员会(CNACR),两个委员会均为IAF成员。
国内所有认证机构均在上述两个委员会注册。
但从事CMM认证的国家机构尚未成立,目前个别企业通过国外机构引入了CMM认证,而已经通过了CMM评定的企业更少。
软件开发企业如何建立SQA体系,进行什么样的认证,要根据企业SQA能力的实际需要、企业的财力、物力等方面进行综合考虑,选择最佳改进SQA能力的途径。
GB/T 12505 计算机软件配置管理计划规范和GBT 12504计算机软件质...
GB/T 12505 计算机软件配置管理计划规范和GB/T 12504计算机软件质量保证计划规范被国标委公告(2005年第146号)文废止,废止后没有替代规范。
下列规范应该含盖了相关内容GB/T 20158-2006 信息技术 软件生存周期过程 配置管理GB/T 18492-2001 信息技术系统及软件完整性级别GB/T 15532-2008 计算机软件测试规范GB/T 11457-2006 信息技术 软件工程术语GB/T 8566-2007 信息技术 软件生存周期过程GB/T 8567-2006 计算机软件文档编制规范...
有效的软件质量管理是怎样的?
质量管理包括:质量计划编制、质量保证和质量控制三个过程域。
质量计划是质量管理的第一过程域,它主要结合各个公司的质量方针,产品描述以及质量标准和规则通过收益、成本分析和流程设计等工具制定出来实施方略,其内容全面反应用户的要求,为质量小组成员有效工作提供了指南,为项目小组成员以及项目相关人员了解在项目进行中如何实施质量保证和控制提供依据,为确保项目质量得到保障提供坚实的基础。
质量保证则是贯穿整个项目全生命周期的有计划和有系统的活动,经常性地针对整个项目质量计划的执行情况进行评估、检查与改进等工作,向管理者、顾客或其他方提供信任,确保项目质量与计划保持一致。
质量控制是对阶段性的成果进行检测、验证,为质量保证提供参考依据,它是一个PDCA循环过程。
随着社会信息化水平的不断提高,信息行业急速膨胀,信息企业快速成长,随之带来的信息市场竞争激烈,企业为了求生存,满足客户要求则成为各行各业的首要责任。
依赖于质量、成本和进度的客户满意度,质量则是重点支撑之一,这样要求我们对质量管理需要加强认识。
我们都知道pmok把项目管理划分为9个知识领域,即范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、采购管理、风险管理和综合管理。
质量管理作为9大知识领域之一,可见其重要性。
二 质量管理责任分配 我们公司在开发项目上按照规范化软件的生产方式进行生产,在生产流程上采用ISO9000的标准进行。
每个项目除配备了项目开发所需角色外,还专门配备了配置管理小组、测试小组和质量保证小组确保质量管理的实施,下面针对这三种角色进行说明: 1、配置管理小组职责 配置管理小组是保证项目开发完毕的同时,内部文档和外部文档都同时完成。
内部文档的及时产生和规范,是保证项目开发各小组能够更好的接口和沟通的重要前提,从另一个方面讲,也是保证工程不被某个关键路径所阻塞而延滞的前提。
如上所述,配置管理小组还是保证质量保证小组得以发挥作用的基础。
配置管理小组的主要职责包括: 完善各个部门发送需要存档和进行版本控制的代码、文档(包括外来文件)和阶段性成果; 对代码、文档等进行单向出入的控制;对所有存档的文档进行版本控制; 提供文档规范,并传达到开发组中。
2、测试小组职责 测试小组作为质量控制的主要手段,负责软件的测试设计和执行工作。
如同软件开发一样,测试在执行之前,同样需要进行测试计划和测试策略的设计,通常情况下测试可以分为如下几种类型,如:正确性测试、功能性测试、性能测试、安全测试和系统测试等。
而这些测试均需要在测试计划和测试策略中进行描述用以指导测试小组成员进行测试用例编写和测试执行。
程序员在交给测试人员之前是进行过一定的单元测试,确保程序编译、运行正确。
测试人员根据详细设计的文档对软件要实现的功能进行一一测试,保证软件的执行正确的实现设计要求,在此也只证明了软件正确的反映了设计思想,但是否真正反映了用户的需求仍需要进一步的功能性测试。
测试人员只有根据软件需求规格说明书所提及的功能进行检测,才能确保项目组开发的软件产品满足用户需求。
在正确性测试完成之后,需要测试的是软件的性能,软件的性能在本项目中占有重要的地位,性能要求有可能改变软件的设计,为避免造成软件的后期返工,测试在性能上需要较大的侧重。
如果有必要的话,测试小组还需要做安全测试,以确保系统使用安全可靠。
3、质量保证小组职责 质量保证小组作为质量保证的实施小组,主要职责是保证软件透明开发的主要环节。
在项目开发的过程中几乎所有的部门都与质量保证小组有关。
质量保证小组对项目经理提供项目进度与项目真正开发时的差异报告,提出差异原因和改进方法。
在项目进度被延滞或质量保证小组认为某阶段开发质量有问题时,提请项目经理、项目负责人等必要的相关人员举行质量会议。
解决当前存在的和潜在的问题。
质量保证是建立在文档的复审基础之上,因而文档版本的控制,特别是软件配置管理,直接影响软件质量保证的影响力和力度。
质量保证小组的检测范围包括:系统分析人员是否正确的反映了用户的需求; 软件执行体是否正确的实现了分析人员的设计思想; 测试人员是否进行了较为彻底的和全面的测试;配置管理员是否对文档的规范化进行的比较彻底,版本控制是否有效。
三 质量管理实施 有了良好的资源配备,又如何在项目全生命周期内实施质量保证,让我们从以下几个方面来看质量保证的实施过程: 1、项目进度的质量保证 项目进度是项目进行是否顺利的最直观表现。
显然在项目开始之前,项目开发计划是必须的。
如果项目开发计划的制定的是完全合理的,那项目进度也就真正表达了项目与最终的交付使用之间的距离,然而要制定完全合理的项目开发计划几乎不太可能。
可见要保证项目进度,首先要保证项目开发计划尽可能合理。
项目计划的合理程度与项目计划制定者从事类似规模和类似业务的项目的经验有直接关系,通过经验往往能够预见潜在的阻碍,这样要求项目计划制定者需要...