测试策略设计三：风险测试策略

一.基于风险测试的原因：
    迭代测试过程中，有时测试需求不多或者上线时间不紧急，这时我们有充分的时间去做测试设计、测试验证，所有需求都得到充分的测试覆盖；但有时会碰到突然有大量的需求要在规定时间内完成开发测试上线，而且测试资源也不足的情况，我们没办法按照之前的测试方法去做充分的验证，这时就要针对性的设计测试策略、选择测试重点以及如何在有限的测试时间内合理利用测试资源完成测试。

二.基于风险的测试策略应用认知：
    1、不同的情形下，测试的深度和广度是不同的，要平衡测试时间、成本、范围与质量；用更少的资源和成本覆盖更多更重要的测试项。
    2、 对于测试工程而言，并非所有测对象都有同样的优先级和重要程度，基于风险的策略实际上就是评估事情的轻重缓急
    3、根据缺陷的二八原则和集群性分析，对于缺陷集中的模块重点投入验证和解决，会给产品质量快速提升。

三.迭代过程中的风险：
  需求风险：
    1、需求范围定义不够明确，在进一步详细定义的情况下可能会超出范围
    2、在制定需求的过程中，客户参与不足，导致后期需求不稳，甚至交付时不满足需求
    3、需求定义模糊，难以理解工作困难
    4、在已经确定的需求基础上增加额外的需求
    5、需求的变更未进行规范管理
  计划进度风险：
    1、估算结果不符合实际情况
    2、对需求描述的领域不熟悉，导致估算的工作量不准确
    3、没有标准的估算方法，使估算的工作量不准确
    4、错误的估计了辅助性工具对项目的助力，导致估算工作量不准确
    5、计划仓促计划和任务定义不够充分，可能带来进度方面的问题
    6、任务之间的关联关系未整理，不够明确
    7、计划不够完整，未覆盖全部过程
  技术风险：
    1、设计的实现方法不符合实际情况，能很好的满足需求，需要重复设计，可能会影响到产品质  量和项目进度
    2、设计出现遗漏，需要重新设计补全
    3、开发开始或中途使用新的开发工具，需要对新工具进行培训学习等
    4、需求和设计同开发人员之间的信息传递不够清晰明确，使开发的功能不满足需求
    5、测试准备不足，测试不能达到质量要求，例如：未编写测试大纲等
  质量风险：
    1、产品质量较差，缺陷较多，可能会出现返工的情况
    2、产品的性能是否可以满足需求和符合使用目的不确定
项目管理风险：
    1、实施的任务提交延迟，计划时间延长
    2、组内成员流失，甚至导致项目进度停滞
    3、组内成员是新员工，工作经验不足，对工作环境不够了解，需要培训或磨合，对其工作量的  评估较难把握
    4、组内个别成员能力欠佳，其工作成果需要投入较多工作量进行验证
    5、人力资源紧缺，临时任务较多，资源不足
    6、项目团队对业务了解程度不足
    7、团队成员间关系不佳，导致沟通不畅

四.风险测试策略设计方法：

    举一个例子，迭代内容是完成一个采购业务的开发测试上线，迭代周期两个月，功能模块有配置模块、业务流程模块、数据统计模块、审批模块、消息通知模块、外部集成模块；开发5周、测试3周，预估测试工作量4到5周，测试时间不足；这时，我们可以基于测试范围，做风险识别；可以邀请测试leader、产品、开发经理等参与评估。主要从两个维度结合起来做评估，一是发生风险的概率，分低、中、高三个等级；二是发生风险的影响范围，也分低、中、高三个等级。根据评估，第一个配置模块，虽然是业务的源头，但上线时有一套初始脚本，并且客户很少会修改配置，因此失效风险低、影响低；业务流程模块核心功能，失效风险高、影响范围大；数据统计模块用于统计业务数据，应用不高、短期失效风险低，其他不一一描述；最后得出结论如下

    根据上述分析得出的优先级，测试人员可以在测试活动的安排上制定应对措施，规避、缓解风险。那么测试的优先级就是风险最好的业务流程和审批流程模块，需要优先进行测试分析、用例设计、测试验证；而且还要反向评估开发的计划安排是否跟自己的测试优先级匹配，如果不匹配，及时同开发经理沟通调整。其次是优先级为中的模块，因为上面的模块验证时间较多，时间被压缩；那么这部分我们可以做缩减，比如设计用例时标识用例的优先级，只执行高、中优先级的用例，记录未执行的用例和覆盖不充分的地方，如果风险被规避，我们再去执行记录的这部分。最后对于优先级较低的模块，我们简单的测试，可以不按用例执行，甚至可以不测试；当然还有其他的办法，比如让开发执行用例进行测试、让产品去做验收测试等等；同样，要记录未进行测试的部分，当风险得到规避的时候，我们再去加强测试深度和广度。当然，风险分析不是一次性的就可以分析透的，需要持续跟踪和识别；我们可以在每日晨会跟进风险项或者每几天、每周对风险项进行更新，一旦发生改变，测试活动计划也应随之相应调整。

    这种基于风险的测试策略可以有效的指导测试人员快速实现重要模块的测试覆盖，并且快速提升产品质量，达到交付要求，但后期一定要继续测试，而不是短期没有问题就不关注了。

五.总结：

    基于风险的策略其实就是列出一个风险的列表，评估每项的测试风险，如果有风险消失或新的风险出现时及时调整测试计划。重点是将产品潜在风险作为测试安排的依据和目标， 因此对当前潜在风险的全面分析和把握，才能有效地设计并组织恰当的测试。最后测试完成后，根据测试的结果、测试数据度量分析我们的风险识别、风险分析及测试过程中存在的问题。而且千万不要忘了过程中缩减的测试项记录下来，纳入后续迭代中进行覆盖。