软件评测师教程笔记之第4章软件测试过程与管理.doc
《软件评测师教程笔记之第4章软件测试过程与管理.doc》由会员分享，可在线阅读，更多相关《软件评测师教程笔记之第4章软件测试过程与管理.doc（12页珍藏版）》请在冰点文库上搜索。
第4章软件测试过程与管理
4.1软件测试过程
软件的测试过程一般分成测试计划、测试设计与开发、测试实施、测试评审与测试结论等阶段。
软件测试过程是一种抽象的、遵循GB/T18905（ISO14598.5）《评价者用的过程（ProcessforEvaluator）》中定义软件评价过程的模型，是国际上共遵守的软件评测过程标准，是软件测试过程管理的精髓。
为符合GB/T18905基本原理，仍保留“评价过程”的标准用户。
4.2评价过程的特性
（1）可重复性：
由同一评价者按同一评价规格说明对同一产品进行重复地评价，应产生同一种可接受的结果。
（2）可再现性：
由不同评价者按同一评价规格说明对同一产品进行评价，应产生同一种可接受的结果。
（3）公正性：
评价应不偏向任何特殊的结果。
（4）客观性：
评价结果应是客观事实，即不带有评价者的感情色彩或主观意见。
4.3评价过程
4.3.1评价活动
评价过程由下列5个活动组成：
（1）确立软件评价需求
（2）编制评价规格说明
（3）制定评价计划
（4）评价执行计划
（5）作评价结论
4.3.2评价过程的输入
请求者提供其需求，并作为评价需求的最初版本。
请求者提供下列评价过程的输入
（1）软件的说明书；
（2）软件的部件；
评价者提供下列评价过程输入。
（1）预先确定的评价规格说明；
（2）评价方法；
（3）评价工具；
4.3.3评价过程的输出
在评价期间，评价者提供下列输出产品：
（1）评价记录，包括评价计划和评价动作的记录；
（2）评价报告草案，包括评价需求，评价规格说明和综合的评价结果；
（3）经过评审的评价报告。
4.3.4评价过程需求
评价需求、评价规格说明和评价计划是评价过程的中间产品；评价记录和评价报告是评价过程的最终产品。
（1）评价需求：
描述评价的目标，特别是描述了产品的质量需求。
（2）评价规格说明：
确定对软件及其部件实行的所有分析和测量，标识要分析和测量的软件部件。
（3）评价计划：
描述评价规格，说明需要实施的操作规程；描述评价所需用到的方法和工具。
（4）评价记录：
评价执行计划时详细记载的动作组成；记录由评价者保留。
（5）评价报告：
执行测量和分析的结果，以及能被重复和重新评价的必要信息。
评价报告首先作为评审草案来发布，其最终版本将交给请求者。
4.4评价与生存周期的关系
评价软件产品可以在任何软件生存周期过程的范围内进行。
特别是，评价能在软件获取、供应、开发、运行或维护过程中进行。
4.5评价过程的要求
4.5.1一般要求
1、组织和质量体系
2、请求者的职责
3、评价者的职责
4.5.2评价需求确立
1、评价需求确立的目的
2、评价需求分析
分析评价需求的活动由下列5个子活动组成：
（1）请求者提出评价需求建议；
（2）请求者说明评价覆盖范围；
（3）评价者分析评价原因和描述评价需求来响应请求者；
（4）评价者解释评价的保密范围和严格程度；
（5）评价者同意评价需求；
3、评价需求内容
（1）评价需求应包含对评价产品应用领域的描述，以及产品用途的描述。
（2）评价需求应由GB/T16260中定义为“质量特性”的一系列质量需求组成，还可能用到一些子特性。
（3）评价需求中的每项需求，都应提供要评价软件及部件的规格说明信息。
4、认可与报告
4.5.3评价规格说明
1、评价规格说明的目的
2、评价规格说明编制
编制评价规格说明的活动由下列3个子活动组成：
（1）分析产品的描述
（2）规定对产品及部件执行的测量
（3）按照评价需求验证编制的规格说明
3、评价规格说明的内容
评价规格说明应包括：
（1）评价范围，涉及在产品说明中标识的产品硬件；
（2）评价执行所需的信息，在产品说明中列出的软件部件及其他相关文档之间的相互引用；
（3）要执行的测量和验证的规格说明，以及对要评价的产品部件的引用；
（4）测量的验证的规格说明与评价需求之间，与引用标准或对所列的每个测量或验证的理由之间映射。
4、认可和报告
评价规格说明应作为请求者和测试者之间联合评审的结果予以认可。
4.5.4评价设计
1、评价设计目的
评价设计应把评价者使用的测量规程编成文档，以便评价执行规格说明中规定的测量。
评价者应制定评价计划来描述执行指定的评价时所需的资源和执行各种动作时对这些资源的分配。
2、制定评价计划
制定评价计划的活动由3个子活动组成：
（1）把评价方法编成文档，起草计划；
（2）优化评价计划；
（3）根据可用资源安排评价动作的进度。
（4）评价计划的内容
3、认可和报告
4.5.5评价执行
软件样品登记的信息应至少包括：
（1）部件或文档的惟一标识符
（2）部件的名称或文档标题
（3）文档的状态（包括物理状态或变异状态）
（4）请求者提供样品的版本、配置和日期信息
（5）接收的日期。
1、评价执行目的
评价执行目的是根据评价需求，按照评价规格说明中的规定和评价计划，从对软件产品的测量和验证中获得结果，执行这些动作将完成评价报告和评价记录的草稿。
2、评价执行者的动作
为了执行计划的评价，评价者应做到以下几点。
1）管理请求者提供的产品部件；
2）管理评价动作所产生的数据（包括报告和记录）；
3）管理评价执行动作的工具。
此外，评价者还可以管理在评价者的承诺之外执行的评价动作；
（1）软件部件的管理
（2）评价数据管理
（3）工具使用的管理
（4）现场评价
（5）特定评价技术的需求
（6）评审和报告
4.5.6评价结论
1、评价结论的目的
2、评价报告的联答评审
3、评价数据和文档的处置
4.6配置管理
软件测试过程的配置管理和软件开发过程的配置管理是一样的。
软件测试配置管理包括4个最基本的活动：
（1）配置项标识
（2）配置项控制（变更控制）
（3）配置状态报告
（4）配置审计
4.6.1配置项标识
标识测试样品、标准、工具、文档（包括测试用例）、报告等配置项的名称和类型。
指出何时基准化配置项（置于基线控制之下）。
标识各配置项的所有者及储存位置。
4.6.2配置项控制
规定测试基线，对每个基线必须描述下列内容：
（1）每个基线的项（包括文档、样品和工具）；
（2）与每个基线有关的评审、批准事项以及验收标准。
规定何时何人创立新的基线，如何创立。
确定变更控制委员会的人员组成、职能（包括变更授权、确认与批准）、工作程序。
确定变更请求的处理程序和终止条件。
确定变量请求的处理过程中各测试人员执行变更的职能。
确定变更请求和所产生结果的对应机制。
确定配置项提取和存入的控制机制与方式。
4.6.3配置状态报告
定义配置状态报告形式、内容和提交方式。
确认过程记录和跟踪问题报告，更改请求，更改次序等。
确定测试报告提交的时间与方式。
4.6.4配置审计
确定审计执行人员和执行时机。
确定审计的内容与方式。
确定发现问题的处理方法。
配置管理是管理和调整变更（change）的关键，对于一个参与人员较多、变更较大的项目，它是至关重要的。
4.7测试的组织与人员
组织是指一个系统将材料、知识和方法组合起来，把各种不同的输入转换成有价值的输出。
4.7.1组织结构设计因素
测试组织结构设计因素包括：
垂直还是平缓；
市场还是产品；
集中还是分散；
分级还是分散；
专业人员还是工作人员；
功能还是项目；
4.7.3测试组织管理者
测试管理是很困难的，测试组织的管理者必须具备：
理解与评价软件测试政策、标准、过程、工具、培训和度量的能力；
领导一个测试组织的能力，该组织必须坚强有力、独立自主、办事规范没有偏见；
吸引并留住杰出测试专业人才的能力；
领导、沟通、支持和控制的能力；
测试时间、质量和成本控制的能力。
4.7.4集中管理的测试组织
4.7.5选择合理的组织方案
选择合理高效的测试组织结构方案的准则是：
（1）提供软件测试的快速决策能力；
（2）利于合作，尤其是产品开发与测试开发之间的合作；
（3）能够独立、规范、不带偏见地运作并具有精干的人员配置；
（4）有利于协调测试与质量管理的关系；
（5）有利于满足软件测试过程管理要求；
（6）有利于为测试技术提供专有技术；
（7）充分利用现有测试资源，特别是人；
（8）对测试者的职业道德和事业产生积极的影响。
4.7.6测试人员
1、测试人员的选择
测试人员的能力包括以下几项：
测试人员的能力包括以下几项。
（1）一般能力：
包括表达、交流、协调、管理、质量意识、过程方法、软件工程等；
（2）测试技能及方法：
包括测试基本概念及方法、测试工具及环境、专业测试标准、工作成绩评估等；
（3）测试规划能力：
包括风险分析及防范、软件放行/接收准则制定、测试目标及计划、测试计划和设计的评审方法等；
（4）测试执行能力：
包括测试数据/脚本/用例、测试比较及分析、缺陷记录及处理、自动化工具；
（5）测试分析、报告和改进能力：
包括测试度量、统计技术、测试报告、过程监测及持续改进。
2、测试人员的激励
（1）X理论+Y理论
X理论：
胡萝卜+大棒——迫使人们工作；
Y理论：
经理的职能不是督促人们工作，而是使人们有可能工作。
（2）需要的层次（Maslow模型）
生存需要——工作职位、工资奖金、休息时间；
安全需要——公正待遇、应付工作的能力和信心；
社会需要——团队归属感，互相认同、理解和支持；
自尊需要——具有受人尊重/赏识的能力或/和业绩；
自我实现需要——成为自己期望的人物。
（3）人员激励的关键点
（4）人员自我激励
注意测试工作的7条效率原则：
主动思考，积极行动；一开始就牢记目标，不迷失方向；重要的事情放在首位（但常常把紧急的事情放在首位）；先理解人，后被人理解；寻求双赢；互相合作，追求1+1>2；终生学习，自我更新，不断进步。
3、测试职业发展
4、人员的培训
（1）软件测试培训和内容分类
（2）制定测试人员培训计划
4.8软件风险分析
4.8.1软件测试与商业风险
软件公司的管理者制定整体软件开发战略时使用“计划—执行—检查—改进（PDCA）”循环理念，战略性的策略可以转为商业上的主动。
软件测试是一种用来尽可能降低软件风险的控制措施。
风险的定义为“伤害、损坏或损失的可能性：
一种危险的可能或一种冒险事件。
”
风险分析是一个对潜在问题识别和评估的过程，即对测试的对象进行优先级划分。
风险分析包括两个部分：
（1）发生的可能性——发生问题的可能性有多大；
（2）影响严重性——如果问题发生了会有什么后果。
通常风险分析采用两种方法：
表格分析法和矩阵分析法。
4.9软件测试的成本管理
4.9.1测试费用有效性
“太少的测试是犯罪，而太多的测试是浪费。
”对风险测试得过少，会造成软件的缺陷和系统的瘫痪；而对风险测试得过多，就会使本来没有缺陷的系统进行没有必要的测试，或者是对轻微缺陷的系统所花费的测试费用远远大于它们给系统造成的损失。
4.9.2测试成本控制
测试工作的主要目标是使测试产能最大化，也就是，要使通过测试找出错误的能力最大化，而检测次数最小化。
测试实施成本组成部分包括：
测试准备成本、测试执行成本和测试结束成本。
1、测试准备成本控制
测试准备成本控制的目标是使时间消耗总量、劳动力总量，尤其是准备工作所需的熟练劳动力总量最小化。
准备工作一般包括：
硬件配置、软件配置、测试环境建立，以及测试环境的确定等。
1、测试执行成本控制
测试执行成本控制的目标是使总执行时间和所需的测试专用设备尽可能地减少。
完全重新测试：
部分重新测试：
部分重新测试选择方法有两种：
（1）对由于程序变化而受到影响的每一部分进行重新测试；
（2）对与变化有密切和直接关系的部分进行重新测试。
3、测试结束成本控制
测试结束成本的控制是进行测试结果分析和测试报告编制、测试环境的清除与恢复原环境所需的成本，使所需的时间和熟练劳动力总量减少到最低限度。
4、降低测试实施成本
5、降低测试维护成本
4.9.3质量成本
1、质量成本要素
（1）一致性成本（CostofConformance）
一致性成本是指用于保证软件质量的支出，包括预防成本和测试预算，如测试计划、测试开发、测试实施费用。
测试预算被称为审查费：
（2）非一致性成本（CostofConformance）
非一致成本是由出现的软件错误和测试过程故障（如延期、劣质的测试发布）引起的。
这些问题会导致测试返工、补测、延迟。
追加测试时间和资金就是一种由于内部故障引起的非一致成本。
非一致成本还包括外部故障（软件遗留错误影响客户）引起部分。
这些成本还包括技术支持小组预算，错误修正花费、产品收回、赔偿和销售成本。
4.9.4缺陷探测率（DDP）
（DDPDefectDetectionPercentage）
缺陷探测率DDP是另一个衡量测试工作效率的软件质量成本的指标。
缺陷探测率是衡量测试投资回报的一个重要指标。
4.9.5测试投资回报举例
假设发现的错误为300个，测试过程的估算如下：
（1）单元测试阶段，软件开发人员发现及修改一个错误需要50元
（2）建立独立的测试进行集成和系统测试，开发人员修改后，测试人员再确认，一个错误需要300元
（3）在产品发布后，由客户发现，报告技术支持人员、相关开发人员修改，测试组再进行回归测试，一个错误需要2000元。
第一种情况：
开发人员测试发现100个错误，而产品发布后客户发现错误200个，总成本405000元，缺陷探测率为33.3%
第二种情况：
投资预算人员费用为60000元，测试环境使用费为8000元，测试投资（一致性成本）68000元；开发过程中开发人员修改100个错误外，测试过程中测试人员发现错误150个，而产品发布后客户发现50个错误。
总质量成本下降到218000元，手工测试总质量成本节约了187000元，即为利润。
投资回报率（ROI）=节约的成本i-利润i/测试投资=405000-218000/68000*100%=275%
缺陷探测率（DDP）=（100+150）/（100+150+50）*100%=83.3%
升级会员 