测试目标：
对于给定的任何项目，其测试目标可以包括：
⚫ 评估工作产品，例如需求、用户故事、设计和代码
⚫ 验证是否实现了所有指定的需求
⚫ 确认测试对象是否完成，并按照用户和其他干系人期望那样工作
⚫ 建立对被测对象质量级别的信心
⚫ 预防缺陷
⚫ 发现失效和缺陷
⚫ 为干系人提供足够的信息以允许他们做出明智的决策，特别是关于测试对象的质量级别
⚫ 降低软件质量不足所带来的风险（例如运行软件时，发现了之前未发现的失效）
⚫ 遵守合同、法律或法规要求或标准，和/或验证测试对象是否符合这些要求或标准
根据被测组件或系统的环境、测试级别和软件开发生命周期模型的不同，测试目标会有所变化。不同包括：
⚫ 在组件测试时，尽可能多的发现失效，以便尽早识别和修复潜在的缺陷可能是其一个目标。而另一个目标可能是增加组件测试时的代码覆盖率。
⚫ 在验收测试时，确认系统能够按照预期工作并且满足用户需求可能是其一个目标。而另一个测试目标可能是为干系人提供关于在给定时间发布系统的风险信息。
测试与调试：执行测试可以发现由于软件缺陷引起的失效。而调试是发现、分析和修复这些缺陷的开发活动。
测试过程：
主要由以下主要的活动组所组成：
⚫ 计划和监督
⚫ 分析和设计
⚫ 实施和执行
⚫ 评估出口准则和报告
⚫ 测试结束
测试活动：
⚫ 计划和监控
⚫ 分析
⚫ 设计
⚫ 实施
⚫ 执行
⚫ 评估出口准则和报告
⚫ 测试结束活动
这些活动可以是顺序执行，其中有些活动也可以并行的执行。例如：设计可以和实施并行（例如：探索性测试）。测试分析主要关注测试和测试用例的正确性，以及设计并执行这些测试用例。虽然理解测试过程中的其它步骤也很重要，但是测试分析的主要工作通常集中在测试项目的分析、设计、实施和执行活动。
每个活动组都是由多个活动构成或由多个单独的任务组成，这些任务可能因项目或发布而不同。
此外，虽然这些活动组中的许多活动在逻辑上看起来是顺序的，但它们通常是迭代实现的。例如，敏捷开发涉及到软件设计、构建和测试的小迭代，这些迭代都是在持续计划的支持下连续进行的。所以，在敏捷开发的方法中，测试活动也是在迭代的、持续的基础上进行。即使在顺序开发中，活动的阶梯式逻辑顺序也会涉及重叠、组合、并发或省略，所以必须根据系统和项目的周境因素裁剪这些主要活动。
测试分析根据可测量的覆盖标准来确定“测试什么”。
测试设计是“如何测试”。
功能指的是系统应该做“什么”。
测试级别：组件测试，集成测试，系统测试，验收测试。
测试类型：
--功能测试（考虑软件的行为；可以通过功能覆盖来衡量。功能覆盖是指通过测试执行了某种类型的功能元素的范围，并以所覆盖元素类型的百分比形式来表示。），
--非功能测试（是测试系统运行的“表现如何”；可以通过非功能覆盖来衡量。非功能覆盖是指通过测试执行某种类型的非功能元素所达到的程度，并且以所覆盖的元素类。），
--白盒测试（可以通过结构覆盖来测量。结构覆盖是指某种类型的结构元素在测试中被使用的程度，并以所覆盖的元素类型的百分比形式来表示；某种类型的结构元素是执行的语句、分支、判定条件、条件组合路径，架构、详细设计、内部结构或测试对象代码等），
--与变更相关测试（确认测试的目的是确认是否已成功修复原来的缺陷。回归测试包括运行测试来检测这些意外的副作用。）
测试技术分为黑盒、白盒或基于经验。
--黑盒测试技术
----等价类划分：等价分区有针对有效值或无效值的。。覆盖度量为由至少一个值测试的等价类的数量除以所识别的等价类的总数，通常表示为百分比。等价类划分适用于所有测试级别。
----边界值分析：边界值分析是等价类划分的扩展，但仅适用于等价类是有序的、由数字或顺序数据组成。等价类的最小和最大值（或第一和最后的值）是其边界值。边界值分析可以应用于所有的测试级别。这个技术通常用来测试需要调用数字范围的需求（包括日期和时间）。对分区的边界值覆盖度量是测试的边界值数量除以识别的边界测试值总数，通常用百分比表示。
----判定表/决策表测试：判定表是记录系统必须实现的复杂业务规则的一种很好的方法。当建立判定表时，测试员识别系统的条件（通常是输入）和导致的动作（通常是输出）。判定表的行，通常是条件在顶部，而动作在底部。判定表的每一列对应了一个判定规则，该规则定义了各种条件的一个唯一组合，其表示与该规则相关的动作的执行。条件值和动作通常表示为布尔值（“真”或“假”）或离散值（例如：红、绿、蓝），但也可以是数字或数字范围。这些不同类型的条件和动作可能一起出现在同一判定表中。
完全的判定表有足够多的列来覆盖条件的每个组合。通过删除包含不可能的条件组合的列，包含可能但不可行的条件组合的列，以及包含不影响结果的测试条件组合的列，可以精简化判定表。
判定表测试的最小覆盖标准通常是，至少对判定表中每个判定规则有一个测试用例。这通常涉及覆盖所有条件的组合。覆盖度量是至少被一个测试用例测试过的判定规则的数量，除以判定规则总数，通常以百分比表示。
----状态转换测试：根据组件或系统当前条件或先前历史（例如自从系统初始化后发生过的事件），组件或系统可能会产生不同的响应。先前历史可以用状态的概念来总结。状态转换图不但显示可能的软件状态，同时包含了软件如何入口、出口，以及状态之间的转换的。转换是通过事件触发的（例如，用户输入一个值到输入域内）。事件导致转换。如果相同的事件从相同状态能导致两个或多个不同转换，可以通过守卫条件进行事件的区分。状态改变可能导致软件采取动作（例如，输出计算或错误信息）。
状态转换表不但可显示状态之间所有有效转换和潜在的无效转换，而且可表示有效转换的事件、守卫条件和导致的动作。状态转换图通常仅仅显示有效转换，而不包括无效转换。
设计测试可以用来覆盖典型的状态序列、执行所有状态、执行每个转换、执行转换的特定序列，或测试无效的转换。
状态转换测试可以用于基于菜单的应用，其广泛使用在嵌入式软件行业。此技术也适用于有特定状态的业务场景的建模，或测试屏幕导航。状态的定义是抽象的，即可能表示几行代码或整个业务流程。
覆盖度量通常是已识别状态或已测试转换的数量，除以测试对象的已识别状态或转换的总数，一般以百分比表示。
----用例测试：测试可以从用例中推导出来，用例是设计与软件项交互的一种特殊方式，包含了用例所代表的软件功能的需求。用例与参与者（用户、外部硬件或其他组件或系统）和主体（用例所应用的组件或系统）相关联。
每个用例规定了一个主体能与一个或多个参与者合作开展的一些行为（UML2.5.12017）。用例除了能通过交互和活动进行描述外，还可以在需要时描述前置条件、后置条件和自然语言。参与者和主体之间的交互可能导致主体的状态改变。交互可能以工作流、活动图，或业务流程模型的图示方式表示。
用例包含了其基本行为的可能变化，包括期望行为和错误处理（系统对程序、应用和通讯错误的反应和恢复，例如，导致一个错误信息）。设计测试来执行已定义的行为（基本的、异常的或替代的和错误处理）。覆盖度量是已测试的用例行为，除以测试用例行为的总数，通常以百分比表示。
--白盒测试技术
----语句测试和覆盖：语句测试执行代码中可执行语句。覆盖度量是被测试执行的语句数，除以测试对象中可执行语句总数，通常以百分比表示。
----判定测试和覆盖：判定测试执行代码中的判定，以及测试基于判定结果的可执行的代码。为此，测试用例跟随发生在判定点的控制流（例如，针对IF语句,一个对真（true）结果和一个对假（false）结果；针对CASE语句，测试用例将要求对所有可能结果，包括缺省（default）结果进行覆盖）。
覆盖度量是被测试执行的判定结果数，除以测试对象中判定结果的总数，通常以百分比表示。
----语句和判定测试的价值：当实现100％语句覆盖时，它确保代码中的所有可执行语句至少已被测试过一次，但不能确保所有判定逻辑都已被测试过。在本大纲中讨论的两种白盒技术中，语句测试可能提供的覆盖低于判定测试。
当达到100％的判定覆盖时，它会执行所有判定结果，包括测试取值为真（true）的结果和取值为假（false）的结果，即使没有清晰的假（false）语句（例如，IF语句的代码中没有else）。语句覆盖有助于发现未被其他测试执行的代码发现的缺陷。判定覆盖有助于发现代码中其他测试没有同时采用真和假结果的缺陷。
实现100％的判定覆盖可保证100％的语句覆盖（但反之不成立）。
--基于经验的测试技术
----错误推测：
错误推测法是一种基于测试员的知识来预期错误、缺陷和失效发生的技术，知识包括：
⚫ 应用在过去是如何工作的
⚫ 开发人员常犯的错误类型
⚫ 在其它应用中发生的失效
错误推测技术的一个系统化方法是创建一个可能的错误、缺陷和失效的列表，并设计测试以发现失效以及导致它们出现的缺陷。根据经验、缺陷和失效数据，或根据软件失效的通用知识，构建错误、缺陷和失效列表。
----探索性测试：
在探索性测试中，在测试执行期间动态地设计、执行、记录、和评估非正式的（非预定义的）测试。测试结果常用来进一步了解组件或系统，并对可能需要进一步测试的区域生成测试。
探索性测试有时通过基于会话的测试来构造活动。在基于会话的测试中，探索性测试在定义的时间盒内进行，测试员使用包含测试目标的测试章程来指导测试。测试员可能使用测试会话表格来记录随后步骤和发现。
探索性测试在说明较少或不充分，或测试的时间压力大的情况下是最有帮助的。探索性测试作为对其他更正式的测试技术的补充也是有用的。
探索性测试能与其它黑盒、白盒和基于经验的技术综合使用。
----基于检查表的测试：在基于检查表的测试中，测试员设计、实施和执行测试来覆盖检查表中发现的测试条件。作为分析的一部分，测试员可以创建新的检查表或扩充现有的检查表，但测试员也可能使用没有修改的现有检查表。根据什么是对用户重要的经验和知识，或对软件为什么和如何失败的理解，创建检查表。
检查表可产生用于支持各种测试类型，包括功能和非功能测试。在没有详细测试用例的情况下，基于检查表的测试能提供指南和一定程度的一致性。由于它们是概要性的列表，因此在实际测试中会出现一些变化，导致潜在的高覆盖，但是低重复性。
测试管理：测试组织，测试计划和估算，测试监督与控制，配置管理，风险和测试，缺陷管理。
测试经理的任务：全面负责测试过程和成功领导测试活动。测试管理角色可以由专业测试经理、或项目经理、开发经理或质量保证经理开展。在较大的项目或组织中，多个测试团队可以向测试经理、测试教练或测试协调员报告，每个团队由测试组长或主要测试员领导。
⚫ 制定或评审组织的测试方针和测试策略
⚫ 通过考虑背景（上下文）并理解测试目标和风险来规划测试活动。包括选择测试方法、估算测试的时间、工作量和成本、获取资源、定义测试级别和测试周期，以及规划缺陷管理⚫ 编写和更新测试计划
⚫ 与项目经理、产品所有者和其他人协调测试计划
⚫ 与其他项目活动（如集成计划）共享测试视角
⚫ 启动测试分析、设计、实施和执行、监督测试进度和结果，并检查出口准则的状态（或完成的定义）
⚫ 根据收集的信息准备并提交测试进度报告和测试总结报告
⚫ 根据测试结果和进度调整计划（有时记录在测试进度报告中，和/或在项目中已完成的其他测试的测试总结报告中）并采取所需的行动以进行测试控制
⚫ 支持建立缺陷管理系统和对测试件的充分配置管理
⚫ 引入适当的度量来测量测试进度并评估测试和产品的质量
⚫ 支持选择和实施支持测试过程的工具，包括推荐工具选择的预算（以及可能的购买和/或支持），为试点项目分配时间和工作量，以及为使用该工具提供持续支持
⚫ 决定测试环境的实施
⚫ 在组织内促进和宣传测试员、测试团队和测试专业人员
⚫ 培养测试员的技能和职业（例如，通过培训计划、绩效评估、指导等）
测试员的典型任务：
⚫ 评审并为测试计划做出贡献
⚫ 分析、评审和评估需求、用户故事和验收准则、说明和模型的可测试性（即测试依据）
⚫ 识别并记录测试条件，并捕获测试用例、测试条件和测试依据之间的可追溯性
⚫ 设计、建立和验证测试环境，通常与系统管理和网络管理协调
⚫ 设计和实施测试用例和测试规程
⚫ 准备并获取测试数据
⚫ 创建详细的测试执行进度表
⚫ 执行测试、评估结果并记录与预期结果之间的偏差
⚫ 使用适当的工具来促进测试过程
⚫ 需要时，自动化测试（可由开发人员或测试自动化专家支持）
⚫ 评估非功能特性，例如性能效率、可靠性、易用性、安全性、兼容性和可移植性
⚫ 评审他人开发的测试。
测试计划：
概述了开发和维护项目的测试活动。制定计划受组织的测试方针和测试策略、使用的开发生命周期和方法、测试范围、目标、风险、约束、关键性、可测试性和资源可用性的影响。
⚫ 确定测试的范围、目标和风险
⚫ 定义整体测试方法
⚫ 将测试活动集成并协调到软件生命周期活动中
⚫ 确定要测试的内容，开展各种测试活动所需的人员和其他资源，以及如何开展测试活动
⚫ 安排测试分析、设计、实施、执行和评估活动的进度表，可以在特定日期（例如，在顺序开发中）或在每次迭代周境中（例如，在迭代开发中）
⚫ 选择测试监督和控制的度量
⚫ 为测试活动编制预算
⚫ 确定测试文档的详细程度和结构（例如，通过提供模板或示例文档）
测试计划的内容各不相同，可以超出上述主题。测试计划的样本可以在ISO标准（ISO/IE/IEEE 29119-3）中找到。
测试策略：测试策略提供测试过程的一般描述，通常在产品或组织级别。常见的测试策略类型包括：
⚫ 分析型：此类测试策略基于对某些因素（例如，需求或风险）的分析。基于风险的测试是分析型方法的一个示例，其中根据风险级别设计测试并确定优先级。
⚫ 基于模型：在这种类型的测试策略中，测试是基于产品的某些必需方面的某些模型设计的，例如功能、业务流程、内部结构、或非功能特性（例如，可靠性）。此类模型的示例包括业务过程模型、状态模型和可靠性增长模型。
⚫ 方法型：此类测试策略依赖于系统地使用一些预定义的测试集或测试条件，例如常见或可能类型的缺陷分类、重要质量特性列表或公司范围内的用于移动应用或网页的外观和感受标准。
⚫ 符合流程的（或符合标准）：此类测试策略包括基于外部规则和标准的分析、设计和实施测试，例如行业特定标准、过程文档、严格标识和使用的测试依据，或通过组织强加的任何过程或标准。
⚫ 指导型（或咨询）：此类测试策略主要由干系人、业务领域专家或技术专家的建议、指导或指示驱动，他们可能在测试团队之外或在组织外部。
⚫ 回归规避型：这种类型的测试策略的动机是希望避免现有功能的回归。此测试策略包括重用现有测试件（尤其是测试用例和测试数据）、回归测试的广泛自动化以及标准测试套件。
⚫ 反应型：在这种类型的测试策略中，测试被动应对被测组件或系统以及测试执行期间发生的事件，而不是预先计划（如前面的策略所示）。测试经过设计和实施，并可能立即执行以响应从先前测试结果中获得的知识。探索性测试是反应型策略中常用的技术。
测试方法是选择测试技术、测试级别和测试类型，以及定义入口准则和出口准则（或分别是就绪的定义和完成的定义）的起点。
典型的入口准则：
⚫ 可测试的需求、用户故事、和/或模型的可用性（例如，遵循基于模型的测试策略时）
⚫ 满足任何先前测试级别出口准则相关的测试项的可用性
⚫ 测试环境的可用性
⚫ 必要的测试工具的可用性
⚫ 测试数据和其他必要资源的可用性
典型的出口准则：
⚫ 已执行计划的测试
⚫ 已实现规定的覆盖级别（例如，需求、用户故事、验收准则、风险、代码）
⚫ 未解决的缺陷数量在商定的限度内
⚫ 估计的遗留缺陷数量足够低
⚫ 可靠性、性能效率、易用性、安全性和其他相关质量特性的评估级别已足够
即使没有满足出口准则，由于预算已耗尽、预定的时间已到、和/或将产品推向市场的压力，测试活动被缩减是很常见的。如果项目干系人和业务所有者已经评审并接受了无须进一步测试的情况下上线的风险，那么在这种情况下结束测试是可以接受的。
测试执行进度表：一旦生成了各种测试用例和测试规程（某些测试规程可能会自动化）并组装到测试套件中，测试套件就可以安排在测试执行进度表中，该进度表定义了它们的运行顺序。测试执行进度表应考虑诸如优先级、依赖性、确认测试、回归测试和执行测试的最有效顺序等因素。
理想情况下，测试用例将基于其优先级次序运行，通常是首先执行具有最高优先级的测试用例。但是，如果测试用例具有依赖性或者测试的功能具有依赖性，则此实践可能不适用。如果具有较高优先级的测试用例依赖于具有较低优先级的测试用例，则必须首先执行此优先级较低的测试用例。同样，如果跨测试用例存在依赖关系，则无论其相对优先级如何，都必须对它们进行适当的排序。基于对变化的快速反馈的重要性，确认和回归测试也必须考虑优先级，但这里同样适用依赖性。
在一些情况下，测试的各种顺序是可能的，伴随这些顺序有不同的效率水平。在这种情况下，必须在测试执行效率与遵守优先级之间进行权衡。
影响测试工作量的因素：测试工作量估算涉及预测为满足特定项目、发布或迭代的测试目标所需的测试相关工作量。影响测试工作量的因素可能包括产品的特点、开发过程的特点、人员的特点、和测试结果，如下所示。
--产品的特点
⚫ 与产品相关的风险
⚫ 测试依据的质量
⚫ 产品规模
⚫ 产品领域的复杂性
⚫ 质量特性要求（例如，安全性、可靠性）
⚫ 所需的测试文档详细程度
⚫ 对法律和法规的合规性要求
--开发过程的特点
⚫ 组织的稳定性和成熟度
⚫ 所使用的开发模型
⚫ 测试方法
⚫ 使用的工具
⚫ 测试过程
⚫ 时间压力
--人的特点
⚫ 参与人员的技能和经验，尤其是类似的项目和产品（例如，领域知识）
⚫ 团队凝聚力和领导力
--测试结果
⚫ 发现缺陷的数量和严重程度
⚫ 所需要的返工量
测试估算技术：有许多估算技术用于确定充分测试所需的工作量。两种最常用的技术是
⚫ 基于度量的技术：根据历史类似项目的度量，或基于典型值来估算测试工作量。例如在敏捷开发中，燃尽图是基于度量的方法的示例，其中显示了捕获和报告的工作量，它们提供了团队的速度以确定团队在下一次迭代中可以完成的工作量；而计划扑克是基于专家的方法的一个例子，因为团队成员正在根据他们的经验估算交付一个特性的工作量。
⚫ 基于专家的技术：根据测试任务所有者或专家的经验来估算测试工作量。例如在顺序项目中，缺陷移除模型是基于度量的方法的示例，其中捕获和报告了缺陷的数量和移除它们所需的时间，然后为未来估算类似性质的项目提供了基础；而宽带德尔菲估算技术是基于专家的方法的一个例子，其中专家组根据他们的经验提供估算。
测试监督与控制：测试监督与控制的目的是收集信息并提供有关测试活动的反馈和可见性。
测试控制措施的示例包括：
⚫ 当已识别的风险发生时（例如，软件交付延迟），重新确定测试优先级
⚫ 由于测试环境或其他资源的可用性或不可用性而更改测试进度表
⚫ 由于返工，重新评估测试项是否符合入口或出口准则
测试中使用的度量：
在测试活动期间和结束时收集度量，用以评估：
⚫ 根据计划的时间表和预算取得的进展
⚫ 测试对象的当前质量
⚫ 测试方法的充分性
⚫ 与目标相关的测试活动的有效性
常见的测试度量包括：
⚫ 在测试用例准备中，计划工作已完成的百分比（或计划测试用例已实施的百分比）
⚫ 在测试环境准备中，计划工作已完成的百分比
⚫ 测试用例执行（例如，测试用例运行/未运行、测试用例通过/失败，和/或测试条件通过/失败的数量）
⚫ 缺陷信息（例如：缺陷密度、发现和修复的缺陷、失效率和确认测试结果）
⚫ 需求、用户故事、验收准则、风险，或代码的测试覆盖
⚫ 任务完成、资源分配和使用和工作量
⚫ 测试成本，包括与查找下一个缺陷的好处相比的成本，或与运行下一个测试的好处相比的成本
测试报告的目的、内容和受众：测试报告的目的是在测试活动（例如，测试级别）期间和结束时，总结和传达测试活动信息。在测试活动期间准备的测试报告可能被称为测试进度报告，而在测试活动结束时准备的测试报告可能被称为测试总结报告。
--在测试监督和控制期间，测试经理定期为干系人发布测试进度报告。除了测试进度报告和测试总结报告的常用内容之外，典型的测试进度报告还可能包括：
⚫ 对照测试计划，测试活动和进度的状态
⚫ 妨碍进度的因素
⚫ 计划在下一个报告周期进行的测试
⚫ 测试对象的质量
当达到出口准则时，测试经理会发布测试总结报告。此报告根据最新的测试进度报告和任何其他相关信息提供所开展测试的总结。
--典型的测试进度报告和测试总结报告可能包括：
⚫ 所开展测试的总结
⚫ 测试周期内发生的情况的信息
⚫ 计划的偏离，包括测试活动的进度、持续时间，或工作量偏差
⚫ 对照出口准则或完成的定义，测试和产品质量的状态
⚫ 已阻碍或继续阻碍进度的因素
⚫ 缺陷、测试用例、测试覆盖、活动进度和资源消耗的度
⚫ 剩余风险
⚫ 生成的可重用的测试工作产品
ISO 标准（ISO/IEC/IEEE 29119-3）涉及两种类型的测试报告，测试进度报告和测试完成报告（在本大纲中称为测试总结报告），并包含每种类型的结构和示例。
配置管理：目的是在整个项目和产品生命周期期间，建立和维护组件或系统、测试件及其他们之间相互关系的完整性。
风险的定义：风险涉及未来可能发生负面后果的事件。风险级别取决于事件发生的可能性以及事件的影响（伤害）。
产品和项目的风险：产品风险涉及工作产品（例如，说明、组件、系统或测试）可能无法满足其用户和/或干系人的合法需求的可能性。当产品风险与产品的特定质量特性（例如，功能性、可靠性、性能效率、易用性、安全性、兼容性、维护性和可移植性）相关联时，产品风险也称为质量风险。
--产品风险的例子包括：
⚫ 软件可能无法根据说明执行其预期功能
⚫ 软件可能无法根据用户、客户、和/或利益相关方的需要执行其预期功能
⚫ 系统架构可能无法充分支持某些非功能性需求
⚫ 在某些情况下，可能会不正确地执行特定计算
⚫ 循环控制结构可能不正确地编码
⚫ 对于高性能事务处理系统，响应时间可能不足
⚫ 用户体验（UX）反馈可能无法满足产品预期
--项目风险涉及的情况如果发生，可能会对项目实现目标的能力产生负面影响。项目风险的例子包括：
⚫ 项目事件：
◼ 延迟可能会出现在交付、任务完成，或满足出口准则或完成的定义时
◼ 不精确的估算、将资金重新分配给更高优先级的项目，或整个组织的一般成本削减可能导致资金不足
◼ 后期更改可能会导致大量的返工
⚫ 组织事件：
◼ 没有足够的技能、培训和员工
◼ 人员事件可能会导致冲突和问题
◼ 由于业务优先级冲突，用户、业务人员或主题专家可能无法支持
⚫ 政治事件：
◼ 测试员可能没有充分传达他们的需要和/或测试结果
◼ 开发人员和/或测试员可能无法跟进测试和评审中发现的信息（例如，没有改进开发和测试实践）
◼ 对测试可能存在不正确的态度或期望（例如，不了解测试期间发现缺陷的价值）
⚫ 技术事件：
◼ 可能没有很好地定义需求
◼ 考虑到现有的限制，可能无法满足需求
◼ 测试环境可能未按时准备就绪
◼ 数据转换、迁移规划、和它们的工具支持可能延迟
◼ 开发过程中的弱点可能会影响项目工作产品的一致性或质量，例如设计、编程、配置、测试数据、和测试用例
◼ 差的缺陷管理和类似问题可能导致累积缺陷和其他技术债务
⚫ 供应商事件：
◼ 第三方可能无法提供必要的产品或服务、或破产
◼ 合同事件可能会给项目带来问题
项目风险可能会影响开发活动和测试活动。在某些情况下，项目经理负责处理所有项目风险，但测试经理对测试相关的项目风险负责并不罕见。
产品风险分析的结果用于：
⚫ 决定要使用的测试技术
⚫ 决定要开展的测试的特定级别和类型（例如，安全性测试、可达性测试）
⚫ 决定测试的范围
⚫ 确定测试优先级，以尽早发现关键缺陷
⚫ 决定是否可以采用除测试之外的任何活动来降低风险（例如，为缺乏经验的设计员提供培训）
风险测试：
为确保尽可能减少产品失效的可能性，风险管理活动提供了一种严格的方法：
⚫ 分析（并定期重新评估）可能出现的错误（风险）
⚫ 决定哪些风险的处理是很重要
⚫ 实施行动以缓解这些风险
⚫ 制定应急计划去处理可能成为实际事件的风险
此外，测试可能识别新风险，帮助确定应该缓解哪些风险，并降低风险的不确定性。
测试自动化的收益和风险：
--使用工具支持测试执行的潜在收益包括：
⚫ 减少重复性的手工工作来节省时间（比如，执行回归测试、环境设置/卸载、重新输入相同测试数据，和代码规则检查）
⚫ 更好的一致性和可重复性（比如，测试数据按照一致的方式产生，用工具按照相同的顺序和频率执行测试，以及从需求一致地获取测试
⚫ 更客观的评估（比如，静态测量、覆盖）
⚫ 更容易得到测试的相关信息（比如，关于测试进展、缺陷发生率和性能的统计和图表）
--使用工具支持测试的潜在风险：
⚫ 对工具抱有不切实际的期望（包括功能性和易用性）
⚫ 低估首次引入工具所需的时间、成本和工作量（包括培训和额外的专业知识）
⚫ 低估从工具中获得较大和持续收益所需付出的时间和工作量（包括测试过程所需的变更和使用工具方法的持续改进）
⚫ 低估对工具生成的测试资产进行维护所需的工作量
⚫ 对工具过分依赖（替代测试设计或执行，或者对一些更适合手工测试的方面却使用自动测试工具）
⚫ 忽视对测试资产的版本控制
⚫ 忽视多个重要工具之间的关联和互操作性问题，例如：需求管理工具、配置管理工具、缺陷管理工具，和其他从不同供应商获得的工具
⚫ 工具供应商破产、停止维护工具或将工具卖给其他供应商的风险
⚫ 供应商对工具的支持、升级和缺陷修复支持不力
⚫ 开源工具项目中止的风险
⚫ 工具可能不支持新平台或新技术的风险
⚫ 工具所有权可能不清晰的风险（例如：指导、升级等）
工具的有效使用：选择，试点，成功因素
--为组织选择工具所需要考虑的关键点有：
⚫ 评估组织的成熟度，引入工具的优点和缺点
⚫ 识别引入工具能改进测试过程的机会
⚫ 了解测试对象所使用的技术，以便选择与此技术兼容的工具
⚫ 了解组织内使用的构建和持续集成工具，以便确保工具的兼容与集成
⚫ 根据清晰的需求和客观的准则对工具进行评估
⚫ 考虑工具是否提供免费试用期（以及多长时间）
⚫ 评估供应商（包括培训、提供的支持及其他商业方面考量），或非商业性工具（例如：开源）的支持
⚫ 针对工具使用的指导和培训，识别内部需求
⚫ 评估培训需求时，需要考虑工作中将直接使用工具的人员的测试（以及测试自动化）技能
⚫ 考虑各种许可证模式的优缺点（例如：商业或开源）
⚫ 根据实际的情况估算成本-收益比（如果需要的话）
作为最后一步，应进行概念验证评估，以确定该工具是否在所测试的软件和当前基础设施内有 效运行，或在必要时确定为有效使用该工具而需要对该基础设施进行的修改。
--组织引入工具的试点项目：完成工具选择和成功概念验证后，将选择的工具引入组织通常从试点项目开始，试点项目有以下目的：
⚫ 收集工具有关的深入知识，了解工具的优缺点
⚫ 评估工具与现有过程以及实践的配合程度，确定哪些方面需要作修改
⚫ 定义一套标准的方法来使用、管理、储存和维护工具及测试资产（比如，定义文件和测试的命名规则，选择编码标准，创建库和定义模块化测试套件）
⚫ 评估在付出合理的成本后能否得到预期的收益
⚫ 理解希望工具收集和报告的度量，配置工具来保证度量的捕获和报告
--工具的成功因素
在组织内成功地评估、实施、部署和持续支持工具的因素包括：
⚫ 逐步在组织的其余部分推广工具
⚫ 调整并改进过程来配合工具的使用
⚫ 为工具使用者提供培训、辅导和指导
⚫ 定义工具使用指南（例如：自动化的内部标准）
⚫ 实施一种在实际使用中收集工具使用信息的方法
⚫ 监督工具的使用和收益
⚫ 为测试团队使用工具提供支持
⚫ 在所有团队内收集经验和教训