目录

• 一、没有测试计划会怎么样/li>
• 二、测试范围
• 三、测试策略
• • 1.功能测试
  • 2.兼容性测试
  • • 1.如何确定这些/li>
    • 2.实施
    • 3.测试用例的选取
  • 3.性能测试
• 四、测试资源
• 五、测试进度
• 六、预测风险预估

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

一、没有测试计划会怎么样/h1>

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

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

二、测试范围

• 测什么和不测什么

三、测试策略

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

1.功能测试

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

2.兼容性测试

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

1.如何确定这些/h3>

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

2.实施

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

3.测试用例的选取

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

3.性能测试

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

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

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

四、测试资源

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

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

五、测试进度

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

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

六、预测风险预估

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

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

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

来源：海贼王小二