软件质量保证方法论

软件质量保证方法论（精选6篇）

软件质量保证方法论 第1篇

论软件质量保证的方法和策略

【摘要】

本文讨论某省环保厅重点污染源在线监测系统的质量保证方法和策略。该系统的目标是全天候在线监控重点污染源企业污染物排放情况及污染处理设施运行情况，包括污染源自动监控及污染源报警，主要实现污染源远程监测、现场数据采集、自动判断是否超标、超标报警等功能，满足全省环境监察人员对重点污染源企业监测数据的查询分析、报表打印、远程自动采样等需求。污染源在线监测系统对质量要求较高，系统自交付运行以来，用户反馈表明质量特征上很好的满足了在线监测的需求。在软件开发的过程中我们采取了全过程的质量管理，围绕软件的6个质量特征因子，形成了软件开发团队的约束文件，针对不同角色制定了不同的质量主题，做到了软件质量的可控性。在该项目中我担任了项目经理，参与了系统的分析与设计工作。

【正文】

近年来，随着社会经济的发展，环境污染负荷逐渐增加，环境问题已经成为关系到国家和民族生存的重大问题。为有效加强污染源监管，提高环境监察执法信息化应用能力工作迫在眉睫。2008年3月份某省环保厅委托我所在的公司承担污染源在线监测系统的开发。本系统主要实现对企业排污、污染治理设备及监测、监控设备进行实时监测。当发生排污超标、治理设施停运等异常事件时，现场适配器自动识别事件类型，报送环境监察部门，并告知事件内容。该项目整个项目历时7个月，在2008年10月份交付使用。系统使用一年多来该省环保厅环境监测和执法能力有了很大提高，得到了用户的一致好评。

一、需求分析阶段，通过结对分析与需求评审保证需求分析的质量

需求分析的质量是否优良，决定着后继各工作环节能否按既定方向进行。由于客户环境监察工作较为繁忙，计算机应用水平不高等因素，与中层管理人员、基层操作人员的交流有很大困难，参与项目的时间与精力得不到保障，因此，我们制订了结对分析的策略，以提高需求分析的效率与质量。

结对是敏捷软件开发一个最佳编程实践，我们创造性地将其引入到需求分析阶段。需求分析各个环节(包括需求获取、分析，与用户沟通)均由两个开发人员来共同完成，能取得较高的需求分析质量。例如，这一策略在企业信息管理这一关键环节的需求分析上发挥了重要作用。企业信息管理人员年纪较长，对计算机概念模糊，沟通上存在很大障碍，通过两个需求分析人员共同来完成该项工作，做到了分析人员的优势互补。通过结对分析不仅得到较高的需求分析质量，并且节省了用户的时间，对用户也有一定的推动。只有两个分析人员达成一致，才将相应需求嵌入基线库中，保证了需求的科学性。这样做虽然增加了人力成本，但提高了需求分析效率。

强化需求评审。需求评审分为三个层次：①全局评审。参与人员主要是用户方核心管理层、业务领域专家、分析人员。主要任务是评审需求与公司目标、高层想法是否一致。这一评审至关重要，它把握了软件系统实施方向的正确性。②局部评审。参与人员主要是用户方业务中层及一线操作人员、业务领域开发工程师。主要任务是就业务层相关业务流程进行再次确认。因为需求过程中相应部门的业务人员站在自己的角度看待问题，对于整个流程关心不够，需要纠正各部门用户需求不一致的问题。③内部评审。全体开发人员、分析人员参与。分析人员建立初步的UML用例图，工作流程图，活动图等供全体讨论。任务是澄清一部分模糊的需求。

在需求阶段，还采取了其它措施来保证需求分析的质量，如强调需求分析工具的使用等。

二、系统设计、编码阶段，强调纪律与规范

设计与编程质量对于软件产品的质量有着直接的作用。在这一阶段，我们的主要采取的措施是强调纪律与规范，制订相应的约束规范文件，要求设计有可追溯性，强调设计、开发过程标准化。另一主要措施选择适合的工具。我们选择的开发平台为，NET，开发工具为Visual Sutdio 2005，后台数据库为SQL Server 2005，使用数据库智能感知小工具SQL Prompt，代码生成工具CodeSmith生成代码，NDoc来生成设计文档，使用微软企业库。企业库是微软针对共性内容发布的经过实践检验的高质量产品。

我们制订了NET编码规范，目的是保证不同开发人员的代码风格基本一致，降低开发人员流动可能导致的项目风险;强调代码的可理解性与“设计先行与强化注释”;制订了SQL书写规范。这一系列规范标准的制订从源头上保证了软件设计的质量。

编码人员分成两类角色：业务领域工程师和核心代码工程师。业务领域工程师针对具体的业务功能进行编码。在设计时我们要求业务领域工程师要有这样的意识：变更不可避免，在设计时尽可能考虑到将来变更的可能性，尽可能做到模块之间的松耦合，模块内部的高内聚。核心代码工程师完成公共代码的实现与维护。核心代码质量在系统中至关重要。对核心代码工程师加以分组，每组两位工程师实行结对编程。以克服思维局限，共同完成设计、UML图、实现，保证代码质量。实践证明，采取这些办法后，在用户提出相应功能变更时，软件修改相对较轻松，能较好地适应业务变化。

三、强调软件实现与测试同步，强化缺陷管理

测试是保证软件质量较为重要的一个环节。针对开发团队部分成员测试意识不强，项目

组有针对性地进行培训;强调测试与设计同步，测试用例与功能代码的编制同步;及时进行单元测试，统一用VS2005 for Tester作为测试工具;缺陷管理统一存放在服务器中，严格控制缺陷的开启与关闭，并把缺陷数据作为工程师考核依据之一，指派兼职文员进行缺陷管理。

所有测试中出现的问题，经整理后在项目团队例会上进行总结;在团队内部交流并在平台WSS中建立一个专门的警示网站，发布已经暴露的缺陷解决方案，让项目团队共享，避免问题重复出现;构建项目团队自有知识库，作为公司设计重用的一个重要资源。

除了高度重视实现阶段的测试，同时也积极主动地去发现质量问题。团队使用VS2005自带工具进行性能优化分析，找出使用频度高与关键代码进行性能优化。利用VS2005压力测试工具，找出性能瓶颈，制订相应策略进行优化。

系统自交付以来，用户反馈系统运行稳定。实践证明，我们的一系列质量保证策略与实践取得了很大成功。只有在需求分析、设计、开发等各个环节实施质量保证措施，才能保证软件产品的质量。软件项目要做到“有法可依，执法必严”，并要高度重视各个环节辅助工具的使用，这样才能较好地保证最终软件产品的质量。

软件质量保证方法论 第2篇

左边是设计和分析，是软件设计实现的过程，同时伴随着质量保证活动---审核过程，也就是静态的测试过程；右边是对左边结果的验证，是动态的过程，即对设计和分析的结果进行测试，以确认是否满足用户的需求。V模型避免了瀑布模型所带来的误区-----软件测试是在代码完成之后进行的。p302、什么是变更控制？（P111）

软件开发过程中都会产生许多变更，如配置项，配置，基线，构建的版本，发布的版本的变更，对于这些变更，都要有一个控制机构，以保证所有的变更都是可控的，可跟踪的，可重现的。这样的一类机构对变更的管理，就是变更控制。

3、软件可靠性概念？（P176）

软件可靠性是指在给定时间内，特定环境下软件无错运行的概率，软件可靠性包含了以下三个要素：规定的时间，规定的环境条件，规定的功能。

4、CMM（P195）

CMM：能力成熟度模型，用来衡量组织软件过程成熟度和评价其软件过程能力。能力成熟度是指一个特定过程被明确定义，管理，测量，控制并且是有效的程度。分为五个等级： 初始级 软件过程的特点是无序的，甚至是混乱的。几乎没有什么过程是进过定义的。可重复级 关键过程区域集中关注软件项目所关心的，与建立基本项目管理控制有关的事情。

已定义级 将软件生命周期的各个阶段严格的划分出来，从组织这个层次来保证过程质量该进

已管理级 软件产品的质量目标被量化管理，它遵循了全面质量管理活动的科学程序，关键过程域的关注焦点是建立起对软件过程和正在构造的软件工作产品的定量了解。

优化级 关键过程域包括那些为了实施连续不断的和可测的软件过程改进，组织和项目都必须解决的问题。

5、TQM的实施步骤（P265）

（1）建立质量小组，负责过程改进，流程完善，不断发现质量问题提出并实施解决方案。

（2）进行TQM思想的教育，通过教育，要让每个员工深刻认识到“满足顾客的需求是第一的”的思想，理解“什么是顾客需求”，如何让顾客满意等内容。

（3）了解市场，明确顾客需求，了解目前研发的软件产品的市场，包括竞争对手，客户群等，让员工明白什么是质量好的软件产品或软件服务，认真对待质量要求，开发出合格的产品。

（4）建立明确的质量基准和质量评估机制，以便和实际质量水平进行对比，识别质量的目标和工作的重点区域，采取相应措施。

（5）建立相对完善的奖励机制，在认可和给予奖励的过程中，应力求公正，真实，选择恰当的时间，恰当的场合，恰当的方式。

2、版本控制的目的:是在于对软件开发过程中文件或目录的发展过程提供有效的追踪手段，保证在需要时找到旧的版本，避免文件的丢失，修改文件的丢失和相互覆盖，通过对版本库的访问控制避免未经授权访问和修改。另外软件的控制是实现团队开发，提高效率的基础。

3、PDCA包括4个部分：计划、执行、检查、行动描述总结

(1)计划计划：就是分析当前状况，发现问题，找出原因和主要原因，制定质量方针、质量

目标、质量计划书和管理原则。管理原则有：过程方法、管理的系统方法、持续改进

(2)执行：执行时计划的履行和实现，主要按计划实施地去做，去落实具体对策，并实施过

程的监控，使活动按预期设想前进，最终达到计划设定的目标。

(3)检查：是对执行后效果的评估。检查是伴随着实施过程自始至终的，不断收集数据、信

息获取的过程，并通过数据分析、结果度量来完成检查。

行动：重点在于检查完结果，要采取措施，即总结成功的经验，吸取失败的教训，实施标准化，以后依据标准执行。

4、阶段性开发模型：增量模型和迭代模型

(1)增量模型描述软件产品的不同阶段是按产品所具有的功能进行划分的，先开发主要

功能或用户最需要的功能，然后随着时间的推进，不断增 加新的辅助功能或次要功能，最终开发出一个功能完善的，稳定的产品。

(2)迭代模型描述软件产品的不同阶段是按产品深度或细化程度来划分，先将产品的整个框架都建立起来，在系统的初期，已经具有用户所需要的全部功能。然后随着时间推进,不断细化已具有的功能或完善已具有的功能,这个过程是一个迭代的过程

6、零缺陷质量管理的实施步骤：（P268）

（1）建立推行零缺陷质量管理的组织事情的推行都需要组织的保证，通过建立组织，可以动员和组织全体职工积极的投入零缺陷管理，提高他们参与管理的自觉性也可以对每个人的合理化建议进行统计分析，不断进行经验交流，公司的最高管理者要亲自参加，表明决心，做出表率，要任命相应的领导人，建立相应的制度，要教育和训练员工

（2）确定零缺陷管理的目标，确定零缺陷小组在一定时期内所要达到的具体要求，包括确定目标项目，评价标准和目标值

（3）进行绩效评价，（4）建立相应的提案机制

（5）建立表彰制度

SQA组织的责任是审计软件经理和软件工程组的质量活动中出现的偏差。

7、SQA计划（P283）

SQA在项目早期要根据项目计划制定与其相应的SQA计划，定义各阶段的检查点。标识出检查审计的工作产品对象，以及在每个阶段SQA的输出产品。具体实施步骤如下：

（1）了解项目的需求，明确项目SQA计划的要求和范围

（2）选择SQA任务

（3）估计SQA的工作量和资源

（4）安排SQA任务和日程

（5）形成SQA计划

（6）协商，评审SQA计划

（7）批准SQA计划

（8）执行SQA计划

SQA计划包含以下内容：

（1）目的，SQA计划的目的和范围（2）参考文件，该SQA计划参考的文件列表（3）管理，组织，任务，责任（4）文档，列出所有的相关文档，如程序员手册，测试计划，配置管理计划等（5）标准定义，文档标准，逻辑结构标准，代码编写标准，注释标准等（6）评审/审核（7）配置管理，配置定义，配置控制，配置评审（8）问题报告和处理（9）工具，技术，方法（10）代码控制（11）事故/灾难控制，包括火灾，水灾，紧急情况等。

8、评审和审核的区别？（P285）

评审：过程进行时，SQA对过程的检查，SQA的角色在于确保当执行工程活动时，各项计划所规定的过程得到遵循，评审通常通过评委会的的方式进行，是对工作流程的评审

审核：在软件工作产品生成时，SQA对工作产品进行的检查，SQA的角色在于确保开发工作产品中各项计划所规定的过程得到遵循，审核通常通过对工作产品的审查来执行。侧重于产品本身。

SQA报告应遵循三条原则SQA和高级管理者之间应有的沟通渠道，SQA报告必须发布给软件工程组织但不必发布给项目管理人员，在可能的情况下向关心软件质量的人发布。

SQA度量是记录花费在SQA活动时间人力数据。涉及以下三方面：软件产品评估度量、软件产品质量度量、软件过程审核度量。

SQA的评估任务是软件开发前期对目标的软件和硬件资源进行评估，以确保其充分性和适合性。

9、白盒测试、黑盒测试（P390）

白盒测试将被测试程序看做一个盒子，测试者能够看到被测程序，可以分析被测程序的内部结构。

白盒测试可以用来对代码结构进行全面测试，常用的有语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，条件组合覆盖，路径覆盖，循环测试

黑盒测试常用来验证软件或模块功能是否得到实现，主要运用单元的性能和功能方面的测试除了测试其功能外，还需确保代码在结构上可靠，健全并能够有良好的响应。黑盒测试主要运用于单元的功能和性能方面的测试。功能测试包括用户界面测试各种操作的测试不同的数据输入逻辑思路，数据输出和存储的测试。

区别：关键区别应该就是测试对象不一样，白盒测试主要针对的是程序代码逻辑，黑盒测试主要针对的是程序所展现给用户的功能，简单的说就是前者测试后台程序后者测试前台展示功能

10、测试的原则概括为10项：

（1）所有测试的标准都是建立在用户需求之上2软件测试必须基于“质量第一”的思想去开展各项工作3实现定义好产品的质量标准4软件项目一启动。软件测试也就是开始5穷举测试是不可能的6第三方进行测试会更客观，更有效7软件测试计划是做好软件测试工作的前提8测试用例的设计出来的，不是写出来的9不可将测试用例置之度外，排除随意性10对发现错误较多的程序段，应进行更深入的测试

39、功能测试的概念：是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否能正常使用、是否实现了产品规格说明书要求、是否能适当地接收输入数据而产生正确的输出结果等。

5、风险管理法：SEI（软件工程研究所）风险控制一般分5个步骤：P80

(1)风险识别：试图系统化的方法来确定威胁项目计划的因素。识别方法包括：风险检

测表、头脑风暴会议、流程图分析、与项目人员面谈。

(2)风险分析：可以分为定性风险分析和定量风险分析。定性风险分析是评估已经识别

风险的影响和可能性的过程。定量风险分析是量化分析每一风险的概率及其对项目目标造成的后果，同时也要分析项目总体风险的程度。

(3)风险计划：制定风险行动计划，应考虑以下部分：责任、资源、时间、活动、应对

措施、结果、负责人。

(4)风险控制：方法：风险避免、风险弱化、风险承担、风险转移。

(5)风险跟踪：监视风险的状况，检查风险的对策是否有效、跟踪机制是否在运行，不

断识别新的风险并制定对策。

6、评审的内容：分为管理评审、技术评审、文档评审、过程评审（P217简答）

(1)管理评审是以实施质量方针和目标的质量体系的适应性和有效性为评论基准,对体系文

件的适应性和质量活动的有效性进行评价。目标：按规定的时间间隔对质量体系进行评审，确保持续的适宜性和有效性，以满足本标准要求和提供的质量方针和目标。输入：体系审核的结果。输出：《管理评审报表》

(2)技术评审是对产品以及各阶段的输出内容进行评估。目的：确保需求说明、设计说明书

与最初的说明书保持一致，并按照计划对软件进行了正确的开发。输入：需求文档、源代码、测试用例、评审检查单、其它文档。输出：技术评审报告

(3)文档评审分为格式评审和内容评审。

(4)过程评审是对软件开发过程的评审，其主要任务是通过对流程的监控，保证SQA组织

定义的软件过程在项目中得到了遵循，同时保证质量方针能得到更快更好的执行。

40.朱兰三部曲：

质量策划：为建立有能力满足质量标准化的工作程序，质量策划是必要的质量控制：为了掌握何时采取必要措施纠正质量问题就必须实施质量控制

质量改进：质量改进有助于发现更好的管理工作方式

40、从软件开发的各阶段论述如何提高软件产品的质量？

1、需求

我们知道人与人的交流总是会存在一些误会，同样一句话，心情不好与心情好的时候听起来的感觉可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上就应该注意尽量避免歧义的产生。如果对UML比较熟悉的话，需求分析可以利用UML工具进行，这样可以减少一些自然语言引起的歧义，但是UML可能与用户沟通起来有一些障碍，因为并不是所有的用户都了解UML各种图形的意思。除了工具之外，我们可以从以下几个方面来保证需求描述的质量。

1、看句子和段落是否简短，一个很长的句子，看起来会非常困难，因此无法弄懂真正的需求，另外过长的句子和段落容易让人忽视一些需求，所以如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。

2、句子是否有语法错误，还要注意标点符号，有时，标点符号点错了，就完全成了另外一个意思了。

3、是否存在模糊不清的需求，出现类似于可能，大概，或者等词汇表述的需求。

4、另外注意引用的术语和词汇是否前后一致。

5、是否存在一些形容词、比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的，界面友好的，减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围，要不然不同的人根据不同的理解就会得出不同的结果，最终可能跟用户最初的要求有偏差，那“炒回锅肉”的事情就不可避免地会发生。

另外保证需求质量的一个很重要的因素就是需求是否细化，如果需求不细化也会很容易造成代码的返工，于是就出现了我们的程序员尽管总是加班加点却总是不能如期的完成任务的情景。那么我们怎样才能判断需求细化的程度呢?需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢?哪些需求又太粗了呢?答案是需求是否可以写出相应的测试用例，如果写不出来，就说明需求还不是很细，还需要再进行细化。

2、设计

软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色，例如：用户、项目管理人员、程序员、测试员、维护人员等等。不同的角色对架构设计的要求也不相同。例如用户关心的是需求，因此我们的设计对需求的覆盖率是多少?对于程序员来说模块是否清晰，类的功能是否单一等等，对于测试人员来说系统的是系统的可测试性。对于维护人员来讲系统的扩展性、可维护性如何?一个高质量的软件架构，应该最大限度的考虑并满足不同角色的不同要求。正

是因为有这些要求，我们在进行软件设计的时候，应该进行全面的考虑。一般用来衡量软件设计质量的标准可以从以下几个方面来考虑：

1)、功能性：包括完全性、正确性、安全性、兼容性、互用性。完全性包括功能点覆盖率，重点功能点覆盖率，优先功能覆盖率。正确性包括需求一致度。安全性根据软件需求的不同有不同的安全性要求。

2)、效率：包括产品运行的时间效率和利用的硬件资源两方面来考虑。

3)维护性：包括架构的可改正性，可扩充性以及可测试性。如果用户的一个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性就比较差。

4)可移植性：包括硬件的独立性、软件独立性、可安装性、可重用性。软件设计是否模块化、每个模块的可复用性如何都是应该考虑的因素。

5)可靠性：包括缺陷数量、容错性、可用性。

6)使用性：包括可理解性、易学习性、可操作性、易沟通性。我们软件的最终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对软件的接纳程度。因此在软件的可使用性也是非常重要的。

3、编码

代码质量的一个很重要的标准就是代码的可读性及规范性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和维护，同时出错的几率也会更高。如果一个方法内部的代码很长，而且使用了很多令人难以理解的数据集，这样就会带来代码维护的困难，因为很少有人能够有效地分析它们，因此也就是最容易出现缺陷和错误的地方。类之间的耦合度会造成类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，每一个导入类发生变化都会影响到该类本身，另外如果该类的public方法太多也会导致类之间的高耦合性增加。

也许有的程序员会认为写出可读、规范的代码会影响工作进度。的确，对于程序员个体短时间来说为代码写上注释是要花费些时间，但如今软件开发是多人协作

周期很长的过程，写过程序的人都知道，如果自己写了不规范的代码，随着自己所写的代码越来越多，到后来需要修改某个前期写的模块时都不知道自己当初是怎么想的了，读自己的代码也需要花很长时间才读懂。况且如果随着人员的调动等其他原因，往往维护代码的程序员已不是当初写代码的人，很多情况就是读懂了一段糟糕的代码还比重新写出一段代码花费的时间还长，严重影响工作效率(有些时候还影响维护人员的心情)，反过来，如果大家都讲究把代码写成规范可读的，无疑对于整个组织来说提高总体工作效率是非常有用的。

代码质量另一个非常重要的衡量手段就是测试，通过统计测试代码所产生的缺陷情况，如严重等级分布、缺陷曲线的变化等可以从一个方面来简单地评估代码质量。

4、测试

测试人员在测试过程中，需要站在不同的利益相关者的角度，对测试对象的质量进行检查和验证，例如：测试人员除了关注需求文档中明确描述的需求条目之外，还应该关注隐现的需求，比如：竞争对手的产品特征、用户的群体特征和使用习惯等。因此，在测试过程中，测试人员除了关注测试对象的功能测试之外，还需要针对其他非功能特性进行测试。

彩超软件质量控制方法 第3篇

彩超研发是一项涉及生物学、医学、物理学和计算机等多学科交叉的工作, 对该领域的研究需要投入巨大的人力、物力和财力, 而且一些基础研究的投入需要一定周期。在一些发达国家, 许多科研机构和跨国企业做了大量前瞻性的基础研究工作, 为彩超技术不断的深化与完善, 奠定了一定的理论和实践基础。随着整个超声行业技术的发展和企业自身研发能力的提高, 海鹰医电实现了从黑白超声到彩色超声的跨越, 成为国内能够完全自主完成彩超研发、生产为数不多的企业之一。彩超软件与以往的黑白超软件相比具有更多的软件功能、提供更复杂的用户操作, 如何保证规模庞大的彩超软件的质量成为一大挑战性问题。保证软件的质量的重要途径就是制定和实施贯穿于开发全过程的技术与管理规范, 实施工程化管理, 运用软件工程的原理、思想和标准, 通过技术规范与管理规范的有效实施来提高软件产品的可靠性及开发效率[1,2]。

2软件生命周期分析

软件生命周期是软件的产生直到报废的生命周期, 周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段, 这种按时间分程的思想方法是软件工程中的一种思想原则, 即按部就班、逐步推进, 每个阶段都要有定义、工作、审查、形成文档以供交流或备查, 以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟, 软件生命周期设计方法的指导意义正在逐步减少[1,3]。常用瀑布模型来描述软件生存周期的各项内容, 如下图1:

结合软件生存周期和企业实际研发、生产水平, 彩超软件质量控制可以在软件计划、软件实现、软件测试三个过程着重把关, 控制软件质量。

3在软件计划过程中控制软件质量

软件计划以软件需求分析为母体分解实施。软件产品以满足用户需求为软件开发的主要任务, 而需求分析正是用户需求的提炼。在项目初期及开发过程中, 经常会碰到不能很好理解用户需求及用户需求频繁变更的情况, 正确地对待这些变更并在计划中灵活安排可以保证软件产品在预计的进度内完成, 可以保证计划工作的严肃性, 可以维护软件计划、产品和活动与需求的一致性, 从而从制度上控制软件质量。

4在软件实现过程中控制软件质量

软件的实现过程对于软件产品的质量有着重要影响。统一软件过程 (RUP) 框架和面向对象 (OO) 程序方法在软件开发中的运用能明显提高软件开发效率, 降低整个项目风险, 从而提高软件质量。

4.1 RUP框架。RUP框架由Ratinnal公司在吸取多种软件过程和模型的长处的提出, 利用用例驱动、以系统架构为中心、迭代增量的开发模型, 能全面支持面向对象的开发方法, 所以一经推出市场, 就迅速得到业界广泛的认同[4]。

传统的软件开发模型瀑布式模型是一个单维的模型 (如图1所示) , 在RUP框架中, 软件开发生命周期根据时间和RUP的核心工作流, 划分为二维空间, 可以用二维坐标来描述。横轴通过时间组织, 体现开发过程的动态结构, 用“周期”、“阶段”、“迭代”、“里程碑”等术语描述;纵轴以内容来组织, 体现开发过程的静态结构, 即在某一时刻软件开发所要进行的工作, 可以用“活动”, “工作流”, “产品”, “工作者”等概念来表示[3,4]。

RUP中的软件生命周期在时间上被分解为四个顺序的阶段, 分别是:初始阶段、细化阶段、构造阶段和交付阶段。每个阶段结束于一个主要的里程碑, 在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话, 可以允许项目进入下一个阶段。

在彩超软件中, 初始阶段的目标是根据医生对彩超的软件需求建立模型并确定模型的边界条件。本阶段具有非常重要的意义, 在这个阶段中关注的是整个超声软件中总体需求的风险。细化阶段的目标是分析超声软件各模型领域, 建立健全的体系结构基础, 编制超声软件计划。在构造阶段, 实现所有模块并集成为产品, 所有的软件功能被详细测试。交付阶段的重点是确保软件对最终用户是可用、易用、好用。交付阶段可以跨越几次迭代, 包括为发布做准备的产品测试, 基于用户反馈的少量的调整。

4.2 OO程序方法。OO程序方法一个重要的优点是支持信息隐蔽、数据抽象与封装, 使得软件的开发、修改和维护易于进行;OO程序方法的另一个重要优点是, 它可以在整个软件生命周期达到概念、原则、术语及表示法的高度一致, 这种一致性使得各个系统成分尽管在不同的开发与演化阶段有不同的形态, 但可具有贯穿整个软件生命周期的良好映射[3]。

在彩超软件制作过程中, 采用这两种开发过程和开发方法可以使整个超声软件开发、维护、升级更为容易, 提高软件生产效率、降低软件生产成本, 控制软件质量从而提高软件的整体质量。

5在软件测试过程中控制软件质量

软件测试是保证软件质量和可靠性的重要手段。在西方软件发达国家, 软件测试受到普遍重视。在国际著名软件企业中, 软件测试的费用占到了整个开发过程费用的40%以上。特殊情况下, 对于性命枚关的软件, 如飞行控制、核反应堆监控软件等, 其测试费用甚至高达所有其他软件工程阶段费用总和的3-5倍[3,5]。

5.1彩超软件的测试项目。针对彩超软件, 需要制定和不断修订严格的测试项目, 其主要包括性能测试和功能测试两大部分。每个测试项目由可定量描述的测试项组成。

超声软件的性能测试包括每个探头的黑白分辨率, 选取标准模块两个不同深度对横向分辨率和纵向分辨率进行定量检测;性能测试还包括每个探头的频谱分辨率, 选择人体两个不同器官进行血流定性检测。

超声软件的功能测试包括每个探头的功能调节的测试, 有声功率、发射频率、扫描密度、动态范围、平滑处理、帧平均、二次谐波、焦点数、扫描范围、图像优化、边缘增强、灰阶曲线、深度、扫描范围、2B切换、4B切换、黑白翻转、图像旋转等测试项目;探头的预设值测试;测量功能测试, 有2D常规测量、M常规测量、Doppler测量、产科测量、男科测量、妇科测量、泌尿科测量、外周血管测量、多胞胎测量、小器官测量、矫形外科测量、心脏测量等测试项目;内置工作站测试, 有妇科、男科、泌尿科、小器官、血管、心室、二尖瓣、主动脉、左心室、常规报告、检索、诊断模板、等测试项目;其他功能测试, 有回放功能 (自动手工, 速度调节) 、语言调节、日期、时间设置、图像存储格式选择、图像存储模式、体标目录、患者信息输入、i Touch (预设值) 保存/回调、穿刺功能、体标选择、Dicom传输、3D/4D、宽景成像、注释功能、字符输入、输入法切换等测试项目。

5.2彩超软件的测试主体。彩超软件的测试主体包含软件开发人员内部自测、研发团队总体测试、生产检验二次把关三级。不同的测试主体使用同样的测试标准, 但合理的测试结果是, 不同的测试主体发现的问题应该不尽相同。软件开发人员内部测试的工作重点是软件功能错误的检测, 在内部自测将绝大多数功能错误解决的基础上提交研发团队总体测试;研发团队总体测试的工作重点是软件性能指标的检测, 在将绝大多数性能误差解决的基础上提交生产检验进行二次测试;而二次测试的工作重点是绝对软件在批量生产过程中的问题。

6总结

随着彩超的发展, 功能越来越复杂, 彩超软件的总体规模越来越大。通过在计划、实现过程、测试三个环节的科学管理, 可以有效控制彩超软件的质量, 提高产品的可靠性。

摘要：随着彩超的发展, 功能越来越复杂, 彩超软件的总体规模越来越大。通过在计划、实现过程、测试三个环节的科学管理, 可以有效控制彩超软件的质量, 提高产品的可靠性。

关键词：彩超软件,质量控制,计划,实现过程,测试

参考文献

[1]张海藩.软件工程导论[M].北京:清华大学出版社, 2012.

[2]赵爱静.软件质量评价在航天测控软件中的应用[J].无线电工程, 2009, 39 (8) .

[3]熊策.软件质量控制技术的研究与应用[D].长沙:中南大学, 2004.

[4]丁峰, 等.RUP软件工程过程研究及应用[J].计算机工程, 2000, 26 (10) .

软件测试是提高软件质量的保证 第4篇

【关键词】错误 测试 目的 质量

随着信息技术的发展,计算机的应用领域越来越广,软件对于人们生活所造成的影响是巨大的,软件的好坏直接关系着人们的日常生活。尤其是计算机网络迅速发展的今天,由于小的软件故障就有可能造成一些不必要的大损失。

现在人们已经逐步认识到:正是软件错误导致了软件开发在成本、进度和质量的失控。有错是软件的属性而且是无法改变的,因为软件是由人来完成的。问题在于我们如何去避免错误的产生和消除已经产生的错误,使软件中的错误密度达到尽可能低的程度。“软件测试”为我们提供了这种可能。隐藏在软件中的错误可以依靠“软件测试”来揭示,软件中的错误密度也可以通过“软件测试”来进行估计。“软件测试”是信息技术的重要方面,是保证软件达到高质量和高可靠性的关键元素。

一、软件测试的目的

软件测试是软件工程过程的一个重要阶段,是在软件投入运行前,对软件需求分析、设计和编码各阶段产品的最终检查,是为了保证软件开发产品的正确性、完全性和一致性,从而检测软件错误、修正软件错误的过程。

谈到软件测试,许多人都会引用Glenford J.Myers就软件测试目的提出的以下观点:

①测试是程序的执行过程,目的在于发现错误;② 一个好的测试用例在于能发现至今未发现的错误;③一个成功的测试是发现了至今未发现的错误的测试;

这是一种比较狭窄的观点。软件测试是以查找错误为中心,但发现错误并不是软件测试的惟一目的,查找不出错误的测试也不是没有价值的。

软件的测试,基于不同的立场,存在着完全不同的测试目的。从用户的角度出发,软件测试不是为了演示软件的正确功能,而是希望通过软件测试暴露软件中隐藏的错误和缺陷,以考虑是否可以接受该产品。从软件开发者的角度出发,应当从软件过程的角度来看软件测试。测试并不仅仅是为了要找出错误或缺陷,而是以查找错误为中心,分析错误产生的原因和错误在开发的哪一个阶段产生,这具有非常重要的意义。通过分析错误或缺陷的原因,可以立即在软件开发行动中对其进行改正,通过分析也能帮助推理出与所分析的错误或缺陷有关联的潜在错误或缺陷,从而有针对性地设计出检测潜在错误或缺陷的方法,改善测试的有效性。最终表明软件产品中不存在错误的过程,验证该软件已正确地实现了用户的要求,确保软件的质量。

软件工程的总目标是充分利用有限的人力和物力资源,高效率、高质量地完成软件开发项目。对于软件不足的测试,势必使软件带着一些未揭露的隐藏错误投入运行,这将意味着软件具有一定的缺陷,软件产生的更大危险将要让用户承担。但是对软件进行完全测试是不可能实现的,因为会受到软件开发过程中人力和物力资源的影响。也有可能到了测试后期,即使找到了错误,然而修正错误需要付出了很高的代价。软件测试只能表明错误的存在,而不能表明错误不存在。可见,测试是为了使软件中蕴涵的缺陷低于某一特定值,使产出、投入比达到最大。

因此,测试的目的是以最少的人力、物力和时间投入,尽可能多地找出软件中潜在的各种错误和缺陷,检验软件的功能和性能是否符合用户需求、确保软件产品中的问题在分发之前被准确定位、改进生产过程,提高用户满意度。

二、软件测试的原则

根据软件测试的目的,软件测试的原则应该是:

(1)应当把尽早地和不断地进行软件测试作为软件开发者的座右铭。坚持在软件开发的各个阶段的技术评审,这样才能在开发过程中尽早发现和预防错误,把出现的错误克服在早期,杜绝某些隐患,提高软件质量。

(2)测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。如果对测试输入数据没有给出预期的程序输出结果,那么就缺少了检验实测结果的基准,就有可能把一个似是而非的错误结果当成正确结果。

(3)程序员应避免检查自己的程序。如果由别人来测试程序员编写的程序,可能会更客观,更有效,并更容易取得成功。 

(4)制定严格的测试计划,并把测试时间安排的尽量宽松,不要希望在极短的时间内完成一个高水平的测试。

(5) 妥善保存一切测试过程文档,意义是不言而喻的,测试的重现性往往要靠测试文档。

(6)回归测试的关联性一定要引起充分的注意,修改一個错误而引起更多的错误出现的现象并不少见。

三、软件测试的方法

软件测试方法包括静态测试、动态测试两种。其中,静态测试包括代码审查、静态分析。动态测试包括黑盒测试、白盒测试。黑盒测试适用于单元测试到系统联试阶段,而白盒测试通常适用于单元测试、集成测试及部分软件的配置项测试阶段。

1、静态测试

在静态测试中,代码审查的针对性强,一般情况下能发现70%-75%的特定问题,而且还能发现许多隐藏很深但非常致命的缺陷。但这种方式对资源的耗费很大,过分地依赖代码审查人员的素质和表现,对有些软件不适用;静态分析自动化程度高、效率高,分析全面、准确,包括分析理解、质量度量、规则检查等,但它存在适用性有限,许多分析结果需要人工给予进一步的分析和确认。

所以,应该将代码审查和静态分析两者结合,在静态测试中做到:

能用工具做的尽量用工具进行静态分析;

对部分静态分析结果通过代码审查的方式进行进一步的确认;

先静态分析,再代码审查;

利用静态分析结果作为引导,使代码审查工作更为有效。

2、动态测试

在动态测试中,黑盒测试直接面向需求设计测试用例,把被测程序看成一个黑盒,只考虑数据输入与输出的关系,完全不考虑程序内部的结构和特征。测试者只是按照软件规格书内容导出测试数据,并将注意力集中在寻找程序未按规格运行的情况。白盒测试直接针对软件内部的控制流和数据流进行测试用例的设计,要求测试人员对软件源程序有较深入的了解,允许测试人员从程序的逻辑着手检查程序的内部结构和源代码,得出测试数据,但常常会忽略了软件规格书的要求。

所以,应该将黑盒测试和白盒测试两者结合,在动态测试中做到:

先黑盒,再白盒;

在软件各测试阶段都可以使用这样的测试策略。

在整个测试过程中,应注重动态测试和静态测试的互补,将静态测试和动态测试相结合,先静态测试后动态测试,先静态分析再代码审查,先黑盒测试再白盒测试。

四、软件测试与软件质量保证的关系

软件测试能够提高软件质量,但与软件测试和软件质量保证二者之间既存在包含又存有交叉的关系。

软件测试能够找出软件缺陷,确保软件产品满足需求。但是测试不是质量保证,二者并不等同。测试可以查找错误并进行修改,从而提高软件产品的质量。软件质量保证则是避免错误以求高质量,并且还有其他方面的措施以保证质量问题。

从共同点的角度看,软件测试和软件质量保证的目的都是尽力确保软件产品满足需求,从而开发出高质量的软件产品。两个流程都是贯穿整个软件开发生命周期中。正规的软件测试系统主要包括:制定测试计划、测试设计、实施测试、建立和更新测试文档。而软件质量保证的工作主要为:制定软件质量要求、组织正式审查、软件测试管理、对软件的变更进行控制、对软件质量进行度量、对软件质量情况及时记录和报告。软件质量保证的职能是向管理层提供正确的可行信息,从而促进和辅助设计流程的改进。软件质量保证的职能还包括监督测试流程,这样测试工作就可以被客观地审查和评估,同时也有助于测试流程的改进。

二者的不同之处在于软件质量保证工作侧重对软件开发流程中的各个过程进行管理与控制,杜绝软件缺陷的产生。而测试则是对已产生的软件缺陷进行修复。

五、结束语

在软件越来越普及的今天,对软件产品质量的度量、评估和保证,成了用户和软件开发企业都十分关注的问题。软件测试是保证软件产品质量的重要手段,但完全的软件测试也是不现实的,它不能保证发现软件中的所有问题,它不能取代其它质量保证手段,而且,软件测试过分是一种浪费。在系统条件人力和物力资源的允许下,软件测试只有经过有序地组织、管理,并在各个阶段的每一测试过程中,运用合理的测试原则、方法,才能做到测试最优,也即保证软件产品质量最优。

参考文献:

[1]刘琴等译 《软件测试基础教程》[M].北京:人民邮电出版社,2009:1

[2]何国伟 王纬 等编 软件可靠性[M]. 湖南 国防工业出版社,1998:1

[3] (美)Ron Patton 周予滨 姚静译《软件测试》[M]. 机械工业出版社,2002.1

作者简介:

浅谈软件质量保证 第5篇

摘要：

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

前言：

SQA的由来：随着第一个正式的质量保证和控制方案在1916年贝尔实验室的出现，整个制造业都认可了这一方案，时至今日每个公司都有其保证其产品质量的机制，公司对质量的保证也渐渐成为其核心的市场策略。对于软件开发来说，一个项目的主要内容是：成本、进度、质量。软件本身作为一种无形产品，其质量指的是：“系统,部件或者过程满足顾客或者用户需要或期望的程度”。在20世纪五六十年代，质量保证曾经只由程序员承担。而正规的软件质量保证标准首先在20世纪70年代初军方的软件合同中出现，此后迅速传遍整个商业世界。提出而随着市场化发展的成型，任何软件公司对自己产品的质量问题越来越关注，测试所花费的成本越来越多。在起初国外很多的大软件公司公司比如IBM、CA等，SQA的职责就是测试（主要是系统测试）。后来，由于缺乏有效的项目计划和项目管理，留给系统测试的时间很少。另外由于软件最终使用者的不专业性，需求变化太快，没有完整的需求文档，测试人员就只能根据自己的想象来测试。这样一来，测试就很难保障产品的质量，促进了事先预防的SQA职能的产生。随后随着软件开发模型的不断演化和发展CMM模型的出现，它引入了“全面质量管理”的思想，至此许多公司将SQA人员独立于项目组，以保证评价的客观性。专业的SQA人员应运而生。

简介：

软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。其根本目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。

SQA的基本目标：

1: 软件质量保证工作是有计划进行的。

2: 客观地验证软件项目产品和工作是否遵循恰当的标准、步骤和需求。3: 将软件质量保证工作及结果通知给相关组别和个人。

4: 高级管理层接触到在项目内部不能解决的不符合类问题。

具体分析：

1：软件质量所包含的因素及软件质量评价标准：

软件质量包含的因素：正确性，可靠性，效率，完整性，可用性可维护

性，灵活性，可测试性，可移植性，可复用性，互操作性等等。

软件质量评价标准：质量需求准则，着眼点是是否满足用户的要求；质量设计准则，开发者在设计实现时是否按软件需求保证了质量。质量度量准则，为质量度量规定了一些检查项目。

从事专业SQA的人员所应具备的基本素质，工作中的基本职能及与其他相似职能的区别：

SQA人员所应具备的基本素质：

按照软件界已经达成的共识：影响软件项目进度、成本、质量的因素主要是 “人、过程、技术”。首先要明确的是这三个因素中，人是第一位的。SQA小组的成员首先应当时刻以客户的观点看待软件。从事SQA工作由于要按照相应的标准对专业的行为加以监管，深刻了解企业的工程，并具有一定的过程管理理论知识 对开发工作的基本情况了解，能够理解项目的活动，因此首先应具备较高的关于软件开发方面的知识；在工作中过程为中心：应当站在过程的角度来考虑问题，只要保证了过程，QA就尽到了责任；还应具有服务精神即为项目组服务，帮助项目组确保正确执行过程；另外应善于沟通，能够营造良好的气氛，避免其工作本身成为一种找茬活动。我所在的小组在课程实践过程中就出现过负责设计的同学对编码阶段的同学出现质疑，最终出现不愉快的事情。

工作中的基本职能以及于其他相似职能的区别：

要做好SQA工作首先应该明确SQA人员的职能以及与QC、SEPG的区别。QC：检验产品的质量，保证产品符合客户的需求；是产品质量检查者； SEPG：制定过程，实施过程改进；

而SQA人员的主要工作为审计过程的质量，是过程质量审计者，其基本职能为确保过程被正确执行。其本身并不参与过程的制定，A的职责就是确保过程的有效执行，监督项目按照过程进行项目活动；它不负责监管产品的质量，不负责向管理层提供项目的情况，不负责代表管理层进行管理，只是代表管理层来保证过程的执行。

3：SQA活动：

软件质量保证由各种任务构成，这些任务分别与两种不同的参与者有关：做设计工作的软件工程师和SQA小组成员。

软件工程师通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件测试来考虑质量问题（并完成软件质量保证和质量控制活动）

SQA小组成员的职责为辅助软件工程小组得到高质量的最终产品。其主要工作如下：

为项目准备SQA计划。该计划在制定项目计划实制定，由所以感兴趣的相关部门评审。该计划将控制由项目组和SQA小组执行的质量保证活动。在计划中应标识一下几点：需要进行的评价；需要进行的审计和评审；项目可用的标准；错误报告和跟踪的规程；由SQA小组产生的文档；为软件项目提供的反馈数量。另外还需明确最终审计的结果报告给谁。

参与开发该项目的软件过程描述。软件工程小组为要进行的工作选择一个过程。SQA将评审过程描述以保证该过程与组织政策，内部软件标准，外界所订标准（如ISO9001）以及软件项目计划的其他部分相符。

评审各项软件工程活动，对其是否符合定义好的软件过程进行核实。SQA小组识别记录和跟踪与过量的偏差，并对是否已经改正进行核实。

审计指定的软件工作产品，对其是否符合定义好的软件过程中的相应部分进行核实。SQA小组对选出的产品进行评审；识别，记录和跟踪出现的偏差；对是否已经改正进行核实；定期将工作结果向项目管理者报告。在审计过程中。注意审计一定要有项目组人员陪同，双方要开诚布公，坦诚相对。审计的内容主要包括：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。

确保软件工作及工作产品中的偏差已被记录在案并根据预定规程进行处理。偏差可能出现在项目计划，过程描述，采用的标准或技术工作产品中。

记录所有不符合的部分并报告给高级管理者。对不符合的部分进行跟踪直至问题得到解决。

4：软件评审：软件评审是软件工程过程中的过滤器。评审被用于软件开发过程的多个不同的点上，起到发现错误和缺陷节日引发排错活动的作用。软件评审起到的作用是净化分析，设计和编码的软件工程活动。在课程实践过程中由于初始需求分析的不明确以及后来概要设计过程中关键点的遗漏所引发的错误曾经导致我们小组代码的两次大部分返工，现在看来在课程实践过程中没有进行软件评审所致

5：正式技术评审（FTR）

正式技术评审是一种由软件工程师和其他人进行的软件质量保障活动。

正式技术评审的目标是：发现功能、逻辑或实现的错误；证实经过评审的软件的确满足需求；保证软件的表示符合预定义的标准；得到一种一致的方式开发的软件；使项目更易管理。

评审会议一般由3-5人参加，不超过2小时，由评审主席、评审者和生产者参加，必须做出下列决定中的一个：工作产品可不可以不经修改而被接受；由于严重错误而否决工作产品；暂时接受工作产品。

评审总结报告和记录保存：评审会议结束时，生成一份评审问题列表，完成一份包括“评审什么？由谁评审？结论是什么？”的评审总结报告。

评审总结报告是项目历史记录的一部分，标识产品中存在问题的区域，作为行政条目检查表以指导生产者进行改正。

评审指导原则：评审产品，而不是评审生产者。注意客气地指出错误，气氛轻松；制定日程并且遵守日程；不要离题，限制争论和辩驳。有异议的问题不要争论但要记录在案；对各个问题都发表见解。问题解决应该放到评审会议之后进行；做书面笔记；限制参与者的人数并坚持事先做准备；为每个要评审的工作产品建立一个检查表。应为分析、设计、编码、测试文档都建立检查表。；为了让评审有效，为FTR分配资源和时间；为了提高效益对所有评审进行有意义的培训；评审以前所做的评审。

6结合课程实践浅谈自己的感受

下面我将结合课程的实践讲一讲个人对于软件质量保证的一些感受，首先说一说每个人所扮演的角色，负责编码的同学相当于软件工程师的角色，而负责需求分析及概要设计的同学责同时兼任了SQA小组成员的角色。在具体实现过程中，在需求分析阶段，通过需求调研我们小组大体明确了客户即TA对机动车违章管理系统的需求，但由于没有把需求调研的工作做到位，在完成需求分析的过程中，我们小组出现了一些问题，主要是对TA要求的理解出现了分歧。此时承担SQA小组责任的同学并没有严格要求自己进一步与TA沟通，解决理解上的分歧，而是个人主观的认为自己的理解就是对的。致使在具体实现时与初始需求出现了一些偏差。这个问题的发生，主要是因为承担需求分析的同学同时兼任SQA小组工作的原因，致使监督的客观性方面出现了问题。在概要设计阶段由于考虑到后期一些功能在后期具体实现中的困难，没有严格按照获取的需求进行设计，主要是出于实现难度的考虑草率的对本已获得的需求进行了一些修改致使本就出现变差的需求进一步打了折扣。在编码阶段针对出现问题时，更是仅仅是就问题而谈问题，把原始的计划放到了一边。回顾整个课程的过程：从在初始人员定位时并没有认识到SQA小组的重要性，因此并没有严格指定专人负责，只是在出现问题时才想到，而在明确两人兼任SQA小组工作后，也没有严格制定明确的计划，也没有正式的评审各项软件工程活动，仅仅是想到什么就说什么，不但造成了小组成员间的冲突，更是对问题的解决没有多大的帮助。而“软件工程师”即从事编码的同学虽然对软件本身进行了一些测试，修正了一些错误，改进了一些BUG，但这一切都是通过想当然去做的，并没有参考设计文档。结论：

无论何种软件只有在保证其质量的前提下才能体现出它的价值。软件质量保证则是保证软件质量的基石。而在软件质量保证的过程中，首先应该明确自己的定位，而后严格按照上面提出的步骤与方法去实现才能更好的完成SQA工作。这一切，都需要我们在今后的学习、工作中积极地去实践。

参考文献：

软件工程实践者的研究方法 Roger S.Pressman

软件质量保证报告（最终版） 第6篇

现在越来越多的公司都开始真正重视起软件质量问题，要做到高质量的软件应该满足软件需求定义的功能和性能。

文档符合事先确定的软件开发标准软件的特点和属性遵循软件工程的目标和原则，还应该考虑在预算和进度范围内交付，因此在项目进行过程中要对偏差进行控制质量控制和质量保证。

质量控制是为了保证每一件工作产品都满足对它的需求而应用于整个开发周期中的一系列审查、评审和测试，质量控制在创建工作产品的过程中包含一个反馈循环，通过对质量的反馈，使得我们能够在得到的工作产品不能满足其规约时调整开发过程。所有工作产品都应该具有定义好的和可度量的规约，这样就可以将每个过程的产品与这一规约进行比较。质量保证由管理层的审计和报告构成，目标是为管理层提供获知产品质量信息所需的数据，从而获得产品质量是否符合预定目标的认识和信心。

软件质量保证

软件质量保证是为了保证软件系统或软件产品满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产高质量的软件。在软件质量方面必须强调三个要点：软件必须满足用户规定的要求，与用户需求不一致的软件，就无质量可言。

软件应遵循软件标准所定义的一系列开发标准，不遵循这些标准的软件，其质量难以得到保证。

软件还应满足某些隐含的要求，例如希望有良好的可理解性、可维护性等，而这些隐含的要求可能未被写在用户规定的需求中，满足它的显性需求而不满足其隐含需求，那么该软件的质量是令人怀疑的。

我们评价一款软件可以从以下一些角度进行

正确性

正确性是指软件按照需求正确执行任务的能力。正确性也涵盖了“精确性方面。无庸质疑，这是对一款软件最基本的要求，比如我们通过ATM自动取款机取款时，在输入1,000时，结果只输出了800或者输出了1,200，可想而知这会对银行和客户会产生多大的影响。一款软件满足不了正确性的要求，再谈其他任何方面都没意义。

可靠性

可靠性是指在一定的环境下，在给定的时间内，系统能够正常运行的概率。我曾在手机中遇到一个问题：在待机状态下，手机网络信号等一切显示正常，会出现一些无法通信的情况，电话无法拨打，短信不能收发，重新开机后方可恢复正常。想象下如果情人约会，或者紧急救助时遇到这种情况会产生什么样的后果。

健壮性

健壮性是指在异常或者不利情况下，软件能够正常运行的能力。我们可以用生活中的一个例来说明，当流感出现的时候，在同样环境下，有些人很容易就生病，而有些人却任你东南西北风，就是安然无恙。

美观性

美观性主要指软件UI设计的情况，美观性就是从大众化审美以及心理学角度对软件提出的一个要求，这个要综合考虑软件的使用人群特点等。美观性包括软件的颜色搭配，字体使用，排版布局等方面。

性能

性能也就是一个软件效率问题，也就是软件特定时间空间环境下系统的响应能力。我们平时在使用手机进行编写短信时，可能有的手机在输入一个字符后，手机显示的很缓慢！这就是软件性能比较差的一个表现。

易用性

顾名思义，易用性是软件能否满足客户容易操作使用程度。易用性也是衡量一款软件质量好坏的一个重要方面，我们经常会听到有些人说某些手机太复杂了，不好用，不会用，那我想这样的软件并不能真正能称为好软件。在开发过程中，如果软件开发人员一味关注技术而不从用户使用的角度来考虑那就大错特错了。

兼容性

兼容性指一款软件和其他不同软件通信（或交换信息）的能力。以前我在做一些蓝牙耳机测试的时候，就出现有蓝牙耳机和某些手机配对后通过耳机端无法对手机端进行控制的问题，这就造成了和某些手机无法搭配使用，问题比较严重。在做兼容性测试方面，首先要保证所做软件能和市场上一些知名品牌产品以及市场占有率比较高的产品的兼容。安全性

安全性是指软件系统防止被非法入侵的能力。如我们会有听说某网络系统被黑客入侵导致瘫痪的情况就是一个例子。当然一个系统的安全性既和软件本身的抗入侵能力有关又和一些相关保护措施有关，如是否有加密、安装防火墙等。

可移植性

可移植性指的是软件不经修改或稍加修改就可运行于不同软硬件环境（CPU、OS和编译器）的能力，主要体现为代码的可移植性。

可扩展性

可扩展性反映软件适应“变化”的能力，如增加新功能等。可扩展性和可移植性一样，主要都是从开发的角度对软件提出的要求。从一些不同角度来评价一款软件，当然实际评测过程中还要根据嵌入式、B/S架构、C/S架构等不同特点软件来有所侧重，同时还要结合软件软件使用对象、生命周期等来综合评价。当然，以上各点满足了也不能就能说明就是一款好软件了，其他比如可维护性、可复用性、可测试性等也是我们要根据实际情况来考虑的因素。

软件质量的目标

软件公司生产软件的最根本目标是为了让产品赢得市场、赢得顾客，从而获取利润。如果企业连生存的能力都没有了，软件的质量做的再完美也无用。软件公司开发一款软件，并不是说质量越高越好。质量越高，成本相对会越高，这样企业就可能支持不力，无法生存；或者价格很高，客户无法接受。在此并不是说软件质量并重要，质量很重要！好和坏从来都是相对的。从用户的角度而言，在能够正常满足使用要求的软件就是好软件；对企业而言，在软件生命周期里，能够软件能够满足用户使用，能给自己带来更多利润的软件就是好软件。不同场合对软件质量的要求是不一样的，比如我们国家发射神州五号而后神州六号宇宙飞船，这就要求其软件质量要百分百可靠，不能出哪怕一点点的差错，相信在不久的将来我们国家在发射载人登月宇宙飞船时，对飞船软件质量的的重视程度会有过之而无不及。人员素质

软件是人做出来的，软件质量的好坏和开发、测试以及有关管理人员都息息相关。在软件开发方面，我们在此不谈，只从测试的角度来谈软件质量保证。说质量保证，先问下自己，从事质量保证的人员真的有能力去做好质量保证吗？质量保证的人员能力问题是个重要方

面，如果连软件中潜在问题都发现不了，想解决问题，做高质量的软件，谈何容易？

测试人员能力是一方面，其他如从事软件测试人员的职业素养也是个重要方面。如果一款软件未有充分去测，甚至对有些概率性的问题一笑而过，耐不住性子深入去测，或者在发行版本时只简单测试一下，这些都无法真正保证软件的质量。而这种情况下的出现，测试人员根据简单的测试，下了个软件没问题的结论，这样对顾客而言影响是很大的，最终对公司而言无论形象还是未来产品销售等方面的都是不利的。

公司规范

测试人员的能力再强，测出的问题再多，如果在些问题没有解决的情况下匆匆将软件release给客户，软件问题一大堆。这样的测试其实是没有多大的实际意义的。测试的目的是发现问题，解决问题，保证软件质量。

当然这个保证单凭测试人员、QA是不行的，在我们国内，其实很多企业测试人员和QA人员在软件发行问题上根本没有发言权，基本上都是公司领导说了算，如果公司领导说“这些问题没关系，我觉得软件可以发行”，那这时软件基本都会发行的。至于所谓的测试、QA以及项目经理等人员，你就一边吹风去吧。

所以，在软件问题评估，软件发行等问题上一定要给质量保证人员（通常是QA）足够的权力，QA测评通不过就是通不过！

可惜目前真正能做到这一步的公司并不多。企业为了生存，也很难把这方面真正做好，比如有些产品赶在某些节假日上市时有着良好的时常，而过了那一段时期，可能产品就很难卖了。当然，这些就不是测试人员考虑的范围了。

我们如何成为一名优秀的软件质量保证工程师

软件质量保证牵扯到软件开发的方方面面，包括从启动到需求，到设计，到开发，到测试，到发布，到后期维护的整个过程。在启动阶段，你要理解如何制定项目章程，如何书写项目范围说明书，如何制定项目计划；在需求阶段，你需要理解如何与用户确认需求，如何进行需求分析，如何与用户确认用户需求；在设计方面你要大体理解当前设计前沿技术，了解数据库知识，如何进行概要设计和详细设计；在构造阶段，您需要了解编码规范，编程技巧，集成技术；在测试阶段你需要理解如何进行单元测试，集成测试，系统测试；在验收阶段您需要理解如何进行验收测试，如何培训用户，如何替用户搭建环境；在维护阶段您需要理解如何理解代码，如何进行再工程技术。在这里你好像是一位多面手，但是了解得越多，对你从事质量保证工作越有好处。由于现代分工比较细致，往往一个质量小组需要各个方面的人才组合在一起，才能发挥更大的效能，才能达到1+1>2的结果。

对于从事软件质量保证工作，您需要一定的数学知识，尤其是概率统计知识。无论你是否采用6Sigma，你需要对你的软件质量进行度量活动，需要收集数据，分析数据从而解决问题。你要理解如何使用直方图，散点图，鱼刺图，饼图等工具。这样你才能展示问题的原因，寻找解决问题的原因。