一、计划的意义

  1、leader：根据计划进行资源的分配

  2、根据计划调整目标

  3、根据计划各职位的人员进行配合

 

 

二、计划内容

  1、项目概述

    a、项目背景：项目的使用人员和项目的基本功能和目的

    b、该计划的使用和阅读人员

 

  2、项目的组织形式

    a、组织结构图：描述团队职位，职位直接的关系，成员负责的内容

    b、角色和职责：职位和它的工作内容

    c、团队协作：协作的团队、合作方式、会议方式

 

  3、测试对象

    a、质量模型分析测试点

    b、描述测试特性

      应测特性：软件测试的模块、质量模型中的特性

      不测特性：哪些特性本次无需进行测试并且说明不测原因

 

  4、测试通过和失败的标准

    a、覆盖率：95%以上用例通过；重要的用例100%通过

    b、bug修复率：bug修复率达到95%以上；允许遗留的bug等级和数量

    c、具体判定标准根据时间情况而定

 

  5、挂起和恢复的标准

    a、无法继续测试或继续测试意义不大

    b、测试环境破坏，无法进行测试

    c、预测试不通过

    d、用户的需求发生重大的改变，造成基本功能和大部分主要功能的变化

    e、开发的设计发生根本变化，大部分功能受到影响

 

  6、测试任务安排

    a、完成系统测试计划的生成和评审

    b、方法和标准，如使用xxx工具

    c、输入和输出：输入就是依据什么，输出是产出的东西

    d、风险和假设：测试过程中可能遇到的风险

      假设是为了完成该任务，需要做好的准备工作

    e、角色和职责：xxx人负责xxx部分

 

　　6.1.几个时间节点要卡主

　　　　a.需求评审时间（决定你写测试用例的时间，最好评审过后就写，以免忘记）

　　　　b.用例 评审时间（决定你写用例的时间，用例需要经过评审，这样可以让参与的所有人都知道你测了那些东西，一个时候避免漏写，一个是规避责任）

　　　　c.测试交付日期（这个很重要，代表你有多长时间去测试）

　　　　d.测试安全时间（一定要留出一部分安全时间，1.给开发修复缺陷 2.以免有新的紧急需求插入）

　　　　

　

 

  7、工作量

    a、描述方式：人日、人时、人月

    b、根据测试范围和测试方法进行评估：可以用图解的方式说明

    c、根据项目背景估算

    d、根据开发阶段估算

    e、根据经验估算

    f、根据风险估算

    

    估算原则：

      任务分解的越详细，估算的越准确

      团队协作完成

 

　　7.1.开发周期与测试周期的协调

　　　　a.如果开发周期很长这就应该能说明这块的内容很多，如果后面开发完成之后全堵到测试这块来了，我们可以和研发组协商，完成拆开几段来完成，这样整个项目完成后我们的压力也不是很大。

　　　　b.在开发期间我们需要准备好测试用例，测试环境，测试数据，还测试策略，正确开发完成的部分我们就能上手测试。

 

　　7.2.风险预警

　　　　a.在一个阶段完成是需要发出一封邮件，反映出，目前测试，开发的各自进度，现在完成了多少，还有多少，和原来的计划偏差了多少，预计风险在哪里，以及缺陷频率高的模块（就说明这块地风险很大），发到各负责人。

　　　　b.在测试中遇到比较影响整个测试进度的缺陷，时也需要发风险预警，总之问题不能在测试这块卡主。

　　　　c.在感觉与原来计划偏差较大，以至于发版日发版，风险过大时最少要提前两天以上，及时反馈出来，好协商调配资源，重新整理存在风险的这部分计划。

  

  8、资源明细

    用到的人力、物力（电脑等）

 

  9、附件

    参考的文档 

 部分参考：