-------------
新增文件夹...
新增文件夹
(多个标签用逗号分隔)
TestDirector8.0 后台管理员使用手册.doc
TestDirector，它是Mercury Interactive公司推出的基于WEB的测试管理工具。TestDirector能够帮助组织和管理软件测试过程的每个阶段，包括测试需求定义、测试计划、测试执行和缺陷跟踪。TestDirector能消除组织机构间、地域间的障碍。它能让测试人员、开放人员或其它的IT人员通过一个中央数据仓库，在不同位置就能互通测试信息。使用测试管理工具的好处：支持并规范软
TestDirector，它是Mercury Interactive公司推出的基于WEB的测试管理工具。TestDirector能够帮助组织和管理软件测试过程的每个阶段，包括测试需求定义、测试计划、测试执行和缺陷跟踪。TestDirector能消除组织机构间、地域间的障碍。它能让测试人员、开放人员或其它的IT人员通过一个中央数据仓库，在不同位置就能互通测试信息。使用测试管理工具的好处：支持并规范软件测试全过程；将测试需求分析、测试用例设计、测试实施及缺陷管理无缝集成，保证了测试质量；实施开放式测试需求、测试用例和缺陷的管理；突破区域限制；较强的分析统计和报表功能，可实时分析软件质量状况、评估发布时间；流程驱动能力，支持邮件通知功能；无纸化管理，便于查询与统计； &&
加载中...!如果长时间没有加载，请刷新页面
下载本文档需要登录，并付出相应积分（）。购买积分->。
文件大小:1.88 MB
所需积分:& 10
TestDirector8.0 后台管理员使用手册.doc
文件大小:1.88 MB &&&&所需积分:& 10
本次下载将耗费您10个积分(说明：不需要积分就可以下载)重复下载将不扣积分！如果想购买积分，
相关资讯 　—　
相关讨论话题 　—　
浏览：2104次&& 下载：1次
上传时间： 17:40:10
同类热门文档
2948次浏览 &2次下载
5871次浏览 &9次下载
3350次浏览 &1次下载
2309次浏览 &5次下载
3250次浏览 &13次下载
3498次浏览 &7次下载
相关经验 -
& 1人评&77页
& 2人评&8页
& 1人评&151页
& 1人评&127页
& 0人评&0页
OPEN-OPEN, all rights reserved.软件测试管理_百度百科
特色百科用户权威合作手机百科
收藏 查看&软件测试管理
本书内容覆盖了测试估算、基于风险的测试、测试过程监控、测试外包、测试行业价值分析等测试管理过程中比较棘手的问题；分析了复杂的综合系统和安全关键系统的测试管理的难点；结合ISO 9126质量模型和IEEE 1044等国际标准，阐述了实际项目中缺陷管理的解决方案；结合软件测试领域的国际标准和能力模型（TMM、TPI、CTP和SETP等），阐述了测试过程和测试能力改进的方法，为测试团队的过程改进提供了指导性的方法。本书还为自动化测试工具、测试团队管理和测试人员考核等难题的解决提供了非常具有参考价值的实践。作&&&&者郑文强, 马均飞 编著出版时间2010年7月
定价：35.00元
开本：16开
页码：404页本书将软件测试管理知识和项目测试实践经验紧密结合，详细阐述了如何有效地开展软件测试过程中不同的测试管理活动。
本书适用于测试工程师、测试经理和质量改进人员，同时也可以作为国际软件测试认证委员会（ISTQB）高级测试管理模块的培训参考教材。可以识别、牢记和回忆术语或者概念的内容。
关键词：牢记、回忆、识别、认知。
可以识别“失效”的定义：“不能向最终用户或其他干系人提供服务”或“组件或者系统的实际运行情况与预期的发布、服务或结果背离”。应可以对给出的相关主题选择原因或解释，能够对事实（例如：对比术语）、测试概念、测试过程（解释任务顺序）等进行总结、区分、分类，并给出相应的实例。
关键词：总结、归类、比较、映射、对比、举例说明、解释、翻译、描述、推断、结论、分类。
请解释为什么需要尽早进行测试的设计：
在清除缺陷成本低的时候就发现它们。
尽早发现那些最重要的缺陷。
请解释集成测试和系统测试之间的异同：
相同：需测试不同的组件，可以对非功能性特性进行测试。
不同：集成测试关注于接口和交互，而系统测试则关注于从全系统角度进行测试，例如：端到端的过程处理。应可以选择正确的测试概念或者技术，并应用于给定场景中。K3通常适用于规程知识方面。在K3知识等级中并没有太多的创造性工作，例如，评估软件应用、为特定软件创建模型。针对给定的并且在本大纲中已经覆盖的模型，从该模型中按照规程步骤生成测试用例，就是类似于K3的工作。
关键词：实施、执行、运用、遵循规程、使用规程。
可以识别有效边界值和无效边界值。
使用通用的测试用例生成规程，从给定的状态转换图（和相关的测试用例集）中派生出测试用例，并覆盖所有的状态转换。应可以将与规程或技术有关的信息分成不同的组成部分，以便更好地理解，可以对现象和结论进行划分。典型的应用是为解决某些问题或任务而进行的文档、软件、工程环境的分析，并提出合适的建议，以解决实际问题和任务。
关键词：分析、区分、选择、结构、定位、特性、解构、评估、判定、监控、协调、创建、合成、产生、假定、计划、设计、构建、生产。
分析产品风险，进行风险预防，并进行纠正工作。
描述事件报告中的哪些部分是基于事实的，哪些内容是从测试结果中推导出来的。是艺术？是责任？是科学？是决策？
不同的人，对管理有不同的理解。尽管很多大师对管理进行了各种不同的定义，但是编者认为：无论管理，管理者都必须掌握行业内不同的技术和方法。这些技术和方法的正确应用是成为一名成功管理者的前提，这同样适用于软件测试的管理：
当你掌握了FMEA（失效模式和影响分析）的时候，对测试风险的管理将更加轻松。
当你了解了TPI、TMM等模型后，对软件测试过程的改进就不会那么头疼。
当你阅读完书中不同度量的案例之后，你就不会在面对一堆测试数据时毫无头绪。
当你了解了质量成本后，你将更加容易地与其他利益相关者进行测试方面的沟通。
当你洞悉了测试过程的所有阶段和活动后，你对软件测试管理将不再迷茫。
本书就是用来解决软件测试管理过程中的技术和方法问题的书籍。书中没有伟大的思想、没有崇高的人生境界，有的是经典实用的技术和方法，有的是编者近10年的软件测试管理实践的经验，以及技术、方法和经验相互结合，提炼得到的一些测试管理问题的解决方案。相信书中介绍的技术、方法和实践能够给读者带来对软件测试管理的全新认识。时光飞逝，转眼间，我们跨入软件测试领域已经有10年之久了。在这10年里，参与了很多项目的测试，有成功的，也有失败的，其中的酸甜苦辣，也随着编者的不同经验、角色和职责而不断发生变化。
回头看看这10年走过的软件测试之路，可以非常明显地感觉到国内整个软件测试行业的飞速发展：软件测试从编者刚入门时的“打杂”角色，已经变成软件工程领域的重要组成部分。软件测试行业水平低下、测试人员技能水平不高、测试人员待遇差等，是过去经常可以看到的观点和论调。但是时至今日，我们已经完全不赞成这样的观点了。中国的软件测试在过去的10年中取得了飞速的发展，无论是人才的储备、测试技术和测试管理能力，还是软件测试从业人员的地位，都已经获得了极大的提高，总体水平越来越接近于世界一流水平。甚至在过程实施、技术应用方面已经可以和世界水平保持同步。
但是，我们还是应该认识到我们和欧美成熟的软件测试行业之间某些方面的差距，例如，我们在行业发展趋势的把握和推动方面，仍然存在一定的差距。国外的软件测试行业活跃着很多从业超过20年的资深软件测试专家，他们在不断推动整个软件测试行业的进步。
相比之下，国内目前还没有形成这样的氛围。尽管工作年限越多，并不能完全代表能力越强，但是能够专注于一个行业超过20年的人，对行业的理解是深厚的，也是值得我们尊敬和学习的。因此，中国的软件测试行业还有很多路要走，我们也希望国内能有更多的人在软件测试行业投入终身的热情，共同推动软件测试行业的不断发展。尽管在工作后对软件测试有较大的兴趣，但是系统地学习软件测试管理是在2007年国内第一次举办的国际软件测试认证委员会（ISTQB）高级测试管理认证培训上。那次培训由国际著名软件测试专家Hans Schaefer（挪威软件测试认证委员会主席）主讲。在培训过程中，结识了很多软件测试领域的专家，同时也开始认识到软件测试管理的博大精深。软件测试管理不仅仅依赖于我们平时工作中积累的，同时也需要软件测试管理知识体系中提供的技术和方法，不断指引我们做正确的事。
就职于Alcatel的时候，马均飞和我是同一个项目的同事，大家对软件测试都有浓厚的兴趣，也经常在一起讨论一些软件测试的问题。2009年春天，有一次我们在聊天的时候，觉得在软件测试领域呆了近10年了，在测试管理方面都积累了一定的经验，大家是否应该写一本关于软件测试管理方面的书。通过出书的方式，将我们的经验与软件测试和方法紧密结合，提炼出在测试管理过程中应用的不同解决方案，希望能和更多的人分享这些经验。
确定了写作目标之后，我们就开始收集资料、准备素材、梳理框架结构，然后根据每个人的特长和经验进行分工，接着分头开始写作。由于我们两个以前在测试和测试管理方面交流比较多，开始动笔以后，基本上是各自埋头负责自己的问题。马均飞和我花了将近4个月的业余时间，在2009年10月完成了各自写作的任务。
接下来的工作就是对对方的内容进行Review（评审），由于在写作过程中并没有对中间的输出进行任何Review，因此，各自负责内容的Review工作进行了两轮。前期的Review是最辛苦的过程，不仅仅是精力方面付出很多，同时由于大家在某些知识点和经验方面无法说服对方，常常出现针对某个管理点争论几个小时的情况。
直到2009年12月，才完成第一个统稿版本，在这个统稿版本的基础上，我们每个人针对全书继续进行了两轮完整的Review，主要是修改格式、错别字以及其他一些低级的错误。到2010年2月，终于迎来了另一个里程碑：版本的定稿，到这个时候才算是完成了本书的创作，我们对整本书的质量还是比较满意的。
马均飞和我在整个写作和Review过程中合作非常默契，不仅在软件测试管理方面有了更深入的理解，同时在写作技巧、沟通和合作方面也有了新的理解，这也将推动我们在以后的合作中不断前行。本书共8章，以整个软件测试过程作为基础，讲解了测试过程中每个阶段相关的测试管理知识点。读者根据该书的测试管理知识点和对应的解决方案，可以完成其日常的测试管理工作，并能达到基本的测试管理的目标：测试质量、测试进度、测试成本和测试资源之间的平衡。
第1章　介绍了各种不同的软件开发模型，组件测试、集成测试、系统测试和验收测试四个测试级别的特点、目的和测试环境要求等；阐述了两个特定系统：综合系统和安全关键系统；通过具体的案例，说明测度对于测试监控和作出决定的重要指导作用。
第2章　以测试过程为基础，详细阐述了系统化测试过程的组成：测试计划和控制、测试分析和设计、测试实现和执行、评估出口准则和报告，以及测试结束活动；针对测试过程的每个阶段，分别阐述了各个阶段的主要测试活动、输入和输出，以及监控这些测试活动的度量指标等。
第3章　对测试管理过程中的多个方面进行了详细的阐述，包括：测试管理文档、测试估算、测试计划制定、测试过程监控、测试商业价值、测试外包、基于风险的测试、失效模式和影响分析和测试管理难题等。
第4章　介绍了基本的评审过程的主要组成阶段，以及其中的角色和职责；描述了不同评审类型之间的区别，并分析了如何在测试过程中选择合适的评审类型，以及如何才能保证评审获得预期结果。
第5章　介绍为了保证有效而及时地解决测试过程中发现的缺陷，组织如何建立一套完整的过程和规则对缺陷进行跟踪和管理；还介绍了如何通过缺陷的属性对测试过程和测试质量进行度量，以及测试过程中与缺陷相关的问题和解决方法。
第6章　讲解了和测试过程改进相关的标准，以及测试过程改进和优化的过程；通过具体的案例分别阐述了多个软件测试相关的能力模型（TMM、TPI、CTP、STEP和CMMI）在测试过程改进中的作用和步骤，以及注意事项。
第7章　描述了贯穿整个软件测试过程中可能应用的各种测试工具，并介绍了测试工具的成本和收益；通过案例详细讲述了测试工具和自动化策略，以及如何有效地引入测试工具和自动化。
第8章　阐述了测试人员应该具备的各种测试技能和软技能，通过案例描述了如何开展有效的个人技能评估，为招聘合适的测试人员提供合适的准则；同时描述了成功的测试团队应该具备的架构和特点，以及如何有效地对测试团队中的测试人员进行激励和沟通。本书融合了中兴、华为、Alcatel、Lucent、IBM等公司的实践管理经验，以一个贯穿始终的大型项目案例为背景，系统地介绍了软件测试管理知识体系。每个章节都设定了明确的学习目标，有利于读者的理解和学习。学习目标分为4个等级：K1（牢记）、K2（理解）、K3（应用）和K4（分析），详细的介绍见“本书学习目标等级”。书中采用统一的软件测试术语，并随每个章节出现的术语提供了解释。
本书在介绍自身经验的同时，还介绍了大量的业界最佳实践，融合了国内外软件测试领域专家的思想精华。本书直接参考的文献达上百篇，并通过脚注的形式提供给读者，为读者的扩展阅读提供方便。
如果读者希望全面了解软件测试管理知识，建议从头到尾按顺序阅读。如果暂时只对部分章节感兴趣，也可以直接跳到相关章节。本书系统地介绍了软件测试管理知识，读者一口气阅读完是比较困难的，其中涉及很多技术和方法，读者可以在用到的时候再回头来翻阅本书，相信书中的一些内容一定能够对读者的学习和工作起到帮助。本书的出版离不开在我们成长过程中给予我们帮助的同学、同事和朋友，尤其要感谢刘琴博士和周震漪老师给我们的帮助，他们的专业知识和敬业精神一直激励着我们不断进步和成长。本书的出版也离不开博士和老师的帮助，他们为此书的出版提出了宝贵的意见。
感谢电子工业出版社孙学瑛编辑和李利健编辑为本书提供的宝贵意见和大力支持，本书才得以在这么短的时间内与大家见面；同时感谢杨绣国编辑和其他博文视点同事，他们的专业素质和敬业精神令我们感动。
最后要感谢我的家人，这本书的写作占用了大量晚上和周末的时间，没有她们的支持和鼓励，本书将很难和大家见面。
由于编者水平和时间的限制，书中难免会出现错误，欢迎读者不吝指正。
郑文强第1章 软件测试基础 1
1.1 简介 1
1.2 软件开发生命周期中的测试 1
1.2.1 软件开发生命周期模型 2
1.2.1.1 顺序模型 2
1.2.1.2 增量迭代模型 6
1.2.1.3 模型中的测试 11
1.2.2 软件测试级别 12
1.2.2.1 组件测试 13
1.2.2.2 集成测试 16
1.2.2.3 系统测试 21
1.2.2.4 验收测试 22
1.2.2.5 维护测试 23
1.3 特定系统 24
1.3.1 综合系统 24
1.3.2 安全关键系统 28
1.4 度量和测度 32
1.4.1 测度的意义和要求 34
1.4.1.1 测度的意义 34
1.4.1.2 测度的要求 38
1.4.2 基本过程 40
1.4.2.1 确立和维持测度承诺 42
1.4.2.2 计划测度过程 42
1.4.2.3 实施测度过程 45
1.4.2.4 评估测度 46
1.4.3 度量数据应用 47
1.4.3.1 案例分析：测试用例设计进度 47
1.4.3.2 案例分析：测试用例执行进度 48
1.4.3.3 案例分析：测试的充分性 49
1.4.3.4 案例分析：产品发布准则 51
1.5 道德规范 53
1.6 小结 53
第2章 测试过程 55
2.1 简介 55
2.2 测试过程模型 56
2.3 测试计划和控制 57
2.3.1 主要活动 57
2.3.2 测试计划 62
2.3.3 测试执行进度 62
2.3.4 阶段度量指标 63
2.4 测试分析和设计 64
2.4.1 主要活动 64
2.4.2 阶段度量指标 65
2.5 测试实现和执行 66
2.5.1 主要活动 66
2.5.2 测试实现 68
2.5.2.1 测试规程规格说明 68
2.5.2.2 测试环境搭建 68
2.5.2.3 测试执行准备 72
2.5.3 测试执行 74
2.5.3.1 入口准则 74
2.5.3.2 测试结果比较 75
2.5.3.3 测试日志 76
2.5.3.4 确认测试和回归测试 76
2.5.4 阶段度量指标 77
2.6 评估出口准则和报告 78
2.6.1 主要活动 78
2.6.2 评估出口准则 78
2.6.3 测试报告 80
2.6.4 阶段度量指标 80
2.7 测试结束活动 81
2.7.1 主要活动 81
2.7.2 数据收集和分析 82
2.7.3 经验总结报告 83
2.8 小结 85
第3章 测试管理 86
3.1 简介 86
3.2 测试管理文档 89
3.2.1 测试方针 90
3.2.2 测试策略 91
3.2.3 主测试计划 92
3.2.3.1 介绍 93
3.2.3.2 详细内容 95
3.2.3.3 其他 96
3.2.4 级别测试计划 101
3.2.4.1 测试项和不测试项 102
3.2.4.2 测试的质量属性 103
3.2.4.3 测试时间进度 105
3.2.4.4 测试准则定义 105
3.2.4.5 测试风险 108
3.2.4.6 测试文档输出 109
3.2.4.7 角色和职责 109
3.2.5 级别测试设计规格说明 110
3.2.6 级别测试用例规格说明 111
3.2.7 级别测试规程规格说明 112
3.2.8 级别测试日志 113
3.2.9 异常报告 114
3.2.10 级别测试报告 116
3.2.11 主测试报告 117
3.3 测试计划裁减 118
3.4 测试估算 119
3.4.1 影响因素 122
3.4.2 基于百分比的方法 125
3.4.3 基于专家团队的方法 125
3.4.4 基于类似项目的方法 127
3.4.5 基于工作分解结构的方法 127
3.5 测试计划制定 128
3.5.1 尽早制定测试计划 128
3.5.2 测试计划的迭代 131
3.6 测试过程监控 133
3.6.1 风险 135
3.6.2 测试 138
3.6.2.1 案例分析：测试用例设计进度 138
3.6.2.2 案例分析：测试用例执行进度 139
3.6.3 覆盖率 141
3.6.3.1 案例分析：基于需求的测试覆盖率 141
3.6.3.2 案例分析：基于平台的测试覆盖率 142
3.6.4 缺陷 143
3.6.4.1 案例分析：缺陷发现阶段分布 143
3.6.4.2 案例分析：缺陷所属模块分布 144
3.6.4.3 案例分析：发现缺陷的测试类型分布 145
3.6.5 信心 146
3.6.5.1 案例分析：测试发现缺陷状态变化 146
3.6.5.2 案例分析：测试用例通过率 147
3.7 测试商业价值 148
3.7.1 预防成本 149
3.7.2 检测成本 149
3.7.3 内部失效成本 150
3.7.4 外部失效成本 150
3.8 分布式测试、外包测试和内包测试 155
3.8.1 分布式测试 155
3.8.2 外包测试 156
3.8.3 内包测试 157
3.8.4 风险 158
3.9 基于风险的测试 161
3.9.1 什么是基于风险的测试 161
3.9.1.1 风险的定义 161
3.9.1.2 产品风险和项目风险 162
3.9.1.3 基于风险的测试策略 163
3.9.2 风险管理过程 168
3.9.2.1 风险识别 169
3.9.2.2 风险分析 175
3.9.2.3 风险应对 177
3.9.2.4 ISO/IEC
3.9.3 风险管理实践 189
3.9.4 基于风险的测试方法 191
3.9.4.1 作用和优点 192
3.9.4.2 基于FMEA的测试 197
3.9.4.3 注意点和误区 206
3.10 失效模式和影响分析 207
3.10.1 什么是FMEA 208
3.10.2 应用领域 211
3.10.2.1 产品 212
3.10.2.2 过程 213
3.10.3 实现步骤 213
3.10.3.1 了解分析对象 215
3.10.3.2 识别失效模式 216
3.10.3.3 分析失效影响 217
3.10.3.4 确定严重程度 217
3.10.3.5 确定可能性 218
3.10.3.6 确定检测难度 218
3.10.3.7 分析潜在原因 219
3.10.3.8 计算风险优先级因子 219
3.10.3.9 确定处理优先级 219
3.10.3.10 采取应对措施 220
3.10.3.11 重新计算RPN 221
3.10.4 收益与成本 221
3.10.5 确定RPN 222
3.11 测试管理难题 223
3.11.1 探索性测试 223
3.11.1.1 什么是探索性测试 223
3.11.1.2 基于会话的测试管理 225
3.11.2 综合系统 226
3.11.3 安全关键系统 227
3.11.4 非功能性测试 228
3.12 小结 231
第4章 评审 233
4.1 简介 233
4.2 基本原则 236
4.3 选择合适的评审类型 238
4.3.1 审查 238
4.3.2 技术评审 240
4.3.3 走查 240
4.3.4 非正式评审 241
4.3.5 管理评审和审计 242
4.3.6 特殊工作产品的评审 243
4.3.7 正式评审的开展 244
4.4 有效的评审过程 244
4.4.1 计划阶段 245
4.4.2 预备会阶段 247
4.4.3 个人准备阶段 247
4.4.4 评审会议阶段 248
4.4.5 返工阶段 249
4.4.6 跟踪结果阶段 249
4.5 评审成功因素 250
4.6 小结 252
第5章 缺陷管理 253
5.1 简介 253
5.2 缺陷发现阶段 255
5.3 缺陷生命周期 255
5.3.1 识别 256
5.3.2 调查 257
5.3.3 改正 258
5.3.4 总结 259
5.3.5 案例 260
5.4 缺陷要素 264
5.5 缺陷度量 266
5.5.1 缺陷发现进度 266
5.5.2 缺陷修复进度 267
5.5.3 缺陷优先级 268
5.5.4 缺陷严重程度 270
5.6 缺陷沟通 271
5.7 小结 277
第6章 标准和测试过程改进 278
6.1 简介 278
6.2 相关标准 278
6.2.1 标准的来源和有效性 278
6.2.2 国际标准 280
6.2.2.1 ISO 280
6.2.2.2 IEEE 281
6.2.3 国家标准 282
6.2.4 特定领域标准 283
6.2.4.1 航空电子系统 284
6.2.4.2 航天工业 285
6.2.4.3 食品与药物管理局 285
6.2.5 其他标准 285
6.3 测试改进过程 285
6.3.1 改进的方法 286
6.3.2 改进的类型 286
6.4 测试过程优化 287
6.5 TMM 288
6.5.1 成熟度等级 288
6.5.2 内部结构 291
6.5.3 评估模型 293
6.6 TPI 295
6.6.1 模型结构 295
6.6.2 评估过程 300
6.7 CTP 301
6.7.1 模型结构 301
6.7.2 评估模型 305
6.8 STEP 306
6.8.1 组成 306
6.8.2 架构 307
6.8.3 活动时序 308
6.8.4 工作产品 309
6.8.5 角色和职责 309
6.9 CMMI 310
6.9.1 模型组成 310
6.9.1.1 表述方式 311
6.9.1.2 过程域 313
6.9.1.3 评估方法 314
6.9.2 验证和确认 314
6.10 小结 316
第7章 测试工具与自动化 318
7.1 简介 318
7.2 测试工具的概念 318
7.2.1 成本效益和风险 319
7.2.2 测试工具策略 322
7.2.3 测试工具集成 323
7.2.4 脚本和脚本语言 324
7.2.5 测试准则 328
7.2.6 测试工具部署 330
7.2.6.1 工具引入的成本效益 331
7.2.6.2 工具选择 332
7.2.6.3 工具引入 332
7.2.7 开源测试工具 333
7.2.8 测试工具开发 335
7.3 测试工具分类 337
7.3.1 测试管理工具 338
7.3.2 测试执行工具 339
7.3.3 调试工具 341
7.3.4 错误传播和注入工具 342
7.3.5 模拟器与仿真器 343
7.3.6 静态和动态分析工具 343
7.3.6.1 静态分析工具 343
7.3.6.2 动态分析工具 344
7.3.7 关键字驱动测试自动化 345
7.3.8 性能测试工具 345
7.3.9 Web测试工具 346
7.4 小结 347
第8章 个人技能和团队构成 349
8.1 简介 349
8.2 个人技能 349
8.2.1 角色和职责 350
8.2.2 软技能 353
8.2.3 个人技能评估 356
8.3 团队能力 359
8.3.1 团队角色分类 360
8.3.2 案例：测试团队分析 361
8.3.3 测试团队优化 364
8.4 测试团队独立性 366
8.4.1 测试组织结构 366
8.4.2 测试外包 369
8.5 激励 370
8.5.1 激励方式 371
8.5.2 量化管理 376
8.6 沟通 377
8.6.1 正确对待缺陷 378
8.6.2 开发和测试的合作 378
8.7 小结 379
参考文献 381
附录A IGMP需求列表 383
☆示例：未来作战系统 25
☆示例：企业级存储设备 28
☆示例：美国食品和药物管理局对软件开发活动的要求 30
☆示例：安全关键系统组件 31
☆示例：Practical Software and Systems Measurement 33
☆示例：测试过程监控：测试执行进度 34
☆示例：测试过程改进 35
☆示例：测试团队激励 37
☆示例：系统测试执行入口准则 75
☆示例：编写测试设计规格说明的测试任务 95
☆示例：智能宽带接入服务器iBAS R1.0主测试计划 97
☆示例：iBAS R1.0 IGMP系统测试计划中对测试项和不测试项定义 103
☆示例：iBAS R1.0 IGMP系统测试计划中定义的IGMP系统测试需要覆盖的质量属性 104
☆示例：iBAS R1.0 IGMP系统测试的进度甘特图（部分） 105
☆示例：iBAS R1.0 IGMP系统测试计划中定义的系统测试各种测试准则 107
☆示例：iBAS R1.0 IGMP系统测试风险列表（部分） 108
☆示例：iBAS R1.0 IGMP系统测试中需要输出的文档 109
☆示例：iBAS R1.0 IGMP系统测试中定义的角色和职责 110
☆示例：iBAS R1.0项目中对自动化测试的计划 130
☆示例：iBAS R1.0项目测试计划对于自动化测试内容的迭代 132
☆示例：内部失效成本 150
☆示例：应用质量成本分析测试的投资回报 153
☆示例：风险应对和管理在iBAS R1.0项目IGMP功能中的应用 165
☆示例：风险问卷调查法 170
☆示例：风险模板 171
☆示例：失效模式分析的模拟场景 172
☆示例：下面是IGMP测试过程中，由于在早期没有有效地管理和监控“采购IGMP测试仪表”风险，而对后续测试执行导致的后果 190
☆示例：探索性测试 224
☆示例：“IGMP系统需求规格说明”评审邀请信 246
☆示例：IGMP系统需求规格说明审查收集的数据 249
☆示例：iBAS R1.0中针对IGMP功能提交的一个缺陷报告 265
☆示例：缺陷发现进度度量 266
☆示例：缺陷修复进度度量 267
☆示例：缺陷优先级度量 268
☆示例：缺陷严重程度度量 270
☆示例：中华人民共和国标准法的部分描述 279
☆示例：中华人民共和国标准法部分内容 280
☆示例：中国标准分类 282
☆示例：DO-178B中的软件生命周期数据 284
☆示例：TMM集成级中监控测试过程的子目标 291
☆示例：部分测试监控过程的ATRs 292
☆示例：验证活动的方法 315
☆示例：确认活动的对象和方法 316
☆示例：iBAS R1.0项目的自动化测试用例挑选标准 321
☆示例：TOOL COMMAND LANGUAGE 325
☆示例：针对“创建文件”的检查点 327
☆示例：开源测试工具 333
☆示例：iBAS项目自动化测试工具开发 335
☆示例：测试管理工具 339
☆示例：性能测试工具 346
☆示例：Selenium 347
☆示例：有效授权 372
☆示例：有效沟通 373
☆示例：提供学习和培训的机会 374
☆示例：尊重和认可 375
☆示例：物质奖励 375
新手上路我有疑问投诉建议参考资料 查看}