什么是测试计划？
 
       测试计划Testing plan，描述了要进行的测试活动的范围、方法、资源和进度的文档；是对整个信息系统应用软件组装测试和确认测试。 它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。
 
测试计划包含哪几个方面的内容？
 
       1、测试范围；2、测试点；3、测试类型；4、测试资源；5、进度安排。
  
 
简单地说，测试计划就是安排测试资源，写出测试点，说明每个测试点的开始时间和结束时间。
 
测试计划的目的
 

    制定测试计划，要达到的目标如下： 
 
（1）为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。
 
（2）为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。
 
（3）开发有效的测试模型，能正确地验证正在开发的软件系统。
 
（4）确定测试所需要的时间和资源，以保证其可获得性、有效性。
 
（5）确立每个测试阶段测试完成以及测试成功的标准、要实现的目标。
 
（6）识别出测试活动中各种风险，并消除可能存在的风险，降低由不可能消除的风险所带来的损失。 
 
        制定一个好的测试计划对测试人员的能力要求是非常高的，测试人员需要有丰富的经验沉淀，需要有很好的全局意识才能做好一个项目的测试计划。
  

  相信大多数的软件测试工程师都听说过或者简单了解过测试计划，但是你真的知道什么是测试计划么？你真的知道如何编写测试计划么？大多数人应该是一脸茫然。百度的结果五花八门，有没有相对规范的标准呢？答案是没有，至少我没有找到。那么今天我就结合经验和对一些国内技术前沿的公司跟大家聊一聊什么是测试计划以及如何编写测试计划。
   计划的必要性：
   在我们日常的工作和生活中，经常需要做计划。古人云：凡事预则立，不预则废（《礼记.中庸》），也就是强调预先计划的重要性和必要性。
   我们做项目，项目需要定项目计划；测试作为项目中的一部分，当然也需要制定测试计划。
 
测试计划就像是我们写论文一样，首先做好提纲，才能一步一步的完善填充，有了测试计划就掌握了整个项目的进度和方向，在工作中可以有个指导的作用，不至于偏离工作方向；
测试计划规定预期的目标，以什么样的程度完成和在预期多久内完成，这样的规定能够使工作人员做好心理准备，合理的期限和目标能够使工作人员不松懈，有效率的完成一个项目；
计划作为对未来工作的规划，肯定会受到突发的或者不稳定的因素影响而导致整个项目出现延期甚至无法进行的结果。因此计划中对于风险评估的必要性就在于罗列出影响整个项目进行的因素，并制定相应紧急方案，将损失降至最小化；
人员的安排呈现合理化。任何一个项目内的工作都有难易繁简的划分，因而才需要有专长的工程师进行对应的测试。难度较大的由资深测试人员安排，难度小的由新进实习生来进行，整个项目的进行就会显得合理化层次化条理化。同时将职责清晰地具体划分到个人身上，也有利于日后的纠错，及时发现哪个环节出现问题；
测试计划的制作是在需求分析完成之后所进行，所以测试计划的执行在一定程度上也是对需求分析的进一步的检验，若在制定过程中，发现有不合理的因素存在，还能及时反馈，进行调整，不至于使众多的人力做了无用功；
测试计划的安排也是一个项目中多个部门间合作的工作指导，一环扣一环，工作的交接在时间上做好详细的备注，才能让部门的合作显得默契。
 
  一个测试计划制定者的素养：
 
有多年从事测试工作的经验，能够条例清晰的罗列出测试中的流程和应当留心的步骤，以及不可缺少的风险规避的意识
对于部门的员工能力要有一定程度的了解，才能合理的安排工作内容
高压下的冷静处理能力，一旦项目出现突发的严重问题，能够冷静找出出错环节。
人际沟通的能力，一个测试计划也是有与其他部门之间的合作关系，需要与其保持及时有效的沟通，了解到他们的需求
 
  那么我们什么时候来做测试计划呢？
   一般来说，在产品需求确认，做过测试需求分析之后我们就要开始编写测试计划。当然测试计划编写的工作要根据工作实际来决定，也就是具体情况具体分析（政治课学的哈~）
   其实，要想做好测试计划必须有一定的测试经验。那么下面我就结合工作实际，跟大家聊一聊测试计划的内容。
   测试计划的内容：
 
 
测试范围 明确测什么？比如：产品的具体业务需求有哪些？产品是web端的还是移动端的，还是两者都有？
 
 
测试策略 明确怎么测？对不同业务需求，具体要有哪些测试类型、测试场景、测试方法。
 
 
资源安排 包括测试人员的安排，测试环境是怎样的，测试工具的选择等。
 
 
进度安排 在明确测试范围、方法和人员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、上线计划衔接。
 
 
发布标准 发布标准是测试完成和产品上线需要满足的条件，以便项目内所有角色都有一致认可的目标。怎样才算是测完了？达到怎样的标准才可以上线？
 
 
风险预防 最后，我们需要对整个测试过程中可能存在的风险，以及当这些风险发生时的应对措施提前进行一些考虑和准备，并在测试计划中体现出来。
 
 
  我们把这些内容模板化，形成测试计划的模板。无论是在实际的工作中还是大家学习编写测试计划，都可以用这样的模板来使用。
 
 在此模板的基础上，我们一点点来剖析如何编写测试计划。
 
 这里的参考资料可以有：（可行性分析报告、软件需求定义、软件系统分析、软件概要设计、软件详细设计、软件测试需求、硬件可行性分析报告、硬件需求分析、硬件概要设计、硬件原理图设计、硬件结构设计、硬件测试需求、模块开发手册、测试时间表及人员安排、测试计划、测试方案、测试报告、测试分析报告、用户操作手册、安装指南等）
 2 测试范围
 测试范围的确定来自于需求文档，依据是项目的交互稿和需求分析结果
 2.1功能测试范围的分析
 功能点的拆分、接口测试、UI测试
 2.2系统测试范围的分析
 （1）容错处理
 （2）兼容性要求
 （3）配置要求
 （4）性能要求
 （5）安全性要求
 （6）可靠性、日志文件
 
 3.测试策略
 为了更好确定软件测试策略，可以问如下一些问题：
 (1).回归测试的范围如何确定？
 (2).如何利用可重复性的测试？
 (3).测试缺乏可预见性，如何收集衡量测试结果的指标？
 (4).如何建立稳定的、模拟系统实际运行的测试环境？
 (5).如何从无穷的输入数据中选择合理的、有效的测试数据集？
 (6).如何衡量这份测试策略的有效性？
 1、基于测试技术的测试策略
 (1).任何情况下都要使用边界值分析方法
 (2).等价类划分法是对边界值分析方法的有效补充
 (3).如果功能的输入数据/条件存在多种组合情况，则使用因果图
 (4).错误推测法
 (5).对照程序逻辑来审查已有测试用例的逻辑覆盖程度
 (6).白盒测试
 2、分阶段的测试策略
 (1).严格执行代码审查
 (2).单元测试和集成测试，准备自动化测试
 (3).系统测试中，以每次发布用户基线为结束标志
 (4).不能忽略安全性测试、可用性测试、配置测试和数据完整性测试
 (5).在功能测试、安全性测试、配置测试中进行探索性测试
 3、基于测试方案的综合测试策略
 (1).测试优先级，优先级越高，越早测试，测试力度越大
 (2).使用尽可能少的测试用例，发现尽可能多的程序错误
 (3).测试策略尽量简单、清晰
 (4).基于缺陷分析的测试策略
 
 4、测试资源
 测试人力资源包含两个维度：
 1、测试人员数量
 2、测试人员经验、能力。
 环境资源一般包括：
 1、测试服务器环境（尽量与线上环境保持一致）
 2、终端环境（PC配置，手机型号）
 3、测试工具（bug管理工具，用例管理工具，性能测试工具等）
 在我们的测试计划中，测试人员分配、测试环境资源、网络资源、工具使用都要明确写出来。
 
 5、进度安排
 测试工作的进度安排依赖于开发工作的节点和提交测试进度的时间，并且直接影响预期的上线时间。所以我们需要根据产品业务的复杂度、所需要进行的不同的测试类型的复杂度、产品上线的质量要求的高低、测试人员的数量、能力和经验这些因素，来评估不同阶段、不同类型的测试工作的工作量。
 可以用工作分解结构表方法评估工作量：
 1、列出本项目需要完成的各项任务
 2、细化每个任务，尤其是测试阶段，需要对模块进行拆分，拆分到可衡量和细化的维度
 3、预先设计测试点，按照测试点来估算
 4、给每个维度估算时间，需要优化和重复操作的部分
 5、在已估算结果上浮动10%-15%
 
 6、发布标准
 测试完成的标准，也就是说做到什么样算是测试工作做完了。主要包括：
 1、测试计划里所有测试类型都已经完成了
 2、功能上、兼容性上没有影响用户使用的Bug
 3、允许遗留小部分影响不是很大的Bug，但这个数量应该小于一个值
 4、性能上符合设计目标和上线要求 这些标准都是针对测试工作本身的要求。
 在满足了测试本身的前提下，产品要发布还需要满足要求：
 1、产品需求都已完成
 2、交互视觉走查都已完成
 3、一流的小部分Bug项目组完成了风险评估，都认可且问题不大
 4、产品使用说明或用户手册或更新log都已完备等等。
 
 7、风险说明
 测试风险分类：
 1、测试范围的风险，测试遗漏、需求变更；比如说一开始测试需求分析不准确、不到位漏了测试点，甚至某个测试类型遗漏了，这样问题就比较大了，所以测试需求分析是整个测试工作的基础，还有就是产品需求变更的风险，加需求、减需求、改需求都需要重新进行测试需求分析，需要测得一定要测到，不需要测的就不要浪费人力物力和工作量；
 2、测试进度的风险，工作量预估不准确、耦合任务延迟、测试人员变动；比如说做计划时工作量估计的不准，测试做着做着发现时间不够导致项目延期，还有测试依赖开发，可能开发工作没有按时完成或改bug不及时导致进度延后，还有可能测试人员因为别的项目更重要抽调走了或者请假、离职等原因造成人员变动；
 3、产品质量的风险，代码质量、测试人员能力；比如开发的代码质量比较低或者测试人员是新人对业务不熟悉，能力和经验有所欠缺等等。
 测试风险的控制方法：
 1、根据风险发生的概率和带来的影响确定风险的优先级，然后才去措施避免那些可以避免的风险；
 2、风险转移，比如去掉新功能，转移风险；
 3、不可避免的风险，就设法降低风险，如提高测试用例的覆盖率；
 4、事先做好风险管理计划，喜欢里程碑和验收管理；
 5、有一套应急、有效的处理方法，比如全员了解，注意日常观察，及时发现风险出现的征兆；
 6、做计划时，要留有余地
 7、制定文档标准。
 
   到这里我们就完成了一份测试计划。有的人可能依旧存在疑问：做计划真的有那么重要么？我们实际工作中有很多项目根本就没有计划依旧可以完成的啊！我们来看一下不做计划可能会有哪些问题~
  首先，如果没有计划我们无法预估工作量和需要的测试人员数量。一个项目的工作量和需要的人员数量都没有依据，在公司里怎么来协调和安排呢？
  其次，测试人员的分工明确，会导致工作重复和遗漏。出了问题大家可能都觉得不是自己的问题，导致工作混乱效率低下。
 再就是测试进度失控。到底什么时候做完没有一个预期，其他的团队怎么安排工作呢？进度有没有失控也没有判断依据，临到预计的上线时间才发现还有很多没有测到、没测完，直接影响整个项目的进行。
 还有就是应对需求变更困难，对可能出现的风险没有准备。一旦出现问题，大家一片混乱，很容易导致测试遗漏和项目延期。
  最后就是没有统一发布标准，上线意见不一致。测试团队认为Bug太多不能上线，开发团队认为都是小Bug不要紧，先上线再说，导致争执不下的局面。、
  当然根据项目不同还可能存在其他一些列问题…
  总而言之，测试计划的作用非常重要。
 
指导测试过程
协调项目安排
提高测试效率
提高测试质量
 做测试计划对测试人员的能力和要求是非常高的，从另一个角度来说，测试计划可以体现一个测试人员的自我修养。一个测试人员需要很好的经验沉淀、有很多好的全局意识才能做好一个项目的测试计划。
 希望大家都能够很好的胜任编写测试计划这项工作。

 1、软件测试计划的制定
 
 1.1、需求分析
 
 
  

   定义被测试对象和测试目标
  
 
 
  

   确定测试阶段和测试周期的划分
  
 
 
 1.2、测试策略
 
 
  

   测试方法的选择
  
 
 
  

   测试工具的选择
  
 
 
  

   测试用例设计方法的选择
  
 
 
 1.3、工作量估算
 
 
  

   测试过程的任务定义
  
 
 
  

   各任务的工作量估算
  
 
 
 1.4、进度安排
 
 
  

   测试人员的时间任务安排
  
 
 
  

   测试设备的配置
  
 
 
  

   测试工具的配置
  
 
 
 1.5、度量标准
 
 
  

   测试通过或失败的标准
  
 
 
  

   测试挂起及恢复的标准
  
 
 
  

   测试中需要进行度量的目标度量项
  
 
 
 1.6、风险评估
 
 
  

   定义项目中潜在的风险
  
 
 
  

   制定相应的风险减缓措施和应急措施
  
 
 
 1.7、子计划制定
 
 
  

   度量分析计划
  
 
 
  

   配置管理计划
  
 
 
  

   质量保证计划
  
 
 
  

   验证和确认计划
  
 
 
  

   沟通计划
  
 
 
 1.8、计划评审
 
 
  

   评审的形式
  
 
 
  

   评审的记录
  
 
 
 2、软件测试计划的内容要素
 
 
  

   软件测试计划的内容要素包括
  
 
  
 
    

     软件测试的范围
    
 
 
    

     软件测试的策略
    
 
 
  
 
    

     软件测试的需求
    
 
 
    

     软件测试的资源要求
    
 
 
    

     软件测试的人员要求
    
 
 
    

     软件测试的进度
    
 
 
    

     测试阶段停止测试的标准
    
 
 
    

     测试用例设计的方法
    
 
 
    

     测试中潜在的风险和问题区域
    
 
 
    

     角色与职责
    
 
 

前言：
 
测试计划是测试中比不可少的一部分，一份完整的测试计划反应了整个项目的测试安排与测试进度，让项目在测试环节达到了可控的环节。需要注意的是，测试计划一般在大功能改动的时候需要用到，并不是每个周版本必须的。是否编写可根据项目需要，另外测试计划的编写时间，一般是你在了解了需求，分析完了需求后才开始编写。要不然你都不知道自己测试什么，怎么测试。
 
1. 测试目标：
 
根据xxx需求，提炼测试功能点、制定测试策略、评估测试 风险，预估编写测试用例、执行功能测试和回归测试的工作量，进行人员和进度 安排。
 
2. 测试范围：
 
功能模块：（需要结合实际情况）
 
3. 测试策略：
 
对需求中的功能改进进行完整测试，并根据应用场景和并发数考虑兼容性和 性能测试方案。 并需要指定出测试工具。
 
3.1 功能测试
 
见测试用例表
 
3.2 性能测试
 
3.3 系统兼容性测试
 
4. 测试资源
 
4.1 人员安排
 
4.2 测试环境
 
4.3 bug管理
 
5. 测试进度安排
 
5.1测试进度安排
 
任务
时间
执行人员
工作量
编写测试计划
测试环境准备
第一次功能测试
性能测试
回归测试
测试报告总结

5.2输出文档
 
测试计划
测试报告
 
6. 验收
 
6.1 测试验收标准
 
		1.完成所有类型测试
		2. 没有影响到用户业务使用的bug
		3. bug数量少于一定数量
		4. 功能业务，性能指标符合需求
 
6.2 产品上线标准
 
产品 checkelist
1. 已按照交互文档、需求文档完全的实现需求；
2.  符合交互稿的交互设计规范、符合视觉要求，已经通过设计评审；
3.  允许遗留可能会对用户正常使用造成一定影响的 normal 级缺陷，但应在 发布前告知项目组，并经风险评估一致同意发布后方可发布
 
7. 风险说明
 
主要包括三个方面：
 
测试范围风险 （测试遗漏，需求变更）
测试进度风险（预估量不准确，测试人员变动，其他业务工作，）
产品质量风险（代码质量，测试人员能力）
 
比如：1. 上述工作量预估中对需求变更进行了一定的风险覆盖，但如果需求变更 超出目前预计，则可能导致编写测试用例和执行测试相关工作量增加、 测试进度延迟。。 2. 开发提交测试版本比该计划延迟的风险，发生此种情况时，执行测试的 时间应该合理顺延。 3.提交测试版本质量较低的风险，可能导致比该计划更多轮次的回归测试。
 4.代码版本管理执行不力的风险，发生版本管理混乱的情况时，将只选取 一个稳定版本进行测试，不考虑中间版本的反复测试。一轮测试完成后， 再进行下一稳定版本的回归测试。 5. 云课堂所依赖的测试服务器环境，如果服务器端测试环境不稳定，会影 响开发提交测试版本和测试的进度
 
最后箴言：
 
每次我们测试的时候都可以用5W+H思考方法，
 
1）why——为什么要进行这些测试；
 
2）what一测试哪些方面，不同阶段的工作内容；
 
3）when一测试不同阶段的起止时间；
 
4）where一相应文档，缺陷的存放位置，测试环境等；
 
5）who一项目有关人员组成，安排哪些测试人员进行测试
 
6）how一-如何去做，使用哪些测试工县以及测试方法进行