软件质量保证.docx

软件质量保证.docx

《软件质量保证.docx》由会员分享，可在线阅读，更多相关《软件质量保证.docx（15页珍藏版）》请在冰豆网上搜索。

软件质量保证

软件质量保证

软件质量保证

软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、

步骤、实践和方法能够正确地被所有项目所采用。

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

它通过对软件产品和活动

进行评审和审计来验证软件是合乎标准的。

软件质量保证组在项目开始时就一起参与建立

计划、标准和过程。

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

一、基本目标

目标 1:

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

目标 2:

 客观地验证软件项目产品和工作是否遵循恰当的标准、步骤和需求。

 目标 3:

 将

软件质量保证工作及结果通知给相关组别和个人。

 目标 4:

 高级管理层接触到在项目内部

不能解决的不符合类问题。

二、QA 的由来

我们知道，国外很多的大公司，QA 的职责就是测试（主要是系统测试），比如

IBM、CA、PeopleSoft 等。

其实在最初，几乎所有的公司都是这样的。

后来，由于缺乏有效

的项目计划和项目管理，留给系统测试的时间很少（注：

我以前做的一个项目，项目经理

就明确告诉我系统测试就 1 天，没得商量）。

另外，需求变化太快，没有完整的需求文档，

测试人员就只能根据自己的想象来测试。

这样一来，测试就很难保障产品的质量，事先预

防的 QA 职能就应运而生。

事先预防其实是借鉴了 TQM 的思想，而且也符合软件工程“缺陷越早发现越早修改越经

济”的原则。

这些思想的渊源还可以追溯到中国古代的典故中，比如曲突徙薪、扁鹊论医

术等。

三、QA 的现在

目前，实施 CMM 的企业越来越多了。

CMM 模型就要求建立 QA 角色。

这里的 QA 类似于

过程警察，主要职责是，检查开发和管理活动是否与已定的过程策略、标准和流程一致，

检查工作产品是否遵循模板规定的内容和格式。

在这些企业中，一般还要求 QA 独立于项

目组，以保障评价的客观性。

从国内来看，多数的 QA 没有技术背景，检查出的偏差多为

鸡毛蒜皮，再加上自己没有令人信服的背景，领导也不支持，当然做起来就很困难了。

缺乏信任和支持只是一个方面，QA 工作本身就很具挑战性。

它要求 QA 具有软件工程的

知识、软件开发的知识、行业背景的知识、数理统计的知识、项目管理的知识、质量管理

的知识等等。

我们常常遇到这样的问题，改进到一定程度就很难突破，感觉心有余而力不足了，就开始

郁闷了。

后来通过学习、培训、交流，思想和技能得到升华，又发现了木桶中最短的那块，

然后又开始改进，然后又遇到了玻璃天花板，然后……就这样处于郁闷的循环中。

假使我们掌握了所有的知识，能突破所有的玻璃天花板，那是不是 QA 就可以一帆风顺了。

答案是否定的。

QA 角色定义本身就有很大的局限性。

QA 充当的是过程警察的角色，无论

是否有意义，都专横地强制过程的执行，容易在项目组中造成敌对的关系，受到排挤，而

且这种警察的姿态也破坏了团队精神。

如此一来，QA 工作还需要的是人际关系技能，就如

我以前写的《质量平衡》和《QA 应该独立于项目组吗？

》一样，艺术化地处理这种关系。

四、QA 的未来

从某种程度上说，独立的 QA 审查机制是瀑布模型的产物。

随着现代软件开发技术的演变，

螺旋模型和迭代模型的兴起，QA 机制正在悄然发生变化。

这种变化就是从独立专职的 QA

向贯穿过程的兼职 QA 演变。

在 CMMI 模型中，这种兼职的 QA 也是被允许的。

为什么会发

生这种改变呢？

无论是 XP、RUP 还是其它先进的方法论，都是先产生架构，然后再增量开

发，直到完成。

这种模式中，需求和设计缺陷在各个迭代周期被所尽早发现和修复，质量

也内建于架构和过程中，项目的成本和进度也得到保障。

到那时，是不是独立的 QA 就不复存在了呢？

有些成熟度较低的企业还是需要的，主要是

保证过程执行的有效性和评价的客观性。

五、SQA 的理论探索

1、过程的认识

我们都知道一个项目的主要内容是：

成本、进度、质量；良好的项目管理就是综合三方面

的因素，平衡三方面的目标，最终依照目标完成任务。

项目的这三个方面是相互制约和影

响的，有时对这三方面的平衡策略甚至成为一个企业级的要求，决定了企业的行为，我们

知道 IBM 的软件是以质量为最重要目标的，而微软的“足够好的软件”策略更是耳熟能详，

这些质量目标其实立足于企业的战略目标。

所以用于进行质量保证的 SQA 工作也应当立足

于企业的战略目标，从这个角度思考 SQA，形成对 SQA 的理论认识。

 软件界已经达成共

识的：

影响软件项目进度、成本、质量的因素主要是 “人、过程、技术”。

首先要明确的

是这三个因素中，人是第一位的。

现在许多实施 CMM 的人员沉溺于 CMM 的理论过于强调“过程”，这是很危险的倾向。

这

个思想倾向在国外受到了猛烈抨击，从某种意义上各种敏捷过程方法的提出就是对强调过

程的一种反思。

 “XP”中的一个思想“人比过程更重要” 是值得我们思考的。

我个人的意

见在进行过程改进中坚持“以人为本”，强调过程和人的和谐。

根据现代软件工程对众多失败项目的调查，发现管理是项目失败的主要原因。

这个事实的

重要性在于说明了 “要保证项目不失败，我们应当更加关注管理”，注意这个事实没有说

明另外一个问题“良好的管理可以保证项目的成功”。

现在很多人基于一种粗糙的逻辑，从

一个事实反推到的这个结论，在逻辑上是错误的，这种错误形成了更加错误的做法，这点

在 SQA 的理解上是体现较深。

如果我们考证一下历史的沿革，应当更加容易理解 CMM 的本质。

CMM 首先是作为一个

“评估标准”出现的，主要评估的是美国国防部供应商保证质量的能力。

CMM 关注的软件

生产有如下特点：

（1）质量重要 

（2）规模较大

这是 CMM 产生的原因。

它引入了“全面质量管理”的思想，尤其侧重了“全面质量管理”

中的“过程方法”，并且引入了“统计过程控制”的方法。

可以说这两个思想是 CMM 背后

的基础。

上面这些内容形成了我对软件过程地位、价值的基本理解；在这个基础上我们可以引申讨

论 SQA。

2、生产线的隐喻

如果将一个软件生产类比于一个工厂的生产。

那么生产线就是过程，产品按照生产线的规

定过程进行生产。

 SQA 的职责就是保证过程的执行，也就是保证生产线的正常执行。

抽象出管理体系模型的如下，这个模型说明了一个过程体系至少应当包含 “决策、执行、

反馈”三个重要方面。

QA 的职责就是确保过程的有效执行，监督项目按照过程进行项目活动；它不负责监管产

品的质量，不负责向管理层提供项目的情况，不负责代表管理层进行管理，只是代表管理

层来保证过程的执行。

3、SQA 和其他工作的组合

在很多企业中，将 SQA 的工作和 QC、SEPG、组织级的项目管理者的工作混合在一起了，

有时甚至更加注重其他方面的工作而没有做好 SQA 的本职工作。

根据 hjhza 的意见“中国现在基本有三种 QA（按照工作重点不同来分）：

一是过程改进

型，一是配置管理型，一是测试型”。

我个人认为是因为 SQA 工作和其他不同工作组合在

一起形成的。

 下面根据本人经验对它们之间的关系进行一个说明。

 4、QA 和 QC 两者

基本职责

QC：

检验产品的质量，保证产品符合客户的需求；是产品质量检查者； QA：

审计过程

的质量，保证过程被正确执行；是过程质量审计者； 注意区别检查和审计的不同

检查：

就是我们常说的找茬，是挑毛病的；

审计：

来确认项目按照要求进行的证据；仔细看看 CMM 中各个 KPA 中 SQA 的检查采用的

术语大量用到了“证实”，审计的内容主要是过程的；对照 CMM 看一下项目经理和高级管

理者的审查内容，他们更加关注具体内容。

对照上面的管理体系模型，QC 进行质量控制，向管理层反馈质量信息；QA 则确保 QC 按

照过程进行质量控制活动，按照过程将检查结果向管理层汇报。

这就是 QA 和 QC 工作的关

系。

在这样的分工原则下， QA 只要检查项目按照过程进行了某项活动没有，产出了某个产品

没有；而 QC 来检查产品是否符合质量要求。

如果企业原来具有 QC 人员并且 QA 人员配备不足，可以先确定由 QC 兼任 QA 工作。

但是

只能是暂时的，独立的 QA 人员应当具备，因为 QC 工作也是要遵循过程要求的，也是要被

审计过程的，这种混合情况，难以保证 QC 工作的过程质量。

 5、QA 和 SEPG 两者基本

职责

SEPG：

制定过程，实施过程改进； QA：

 确保过程被正确执行

SEPG 应当提供过程上的指导，帮助项目组制定项目过程，帮助项目组进行策划；从而帮

助项目组有效的工作，有效的执行过程。

如果项目和 QA 对过程的理解发生争持，SEPG 作

为最终仲裁者。

为了进行有效过程改进，SEPG 必须分析项目的数据。

QA 本也要进行过程规范，那么所有 QA 中最有经验、最有能力的 QA 可以参加 SEPG，但

是要注意这两者的区别。

如果企业的 SEPG 人员具有较为深厚的开发背景，可以兼任 SQA 工作，这样利于过程的不

断改进；但是由于立法、执法集于一身也容易造成 SQA 过于强势，影响项目的独立性。

管理过程比较成熟的企业，因为企业的文化和管理机制已经健全， SQA 职责范围的工作

较少，往往只是针对具体项目制定明确重点的 SQA 计划，这样 SQA 的审计工作会大大减少，

从而可以同时审计较多项目。

另一方面，由于分工的细致化，管理体系的复杂化，往往需要专职的 SEPG 人员，这些人

员要求了解企业的所有管理过程和运作情况，在这个基础上才能统筹全局的进行过程改进，

这时了解全局的 SQA 人员就是专职 SEPG 的主要人选；这些 SQA 人员将逐渐的转化为 SEPG

人员，并且更加了解管理知识，而 SQA 工作渐渐成为他们的兼职工作。

这种情况在许多 CMM5 企业比较多见，往往有时看不见 SQA 人员在项目组出现或者很少

出现，这种 SEPG 和 SQA 的融合特别有利于组织的过程改进工作。

SEPG 确定过程改进内容，

SQA 计划重点反映这些改进内容，从保证有效的改进，特别有利于达到 CMM5 的要求。

从

这个角度，国外的 SQA 人员为什么高薪就不难理解了，也决定了当前中国 SQA 人员比较被

轻视的原因；因为管理过程还不完善，我们的 SQA 人员还没有产生这么大的价值嘛！

6、QA 和组织级的监督管理

有的企业为了更好的监督管理项目，建立了一个角色，我取名为 “组织级的监督管理者”，

他们的职责是对所有项目进行统一的跟踪、监督、适当的管理，来保证管理层对所有项目

的可视性、可管理性。

 为了有效管理项目， “组织级的监督管理者”必须分析项目的数

据。

 他们的职责对照上图的模型，就是执行 “反馈”职能。

QA 本身不进行反馈工作，最多对过程执行情况的信息进行反馈。

SQA 职责最好不要和“组织级的项目管理者”的职责混合在一起，否则容易出现 SAQ 困

境：

一方面 SQA 不能准确定位自己的工作，另一方面过程执行者对 SQA 人员抱有较大戒心。

如果建立了较好的管理过程，那么就会增强项目的可视性，从而保证企业对所有项目的较

好管理；而 QA 来确保这个管理过程的运行。

五、SQA 的工作内容和工作方法

1、 计划

针对具体项目制定 SQA 计划，确保项目组正确执行过程。

制定 SQA 计划应当注意如下几

点：

 有重点：

依据企业目标以及项目情况确定审计的重点 明确审计内容：

明确审计哪

些活动，那些产品 明确审计方式：

确定怎样进行审计

明确审计结果报告的规则：

审计的结果报告给谁

2、审计/证实

依据 SQA 计划进行 SQA 审计工作，按照规则发布审计结果报告。

注意审计一定要有项目组人员陪同，不能搞突然袭击。

双方要开诚布公，坦诚相对。

 审

计的内容：

是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。

3、问题跟踪

对审计中发现的问题，要求项目组改进，并跟进直到解决。

六、SQA 的素质

过程为中心：

应当站在过程的角度来考虑问题，只要保证了过程， QA 就尽到了责任。

服务精神：

为项目组服务，帮助项目组确保正确执行过程

了解过程：

深刻了解企业的工程，并具有一定的过程管理理论知识 了解开发：

对开发工

作的基本情况了解，能够理解项目的活动

沟通技巧：

善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。

七、SQA 活动

软件质量保证（SQA）是一种应用于整个软件过程的活动，它包含：

1、一种质量管理方法

2、有效的软件工程技术（方法和工具）

3、在整个软件过程中采用的正式技术评审

4、一种多层次的测试策略

5、对软件文档及其修改的控制

6、保证软件遵从软件开发标准

7、度量和报告机制

SQA 与两种不同的参与者相关 —— 做技术工作的软件工程师和负责质量保证的计划、监

督、记录、分析及报告工作的 SQA 小组 。

软件工程师通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件

测试来考虑质量问题，并完成软件质量保证和质量控制活动。

SQA 小组的职责是辅助软件工程小组得到高质量的最终产品。

SQA 小组完成:

（1）为项目准备 SQA 计划。

该计划在制定项目规定项目计划时确定，由所有感兴趣的相

关部门评审。

 ·需要进行的审计和评审； ·项目可采用的标准； ·错误报告和跟踪的

规程； ·由 SQA 小组产生的文档； ·向软件项目组提供的反馈数量。

（2）参与开发项目的软件过程描述。

评审过程描述以保证该过程与组织政策，内部软件

标准，外界标准以及项目计划的其他部分相符。

（3）评审各项软件工程活动，对其是否符合定义好的软件过程进行核实。

记录、跟踪与

过程的偏差。

（4）审计指定的软件工作产品，对其是否符合事先定义好的需求进行核实。

对产品进行

评审，识别、记录和跟踪出现的偏差；对是否已经改正进行核实；定期将工作结果向项目

管理者报告。

（5）确保软件工作及产品中的偏差已记录在案，并根据预定的规程进行处理。

（6）记录所有不符合的部分并报告给高级领导者。

八、正式技术评审（FTR）

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

1. 目标：

（1） 发现功能、逻辑或实现的错误 

（2） 证实经过评审的软件的确满足需求 （3） 保证软件的

表示符合预定义的标准 （4） 得到一种一致的方式开发的软件 （5） 使项目更易管理

2、评审会议

3-5 人参加，不超过 2 小时，由评审主席、评审者和生产者参加，必须做出下列决定中的

一个 :

（1）工作产品可不可以不经修改而被接受； 

（2）由于严重错误而否决工作产品；

（3）暂时接受工作产品。

3、评审总结报告、回答

评审什么？

由谁评审？

结论是什么？

评审总结报告是项目历史记录的一部分，标识产品中存在问题的区域，作为行政条目检查

表以指导生产者进行改正。

4、评审指导原则

（1） 评审产品，而不是评审生产者。

注意客气地指出错误，气氛轻松。

（2）不要离题，限制争论。

有异议的问题不要争论但要记录在案。

（3） 对各个问题都发表见解。

问题解决应该放到评审会议之后进行。

（4）为每个要评审的工作产品建立一个检查表。

应为分析、设计、编码、测试文档都建

立检查表。

（5）分配资源和时间。

应该将评审作为软件工程任务加以调度。

（6）评审以前所做的评审

九、统计软件质量保证

1、对所有错误进行分类统计 IES 规约不完整或规格说明错 MCC 未理解用户意图 IDS 故

意偏离规格说明 VPS 违背编程标准 EDR 数据表示有错 ICI 构件接口不一致 EDL 设计逻辑

有错 IET 测试不完全或有错 IID 不准确或不完整的文档 PLT 设计的程序设计语言翻译错

HCI 不清晰或不一致的人机界面 MIS 杂项错误

按严重，一般和微小级别统计各类错误的次数所占百分比，以及所有错误的数量及百分比。

例如，建立一张类似如下的表格。

然后考虑“重要少数”的错误指标，提出改进意见。

2、根据软件过程中的每个步骤计算错误指标。

Ei = 第 i 发现的错误总数 Si = 严重错误数 Mi = 一般错误数 Ti = 微小错误数

PS = 第 i 步的产品规模（ LOC，设计陈述，文档页数）

Ws，Wm，Wt 分别是严重，一般，微小错误的加权因子, 推荐取值，

Ws=10，Wm=3，Wt=1 软件工程 在过程的每一步中，计算各阶段的阶段指标

PIi = Ws（Si / Ei）+Wm（Mi / Ei）+Wt（Ti / Ei） 错误指标

Ei= ∑（i×PIi）/ PS

=（PI1 + 2PI2 + 3PI3 + … + i*PIi）/ PS

错误指标与上面表格中收集的信息相结合可以得出软件质量整体改进指标。

七、质量保证与检验 确保每个开发过程的质量，防止把软件差错传播到下一个过程，因

此，检验的目的有两个：

 1．切实搞好开发阶段的管理，检查各开发阶段的质量保证。

2．预先防止软件差错给用户造成损失。

 检验的类型有:

1．供货检验：

对委托外单位承担开发作业，而后买进或转让的构成软件产品的部件，规

格说明，半成品或产品的检查。

2．中间检验 / 阶段评审

目的是为了判断是否可进入下阶段进行后续开发，避免将差错传播到后续工作中。

3．验收检验：

确认产品是否已达到可以进行产品检验的质量要求。

 4．产品检验：

判定向用户提供的软件产品是否达到令人满意的程度。

十、检验项目内容

1．需求分析

需求分析→功能设计→实施计划

检查：

开发目的；目标值；开发量；所需资源；各阶段的产品作业内容及开发体制的合理

性。

2．设计

结构设计→数据设计→过程设计

检查：

产品的计划量与实际量；评审量；差错数；评审方法，出错导因及处理情况，阶段

结束的判断标准。

3．实现

程序编制→单元测试→集成测试→确认测试.检查内容除上述外，加测试环境及测试用例

设计方法。

4．验收

说明书检查；程序检查。

 1．3 质量保证实施 软件质量评价标准。

1．质量需求准则：

着眼点是是否满足用户的要求

2．质量设计准则：

开发者在设计实现时是否按软件需求保证了质量

3．质量度量准则：

为质量度量规定了一些检查项目:

 精密度量：

根据质量度量准则进行

详细度量 全面度量 简易度量

五个实施步骤

1．Target：

以用户需求和开发任务为依据，对质量需求准则，质量设计准则的质量特性

设定质量目标进行评价。

2．Plan：

设定适合于待开发软件的评测检查项目，一般设定 20—30 个。

3．DO：

在开发标准和质量评价准则的指导下，制作高质量的规格说明书和程序。

4．Check：

以 Plan 阶段设定的质量评价准则进行评价，算出得分，以质量图的形成表示

出来，比较评价结果的质量得分和质量目标看其是否合格。

5．Action：

对评价发现的问题进行改进活动，重复 Plan 到 Action 的过程直到开发项目完

成。

 1．4 软件可靠性 可靠性统计定义：

在给定的环境和给定的时间间隔内，按设计要求成功运行程序的概率。

 二、软件可靠性

的主要指标 MTBF —— 平均故障间隔时间 MTTF —— 平均故障时间 MTTR —— 平均修复

时间 MTBF = MTTF + MTTR

软件可用性是指在某个给定时间点程序能够按照需求执行的概率。

 可用性

= MTTF /（MTTF+MTTR）×100% 1．5 ISO9000 质量标准

ISO9000 是指质量管理体系标准，它不是指一个标准，而是一族标准的统称。

ISO9000 是

由 TC176（TC176 指质量管理体系技术委员会）制定的所有国际标准。

ISO9000 是 ISO 发布

之 12000 多个标准中最畅销、最普遍的产品。

ISO（国际标准化组织）和 IAF （国际认可论坛）于 2008 年 8 月 20 日发布联合公报，一

致同意平稳转换全球应用最广的质量管理体系标准，实施 ISO9001:

2008 认证。

2000 版 ISO 9000 族标准包括以下一组密切相关的质量管理体系核心标准：

（1）ISO 9000《质量管理体系结构 基础和术语》，表述质量管理体系基础知识，并规定质

量管理体系术语。

（2）ISO 9001《质量管理体系 要求》，规定质量管理体系要求，用于证实组织具有提供满

足顾客要求和适用法规要求的产品的能力，目的在于增于顾客满意。

（3）ISO9004《质量管理体系 业绩改进指南》，提供考虑质量管理体系的有效性和效率两

方面的指南。

该标准的目的是促进组织业绩改进和使顾客及其他相关方满意。

ISO9000 标准被很多国家采用，包括欧盟的所有成员，加拿大、墨西哥、美国、澳大利亚、

新西兰和太平洋区域。

为了注册成为 ISO9000 中包含的质量保证系统模型中的一种，一个

公司的质量系统和操作应该由第三方审计者仔细检查，查看其标准的符合性以及操作的有

效性。

成功注册之后，这一公司将收到由审计者所代表的注册实体颁发的证书。

此后，每

半年进行一次检查性审计。

ISO9001 是应用于软件工程质量保证标准。

这一标准中包含了高效的质量保证系统必须体

现的 20 条需求。

因为 ISO9001 标准，适用于所有的工程行业，因此，为帮助解释该标准在

软件过程中的使用而专门开发了一个 ISO 指南的子集 ISO9000—3。

ISO9001 描述的需求涉及到管理责任，质量系统，合约评审，设计控制，文档和数据控制，

产品标识和跟踪，过程和控制，审查和测试，纠正和预防性动作，质量控制记录，内部质

量审计，培训，服务以及统计技术的主题。