测试计划

概念

测试计划是一个文档，描述了进行测试的测试范围，测试策略和方法，测试资源和进度。是对整个测试活动进行的一个宏观的规划，确定了测试项目，测试任务，谁来执行任务，被测试特性，不被测试特性以及过程中可能存在的风险等。测试计划能够有效的预防存在的风险，保证了测试活动能够在计划范围内顺利的开展。

测试计划的内容

1. 测试范围
   明确测什么？比如：产品的具体业务需求有哪些？产品是web端的还是移动端的，还是两者都有？
2. 测试策略
   明确怎么测。对不同业务需求，具体要有哪些测试类型、测试场景、测试方法。
3. 资源安排
   包括测试人员的安排，测试环境是怎样的，测试工具的选择等。
4. 进度安排
   在明确测试范围、方法和人员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、上线计划衔接。
5. 发布标准
   发布标准是测试完成和产品上线需要满足的条件，以便项目内所有角色都有一致认可的目标。怎样才算是测完了？达到怎样的标准才可以上线？
6. 风险预防
   最后，我们需要对整个测试过程中可能存在的风险，以及当这些风险发生时的应对措施提前进行一些考虑和准备，并在测试计划中体现出来。

测试范围

测试范围的确定来自于需求文档，依据是项目的交互稿和需求分析结果

1. 功能测试范围的分析
   功能点的拆分、接口测试、UI测试
2. 系统测试范围的分析
   (1).容错处理。如断网、业务处理过程中断等
   (2).兼容性要求
   (3).配置要求
   (4).性能要求
   (5).安全性要求
   (6).可靠性、日志文件

测试策略

为了更好确定软件测试策略，可以问如下一些问题：
(1).回归测试的范围如何确定？
(2).如何利用可重复性的测试？
(3).测试缺乏可预见性，如何收集衡量测试结果的指标？
(4).如何建立稳定的、模拟系统实际运行的测试环境？
(5).如何从无穷的输入数据中选择合理的、有效的测试数据集？
(6).如何衡量这份测试策略的有效性？

1. 基于测试技术的测试策略
   (1).任何情况下都要使用边界值分析方法
   (2).等价类划分法是对边界值分析方法的有效补充
   (3).如果功能的输入数据/条件存在多种组合情况，则使用因果图
   (4).错误推测法
   (5).对照程序逻辑来审查已有测试用例的逻辑覆盖程度
   (6).白盒测试
2. 分阶段的测试策略
   (1).严格执行代码审查
   (2).单元测试和集成测试，准备自动化测试
   (3).系统测试中，以每次发布用户基线为结束标志
   (4).不能忽略安全性测试、可用性测试、配置测试和数据完整性测试
   (5).在功能测试、安全性测试、配置测试中进行探索性测试
3. 基于测试方案的综合测试策略
   (1).测试优先级，优先级越高，越早测试，测试力度越大
   (2).使用尽可能少的测试用例，发现尽可能多的程序错误
   (3).测试策略尽量简单、清晰
   (4).基于缺陷分析的测试策略

资源安排

测试人力资源包含两个维度：

1. 测试人员数量
2. 测试人员经验、能力

环境资源一般包括：

1. 测试服务器环境（尽量与线上环境保持一致）
2. 终端环境（PC配置，手机型号）
3. 测试工具（bug管理工具，用例管理工具，性能测试工具等）
   在我们的测试计划中，测试人员分配、测试环境资源、忘了资源、工具使用都要明确写出来

进度安排

测试工作的进度安排依赖于开发工作的节点和提交测试进度的时间，并且直接影响预期的上线时间。所以我们需要根据产品业务的复杂度、所需要进行的不同的测试类型的复杂度、产品上线的质量要求的高低、测试人员的数量、能力和经验这些因素，来评估不同阶段、不同类型的测试工作的工作量。
可以用工作分解结构表方法评估工作量：

1. 列出本项目需要完成的各项任务
2. 细化每个任务，尤其是测试阶段，需要对模块进行拆分，拆分到可衡量和细化的维度
3. 预先设计测试点，按照测试点来估算
4. 给每个维度估算时间，需要优化和重复操作的部分
5. 在已估算结果上浮动10%-15%

发布标准

测试完成的标准，也就是说做到什么样算是测试工作做完了。主要包括：

1. 测试计划里所有测试类型都已经完成了
2. 功能上、兼容性上没有影响用户使用的Bug
3. 允许遗留小部分影响不是很大的Bug，但这个数量应该小于一个值
4. 性能上符合设计目标和上线要求 这些标准都是针对测试工作本身的要求。

在满足了测试本身的前提下，产品要发布还需要满足要求：

1. 产品需求都已完成
2. 交互视觉走查都已完成
3. 一流的小部分Bug项目组完成了风险评估，都认可且问题不大
4. 产品使用说明或用户手册或更新log都已完备等等。

风险预防

测试风险分类：

1. 测试范围的风险，比如说一开始测试需求分析不准确、不到位漏了测试点，甚至某个测试类型遗漏了，这样问题就比较大了，所以测试需求分析是整个测试工作的基础，还有就是产品需求变更的风险，加需求、减需求、改需求都需要重新进行测试需求分析，需要测得一定要测到，不需要测的就不要浪费人力物力和工作量；
2. 测试进度的风险，比如说做计划时工作量估计的不准，测试做着做着发现时间不够导致项目延期，还有测试依赖开发，可能开发工作没有按时完成或改bug不及时导致进度延后，还有可能测试人员因为别的项目更重要抽调走了或者请假、离职等原因造成人员变动；
3. 产品质量的风险，比如开发的代码质量比较低或者测试人员是新人对业务不熟悉，能力和经验有所欠缺等等。

测试风险的控制方法：

1. 根据风险发生的概率和带来的影响确定风险的优先级，然后才去措施避免那些可以避免的风险；
2. 风险转移，比如去掉新功能，转移风险；
3. 不可避免的风险，就设法降低风险，如提高测试用例的覆盖率；
4. 事先做好风险管理计划，喜欢里程碑和验收管理；
5. 有一套应急、有效的处理方法，比如全员了解，注意日常观察，及时发现风险出现的征兆；
6. 做计划时，要留有余地
7. 制定文档标准。

==============================================================================================

目的

1. 制定一个可行性的计划，包括测试对象，测试范围，测试方法和策略，测试进度和预期结果。
2. 确定测试角色和职责
3. 测试时间喝资源，保证可行性和有效性
4. 确定测试阶段完成或者成功的标准，实现的目标
5. 识别风险，消除可能存在的风险

包含

1. 测试项目
2. 测试范围
   - 需要测试什么【被测试特性】（测试的类型，如测试的feature，功能测试，性能测试，回归测试，新版本的新功能， 以及受到影响的功能需要测试）
   - 不需要测试什么【不被测试特性】（新版本基础的原来没有影响的功能不需要测试）
3. 测试方法和策略
   - 用什么方法和策略进行测试，比如冒烟测试，快速的测出新版本在主要功能方面是否存在缺陷；用探索性测试方法，由浅入深的测试软件是否存在缺陷等
4. 测试环境
5. 测试时间
6. 测试风险
7. 测试人员和职责
8. 作者和保密级别
9. log（用于记录谁在合适进行的改动了计划）
10. 测试计划简介及目录
11. 测试计划版本信息
    - 用于跟中测试版本的状态，是Draft，还是Approved
12. 参考文档
    - 测试计划有时需要跟其他文档一起看，或者自己本身存在子文档，则需要加入到参考文档列表里