计划风险与应急措施

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