将待测特征表用做软件风险分析的基础具 有的一个优点是：在你们的项目落后于进 度表时，它可以帮助你们确定将哪些低风 险特征移到后面小节中——作为不予测试 的特征。
不予测试的特征 测试计划中这一部分用来记录不予测试的 特征及其理由。对某个特征不予测试的理 由有很多：可能是因为该特征没有发生变 化，可能是因为它还不能投入使用，或者 是因为它具有良好的跟踪记录
要点 测试经理必须制定一个用于更新测试 计划的策略
应急措施样例＃3 减少对某些低风险模块的测试（即减少质 量过程）。 应急措施样例＃4 推迟实现。
你可以看出，在案例学习2-2和案例学习2-3中列 举的所有应急措施都涉及到对有关方面的妥协。 但是，如果没有计划风险和应急措施，开发员和 测试员就会被迫匆忙地做出选择。软件风险分析 和计划风险与应急措施的分析相辅相成。让我们 回顾一下在前面的章节中讨论的自动取款机 （ATM）的例子。风险分析过程帮助我们找出了 软件风险，从而帮助我们集中测试工作并排定优 先顺序，以便降低其中的风险。
案例学习2-2 计划风险和应急措施样例
计划风险样例 用户在软件生命周期的晚期提出一个重大需求变动。 应急措施样例＃1 请求用户团体为测试工作提供更多的用户（即，增加更多 的资源）。 应急措施样例＃2 决定在进行后续发布之前不实现较低优先级的特征（即， 缩小范围）。 应急措施样例＃3 决定对在软件风险分析过程中确定的某些风险较低的特征 不予测试（或者至少是少测试）（即，减少质量过程 )
待测特征
测试计划中的这一部分列出了待测的内容（从用 户或客户的角度），这与测试项相反，测试项是 从开发者或者程序库管理者的角度对待测内容的 度量。例如，如果你们正在测试某台自动取款机 （ATM），其中的待测特征可能包括：取款、存 款、查询账户余额、转账、购Байду номын сангаас邮票和偿还贷款。 对于较低等级的测试而言，待测特征可能要详细 得多。表3-1显示了在前面小节中描述的风险分析 是如何建立在对每个特征（这些特征是在“待测 特征”部分中确定的）的相对风险进行分析的基 础上的。
需求规格说明 用户指南 操作指南 安装指南 与测试项相关的意外事件报告 注意，应该将那些将会被明确排除于测试 之外的项标识出来
软件风险问题
与其他系统的接口 处理巨额现金的特征 影响许多客户（或者某些极为重要的客户）的特 征 极其复杂的软件 有过缺陷历史的模块（来自缺陷分析） 发生过许多或复杂变更的模块 安全性、性能和可靠性问题 难于变更或测试的特征
测试计划的修改
是否允许在未重新履行审批程序的情况下进行细 微的修改（比如修改拼错的词汇）？ 是否应该对测试计划进行每周一次或者每月一次 的更新？ 测试计划的发布应该采用何种方式（比如电子文 件发布、纸质文件发布，还是两者兼用）？ 测试计划的评审工作应该以顺序地、以会议形式 进行，还是采取其某种组合方式进行？

案例学习2-3 计划风险与应急措施样例
计划风险样例 项目的规模保持增长——这是一个双重打击。不 仅因为项目规模的增长需要增加测试资源，而且， 随着项目规模的增长，软件开发和测试的生产率 一般都会降低。 应急措施样例＃1 增加资源（比如外包、增加用户、增加开发员、 批准加班）。 应急措施样例＃2 缩小项目的范围。选择对用户进行渐进式交付的 策略。
计划风险与应急措施
要点 计划风险是可能会危及测试进度的非 计划事件或滞后活动
交付日期 人员可用性 预算 环境选项 工具清单 采购进度 参与者的支持 培训需求 测试范围 缺乏需求 风险假设 使用假设 资源 特征蠕变 劣质软件
确定计划风险和应急措施有助于做出明智有效的 决策。几乎每个项目小组都能指出可能会带来麻 烦的计划风险：滞后需求、测试环境问题、软件 的延迟交付，等等。我们的目标是提前决定当这 些计划风险发生时所要采取的应对措施。我们认 为，可能存在的应急措施有： 缩小范围 推迟实现 增加资源 减少质量过程
计划风险帮助我们进行“如果……那 么……”式的工作并制定应急措施。比如， 如果Jane Doe真地辞了职，她的离职导致 软件被延迟交付给测试团队，那么会怎么 样呢？其中的一个应急措施是降低质量 （这通常都意味着减少测试）。如果该应 急措施降临到我们头上，我们可能会希望 返回到软件风险分析阶段并考虑减少对最 不重要的组件的测试（即将分割线上移）。
到目前为止，我们可以清楚地看到，计划 风险、软件风险、待测特征/属性、不予测 试的特征/属性，甚至还有整个测试策略都 是围绕“用风险来排定测试工作优先级” 这一理念来构造的。
测试项
测试计划的这部分主要是纲领性地描述在 测试计划的范围内需要对哪些内容进行测 试，以及应该与配置或程序库管理者和开 发员协作完成哪些工作。这部分内容可以 面向测试计划的等级来完成。对于较高的 等级，这部分内容可以按照应用程序或版 本来组织。
可以看出，风险分析小组需要用户来判断 失效对他们的工作带来的影响；需要开发 员和测试员来分析失效可能性。软件风险 列表应该对测试内容、测试程度和测试顺 序有着直接的影响。风险分析是一项十分 艰巨的工作，尤其是第一次尝试进行时更 是如此，但是，以后会好起来的，而且也 值得这样去做。
要点 测试内容比测试程度要重要得多。
对于较低的等级，这部分内容可以按照程 序、单元、模块或者构建来组织。例如， 如果这是一个总体测试计划，这部分内容 可能包括与财会软件的2.2版、用户手册的 1.2版和需求规格说明的4.5版相关的信息。 如果这是一个集成或者单元测试计划，这 部分内容实际上可能会列出待测程序（如 果这些程序可知的话）。IEEE标准中指出， 可以参考下面的文档（如果有的话）来完 成测试项：