part05 软件测试评审

CstA

软件测试工程师培训

软件评审

软件测试培训中心

CstA

Outline

•一、概述

・二、SDLC中的软件验证

・三、SDLC中的软件确认

•四、SDLC中的评审过程

软件涣J试培训I中2

CSJA

1、概述

•1.1概念

•L2V-model中的V&V&T

•L3V&V&T的区另I」

_软件j则试培■训中］

CSJA

1.1概念一软件缺陷(Defect)

1)缺陷是对软件产品预期属性的偏离现象：

■对产品规格说明(Specifications)的偏离。如：规格

说明规定：a+b=>c,而实际产品不是。

■对客户/用户期望的偏离，客户/用户要求未纳入产品

(可能是规格说明疏漏，也可能实现有问题)。

■Fault在硬件中称为故障，在软件中它和Defect同义。

—软件测试由II中心4

区以人

1.1相S念一软件缺陷(Defect)

(2)缺陷有三种：错误(Wrong)：

■未将规格说明正确实现(对规格说明的偏离)。

■遗漏(Missing)：规定的或预期的需求未体现在产品中

(可能未将规格说明全面实现，也可能在开发过程中，甚

至在其后追加了客户需求)。

■额外的实现(Extra)：规格说明未规定的需求被纳入产

品加以实现(也许是用户期望的属性，但只能被当作缺

陷)。

.软件涣J试培训I中5

CstA

既念一软件缺陷(Defect)

(3)缺陷和事故(Failures)

■机械与建筑的比喻

■缺陷是软件内部的“裂缝”。在未影响到用户和系统运行

时，并未表现出来。

■当缺陷引发运行错误(Error)或产生负面影响时，构成事

故，对我们造成伤害。

软件涣J试培训I中6

CstA

LI概念一缺陷的排除手段

•V&V&T：为了发现错误、确定功能、保

证产品质量，在SDLC中进行评审、分析

和测试活动的总称。

-Verification

-Testing

-Validation

.软件涣j试培训I中7

CstA

LI概念一验证

•根据IEEE610.12-1990

•验证(verification)是对系统或单元的评

价过程，以确定一个给定的开发阶段的

产品是否满足在此阶段开始时给定的条

件。

•验证是与软件开发活动同时执行地活动

•验证回答“我们正在构造的产品正确

吗？”

8

CstA

LI概念一确认

•确认是在软件开发过程期间或结束时评

价系统或单元的过程，以确定他是否满

足特定的需求。

■在软件开发后判断软件是否正确地实现

了需求

•回答“我们已经构造的产品正确吗?”

一软---件-------测--------试-------培-------■--------训--------中---------心-----------y°

1.2V-model中的V&V&T

_软件测试培训中心

10

CSIA

1.3V&V&T的区另U

•目的相同：排除缺陷，保证质量

・在SDLC中位置不同

•实施方法不同：验证方法有代码走查、审查，

而确认方法有测试和正确性证明

•关注点不同：验证关心的是确保软件模块或功

能内在的正确性；确认则表明要与规定的需求

进行比较是否满足要求，它所关心的是该软件

产品的价值。

一软件测试于II中心”

CstA

2、SDLC中软件验证活动

•2.1评审

•2.2软件质量度量

•2.3配置管理

软件涣j试培训।中12

CSIA

2.1软件评审（Review）

•2.1.1概述

•2.1.2软件评审的动机

•2.1.3作为连续过程改进的软件评审

•2.1.4评审的类型

•2.1.5软件评审的作用

•2.L6软件项目评审实例

•2.1.7评审在若干国际标准中的要求

•2.1.8正式评审的实施步骤

•2.1.9评审实践中所显示的效益

•2.1.10实施软件评审经常出现的问题

•2.1.11做好软件评审的建议

一软件测试培训中心13

2.1.1概述

■工EEE定义：评审是软件开发组之外的人员或

小组对软件需求、设计或代码进行详细审查的

一种正式评价方法。其目的在于发现其中的缺

陷，找出违背执行标准的情况以及其它问题。

■1994年，工EEE在软件评审和审核标准

(IEEEStandardforSoftware

ReviewsandAudits)中说：软件评审是

一种对软件元素所作的正式的、同行间的评审

活动，其目的在于验证软件元素满足其规格说

明，并能符合标准的要求。

___________________________软件涣J试培训I中14

CstA

概述

■软件评审是软件生产过程中过滤软件错误的一

个“滤波器”。

■软件评审涉及评审的组织机构、管理、准则、

类别、内容、文件和要求等。

■一般要求在软件研制阶段的里程碑点进行软件

评审。评审的主要类别有：软件定义评审、软

件需求评审、概要设计评审、详细设计评审、

软件实现评审和软件验收评审等。

一软件测试培训中心15

CSJA

发展历史

­软件工程过程是一个重要的质量保证手段

•是软件测试不可代替的

•最早于1972年IBM公司实施了M.E.Fagan提出的代

码检查法

•实践表明了它的效果，后推广到针对需求、设计

以至管理

•许多软件工程标准都对其作了规范化要求

•被广泛采用后，展开成各种形式和不同的称呼，

但本质上无太大区别。如：Inspection,Review,

FormalReview（正式评审），PeerReview（同

行评审），Buddycheck,Walkthrough（走查）。

___________________________软件涣J试培训I中16

•1972Walkthroughs/reviewscommonpracticeinIBM.

M.Faganintroducedinspectionprocessbasedon

experiencefromhardwaredevelopment.Strong

resistancetochange.SpreadinIBMwasslow,but

graduallygainedmomentum.Inspectionsof

requirements,design,codetestplans/casesand

userdocumentationwereverysuccessful.

•1976PaperoninspectionsinIBMSystemJournal,

byM.Fagan.Variousformsofinspectionwere

practicedbyIBMcustomersandothers.

•1979Valueofinspectionsacknowledgedby旧M's

largestindividualawardtoM.Fagan.Promotedmore

widespreaduse

___________________________软件涣j试培训i中17

CS1A

•1983Evolutionoftheinspectionprocessthroughuse

inregulardevelopmentandexperimentation.Many

hypothesestoimproveinspectionsevaluatedthrough

measurementof>600experimentaleventsselected

from11,000inspections.

•1986PaperinIEEESoftwareoninspections,byM.Fagan.

(Highlightsofinspectionprocessonly,no

experimentalresults.)

•1989Independently,M.Fagancommencedtraining

softwarecompaniesininspectionsandprocess

improvement.(ClientsusedthetermsFaganInspection

andFaganMethodologytodifferentiatefromother

forms.)

•2001>100clientorganizationstrainedtodateby

MichaelFagan.

一软件测试于II中心18

CstA

Whatinitiatedcreationofinspections?

•1972MichaelFagantransferredinto

softwaredevelopmentmanagement(from

hardwareengineering).

•Theprevailingfocusinsoftwaredevelopment

was:

-Deliverfunction-critical,

-Deliveroncommitted*schedule-critical,and

-Qualityofshippedproduct-important.

一软件测试于ii中心1Q

CstA

•HOWEVER,

•Fixingdefectsinshippedproduct

divertedeffortfromdevelopingthenext

release,causingittobedelayed

•Defectsreallydisturbedcustomers!

一软件飘试培■训中

----------i---------—l-----==«NU

CS1A

•Usedthefollowingworkinghypothesesofcurrent

practice:

->50%ofdevelopmenteffortwasactuallyusedfordefect

rework.

(Defectreworkeffortwasnotbeingactivelymanaged.

Onlythe'visible'workwasbeingplannedandmanaged.)

-Efforttoreworkadefectincreasedineachphaseby10X

upto

100Xbyendofthedevelopmentcycle-andwashigherin

the

field.

•Recognizedthatcreativeoriginalworkoften

containsdefectsanditisourbusinesstodo

creativeoriginalwork.

•Peoplemakemistakes!

___________________________软件试培训i中，二21

CstA

•CREATEDINSPECTIONCREATEDINSPECTION

PROCESSPROCESStofinddefectsasclosetotheir

pointofcreationaspossible.

•Inspectionsappliedtodesign,codeand

requirements.

•Thisalsoenabled:

-Measurementofdefects,

-Managementofdefectrework,and

-RemovalofSystemicdefectsfromthe

developmentprocess.

___________________________软件涣j试培训i中22

2.1.2评审的动机

•不能测试所有软件，穷举测试不现实

•缺乏规约和高层设计的实用测试技术

-需求是软件开发过程中最普遍的问题根源。

-需求是用自然语言编写的，写需求的人通常很少或没有经

过编写软件需求的训练

-自然语言是不严密的、二义性的和非确定性的，而软件是

严密的，无二义性的和确定的。

・测试软件测试计划的想法使人迷惑

•评审能够解决测试解决不了的质量问题

•评审与测试互补

___________________________软件涣j试培训।中23

CS1A

2.1.3作为连续过程改进的软件评审

•在SDLC中采用技术评审的手段清除缺陷

是质量控制技术之一

•评审能增加软件开发的效率和提供产品

质量的测量方法

•评审确保对需要重做部分达成一致意见,

减少重复劳动、测试的量

•评审能比自动软件测试更有效

■技术评审也可以看作手工测试的形式

24

CS1A

2.L3作为连续过程改进的软件评审

•评审能在SDLC早期清除缺陷，很大程度

上减低了成本

•评审还能通过定期分析缺陷记录并在

SDLC早期排除根本原因

•结构化走查和审查是比单纯测试更有效

的缺陷排除手段

•验证任何重做部分满足预先定义的准则

一软件涣试培•训中

j25

CS1A

2.1.3作为连续过程改进的软件评审

•掌握项目的进展状况

•充分理解项目的特性，明确下一阶段的

工作计划

•评价前一阶段工作的质量

•将评审结果作为反馈，惊醒过程评价，

改进软件过程

一软件测试培训中心26

CstA

2」.4评审类型

■非正规评审：同事间随时发生，不需要

负责任，不要求提交评审报告

•正规评审：经过仔细计划的会议，参与

评审者有责任，要提交评审报告

・审查与走查

■评审的复杂度与项目的复杂度相关

一软件飘I试培■训中?7

审查

•审查技术是软件产品开发过程中正规定

义的验证过程

•检查特定阶段的所有软件产品可提交的

制品，评估当前状态和质量有效性

•审查中要作出的决定之一是能否进入到

下一开发阶段。

•审查是系统化的、可控的、压力小的

一软件测试于II中心

CstA

审查

•审查是正式、严格、具有深度的技术评

审

•审查是软件质量实现重大改进的强有力

工具

•在缺陷排除率高的公司中，正式审查是

一个重要的因素

•正式审查被认为是“一流”公司的共同

实践之一

_软件涣试培训中

J29

走查

•讲解评审，通常评审参与者（一般是软件开发

人员）陈述软件的表示，其他人提供对讲解的

反馈

•评审者不需要特别的准备

•由于是非正规评审，容易导致评审的无组织、

难隹制。

•如果开发人员进行走查容易产生压力

•与通过评审会来实施的正式评审不同，走查通

常是非正式的，特别是针对程序而言

软件测试培训中心

30

CSJA

审查与走查的比较

属性审查走查

目的发现问题发现问题

验证重做的工作讨论可选方案

重点是书面的产品是重点说明产品是怎样满足所有需求的

否满足所有需求

做出决定审查组根据多数人意责任人做出所有的决定

见做出所有决定

领导者经过培训的主审员通常是责任人

参与者以文件形式确定的同级人员和技术主管，但不以文件的形式

同级人员

资料介绍讲解员介绍资料责任人介绍资料

度量正式需要可选

程序正式文档非正式文档

培训对所有参与者都要求无培训要求

一软中心

CS1A

审查为什么被看作是正式的

•定义了参与者的角色和责任

•定义了要遵循的过程，包括审查会议前、

会议门及会议后的活动。正式的过程确

保能够达到审查的目的

_软件涣J试培训中32

3A

产品经理的角色和职责

・帮助决定审查的内容

•将审查工作纳入项目计划

•分配审查资源

・保障审查培训工作

・参与主审员的选定工作

•支持主审员完成所要求的任何修改工作

___________________________软件涣J试培训I中33

参与审查会的角色

•主审员：协调本次审查并主持讨论。

•责任人：负责被审查的产品。

•讲解员：在审查会上讲解被审查的产品。

・审查员：审查产品。

•记录员：记录在审查会议上讨论的问题。

•经理：责任人的管理者。

一软件测试培训中心34

CstA

审查组成员的职责一主审员

•是审查过程成败的关键，应具备具备主审员的

素质、经验，具有专业技能和管理技能

•主审员一般由产品经理和责任人选择

•主审员必须能够：

-了解正在审查的信息

-领导审查组展开有效的讨论

-调解争端

-分辨主要问题引导审查组侧重这些问题

-客观性地提出意见

-适当地赋予职责

软件测试培•训中心35

CS1A

审查组成员的职责一主审员

•主审员具体职责

-选定审查组成员

-确保审查组成员用于审查的时间

-确保产品经理了解审查工作

-制定审查会计划，安排资料、后勤的准备

-审查会前验收审查准备情况

-确保审查会高效、有序进行

-确保审查会上确定的问题文档化

-问题追踪直到解决

-审查会后完成会议记录和审查报告

一软件测试培训中心36

CstA

责任人

•准备要审查的信息或工作产品的人

•职责：

-确保要审查的工作产品已就绪

-按时提供审查所需的信息

-帮助主审员做好会议安排、资料准备、问题改正进

度安排

-及时解决审查组确定的所有问题

-坚持客观性，避免辩解

-在审查会上阐明审查员不清楚的问题

一软件测试培训中心37

CstA

讲解员

•负责对备审的工作产品进行释义，同时

也是审查员

•职责：

-完全熟悉正在审查的工作产品

-确定信息的逻辑块并能解释每一个信息块

-支持主审员工作

一软件现j试培■训中.O

CstA

审查员

•寻找工作产品与所依据的文档、标准之间的差

异，确定存在的问题

•职责：

-完全熟悉要审查的工作产品

-完全熟悉审查依据的文档和标准

-鉴别工作产品中存在的问题

-保持客观性

-对产品而不是责任人提出批评

-支持主审员工作

一软------件---------测--------试---------培--------训---------中---------心----------D/.

CstA

记录员（任选）

•在审查会上记录审查组确定的问题及其

说明

•也是审查员

•职责：

-完全熟悉要审查的工作产品

-记录审查组提出的所有问题

-提供主审员要求的其他补充信息

-支持主审员工作

_软件涣J试培训中40

CS1A

审查的内容

•对于正确操作产品起关键作用的模块。

•根据复杂度度量工业标准，如McCabe圈复杂度,

对模块的客观评估，比其他模块更复杂的模块。

•与过去发生错误率较高的模块功能类似的模块。

•相对较新的或缺乏经验的软件工程师编写的模

块。

.软件顼!J试培训I中41

CstA

审查何时正式结束

■当主审员处理完审查问题报告表中确定

的所有问题的修改部分，审查就可以正

式结束了。

软件测试培•训中心42

2.1.5软件评审的作用

•及时消除开发过程中引入的缺陷

•提高软件生产率，降低消除缺陷的成本

•评审可为项目监控提供信息

•评审可找出测试无法发现的问题

•帮助参加评审的人员从发现的缺陷中学到知

识，吸取教训，提高优秀软件工程师的标准

•提供产品质量和过程有效性的数据

43

CstA

作用

•在团队成员之间建立技术上的相互了解。

•增加软件确认测试的有效性

•技术把关，避免软件人员的想当然；

•概念沟通，吸收用户和总体人员参加，审查软件人

员理解的正确性；

•集思广益，吸收有关的分系统人员参加，从不同侧

面确认软件的协调性；

•总结汇报，使实时控制系统总指挥、总设计师了解

软件生产的进度、问题和要求，作出新的部署。

___________________________软件涣j试培训।中44

CstA

1.及时消除开发过程中引入的缺陷(A)

•在软件生存期中缺陷的产生、传递和排除图

缺陷<7

R

_软件涣J试培训中45

1.及时消除开发过程中引入的缺陷(B)

未经软件评审的错误扩展图

开发阶段

来自前阶段传递的错误数发现和传递到下阶段

的错误

按1：M扩展的错误数排除的错误

新产生的错误数比率

概要设计

详细设计

0106编码，单元测试

63710

00(%10

4*1.53------94

1027*32(%

4M=1.5

2527M=3

25

系统测试

12

50%

o1

,软件测试培粉片1心

46

1.及时消除开发过程中引入的缺陷(C)

•经过软件评审的错误扩展图

概要设计

详细设计

一软件测试培训中心47

Csm2、提高软件生产率，降低消除缺陷的成本(A)

1)软件缺陷随着开发进程而逐渐扩展

•开发后期难于发现前期引入的缺陷，又难于排除

•下图表明需求中有两个缺陷dl和d2,其影响区有交叉

维护

软件期试培•训中/一

!J48

£力2、提高软件生产率，降低消除缺陷的成本⑻

(2)在软件实现后，甚至在运行维护阶段找出并清除需求或设计中引入的缺陷，其

成本是开发初期及时发现和消除成本的十几倍，甚至百倍。

25

清

除

缺20

陷

的15

代

价1

0

需求评审设计评审静态分析结构测试功能测试

各阶段清除缺陷的代价

软件测试—中心

II49

CstA

找

到

错

误

的

相

对

成

本

不同阶段发现错误的相对成本

软件涣j试培训中sn

•是否实施评审项目其开发成本的比较

发现错误时间发现错误数每错纠正成本总成本

设计中221.533

测试前366.5234

实施

测试中2115315

评审

交付后367201

合计783

测试前226.5143

实

未

评

施测试中82151230

聿

审交付后1267804

合计2177

注：数据取自RogerS.Preessman,AManager'sGuideToSoftware

Engineering.P327

软件泱试培训中/二

JI51

CstA

3、评审可为项目监控提供信息

•管理人员通过评审获得的项目信息最为客观、

可靠。

•收集有关缺陷的信息，并对其加以分析，有

助于用以总结缺陷出现和消除的规律进而用

以改进过程。

_软件涣J试培训中52

CS1A

4、评审可找出测试无法发现的问题

例如：

•对标准的符合性

•逻辑性

■数据问题

•模块化

•接口问题

•简明性

•性能问题

一软件现I试培■训中„

CS1A

5、帮助参加评审的人员从发现的缺陷中

学到知识，吸取教训。

•避免在以后的项目中出现类似的问题

•可用以丰富和充实检查单(checklist)的内容。

.软件测试培训中心

54

CstA

2.L6软件项目评审实例

■软件项目评审实例

•系统研制评审实例

•软件质量保证系统生存期

•软件评审不充分导致系统灾难性事故的

实例

■软件测试培训中心

55

1.软件项目评审实例

体

初

编

单

集

确

过

代

分

设

码

步

析

系

元

成

程

计

码

认

需

设

与

结

测

测

设

走

走

测

求

计

规

构

试

评

试

计

查