TM第二章测试管理

第二章测试管理

2.2一定条件下的测试管理

2.2.1了解测试干系人

什么是测试干系人：

与测试活动/测试工作产品/最终系统/交付物的质量有利益关系的

测试干系人（除项目/产品/组织）包含哪些人：

    1. 开发人员/开发组长/开发经理

    2. 数据库架构师/系统架构师和设计师

    3. 市场和业务分析师

    4. 高层管理人员/产品经理/项目发起人

    5. 项目经理

    6. 技术支持/客户支持/帮助台人员

    7. 直接和简介用户

2.2.2其他软件开发周期活动及工作产品

测试活动/干系人/软件开发生命周期活动/工作产品之间的具体关系取决什么：

    项目/选定的软件开发生命周期

测试活动还和哪些活动相关联：

    1. 需求工程和管理

    2. 项目管理

    3. 配置和变更管理

    4. 软件开发和维护

    5. 技术支持

    6. 编写技术文档

2.2.3测试活动和其他生命周期活动的整合

软件开发模型

    1.顺序模型----如瀑布/V/M模型

    2.迭代或增量模型----如快速应用开发和统一开发过程

    3.螺旋

V模型中，用什么方法定义测试级别

    1. 系统测试计划活动与项目计划同时进行，测试控制一直持续到系统测试执行和测试结束工作完成

    2. 系统测试分析和涉及与需求规格说明/系统/架构（概要）设计说明/组件（详细）说明编写同时进行

    3. 系统测试实施活动可在系统设计期间开始，但大部分都是与编码和组件测试同时进行

    系统测试相关的部署工作通常会延续到系统测试执行的开始前几天

    4. 当所有的系统测试入口准则被满足（或免除）时开始系统测试执行活动，系统测试入口准则一般是指至少完成了组件测试，通常还包括完成组件集成测试

    系统测试会被持续执行直到系统测试出口准则被满足为止

    5. 整个系统测试执行期间都在评价系统测试出口准则和汇报系统测试结果

    当项目即将达到最后期限时评价和汇报频率更高，也更紧迫

测试如何影响软件开发生命周期中的活动和工作产品：（详见2.4.2）

    测试经理在测试计划/项目计划期间，对各测试级别和选定的生命周期模型与测试过程的结合进行项目特定的整合

各测试级别应明确定义以下要素：

    1. 测试目标，可实现的目的

    2. 测试范围和测试项

    3. 测试依据，以及衡量该测试依据覆盖率的方式（如可追溯性）

    4. 入口和出口准则

    5. 测试交付物，包括结果汇报

    6. 适用的测试技术，以及与这些技术相应的确保覆盖度的方式

    7. 与测试目标/入口和出口准则以及结果汇报相关的度量和度量标准（包括覆盖率的度量）

    8. 针对具体的测试任务应用的测试工具（适用时）

    9. 资源（如测试环境）

    10. 测试团队内外部负责的个人和群体

    11. 符合组织/法规和其他规范（使用时）

注！在各测试几倍对上述要素要一致定义，以免不同几倍的类似测试之间出现不必要的差距，造成危险和资源浪费

2.2.4管理非功能测试

针对非功能测试活动，部分测试计划责任委派给技术测试分析师

测试经理需要求分析师考虑到以下一般因素：（测试分析师详见第四章）

    1.干系人需求

    2.所需的工具

    3.测试环境

    4.组织因素

    5.安全性

测试经理需考虑：怎样将非功能测试集成到软件开发生命周期中：

    1. 应优先安排非功能测试，并根据风险对测试进行排序

    2. 早期的测试级别中，可通过多种途径缓解非功能风险

    3. 对于单次迭代周期花费时间更长的测试设计和实施活动应单独安排成迭代之外的工作活动

2.2.5管理基于经验的测试

基于经验的测试优点：

    1.找出其他测试技术可能遗漏的缺陷

    2.检查其他测试技术的完整性

缺点：

    1.很难评估其达到的覆盖率

    2.需特别留意测试结果的可重复性（尤其多人参与测试时）

如何管理基于经验的测试：

    1. 将工作分解成30-120分钟的时间段（测试会话）

    2. 将自主和自发测试集成到更为传统的预先设计好的测试会话中

    3. 每次探索会话之初，测试人员确认并执行必要的测试启动任务

    4. 在会话期间，测试人员根据采用的测试技术设计和执行测试，查找缺陷，并将测试结果记录在日志中

    5. 在会话结束后，有一个情况汇报，为后续测试会话确立方向

2.3基于风险的测试及其他测试优先级设定和工作量分配的方法

测试管理中普遍存在一个挑战时测试的选择/分配/优先级的设定

什么是基于风险的测试：

    使用产品质量风险来选择测试条件，为这些条件分配测试工作，并为胜场的测试用例设定优先级

    其明确指出的或隐含的目的就是用测试来降低整体的质量风险水平

    具体就是把风险水平降低到可接受的范围

2.3.1基于风险的测试

测试团队规避风险的措施：

    设计/实施/执行测试来缓解质量风险

基于风险的测试包含的活动：

    1. 风险识别

    2. 风险评估

    3. 风险缓解

    4. 风险管理

2.3.3.1风险识别

可通过什么技术来识别风险

    1. 专家咨询

    2. 独立评估

    3. 使用风险模块

    4. 项目回顾

    5. 风险研讨会

    6. 头脑风暴

    7. 检查表

    8. 参考过去的经验

2.3.3.2风险评估

什么是风险评估

    研究识别出的这些风险，发生在风险识别之后

    在对风险识别时，就可对风险进行分类

如何确定风险级别：

    1. 每条风险发生的可能性

    2. 发生风险带来的影响

影响产品和项目风险发生的可能性包括：

    1. 技术和团队的复杂性

    2. 业务分析师/设计师和程序员的人员和培训问题

    3. 团队内部冲突

    4. 与供应商的合同问题

    5. 异地工作的团队队员

    6. 旧方法和新方法对立

    7. 工具和技术

    8. 管理或技术领导不力

    9. 时间/资源/预算和管理压力

    10. 缺乏前期的质量保证活动

    11. 高变更率

    12. 早期的高缺陷率

    13. 接口和集成问题

影响产品和项目风险程度的因素有：

    1. 使用受影响的特性的频率

    2. 该特性对于实现业务目标的关键程度

    3. 声誉的受损

    4. 商业的损失

    5. 潜在的财务/生态/社会损失或法律责任

    6. 民事或刑事法律制裁

    7. 吊销执照

    8. 缺乏合理的变通

    9. 明显的失效导致负面声誉

    10. 安全性

如何判定风险级别：

    1. 定性评估

    2. 定量评估

注！通常采用定性评估

风险分析过程包括：

    1. 达成共识

    2. 检查风险级别的分布情况，确保风险的评分对于测试排序/优先级设定和分工能起到实际的指导作用

2.3.1.3风险缓解

基于风险得测试从质量风险分析开始

质量风险分析是主测试计划和其他测试计划得基础

开发和执行测试的工作量与风险的级别成一定比例

风险级别越高，使用的测试技术越细致，风险的级别越低，使用的测试技术就越不细致

开发和执行测试的优先级也是依据风险级别而设定的

在项目的主要里程碑到来时，定期调整质量分析

调整内容包括：

    1. 识别新风险

    2. 重新评估现有风险的级别和评价风险缓解活动的有效性

    3. 在测试执行之前可缓解产品质量风险

2.3.1.4生命周期的风险管理

测试方针文档和测试策略文档中应描述测试中管理产品风险和项目风险的一般过程，以及风险管理怎样集成到测试的各个阶段中，并使其发挥作用

深度优先：

    所有的高级别风险的测试都是在低级别风险测试之前进行的，且测试的运行严格按照风险排序

广度优先：

    风险封盖了评估选出的测试样本，确保每条风险至少被覆盖一次

2.3.2基于风险的测试技术

轻量级方法的例子：

    1. 使用风险分析与管理

    2. 系统的软件测试和产品风险管理

正式基于风险的测试技术，测试经理有许多可用的选项：

    1.危害分析，延伸至整个分析过程的上游，尝试识别每个风险背后隐藏的危害

    2.一个危害的成本

对每个质量风险，风险评估过程包括三要素：

        1）与该风险项相关的失效的可能性（用百分比表示）

        2）一旦生产期间发生与该风险项相关的典型失效将造成的失效成本（用金融数量表示）

        3）这些失效的测试成本

    3. 失效模式和影响分析和其变体，识别质量风险，风险的潜在原因和可能造成的影响，然后确定严重程度，分配优先级和检测等级

    4. 质量功能展开，一种影响测试的质量风险管理技术，具体而言，关注的是对客户或用户需求的理解不当或不充分引起的质量风险

    5. 故障树分析，对各种实际发现的失效（从测试或生产中）或潜在失效（质量风险）进行根本原因分析，首先分析会导致失效的缺陷，其次是会导致这些缺陷的（人为）错误或（其他）缺陷，一直继续直到找出根本原因

基于风险的测试只要成功，以下四个问题答案是肯定的：

    1. 测试团队发现的重要缺陷是否比次要缺陷更多

    2. 大部分重要的缺陷是否是测试团队在测试执行的初期发现的

    3. 测试团队能都就风险向干系人解释测试结果

    4. 测试团队跳过的测试是否比执行的测试相关风险级别要低

2.3.3选择其他测试技术

1.基于需求的测试可使用的测试技术：

    1）歧义评审

    2）测试条件分析和因果图

    3）歧义评审识别和消除需求文档中的歧义

2.基于模型的方法

3.检查表方法

4.应对行方法

2.3.4测试过程中测试优先级设定和工作量分配

    1. 在测试分析/涉及和实施期间，必须采用在测试计划阶段做的测试分工和设定的优先级

    2. 在执行测试时，还是应该使用在计划阶段设定的优先级，在计划制定后根据获取的信息定期更新优先级

    3. 作为结果汇报和出口准则评估的一部分，测试经理可衡量测试完成的程度，应包括将测试用例和发现的缺陷追溯到相关的测试依据

    4. 测试结束期间，测试经理应评估与所有干系人，包括客户和用户的质量方面的需求和期待相关的度量标准和成功准则

2.4测试文档和其他工作产品

组织和项目中常用的工作文档类型：

    1. 测试方针：描述组织的测试目标和目的

    2. 测试策略：描述组织中通用的/不按项目而变化的测试方法

    3. 主测试计划（项目测试计划）：描述一个特定项目中测试策略的实施情况

    4. 级别测试计划（阶段测试计划）：描述在每个测试级别中所要进行的特定活动

2.4.1测试方针

什么是测试方针：

    描述了组织为什么要进行测试

    定义了组织期望达到的总体测试目标

    由组织中的高级测试管理人员，在测试干系人组的高层经理的协助下制定

    测试方针是质量方针的一部分

什么是质量方针：

    描述质量管理的整体价值和目标

测试方针中的内容包含：

    1. 总结组织驱动测试价值

    2. 定义测试目标，如建立对软件的信息，检测软件的缺陷，降低质量粉线的级别（详见2.3.1节）

    3. 描述如何评估测试满足这些目标的有效性和效率

    4. 列出典型的测试过程

    5. 说明组织将如何改进其测试过程（参见第五章）

测试方针适用于什么样的测试活动：

    1. 新开发项目的测试活动

    2. 维护项目的测试活动

    3. 也可制定真个组织要使用的测试术语和测试工作产品的内部/外部参考规范

2.4.2测试策略

什么是测试测略：

    描述组织的通用测试方法

    用测试管理产品和项目风险/测试级别的划分和测试相关的概要活动的方式

    为组织或一个或多个项目提供通用测试入口和出口准则

    测试策略描述的是一般测试方法

 一般测试方法包括：

    1. 分析型策略，如基于风险的测试

    2. 基于模型的策略，如基于运行概况的测试

在这种情况下，测试团队开发一个模型，该模型展现
了系统存在的环境（基于实际或期望的情况），系统应该接受的输入和系统运行的条件，以及系统应如何运行。例如，在针对高速发展的移动设备应用程序的基于模型的性能测试中，基于当前的使用情况和项目随着时间推移的发展情况，可能会开发出展现往来的网络通信量、活跃和不活跃的用户以及造成的处理负载的模型。另外，也可能开发出当前生产环境的硬件、软件、数据容量、网络和基础设施的模型。还可能开发出理想的、预期的和最小的吞吐率、响应
时间和资源分配的模型 

    3. 系统化的策略，如基于质量特征的测试

    4. 符合过程或标准的策略，如受制于美国食品药品管理局标准的医疗系统的测试

    5. 应对型策略，如缺陷攻击测试

    6. 咨询式策略，如用户导向的测试

    7. 面向回归测试策略，如广泛采用自动化来进行测试

测试策略可描述要执行的测试级别，应给出制定每个测试级别的入口准则和出口准则的概要知道以及这些测试级别之间的关系

测试策略包含以下方面：

    1. 集成方法

    2. 测试规约说明技术

    3. 测试独立性（可根据不同测试级别而有所变化）

    4. 必需的和可选的应遵守的标准

    5. 测试环境

    6. 测试自动化

    7. 测试工具

    8. 软件工作产品和测试工作产品的重用性

    9. 确认测试（再测试）和回归测试

    10. 测试控制和测试汇报

    11. 测试度量和测试标准

    12. 缺陷管理

    13. 测试件的配置管理方法

    14. 角色和职责

2.4.3主测试计划

什么是主测试计划：

    描述如何在特定的项目中所有待进行的测试工作

    包括执行哪几个测试级别，以及这些级别之间的关系和测试级别于对应的开发活动之间的关系

    描述了较大项目或业务中的测试工作，所以它为项目计划或业务指南的补充

主测试计划写入的内容有哪些：

    1. 说明测试人员如何在这个项目中实施测试策略（即如何选择测试方法）

    2. 主测试计划应与测试方针和测试策略相一致

若不一致，则应解释为何出现偏差和例外，以及该偏差可能会存在的潜在影响

主测试计划包含的内容：

    1. 测试项和不测试项

    2. 测试的质量属性和不测试的质量属性

    3. 测试进度安排和预算（应根据项目预算或组织运营预算调整）

    4. 测试执行周期及其软件发布计划的关系

    5. 测试团队与其他人或部门之间的关系和交付内容

    6. 对于每个测试级别定义要测试项和不测试项

    7. 每个测试级别的明确的入口准则/延续（暂停/继续）准则和出口准则，以及这些测试级别之间的关系

    8. 测试项目的风险

    9. 测试工作的整体智力

    10. 执行每个测试级别的职责

    11. 每个测试级别的输入和输出

2.4.4级别测试计划

什么是级别测试计划：

    每个测试级别中所要进行的特定活动或测试类型

    包含了进度安排/任务和里程碑等在主测试计划中不一定包含的细节

    包含该级别的测试规格说明应遵守的标准和使用模板

 

对于敏捷项目，Sprint测试计划或迭代测试计划可替代级别测试计划

2.4.5项目风险管理

项目计划中一个重要部分就是处理风险

哪些风险可由测试经理成功缓解：

    1.测试环境和工具的就绪

    2.测试人员的可用性和能力

    3.缺乏测试工作的标准/规则和技术

管理项目风险的方法包括：

    1. 尽早准备测试件

    2. 预测试的测试环境

    3. 预测试产品的早期版本

    4. 使用更严格的测试入口准则

    5. 加强需求的可测性

    6. 参与项目早期工作产品的评审

    7. 参与对变更的管理

    8. 监督姓名的进展和质量

识别和分析项目风险后，管理风险有以下四种方案：

    1. 缓解风险，通过预防性措施降低风险的可能性/影响

    2. 制定应急计划/降低风险成为事实后的可能性

    3. 将风险转移其它方来处理

    4. 忽略或接受风险

2.4.6其他的测试工作产品

测试经理应确保缺陷报告/测试用例规格说明/测试日志等在下列活动中的一致性和质量：

    1. 建立并度量，以监督这些工作产品的质量，如被拒绝的缺陷报告比例

    2. 与测试分析师/技术测试分析师一起选择和（根据需要）定制工作产品的适当模板

    3. 与测试分析师/技术测试分析师一起建立工作产品的标准，如测试/日志和报告需要详细到什么程度

    4. 选择适当的参与人和干系人并使用适当的技术对工作产品进行评审

2.4学完之后需找出以下问题答案：

怎样依据测试方针和测试策略，建立主测试计划/级别测试计划和其他与这些文档相补

充和相一致的工作产品

依据项目风险，怎样选择适当的风险管理方案

测试策略如何影响测试活动

怎样生成-项目需要的工作产品的文档规范和模板

2.5测试估算

为什么要进行测试估算：

    为了得到特定业务或项目中各种活动的成本和完成日期的近似目标

最好的估算体现在哪些方面：

    1.代表有经验的实际工作这的集体智慧，并能得到相关参与人员的支持

    2.提供具体相近的，关于资金/资源/任务和相关人员的清单

    3.支出每个被估算活动的最可能的成本/工作量和周期

测试估算考虑的因素包括：

    1. 系统所要求的质量级别

    2. 待测系统的规模

    3. 以前测试项目的历史数据，也可包括寒夜数据或其他组织的基准数据

    4. 过程因素，包括测试策略/开发/维护生命周期和过程成熟度/成熟型，以及项目估算的准确度

    5. 物质因素，包括测试自动化和工具/测试环境/测试数据/开发环境/项目文档（如需求文档/设计文档等）以及可复用的工作产品

    6. 人员因素，包括经理和技术组长/高级行政管理人员的承诺/期望/项目团队的技能/经验和态度/项目团队的稳定性/团队成员之间的关系/测试和调试环境的支持/是否有数量的承包商和顾问/以及相关领域的知识

    7. 过程/技术和组织的复杂度/测试干系人的人数/子团队的组成和位置

    8. 项目启动/培训和定向需求

    9. 新工具/技术/定制硬件/大量测试件的熟悉和开发

    10. 非常详细的测试规约说明要求，特别是符合不熟悉的文档标准

    11. 难以确定的组件交付时间，特比我是对于集成测试和测试开发而言

    12. 敏感的测试数据

在测试估算中可单独或组合使用的技术有下列几种：

    1. 直觉/猜测/以往经验

    2. 工作分解结构

    3. 团队估算会议

    4. 公司标准和规范

    5. 测试占整个项目工作量的百分比或人员百年之（测试人员与开发人员的比例）

    6. 组织的历史和度量，包括基于度量的模型，该模型用于估算缺陷数/测试周期数/测试用例数/每个测试的平均工作量以及回归周期的数目

    7. 工业平均值和预估模型

最终的测试估算代表组织和项目目标在质量/进度安排/预算以及特性方面的最佳平衡

 

怎样进行测试估算

影响测试估算的因素有哪些

2.6定义和使用测试度量

为什么要进行测试度量：

    进行度量的工作才会得到有效的执行

测试度量可互粉到以下一种或多种类型中：

    1. 项目质量，对照己定的项目出口准则，如测试用例执行率/通过率和失败率，度量项目进展

    2. 产品度量，度量产品的某些特性，如测试程度和缺陷密度

    3. 过程度量，度量测试或开发过程的能力，如通过测试发现缺陷的百分比

    4. 人员度量，度量个人或小组的能力，如在给定的时间内测试用例的实施情况

使用测试度量可以带给我们什么优点：

    1.测试人员在汇报结果时保持一致

    2.可连贯的跟踪测试进展

测试经理在进行测试度量时需要考虑的因素：

    1. 度量的定义：

        (1) 定义一组有限的有用的度量

        (2) 依据项目/过程/产品的具体目标

        (3) 考虑平衡，因为单个的度量可能会舞蹈对状态或趋势的印象

        (4) 对于度量定义必须得到所有干系人的认可

    2. 度量的跟踪

        (1) 尽可能自动化报告和汇总，缩短采集和处理度量数据的时间

        (2) 测试经理分析度量数据和度量定义阶段约定的解度信息不同，汇总出现偏差的原因

    3. 度量的汇报

        1）帮助管理层迅速理解所获得的信息

        2）呈现对某段时间度量随时间推移的变化，利于查看趋势分析

    4. 度量的有效性

        1）测试经理需验证汇报的信息

        2）汇报工作前，测试经理必须就数据的准确度和可能传达的信息两方面对数据进行评审

从哪几个方面监督测试进展：

    1. 产品（质量）风险

    2. 缺陷

    3. 测试

    4. 覆盖率

    5. 信心

与产品风险相关的度量包括：

    1.完全覆盖的风险百分比（所有的测试都通过）

    2.部分覆盖的风险百分比（有些测试很多测试没有通过）

    3.还未完全测试的风险百分比（还未测试完成）

    4.按风险类别划分的覆盖风险百分比

    5.再初次质量风险分析后识别的风险百分比

与缺陷相关的度量包括：

    1.已发现缺陷总数对比已解决缺陷总数

    2.失效的平均时间间隔和失效的出现率

    3.按下列分类统计的缺陷数和百分比：

        1）特定的测试项或组件

        2）根本原因

        3）缺陷来源（如需求规格说明/新功能/回归等）

        4）测试发布

        5）引入/发现和移除缺陷阶段

        6）优先级/严重程度

        7）拒绝或重复的缺陷报告

    4.从报告缺陷到修复缺陷所花的时间趋势

    5.引入了新缺陷的缺陷修复数

和测试相关的度量包括：

    1. 已计划的/已实施/已运行/已通过/已失败/无法执行的/跳过不执行的测试总数

    2. 回归测试和确认测试的状态，包括趋势和未通过的回归测试总数以及未通过的确认测试总数

    3. 计划每日测试时长对比实际每日测试时长

    4. 测试环境的可用性（准备测试团队可用的测试环境占计划测试时长的百分比）

和测试覆盖率相关的度量包括：

    1. 需求和设计要素的覆盖率

    2. 风险覆盖率

    3. 环境/配置覆盖率

    4. 代码覆盖率

和监督测试计划和控制活动相关的度量包括：

    1.风险/需求和其他测试以及要素的覆盖率

    2.缺陷发现情况

    3.计划开发测试件和执行测试用例的时长对比实际时长

和监督测试分析活动相关的度量

    1. 识别的测试条件数

    2. 测试分析中发现的缺陷数（如通过使用测试依据识别风险或其他测试条件）

和监督设计活动相关的度量项包括：

    1. 测试用例覆盖的测试条件百分比

    2. 测试设计中发现的缺陷数（如对照测试依据开发测试）

和监督测试实施活动相关的度量包括：

    1. 测试环境配置的百分比

    2. 测试依据记录加载的百分比

    3. 测试用例自动化的百分比

和监督测试执行活动相关的度量包括

    1. 执行/通过/失败的测试占已计划的测试百分比

    2. 执行的测试用例覆盖测试条件的百分比

    3. 计划与实际的报告/解决的缺陷对比

    4. 计划与实际达到的覆盖率的对比

监督测试进展和测试完成活动的度量包括：

    1. 入口和出口准则的映射

    2. 计划的测试条件/测试用例/测试规约说明的数目和按测试是否通过分别统计的执行的测试条件/测试用例/测试规约说明的数目

    3. 总缺陷数，通常按严重程度/优先级/目前状态/受影响的子系统或其他分类统计

    4. 要求的/接受的/开展的/测试过的变更数

    5. 计划成本对比实际成本

    6. 计划工期对比实际工期

    7. 测试里程碑的计划日期对比实际日期

    8. 产品风险状态，通常按已缓解与未缓解的风险，主要的风险区域/测试分析后发现的风险等分类统计

    9. 由于阻塞时间或计划变更的到测试工作量/成本/时间损失的百分比

    10. 确认和回归测试状态

和监督测试结束活动相关的度量包括：

    1. 测试执行期间已执行的/通过的/失败的/无法执行的和跳过不执行的测试用例百分比

    2. 纳入可复用的测试用例库的测试用例百分比

    3. 自动化测试用例的百分比-----计划与实际自动化的测试用例百分比

    4. 并入回归测试的测试用例百分比

    5. 已解决/为解决的显著缺陷报告百分比

    6. 识别和归档的测试工作产品的百分比

度量数据的用途：

    1. 分析，找出可从测试结果中观察到的趋势和原因

    2. 汇报，将测试结果告知感兴趣的项目参与人和项目干系人

    3. 控制，改变整个测试/项目的进程和监督进程纠正的结果

什么时候需要进行测试控制：

    测试进展报告与测试计划出现偏差，则应进行测试控制

测试控制的目的是什么：

    为项目/测试重新定向到更可能取得成功的方向

当项目的控制工作受到测试结果影响时，需考虑以下方面：

    1. 修改质量风险分析/测试优先级/测试计划

    2. 增加资源/增加项目/测试工作量

    3. 推迟发布日期

    4. 放松或加强测试出口准则

    5. 改变项目范围（功能/非功能）

2.6定义和使用测试度量

什么是测试度量

典型的测试相关度量有什么不同

不同层面的测试进度监督有什么不同

怎样分析测试结果

怎样汇报测试结果

测试结果包括什么

遗留风险

缺陷状态

测试执行状态

测试覆盖状态

测试报告的作用

为项目项目人员提供信心

帮助相关人员做出发布决策

2.7测试的商业价值

测试为组织/项目/业务带来了定量和定性的价值：

    定量的价值包括：

                    1. 发现缺陷并再产品发布前预防或修复这些缺陷

                    2. 发现缺陷并了解产品再发布前依旧存在的缺陷

                    3. 通过运行测试减少风险并发布有关项目/过程和产品状态的信息

    定性的价值包括：

                    1. 提高产品质量的剩余/使发布更顺利和更可预测

                    2. 增加对产品的信心

                    3. 降低产品功能的失效甚至造成人员伤亡的可能性，避免承担法律责任

质量成本方法将项目和运行的成本分成与产品缺陷成本相关的四个类别：

    缺陷预防成本（培训开发人员，提高他们编写的代码的可维护性和安全性）

    缺陷检测成本（编写测试用例，配置测试环境/评审需求）

    内部失效成本（发布之前，测试/评审期间，修复发现的缺陷）

    外部失效成本（将有缺陷的软件发布给客户导致的支持成本）

2.7测试的商业价值

为什么说测试决定质量成本

测试的价值在哪

2.8分布式测试/外包测试以及内包测试

对于所有类型的测试，怎样定义沟通的范围：

    1. 处理问题升级等内容

    2. 交流要传达的信息类型和沟通的方式

    3. 清楚知道自己及他人的角色和职责，避免产生误解或不切实际的期待

对于分布式测试，不同的工作地点之间的测试分工必须明确/合理

 

 

2.8分布式/外包及内部测试

如何运用不同人员构建团队（是利用分布式团队/外包团队还是内包试团队）

2.9管理行业标准的使用

怎样有效的使用软件测试标准

1. 明确不同标准在测试所处的上下文中的用处

2. 参考已证实的最佳实践，并且提供组织测试过程的基础

3. 必须知道与标准符合情况相关的所有要求，确保维持适当的符合度