软件测试之测试计划案例
文章目录前言1. 范围和目的(需求说明)1.1 需求范围和目的1.2 需求变更2. 总计划安排和负责人3. 测试方案3.1 测试重点3.2 测试策略方法3.2.1 测试类型3.2.2 测试基本策略4. 环境搭建部署及数据准备4.1 测试环境部署4.2 数据准备5. 测试用例6. 测试限制及风险评估项7. 版本验收标准前言本篇文章以某app为例(下面简称策策头条), 陈述测试计划. 我们先看下整体测
文章目录
前言
本篇文章以某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. 测试用例
- 用例覆盖
版本测试要求用例100%覆盖设计文档要求, 并且需要进行评审 - 用例执行
版本用例要求100%执行.
6. 测试限制及风险评估项
- 测试限制: 兼容性无法完全兼顾, 不能保证测试完成后, 版本能在所有手机上正常运行
- 需求测试过程中发生变更, 导致设计的修改和代码的重写, 测试时间不够, 有可能存在未覆盖的风险
- 测试环境, 与实际运行环境不完全一直, 环境差异有可能带来新的问题.
- 非百分百复现的bug未得到解决, 有可能在用户端出现问题
- 自动化回归测试只覆盖基础功能的60%, 未被覆盖的功能, 有出现bug的风险.
7. 版本验收标准
- 功能要求:
本次迭代新增需求用例完成率100% - 此版本缺陷修复率:
紧急: 严重级别错误修复率应达到100%
普通级别错误修复率应达到90%以上
优化级别修复率应达到80%以上. - 缺陷呈现收敛趋势
- 未解决的bug和延后处理bug经过产品, 研发, 测试三方评审确认.
更多推荐
所有评论(0)