《全栈软件测试实战》教学课件—09风险分析与测试总结.pptxVIP

第9章 风险分析与测试总结 风险分析 测试总结 风险分析 ☞点击查看本小节知识架构 学习目标 了解 掌握 掌握 掌握 9.1 风险分析 9.1.1 软件风险 返回目录 9.1.2 规划风险 9.1 风险分析 9.1.1 软件风险 软件风险分析步骤如下所示： (1)组建风险分析小组 风险分析小组一般由项目经理、开发者、测试者、用户、界面设计者等各个领域的专家组成。通常是由项目经理、测试人员、开发人员进行讨论，经验较为丰富的测试主管和开发主管也会参与其中，利用测试或开发经验来发现一些潜在的风险。 9.1 风险分析 9.1.1 软件风险 (2)列出软件功能列表 风险分析小组需要在进行讨论之前获取软件相应的文档，如需求文档、功能设计文档等。而且刚开始可对整个项目进行划分，将较大的内容分类，先不做细化处理，随着讨论的深入再对内容进行细化。 以银行柜员系统为例，一开始可以分成：功能性(取钱、存钱、查询余额、转账、理财办理)、性能、安全性、可用性。 9.1 风险分析 9.1.1 软件风险 (3)分析功能失败的可能性 软件中各部分功能及特性失败的可能性需要从客观和主观两方面同时考虑才能确定，具体可通过以下几部分内容进行判断。 软件功能对软件系统的其他功能或组件的依赖程度。 软件功能自身的复杂度。 软件功能实现团队及软件设计者的经验。 9.1 风险分析 9.1.1 软件风险 若软件使用的是新技术或正在实验阶段，则失败可能性较高。 若是基于旧功能改写，并且旧功能的缺陷就比较多，则整体功能改写的失败可能性就会比较大。 若是基于旧功能改写，则改写代码量越少软件功能失败可能性就越大，这是因为回归测试往往不充分。 9.1 风险分析 9.1.1 软件风险 具体如下表所示。 对上表中列出的失败可能性不需要过于在意，因为不同的讨论小组得出的结论往往不相同。关键是当小组对同一个功能或特性的失败可能性产生较多不同意见时，需要将此功能或特性的失败可能性按照多数人的意见进行界定，因为随着分析的继续，后续出现的变数还会很多。 9.1 风险分析 9.1.1 软件风险 (4)确定功能失败所造成的影响 此步骤更多地是从用户的角度来判断，而不应过多考虑技术问题。此步骤一般会存在主观意识，并且在一些特殊软件的分析上还需要市场分析人员的帮助或意见，具体如下表所示。 9.1 风险分析 9.1.1 软件风险 (5)量化 量化，即将步骤(4)中表的表示可能性的“高、中、低”使用数字来表示，能区分“高、中、低”即可，因此任意数字均可，通常使用“3、2、1”表示“高、中、低”。量化数据是由项目组决定的，但需要在整个项目周期内保持一致。 9.1 风险分析 9.1.1 软件风险 (6)计算风险优先级通常计算风险优先级的公式有两个，具体如下所示。： 矩阵法(也称∑型法)：风险优先级=失败可能性+失败影响。 表格分析法(也称∏型法)：风险优先级=失败可能性×失败影响。 银行柜员系统的风险优先级如表格法表和矩阵法表所示： 9.1 风险分析 9.1.1 软件风险 9.1 风险分析 9.1.1 软件风险 (7)评审并修改量化的数值(与步骤(3)内容相似，但此步骤为数值改写) 在项目进行中可随时按照前面所提的经验来改写数值。 (8)将功能按优先级排列 此步骤是将软件中的功能按优先级进行排序，使项目组成员对各部分功能或特性的优先级清楚明了。测试人员在测试时按照此优先级进行测试，也可对功能再做细致划分，直到可编写测试用例为止。如此编写出的测试用例是软件系统中最重要的部分。 9.1 风险分析 9.1.1 软件风险 (9)确定“风险分割线”在某些需求下，需要对功能或特性进行分割；在一个项目中成本、进度、资源三者需要衡量的情况下，也可能会对一些功能或者特性进行分割。分割线之下的内容可能放到项目的下个周期再行处理，如下表所示。 但在功能或者特性对软件非常关键或必不可少时，则必须增加时间、经费与人员。 9.1 风险分析 9.1.1 软件风险 (10)确定缓解风险的措施 有些风险是无法避免的，只有通过分析进行防范或缓解，指定相应的措施。而这些措施只能减小软件功能或特性的失败可能性，而无法减弱失败的影响，因为失败的影响属于用户范畴，是开发、测试人员不可控制的。例如，在对复杂的模块进行测试时，可先执行 Code Review(代码评审)，再执行黑盒测试。 9.1 风险分析 9.1.2 规划风险 规划风险是在项目进行中出现计划之外的事件，导致项目进度受影响。此类风险必须在测试计划中加以说明。接下来以一个示例的形式讲解此类风险说明，并列举出缓解的措施。 情况1：用户在项目最后阶段，给软件又增加了几个主要的需求。 缓解措施1：增加测试资源。 缓解措施2：将已有的低优先级的功能或者特性推迟测试。 缓解措施3：降低对低优先级的功能和特