测试计划与风险评估

目录

目的

测试计划模板

基本信息

风险评估

---

目的

与业务方明确测试计划，包含测试活动，时间安排，资源情况，依赖项，风险情况等。
为测试团队管理测试任务的计划，执行，监控，以及风险，确保测试任务保质保量按期完成。
预期收益：风险管理，成本控制，效率提升（工作量削峰平谷）。
测试计划个人理解类似于研发做设计文档，起到便于分析回顾的作用。

测试计划模板

基本信息

ID：测试计划唯一id
名称：反应测试计划服务对象
测试负责人：此测试计划总体负责人，数量为一
测试对象，预期质量目标，和时间节点。
测试策略，分解测试/测试开发活动。
测试资源估算与分配，形成测试/测试开发活动排期计划。
测试项目风险预估和应对措施。

风险评估

对于测试的基本理念：无风险不测试。一旦判断出某一需求或者某一迭代风险低，就可以不测试或者进行低强度的测试。
对于这一版本的风险，可以从失效影响和失效可能性进行评估。

	风险因子	定级
失效影响	问题伤害度	很大： 大： 一般	① 考虑被评估的特性/风险项如果发生（如不可用），对应到线上会是几级事故； ② 参考KANO模型、用户对特性/风险项的容忍度
	影响用户量	大量： 部分： 少量：	影响用户量的等级，除了特性本身的用户量，还可以参考交付对象，KA客户或代表一群潜在客户的交付，用户量等级为“大”，demo/试用类的用户量为“小”，普通交付/特性/风险项，用户量取中等即可 只考虑风险对象出错影响到的用户“量级”，不要与失效可能做关联或混淆
	预期质量等级	高： 中： 低：	高：几乎不能出错（不能有严重级别bug） 中：允许少量问题（如一般级别bug） 低：主路径可用（如客户演示顺畅无中断）
失效可能	用户使用频率	高： 中： 低：
	时间是否充裕	是：基本够用，通过加班可按期完成 否：加班也不保证能按期交付
	研发技术经验	丰富： 一般： 无经验：
	技术复杂度	复杂： 一般： 简单：	参考因子：实现的代码复杂度、依赖数量及深度等 从开发维度，重构类的风险项、基于已有特性修改或组合之后的新特性，可以作为技术复杂的的一个参考要素，适当降低复杂度等级：如功能不变，从一个语言转写成另一个语言；或者类似的特性，从课后作业拓展到课堂互动场景，交互几乎不变，都可以将技术复杂度评估为“简单”。但是如果是已有多个特性组合+少量修改，技术复杂度应该为“一般”而不是“简单” 主要依赖开发同学的评估
	业务复杂度	复杂： 一般： 简单：