xxxxxx
xxx公司
二0xx年x月
- 1 -
文档修改记录
| 版本号 | 版本概述 | 责任人 | 日期 | 备注 |
| V1.0 | 初始编制 | xxx | 2020-5-11 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 2 -
目录
1 项目概述
1.1编写目的
指导整个项目实施的测试过程：明确测试的对象、范围、内容；能够指导完善测试结果输出。
| 编号 | 确定项目 | 描述 |
| 1 | 确定测试范围 | 确定被测项目中功能模块，子功能模块等需要测试的范围。 |
| 2 | 确定测试需求 | 确定每个功能结果定义，确定此功能是否存在缺陷。 |
| 3 | 确定测试策略 | 确定对项目做哪些测试。如：功能测试，性能测试等。 |
| 4 | 确定测试方法 | 确定对每个策略是用哪些方法。如：边界值，等价类等。 |
| 5 | 确定测试工具 | 如: 功能测试使用Seleium，性能测试使用Jmeter等。 |
| 6 | 确定测试资源 | 测试需要的设备，服务器、参与测试的人员、测试任务的分工，测试工作的进度。 |
| 7 | 确定测试交付文档 | 确定测试工作中生成哪些文档，可提交文档有哪些。 |
1.2测试项目
项目名称： 某某系统
使用背景： 什么类型的用户
开发者： xxx公司 测试版本 1.0
项目简介：
1.3测试目的
| 编号 | 目的 |
| 1 | 软件测试是为了发现错误而执行程序的过程。 |
| 2 | 测试是为了证明程序有错，而不是证明程序无错。 |
| 3 | 一个好的测试用例在于它发现至今未发现的错误。 |
| 4 | 一个成功的测试是发现了至今未发现的错误的测试。 |
1.4 术语定义
项目术语
测试专业术语
缺陷优先级
严重程度定义
用例优先级定义
1.5 文档受众
| 编号 | 人员 |
| 1 | 产品设计人员 |
| 2 | 产品研发人员 |
| 3 | 产品测试人员 |
| 4 | 备注 |
1.6 测试参考文档
| 编号 | 文档名称 | 作用 |
| 1 | 需求文档 | 确定项目功能模块，功能运行结果。 |
| 2 | 技术文档 | 确定项目中使用开发语言，数据库数据限制。 |
| 3 | 项目模型文档 | 初步了解项目页面内容，方便编写用例。 |
1.7 测试提交文档
| 编号 | 文档名称 | 作用 |
| 1 | 测试计划 | 明确说明测试范围，方法，工作周期信息。 |
| 2 | 测试用例 | 明确说明测试工作的细节测试工作。 |
| 3 | 缺陷报告 | 明确说明项目中的缺陷描述，与修复情况。 |
| 4 | 测试报告 | 明确说明测试结果，测试模块，缺陷分布情况等等信息。 |
2 测试任务
2.1 测试目标
通过测试，需要达到以下目标
- 产品能够覆盖需求说明书的所有需求
- 在网络正常的情况下，xxx可以能够持续无故障运行
- 缺陷数量在可控范围内，上线要求缺陷修复率达到95%以上
- 能够到达专项测试指标
2.2 测试对象
| 测试项 | 对象信息 | 备注 |
| 文档 | 用户使用说明书 |
|
| 产品需求说明书 |
| |
| 产品设计文档(含接口文档) |
| |
| 系统部署文档 |
| |
| 系统维护文档 |
| |
| 软件代码 | 单元模块代码 |
|
| 模块集成代码 |
| |
| 业务系统测试 |
| |
| 产品用户验收测试 |
| |
| 数据 | 数据库表字段类型及边界 |
|
| 数据传输过程安全及存储安全(加密) |
| |
| 数据完整性(逻辑删除) |
|
2.3 测试范围
| 构成 | 一级模块 | 子模块描述 | 备注 |
| 前端操作 | 入口授权 | 不同入口测试、入口跳转、授权允许与否 |
|
| 主页 | 导航、轮播图、分类、图片显示、点击跳转、上下滑动等 |
| |
| 分类 | 导航、分类、图片显示、点击跳转、上下滑动 |
| |
| 购物车 | 导航、数据显示、图片显示、编辑、复选等 |
| |
| 我的 | 导航、数据显示、图片显示、添加等 |
| |
| 后台接口 | 微信登陆 | 微信登陆身份认证的各个子模块 |
|
| 收货地址 | 微信收获地址的各个子模块 |
| |
| 下单模块 | 订单模块相关的各个子模块 |
| |
| 微信支付 | 微信支付相关的各个子模块 |
| |
| 购物车 | 购物车模块的各个子模块 |
| |
| 商品管理 | 商品管理相关各个子模块 |
|
2.4 测试准则
2.4.1 启动准则
开始接入测试
- 确保单元测试通过
- 模块之间的联调测试通过
- 确认提交的测试版本
- 冒烟测试通过
2.4.2 结束准则
结束测试：
- 确保核心测试用例执行完毕
- 确保中级以上的缺陷全部修复，且bug修复率达95%以上
- 测试由于其他原因中断无法进行，通知相关领导进行下一步确认
测试完成标准：
单元测试完成标准
- 按照单元测试计划完成了所有规定单元的测试
- 达到了测试计划中关于单元测试所规定的覆盖率的要求
- 软件单元功能与设计一致
- 在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准
集成测试完成标准
- 按照集成构件计划及增量集成策略完成了整个系统的集成测试
- 达到了测试计划中关于集成测试所规定的覆盖率的要求
- 被测试的集成工作版本每千行代码必须发现至少2个错误（不含优化级别错误）
- 集成工作版本满足设计定义的各项功能、性能要求
- 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准
功能/易用测试完成标准
- 功能测试用例设计已经通过评审
- 按照功能测试计划完成了功能测试
- 达到了功能测试计划中关于功能测试所规定的覆盖率的要求
- 系统达到详细设计定义的各项功能，性能
- 在功能测试中发现的错误已经得到修改，各级缺陷修复率达到标准
兼容测试完成标准
- 兼容测试用例设计已经通过评审
- 按照兼容测试计划完成了兼容测试
- 达到了兼容测试计划中关于兼容测试所规定的浏览器的要求
- 在兼容测试中发现的错误已经得到修改，各级缺陷修复率达到标准
系统测试完成标准
- 系统测试用例设计已经通过评审
- 按照系统测试计划完成了系统测试
- 达到了测试计划中关于系统测试所规定的覆盖率的要求
- 被测试的系统每千行代码必须发现至少1个错误（不含五级错误）
- 系统满足需求规格说明书的要求
- 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准
验收测试完成标准
- 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
- 在验收测试中发现的错误已经得到修改，各级缺陷修复率达到标准
- 所有测试项没有残余紧急、严重级别错误。
- 需求分析文档、设计文档和编码实现一致。
- 验收测试工件齐全（测试计划、测试用例、测试日志、测试通知单、测试分析）
可靠/压力/负载测试完成标准
- 性能测试用例设计已经通过评审
- 按照性能测试计划完成了性能测试
- 达到了性能测试计划中关于性能测试所规定要求
- 在性能测试中不通过的用例已经得到修改，性能达到预计标准
缺陷修复率标准
- 紧急、严重级别错误修复率应达到100%
- 普通级别错误修复率应达到95%以上
- 优化级别错误修复率应达到60%以上
注：项目紧急时，普通级别错误修复率达60%以上；优化级别错误修复率达20%即可。
覆盖率标准
- 测试用例执行覆盖率应达到100%（功能测试用例均以执行）
- 测试需求执行覆盖率应达到100%（业务测试用例均以执行）
2.5 测试环境
(1) 开发环境
开发工具：PhpStorm、微信开发者工具
硬件平台：1核CPU+1GB内存+50GB硬盘
操作系统：windows10、CentOS 7
测试环境
测试手机：手机(Android、iOS)、终端模拟器、测试PC(windows10)
服务器：CentOS 7 (云服务)
服务器配置：1核CPU+2G内存+50GB硬盘
技术框架：Linux + Apache +MySQL +PHP(LAMP)
正式环境
平台应用环境：LAMP【CentOS7.0 + Apache2.4 + MySQL5.5 + ThinkPHP5.0 】
小程序应用环境：微信公众平台小程序正式版发布
2.6.1工作量安排
| 测试阶段 | 任务 | 工作量(人/天) | 人员分配 | 预计开始时间 | 预计完成时间 | 备注 |
| 制定测试计划 | 编写测试计划与方案并评审 | 2 | 张三 | 2020.x.x | 2020.x.x | 包括沟通、编写、评审、完善等 |
| 设计测试用例 | 编写测试用例并评审 | 4 | 王五 | 2020.x.x | 2020.x.x | 包括编写、评审、完善等 |
| 测试环境准备 | 测试环境准备 | 1 | 王x | 2020.x.x | 2020.x.x | 环境测试搭建 |
| 测试实施 | 完成三轮以上功能测试 | 4 | 王X | 2020.x.x | 2020.x.x | 包括冒烟测试、分模块测试、功能测试、回归测试等 |
| 不同环境下的可靠性测试 | 4 | 王X | 2020.x.x | 2020.x.x | 包括脚本的编写、调试和执行 | |
| 完成其他专项测试 | 4 |
| 2020.x.x | 2020.x.x | 包括界面、安全性、兼容性、文档等测试 | |
| 文档编写 | 编写测试报告及总结 | 4 | 王X | 2020.x.x | 2020.x.x | 包括编写和完善 |
2.6.2测试里程碑
| 里程碑 | 预计完成时间 | 完成标准 | 备注 |
| 测试计划与方案 | 2020.x.x | 完成测试计划书的编写 | 计划的编写和完善、评审通过 |
| 测试分析 | 2020.x.x | 完成测试点的分析与提取 | 对于需求进行细化分析、达到可设计用例目的 |
| 测试用例 | 2020.x.x | 完成测试用例的编写 | 用例的编写和完善、评审通过 |
| 测试报告 | 2020.x.x | 执行测试用例，完成测试报告的编写 | 多版本的结果汇总 |
3 项目风险
3.1 风险的来源
3.1.1 产品层面
- 设计不完善
- 需求挖掘不深入
- 需求发生变更
3.1.2 开发层面
- 设计有缺陷
- 设计没有文档
- 缺陷修复不严谨
3.1.3 测试层面
- 测试环境、测试工具
- 设计测试用例有遗落
- 测试业务不熟，导致验证缺陷不完善
- 第三方账号与工具的准备
3.1.4其他层面
法律制度层面
业务层面
3.2 风险的影响
正面影响：积极引导，持续跟进
负面影响：正向转化或引导(重点关注)
3.3 风险的处理
回避
转移
减少
接受
4 测试方案
4.1 设计方法
黑盒测试的方法：
- 等价类划分法
- 边界值法
- 流程图法
- 因果图
- 判定表
- 正交表
- 错误推测法
- 状态迁移法
白盒测试的方法：
- 逻辑覆盖
- 循环覆盖
- 基本路径测试
4.2 测试工具
- 测试中使用的BUG管理工具为禅道
- 接口测试工具为Postman
- 服务器连接工具为xshell
- 数据库连接工具Navicat
- 微信开发者工具(模拟器)
4.3 测试策略
4.3.1测试总则
- 80/20原则，用最少资源发现最多的缺陷
- 同步进行一些核心节点，测试计划与方案+测试点的提取
- 设计测试用例的需要制定优先级，方便提取核心的测试用例(冒烟测试)
- 测试执行过程，对于部分用例进行同步更新与完善
- 在执行过程中，按照测试用例模板要求做好执行日记记录
- 提取测试重点任务，进行有技能经验的测试人员参与测试
4.3.2 测试细则
4.3.2.1 功能测试阶段
测试的轮次达三轮以上
明确不同环境的测试区别，提取不同的测试用例；回归验证重要缺陷时，需要确认对应缺陷的相关联业务是否受影响。
4.3.2.2 UI测试阶段
前期需要结合UI设计图进行手动测试；后期结合UI自动化的技术提升效率
4.3.2.3 性能测试阶段
4.3.2.4 可靠性测试阶段
要求前端发布上线后，在一年内不会出现重大故障
5 测试实施
5.1 单元测试阶段
验证代码本身的逻辑或者语法，主要由开发人员完成
|
| 单元测试 |
| 测试目标 | 开发者编写的一小段代码，检验被测代码的一个很小的、很明确的功能是否正确。 |
| 测试范围 | 测试整个项目中的每一行代码进行测试。 |
| 完成标准 | 代码的一个很小的、很明确的功能都正确。 |
| 需考虑的特殊事项 | // |
| 使用工具 | Java + TestNG + eclipse + 程序相关依赖Jar 包。 |
5.2 集成测试阶段
针对单个模块的组装测试，更多的是验证模块接口是否存在问题，主要由开发人员完成
|
| 集成测试 |
| 测试目标 | 开发者编写的多个段代码单元，组合到一起形成集成测试，检查多个单元组合功能是否正确。 |
| 测试范围 | 开发者编写的多个段代码单元，组合到一起形成的集合。 |
| 完成标准 | 多个单元组合功能正确。 |
| 需考虑的特殊事项 | // |
| 使用工具 | java + TestNG + eclipse + 程序相关依赖Jar 包。 |
5.3 系统测试阶段
业务产品角度，去验证产品是符合产品需求，测试人员
5.4 验收测试阶段
在用户角度，结合实际用户使用场景，进行测试验证，测试人员配合用户参与
6 测试管理
6.1 文档管理
将项目实施过程中产出的文档进行归档维护管理，一般是有git或者是SVN授权部分人员去维护
6.2 缺陷管理
根据缺陷管理工具，针对当前项目模块的所有缺陷进行分类管理，分析模块或者产品层面的质量。最终目标是发现项目过程中出现阶段的人员，资源质量，技术等，方便后期的提升和改进。
扫一扫
9628
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
