《计划风险与应急措施 .ppt》由会员分享，可在线阅读，更多相关《计划风险与应急措施 .ppt（21页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、计划风险与应急措施要点计划风险是可能会危及测试进度的非计划事件或滞后活动l交付日期l人员可用性l预算l环境选项l工具清单l采购进度l参与者的支持l培训需求l测试范围l缺乏需求l风险假设l使用假设l资源l特征蠕变l劣质软件l确定计划风险和应急措施有助于做出明智有效的决策。几乎每个项目小组都能指出可能会带来麻烦的计划风险：滞后需求、测试环境问题、软件的延迟交付，等等。我们的目标是提前决定当这些计划风险发生时所要采取的应对措施。我们认为，可能存在的应急措施有：l缩小范围l推迟实现l增加资源l减少质量过程案例学习2-2计划风险和应急措施样例l计划风险样例计划风险样例l用户在软件生命周期的晚期提出一个重
2、大需求变动。l应急措施样例应急措施样例1l请求用户团体为测试工作提供更多的用户（即，增加更多的资源）。l应急措施样例应急措施样例2l决定在进行后续发布之前不实现较低优先级的特征（即，缩小范围）。l应急措施样例应急措施样例3l决定对在软件风险分析过程中确定的某些风险较低的特征不予测试（或者至少是少测试）（即，减少质量过程)案例学习2-3计划风险与应急措施样例l计划风险样例计划风险样例l项目的规模保持增长这是一个双重打击。不仅因为项目规模的增长需要增加测试资源，而且，随着项目规模的增长，软件开发和测试的生产率一般都会降低。l应急措施样例应急措施样例1l增加资源（比如外包、增加用户、增加开发员、批准
3、加班）。l应急措施样例应急措施样例2l缩小项目的范围。选择对用户进行渐进式交付的策略。l应急措施样例应急措施样例3l减少对某些低风险模块的测试（即减少质量过程）。l应急措施样例应急措施样例4l推迟实现。l你可以看出，在案例学习2-2和案例学习2-3中列举的所有应急措施都涉及到对有关方面的妥协。但是，如果没有计划风险和应急措施，开发员和测试员就会被迫匆忙地做出选择。软件风险分析和计划风险与应急措施的分析相辅相成。让我们回顾一下在前面的章节中讨论的自动取款机（ATM）的例子。风险分析过程帮助我们找出了软件风险，从而帮助我们集中测试工作并排定优先顺序，以便降低其中的风险。l计划风险帮助我们进行“如果
4、那么”式的工作并制定应急措施。比如，如果JaneDoe真地辞了职，她的离职导致软件被延迟交付给测试团队，那么会怎么样呢？其中的一个应急措施是降低质量（这通常都意味着减少测试）。如果该应急措施降临到我们头上，我们可能会希望返回到软件风险分析阶段并考虑减少对最不重要的组件的测试（即将分割线上移）。l到目前为止，我们可以清楚地看到，计划风险、软件风险、待测特征/属性、不予测试的特征/属性，甚至还有整个测试策略都是围绕“用风险来排定测试工作优先级”这一理念来构造的。测试项l测试计划的这部分主要是纲领性地描述在测试计划的范围内需要对哪些内容进行测试，以及应该与配置或程序库管理者和开发员协作完成哪些工作。
5、这部分内容可以面向测试计划的等级来完成。对于较高的等级，这部分内容可以按照应用程序或版本来组织。l对于较低的等级，这部分内容可以按照程序、单元、模块或者构建来组织。例如，如果这是一个总体测试计划，这部分内容可能包括与财会软件的2.2版、用户手册的1.2版和需求规格说明的4.5版相关的信息。如果这是一个集成或者单元测试计划，这部分内容实际上可能会列出待测程序（如果这些程序可知的话）。IEEE标准中指出，可以参考下面的文档（如果有的话）来完成测试项：l需求规格说明l用户指南l操作指南l安装指南l与测试项相关的意外事件报告l注意，应该将那些将会被明确排除于测试之外的项标识出来软件风险问题l与其他系统
6、的接口l处理巨额现金的特征l影响许多客户（或者某些极为重要的客户）的特征l极其复杂的软件l有过缺陷历史的模块（来自缺陷分析）l发生过许多或复杂变更的模块l安全性、性能和可靠性问题l难于变更或测试的特征l可以看出，风险分析小组需要用户来判断失效对他们的工作带来的影响；需要开发员和测试员来分析失效可能性。软件风险列表应该对测试内容、测试程度和测试顺序有着直接的影响。风险分析是一项十分艰巨的工作，尤其是第一次尝试进行时更是如此，但是，以后会好起来的，而且也值得这样去做。l要点测试内容比测试程度要重要得多。待测特征l测试计划中的这一部分列出了待测的内容（从用户或客户的角度），这与测试项相反，测试项是从
7、开发者或者程序库管理者的角度对待测内容的度量。例如，如果你们正在测试某台自动取款机（ATM），其中的待测特征可能包括：取款、存款、查询账户余额、转账、购买邮票和偿还贷款。对于较低等级的测试而言，待测特征可能要详细得多。表3-1显示了在前面小节中描述的风险分析是如何建立在对每个特征（这些特征是在“待测特征”部分中确定的）的相对风险进行分析的基础上的。l将待测特征表用做软件风险分析的基础具有的一个优点是：在你们的项目落后于进度表时，它可以帮助你们确定将哪些低风险特征移到后面小节中作为不予测试的特征。l不予测试的特征不予测试的特征l测试计划中这一部分用来记录不予测试的特征及其理由。对某个特征不予测试的理由有很多：可能是因为该特征没有发生变化，可能是因为它还不能投入使用，或者是因为它具有良好的跟踪记录测试计划的修改l是否允许在未重新履行审批程序的情况下进行细微的修改（比如修改拼错的词汇）？l是否应该对测试计划进行每周一次或者每月一次的更新？l测试计划的发布应该采用何种方式（比如电子文件发布、纸质文件发布，还是两者兼用）？l测试计划的评审工作应该以顺序地、以会议形式进行，还是采取其某种组合方式进行？l要点测试经理必须制定一个用于更新测试计划的策略