测试计划如何编写
2018-03-27 20:42
344 查看
作为一个想成为leader(不论是整个测试部门还是小项目组的leader)的人,测试计划编写是必备技能。
言归正传,直入主题。测试计划具体包含的内容包括以下:1、概述 1.1 项目标识
1.2 目的 1.2.1 根据需求列表确认现有功能,保证软件质量1.2.2 验证软件的一致性、稳定性、兼容性、安全性、可靠性、有效性、功能性1.2.3 通过分析以前项目的测试状态,预估该项目的测试状态,确保软件测试的有效性1.2.4 分析漏测原因,提前做好解决方案,降低风险1.2.5 分析每个阶段计划的有效性并且及时更新,保证各阶段测试的质量1.2.6 根据计划,及时对文档、测试用例进行评审,保证文档的正确性和测试用例的有效性、可执行性 1.2.7 根据计划,及时对文档、测试用例进行评审,保证文档的正确性和测试用例的有效性、可执行性 1.2.8 保证测试报告的交付时间1.2.9 提前计划所需测试资源,确保测试工作的正常进行1.2.10 明确缺陷级别定义,规范提交缺陷模板,以便及时解决缺陷1.2.11 组织结构图说明每个角色的具体任务,在实际工作中起指导作用 1.2.12 针对各种测试类型的测试目的来判断测试的有效性1.3 范围[描述测试的各个阶段(例如集成测试和系统测试),并说明本计划所针对的测试类型(如功能测试或性能测试)。 简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施,则列出所有这些假设。 列出可能会影响测试设计、开发或实施的所有风险或意外事件。列出可能会影响测试设计、开发或实施的所有约束。1.4 参考资料主要参考项目总体计划、需求规格说明书 2、组织结构
3、测试资源需求测试过程中,根据项目各阶段需根据项目的情况进行资源调整。3.1 人力资源需求
3.2 办公位需求
3.3 测试环境
3.4 其它软件/系统
4、测试范围xxx项目功能列表
5、测试目标5.1 测试目标
5.2 测试类型
6、测试里程碑
7、测试进度安排
8、风险评估
9、交付物
10、缺陷级别标准描述需求阶段与客户确定的缺陷等级定义;
11、培训计划
12、相关软件在测试过程中将使用到以下软件 1 .缺陷跟踪工具管理bug并跟踪bug状态:禅道2 .用例与文档管理工具管理项目文档和需求:SVN 以上就是测试计划中包含的所有内容,如果公司没有模板的话,直接按照这个来写吧,no趴笨~
言归正传,直入主题。测试计划具体包含的内容包括以下:1、概述 1.1 项目标识
项目编号 | 项目名称 | ||
项目类别 | ■新建类 □升级类 | 合作供应商 |
人员角色 | 姓名 | 单位 | 职责 | 移动电话 | 电子邮件 | 备注 |
项目经理 | ||||||
测试经理 | ||||||
测试组组长 | ||||||
测试组成员 | ||||||
角色 | 地点 | 数量 | 所需知识技能 | 期望到位时间 | 计划释放时间 | 是否需要培训 | 备注 |
类型 | 地点 | 数量 | 期望到位时间 | 计划释放时间 | 备注 |
办公座位 | |||||
办公网络 | |||||
开发测试网络 | |||||
其它 |
测试环境类型 | 主机 | 存储 | 网络 | 外围设备 | 操作系统软件 | 数据库 | 中间件 | 系统配置参数 | 测试用业务数据 |
web服务器 | |||||||||
类型 | 型号 | 数量 | 备注 |
测试工具 | |||
缺陷跟踪工具 | |||
测试案例管理工具 | |||
浏览器 | |||
关联系统 | |||
其它 |
一级菜单 | 二级 | 三级 | 研发负责人 | 测试案例设计人 | 优先级 |
类别 | 目标 |
进度目标 | 系统测试完成日期: |
性能测试工作完成日期: | |
性能指标 | |
执行目标 | 缺陷清除率:100% |
测试用例覆盖率:100% | |
测试用例通过率:100% | |
文档质量目标 | 交付文档: 测试计划 系统测试用例 系统测试记录 系统测试报告 性能测试方案 性能测试报告 缺陷记录 |
\ |
序号 | 测试类型 | 子测试项 | 测试目的 | 是否采用 | 备注 |
1 | 功能性测试 | 根据系统需求文档和设计文档,检查产品是否正确实现了功能 | |||
3 | 用户界面 (UI) 测试 | 检查界面是否美观合理 | |||
4 | 兼容性测试 | 在不同浏览器上能正常运行 | |||
5 | 流程测试 | 按操作流程进行的测试,主要有业务流程、数据流程、逻辑流程、正反流程, 检查软件在按流程操作时 是否能够正确处理 | |||
6 | 回归测试 | 检查程序修改后有没有引起新的错误、是否能够正常工作以及能否满足系统的需求 | |||
7 | 性能测试 | 提取系统性能数据,检查系统是否 满足需求中所规定达到的性能 | |||
8 | 接口测试 | 检查系统能否与外部接口正常工作 | |||
9 | 安全性和访问控制测试 | 应用程序级别的安全性:检查用户只能访问其所属用户类型已被授权访问的那些功能或数据。 系统级别的安全性检查只有具备 系统和应用程序访问权限的用户才能访问系统和应用程序。 |
序号 | 测试阶段 | 任务描述 | 责任人 | 阶段目标 | 计划开始时间 | 计划结束时间 |
1 | 制定测试计划 | 识别需求功能,预估工作量 制定测试进度,编写测试计划 | 工作量预估完成 测试方案、测试计划编写完成 通过项目组内部评审 | |||
2 | 系统测试案例 | 测试需求分解 编写测试案例 评审测试案例 | 测试案例编写完成 通过评审 纳入配置管理 | |||
3 | 系统测试 | 验证系统软件是否与需求相符,执行业务流程通顺 | 模块集成后的系统业务流程正确 记录发现的缺陷、修改缺陷、复测缺陷 完成测试记录和测试报告 | |||
4 | 性能测试 | 验证系统集成后,软件是否符合各项性能指标 | 软件在模拟真实环境的条件下各项性能达到需求指标 测试脚本、场景的编写 记录发现的缺陷、修改缺陷、复测缺陷 完成测试记录和测试报告 | |||
5 | 业务验收测试 | 根据业务需求和《业务需求功能规格说明书》/《业务需求功能说明单》编写测试案例,测试是否实现所有功能 | 业务测试小组完成测试工作(测试案例编写、记录发现的缺陷、复测缺陷、完成测试记录和测试报告) 软件质量达到预期标准 | |||
6 | 文档编写 | 记录测试记录、完成测试报告、对测试案例进行维护 | 完成测试报告及相关文档整理,测试案例更新归档 |
开始时间: 结束时间: | |||
任务名称 | 负责人 | 开始时间 | 完成时间 |
1.制定测试计划 | |||
编写测试方案与计划 | |||
2.测试案例设计 | |||
3.集成/系统/验收测试 | |||
第一阶段测试 | |||
第二阶段测试 | |||
第三阶段测试 | |||
4.性能测试 | |||
5.文档编写 |
风险描述 | 影响程度 | 应对措施 | 责任人 |
测试目标不清晰或不够明确 | 严重 | 明确测试目标 | |
测试时间有限 | 严重 | 推迟上线或加班 | |
测试人员的不足 | 严重 | ||
代码编写的质量 | 严重 | ||
缺陷修改进度 | 严重 | ||
回归测试不充分(一般不运行全部测试用例,是有选择性的执行) | 一般 | ||
案例功能点覆盖率未达到100% | 一般 | ||
测试案例不能100%执行 | 一般 | ||
开发计划变更 | 严重 | ||
需求的变更 | 严重 |
序号 | 交付物 | 提交时间 |
1 | 测试计划 | |
2 | 测试方案 | |
3 | 系统测试记录 | |
4 | 系统测试报告 | |
5 | 性能测试用例 | |
6 | 性能测试报告 | |
7 | 缺陷 |
缺陷 级别 | 描述 |
一级 | 致命问题 |
1. 程序运行过程中不断申请,但没有完全释放资源,造成系统性能越来越低,并出现无规律的死机现象。 2. 程序运行导致系统崩溃。 3. 由程序引起的资源严重不足、非法退出等 4. 严重的关键计算错误(如计费等)。 5. 数据库发生死锁,且无法自动恢复。 6. 与需求要求差距较大。 7. 系统无响应。 | |
二级 | 严重问题 |
1. 因错误操作导致的程序中断。 2. 功能没有实现。 3. 正确操作导致的错误结果。 4. 与数据库连接错误,无法自动恢复。 5. 数据通讯错误,无法自动恢复。、 6. 数据库的表、业务规则、缺省值未加完整性等约束条件。 7. 界面中的信息不能及时刷新,不能正确反映当前数据状态,可能误导用户。(数据库中剩余记录个数和参数设置对话框中的预设值常常显示为历史值而不是当前值) 8. 对输入数据没有进行充分并且有效的有效性检查,造成不合要求的数据进入数据库。 | |
三级 | 一般问题 |
1. 操作界面错误。(包括数据窗口内列名定义、含义是否一致,界面中英文混杂,界面元素参差不齐,文字显示不全) 2. 打印内容、格式错误。 3. 删除操作未给出提示。 4. 数据库表中有过多的空字段。 5. 提示信息意文不明或为原始的英文提示。 6. 要求用户输入多余的、本来系统可以自动获取的数据。(服务是否启动,安装后用户需要手动修改某些配置文件)。 7. 辅助说明描述不清楚,有歧义。 8. 长操作未给用户提示。 | |
四级 | 改进建议 |
1. 辅助说明描述不清楚。 2. 输入输出不规范。 3. 可输入区域和只读区域没有明显的区分标志。 4. 某一项功能的冗余操作太多。如:对话框嵌套层次太多,影响用户操作。 5. 不能记忆用户的设置或操作习惯,用户每次进入系统都需要重新操作初始环境。 6. 不符合用户操作习惯。(快捷键定义不科学、不实用,键位分布不合理、按键太多,甚至没有快捷键)。 7. 界面不规范。 8. 提示窗口文字未采用行业术语。 |
序号 | 分类 | 培训内容 | 培训日期 | 培训人 | 参加人 | 备注 |
1 | 业务培训 | 详见培训计划 | ||||
2 | 技能培训 | |||||
3 | 工具培训 |
相关文章推荐
- 如何编写测试计划
- 如何编写测试计划?
- 如何编写测试计划
- 如何编写测试计划
- 如何编写测试计划
- 如何编写测试计划
- 如何编写测试计划
- 如何编写软件测试计划
- 如何编写测试计划
- 如何编写系统测试计划
- 如何编写测试计划
- 如何编写测试计划
- 如何编写测试计划
- 如何编写测试计划
- 如何为 SpringMVC 编写单元测试:普通 Controller 测试
- Robotium编写测试用例如何模拟Junit4的BeforeClass和AfterClass方法2 - SingleLaunchActivityTestCase
- 如何编写测试报告
- 如何高效编写测试用例?
- [软件测试必读] 如何制定软件测试计划
- 如何用 Robotframework 来编写优秀的测试用例