软件测试笔记-如何做好测试计划

敏捷开发，测试计划从原来的一次性集中制定测试计划-----迭代的方式持续制定计划

一、没有测试计划会怎么样？

1. 难以知道具体的测试范围，具体的测试策略
   2.难以预估具体的工程量和所需的测试工程师数量，分工不明确
   3.整体进度不可控
   4.对潜在风险的抵抗能力弱

好的测试计划： 测试范围、测试策略、测试资源、测试进度和测试风险评估

二、测试范围

• 测什么和不测什么

三、测试策略

• 先测什么后测什么和如何来测
• 明确测试的重点
• 测试类型和测试方法

1.功能测试

• 根据测试需求分析的思维导图和设计测试用例
• 通常先实现主干业务流程的测试自动化
• 列出主要的功能测试点，决定哪些测试点适合自动化，决定采用什么样的框架和技术
• 手工测试 ---- 决定采用什么类型的测试用例方法，如何准备相关测试数据
• 提供被测软件的可测试性 有可测试性的问题，需要提前考虑切实可行的变通方案

2.兼容性测试

• Web测试需要确定覆盖的浏览器类型和版本
• 移动设备需要确定覆盖的设备类型和具体的IOS/Android版本

1.如何确定这些？

• 既有产品
  大数据技术分析产品的历史数据得出Top30%的移动设备以及iOS/Android版本等信息
• 全新产品
  通过TalkingData网站查看目前主流的移动设备 分辨率大小 iOS/Android

2.实施

• 一般功能测试的后期，功能稳定
• 前段引入楼新的框架或组件库，会先在前期做兼容性评估，确保不会引入无法解决的兼容性问题

3.测试用例的选取

• 已经实现的自动化测试用例
• GUI自动化框架要能够支持同一套测试脚本运行于不同的浏览器

3.性能测试

明确性能需求（并发用户量、响应时间、失误吞吐量等），结合被测系统的特点，设计性能测试场景并确定性能测试框架

• API级别的压力测试？终端级别的基于协议压力测试？基于模块的压力测试？全链路压测？
• 如果是背景数据敏感的，确定背景数据量级与分布，并决定产生背景数据的技术方案。API并发调用？还是数据库上做批量操作？还是两者的结合？
• 都需要明确待开发的单用户脚本的数量

1. 性能测试的实施
   根据业务场景决定需要开发哪些单用户性能（思考时间、集合点、动态关联）
2. 脚本开发完成后
   以脚本为单位测试场景 百分比的用户在做什么操作 ？每个用户的操作步骤之间需要等待多少时间？并发用户的增速是什么？
3. 测试场景的执行
   性能自动化测试执行之后要做性能测试报告的解读

四、测试资源

测试资源就是需要明确“谁来测”和“在哪里测”

• 测试资源通常包括测试人员和测试环境
• 测试人员的维度有“测试工程师的数量” “测试工程师的个人经验和能力”
• 不同的项目可能使用的测试环境不同

五、测试进度

测试进度主要描述各类测试的开始时间，所需工作量，预计完成时间（以此依据建议最终产品上线发布时间）
版本接受测试的工作量，冒烟测试的工作量，自动化脚本开发的工作量，缺陷修复的验证工作量，回归测试工作量

• 传统瀑布模型 测试进度依赖提测时间，提测延期，不裁剪测试需求，上线时间延期
• 敏捷开发 测试贯穿整个开发过程，测试进度不完全依赖提测时间

六、预测风险预估

需求变更、开发延期、发现重大缺陷和人员变动是引入项目测试风险的主要原因

• 需求变更的时候要进行测试需求分析，确定变更后的测试范围和资源评估，及时沟通，不能硬抗
• 测试工作量预估不够准确，可能发现需要增加更多的测试类型
• 测试架构缺陷？全部回归测试
• 提测延期
• 人员变动

预估整个测试过程中可能存在的潜在风险，以及当这些风险发生时的应对策略（不慌）