软件测试之测试计划案例

---

前言

本篇文章以某app为例(下面简称策策头条), 陈述测试计划. 我们先看下整体测试计划的目录.

如下进行各个部分内容展开, 本篇是先展示某个测试计划, 后续文章中则详细介绍如何编写测试计划.

1. 范围和目的(需求说明)

1.1 需求范围和目的

策策头条V1.2在V1.1版本基础上新增如下三个功能模块:
文章详情页–文章评论, 点赞及喜欢
我的–个人信息也–编辑上传个人头像
我的–实名认证

具体需求内容详见<<策策头条前台产品原型图>>

1.2 需求变更

无

2. 总计划安排和负责人

策策头条V1.2版本, 计划为20xx.12.01开始, 到20xx.12.18结束, 版本周期时长xx天, 测试人员2名, 具体进度安排如下:

注:

• 预估人日, 指的是需要一天需要几个人才能完成这个工作, 以编号3位例, 人/日=4,代表一天需要4个人完成该工作; 那么测试人员有2名, 则2天就能完成编号3的工作, 以此类推4名测试人员, 1天就能完成该工作.
• 测试报告由项目组长或者测试主管负责定制.

3. 测试方案

3.1 测试重点

涉及系统: Android, IOS
覆盖范围: 本次版本全部新增需求
测试重点:

• 1)业务功能: 所有需求覆盖内容
• 2)兼容性:
  机型:iPhone7, iPhone8, 小米6, 华为p20, OPPOr17, 魅族6S
  系统版本: 安卓: 4.4, 5.0, 6.0. IOS: 9.0-12.0;

3.2 测试策略方法

3.2.1 测试类型

3.2.2 测试基本策略

• 1)轮次安排
  此版本迭代的功能模式数量较少, 内容如下:
  测试环境: 冒烟测试

  • 第一轮为全覆盖测试, 要求全部新增测试用例全部执行
  • 第二轮为交叉测试, 要求交叉执行全部新增测试用例, 同时保证严重等级为一般以上的bug全部得到处理
  • 第三轮为随机测试, 探索测试, 兼容性测试及自动化回归, 重点关注前两轮测试出现问题的功能, 新功能稳定后, 运行自动化测试脚本对基础功能进行回归验证.

  生成环境: 新功能测试用例执行和基础功能的回归

• 2)测试方法
  功能测试: 可以使用等价类划分, 边界值等黑盒测试方法
  兼容性测试: 根据实际情况选取主流版本机型, 考虑从分辨率, 网络等情况考虑
  自动化测试: 项目中的基础稳定功能模块使用appium开发脚本进行测试.

4. 环境搭建部署及数据准备

4.1 测试环境部署

开发是什么环境就部署什么环境就行了.

4.2 数据准备

自动化测试数据: 每个栏目准备300条数据, 创建20个用户.

5. 测试用例

1. 用例覆盖
   版本测试要求用例100%覆盖设计文档要求, 并且需要进行评审
2. 用例执行
   版本用例要求100%执行.

6. 测试限制及风险评估项

• 测试限制: 兼容性无法完全兼顾, 不能保证测试完成后, 版本能在所有手机上正常运行
• 需求测试过程中发生变更, 导致设计的修改和代码的重写, 测试时间不够, 有可能存在未覆盖的风险
• 测试环境, 与实际运行环境不完全一直, 环境差异有可能带来新的问题.
• 非百分百复现的bug未得到解决, 有可能在用户端出现问题
• 自动化回归测试只覆盖基础功能的60%, 未被覆盖的功能, 有出现bug的风险.

7. 版本验收标准

1. 功能要求:
   本次迭代新增需求用例完成率100%
2. 此版本缺陷修复率:
   紧急: 严重级别错误修复率应达到100%
   普通级别错误修复率应达到90%以上
   优化级别修复率应达到80%以上.
3. 缺陷呈现收敛趋势
4. 未解决的bug和延后处理bug经过产品, 研发, 测试三方评审确认.