以下为测试模板，蓝色字体需要用项目的实际内容替换。仅供参考，欢迎提出改进意见
文档目录
具体文档模板如下：----------------------------------------------------------------------文档编号：项目编号-CS001 版本号
【模板简要说明：在本文档中，凡蓝色粗体文本处应替换为实际内容或删除，
并修改为正常字体和颜色
Cs001 是测试计划 CS002 测试说明文档 CS003 测试报告文档】
项目名称
软件测试计划
编写：
审核：
批准：
广州南方学院软工xxxx测评中心
年 月 日
文档变更记录
| 版本号 | 变更日期 | 主要变更内容 | 变更理由 | 变更人 |
| V1.0 | 2021-XX-XX | 创建原始文档 | 创建 | XXX |
| V2.0 | 2021-XX-XX | 修改XX，完善XX部分内容 | 完善 | XXX |
|
|
|
|
|
|
|
|
|
|
|
|
1.简介
1.1系统概述
【描述系统的业务背景、系统要实现的主要目标等信息。可从需求文档中直接将系统概述拷贝过来】
示例如下：
项目编号：FM-201202-0046
项目名称：XX 系统
系统概述：
XX管理系统涉及借款业务、差旅费报销业务、业务招待费报销业务、项目合同收款业务和项目合同付款业务，可以提供各项业务的申请、领导审批、会计审核、单据打印、个人对账等功能。
禅道由青岛易软天创网络科技有限公司开发，国产开源项目管理软件。它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款专业的研发项目管理软件，完整覆盖了研发项目管理的核心流程。禅道管理思想注重实效，功能完备丰富，操作简洁高效，界面美观大方，搜索功能强大，统计报表丰富多样，软件架构合理，扩展灵活，有完善的API可以调用。
大家可参考：https://www.zentao.net/book/zentaopmshelp/40.html
1.2 编写目的
【描述文档的编写目的】
示例如下：
本文档是整个测试活动的纲领性文件，它明确系统的测试范围、测试策略、测试资源以及进度安排，为整个测试活动提供指导和依据。
1.3参考文档
【列出本文档中用到的参考文档，并简要注明作者或来源】
| 文档名称及版本 | 作者或来源 | 备注 |
| 《需求规格说明书》V1.0 | XXX |
|
| 《概要设计说明书》V1.0 | XXX |
|
| 《详细设计说明书》V1.0 | XXX |
|
1.4 术语说明
【列出本文档中用到的专门术语、定义和缩写词，并解释说明，没有的写“无”】
示例如下：
| 术语、缩写 | 解 释 |
| 黑盒测试 | 也称为功能测试，重点检查程序的功能是否满足需求规格说明书中的定义，程序是否能适当的接收输入数据而产生正确的输出信息 |
| 等价类划分法 | 把程序的输入域划分成若干的部分，然后从每个部分中选取少数代表性数据作为测试用例，每一类的代表性数据在测试中的作用等价于这一类的其他值。 |
| 边界值分析法 | 边界值分析是通过选择等价类边界的测试用例 |
| 错误推测法 | 错误推测方法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例 |
| 场景法 | 通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景是指模拟特定场景和条件边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题 |
| 缺陷修复率 | 对应类型修复的缺陷数/对应类型的缺陷总数*100% |
| 回归测试 | 首先验证那些已修改的问题，再继续执行系统测试用例，验证基本功能和流程控制是否正确，是否引入产生了新的缺陷。 |
2.测试资源
2.1软硬件环境
【描述测试环境的各种配置情况，若测试过程中需要完成不同类型的测试工作，对于每一种类型的测试工作，需要分别对测试环境进行描述，有特殊的要求时，需详细说明】
示例如下：
| 类别 | 测试环境要求 | |
| 客户端 | 软件环境 | 操作系统：Window 2000 Professional （SP2） 浏览器：IE6、chrome 90.0（按照需求中指出产品支持的浏览器及版本进行测试，不支持的就不要测试了，版本过多时，可根据各浏览器的市场占有率选择较多人使用的版本进行测试） |
| 硬件环境 | CPU：Intel(R) Celeron(R) CPU 2.40GHz stepping 01 内存：16G | |
| 网络环境 | 1G LAN | |
| Web应用服务器端 | 软件环境 | 操作系统：CentOS 4.2 |
| 硬件环境 | CPU：Intel(R) Celeron(R) CPU 2.40GHz stepping 01 内存：16G | |
| 网络环境 | 1G LAN | |
| 数据库服务器端 | 软件环境 | 操作系统：CentOS 4.2 数据库：MySQL 5.0.17 |
| 硬件环境 | CPU：Intel(R) Celeron(R) CPU 2.40GHz stepping 01 内存：16G | |
| 网络环境 | 1G LAN | |
2.2 测试工具
（可根据实际的网络拓扑环境裁减展现）
| 测试工具 | 测试用途 |
| 禅道9.0.1 开源版 | 测试用例的设计、管理 |
| Jmeter 2.13 | 性能测试工具 |
| APP scan | 安全扫描工具 |
|
|
|
2.3 测试人员
示例如下：
| 人员 | 职责 |
| 张三 | 测试计划编制、xx功能的测试用例设计、测试报告的编制 |
| 李四 | 报表上报、监控功能的测试用例设计和执行 |
| Xxx | 测试用例的执行 |
3 测试策略
【描述测试策略，如测试环境的各种配置情况，若测试过程中需要完成不同类型的测试工作，对于每一种类型的测试工作，需要分别对测试环境进行描述，有特殊的要求时，需详细说明】
例如：
软件整体测试策略如下：
- 需求文档编制完成后，对需求文档进行测试，以尽早发现需求缺陷；
- 本测试采用系统测试，测试用例覆盖需求规格中的功能、非功能需求。
- 系统测试的测试类型包括：文档测试、功能测试（手动+自动化）、界面测试、性能测试、接口测试、安全测试。使用黑盒测试技术，
依据xx需求文档等设计测试用例，用例设计方法包括等价类、边界值、错误猜测法、正交表法、因果图法（设计用例用到的方法，没有用到的就不要写了）等、
- 采用手功+自动化测试完成功能测试；自动化测试采用selenium webdriver完成测试（selenium IDE也可以，但是推荐使用selenium webdriver）。
利用有效的和无效的数据来执行各个用例，以核实以下内容：
在使用有效数据时工作流通畅并得到期望结果；
在使用无效数据时显示相应的错误消息或警告消息；
- 进行兼容性测试，测试系统在支持的各浏览器上界面、功能是否正确。
- 依据接口规范文档，使用测试工具Jmeter完成接口测试；测试时采用输入、输出等价类划分方法，对各种参数情况进行测试。
- 使用测试工具Jmeter完成性能测试；性能测试在系统功能测试基本完成后进行。
- 使用appSCAN进行安全扫描测试。
4.测试方法
提示：此次测试主要进行功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。针对 Web 系统的常用测试采用如下方法：
- 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
- 确认功能是否正确：如 增加、修改、删除在确定、取消时是否正确处理。
- 必填字段检查：必填字段未输入就保存时，检查系统是否给出正确提示。
- 字符串长度检查：输入内容的长度超出需求规格说明中给定长度范围时，看系统是否正确给出错误信息。
- 字符类型检查：在应该输入指定类型的内容的地方输入其他类型的内容 (如在应该输入整型的地方输入其他字符类型)，看系统是否检查字符类型，会否报错。
- 特殊符号检查：输入内容包括各种特殊符号，特别是空格、各种引号（单引号、双引号）、回车键。看系统处理是否正确。
- 中文字符处理：在可以输入中文的系统输入中文，看会否出现乱码或出错。 检查信息是否能正确保存和显示。
- 信息重复：对有唯一性要求的信息进行重复性测试。例如，员工ID不允许重复，测试时添加重复员工ID，看系统是否会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。
- 检查删除功能：测试可一次删除多条记录的功能时，需要测试不选择记录、选择一条、选择多条记录等情况下。删除功能的处理是否正确。
- 提示信息检查：
删除确认后必须提示用户删除完成；
其他操作有错误时，也必须提示用户，方便用户及时了解情况；
长时间操作必须有进度条指示用户，否则用户可能以为系统卡死。
- 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。 例如，某课程已经被学生选修，删除该课程时，是否允许，如果允许，选修记录会不会有问题。
4.1 测试进入准则
【描述系统测试进入的的条件】
例如：
满足以下条件时，允许进入测试。
- 1.测试代码已经提交配置库；
- 2.开发自测通过；
- 3.测试用例已经通过评审；
- 4.测试环境已经准备就绪。
- 5.冒烟测试通过。
4.2 测试通过准则
【描述系统测试通过的的条件】
例如：
满足以下全部条件时，测试予以通过：
- 全部功能完成测试;
- 在系统测试中发现的一级、二级、三级错误已经得到全部修改并且通过了回归测试.
4.3 测试终止条件
【描述系统测试终止的条件】
例如：
满足以下条件之一时，终止测试。
- 基本功能未实现；
- 产品出现遇重大的改动，如和原设计完全不同的情况。
待条件满足重启测试前需提交相关的通知及说明文件
5.测试范围及测试点
【描述系统测试的范围，哪些功能要测试，哪些不在测试范围内。针对测试范围内的功能，列出测试点】
本次测试需要完成对XXX系统的xxx、xxx、xxx功能的测试，xxx不在测试范围内。
| 功能模块 | 子功能 | 界面测试 | 功能测试 | 边界值测试 | 性能测试 | 接口测试 | 安全测试 | 兼容性测试测试 | 说明 |
| 用户管理 | 用户添加 | 1 | 1 | 1 |
| 1 |
| 1 |
|
| 用户修改 | 1 | 1 | 1 |
| 1 |
| 1 |
| |
| 用户删除 | 1 | 1 | 1 |
| 1 |
| 1 |
| |
| 用户查询 | 1 | 1 | 1 |
| 1 |
| 1 |
| |
| 登录 | 登录 | 1 | 1 | 1 |
1 | 1 | 1 | 1 |
|
| 退出 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| |
| 数据上报 |
| 1 |
1 | 1 | 1 |
|
| 1 |
|
| 数据统计分析 |
| 1 | 1 | 1 | 1 |
|
| 1 |
|
表各功能的主要测试点如下。
5.1文档测试
对需求规格说明进行文档测试，从完整性、一致性、准确性进行测试。
按照<需求文档检查表>完成需求文档的测试。
5.2 用户管理功能
【描述功能对应的需求章节、需要覆盖的主要测试点】
追踪需求章节：3.2.3 用户管理
5.2.1用户添加功能；
- 检查界面布局是否美观，是否符合用户使用习惯；
- 检查界面是否有别字。
- 检查界面风格是否与系统保持一致。
2.功能测试
- 测试所有字段输入正确信息后，信息能否正确保存。
- 测试是否正确进行了必填字段检查
- 测试各字段中特殊字符、中文时，系统是否给出正确处理；
- 测试输入数据类型错误时，系统是否给出错误提示；
- 测试添加的账号已经存在时，是否给出错误信息。
3.边界测试
- 姓名的长度范围为[1,20]，测试字符串长度在边界外、边界内、边界上时，处理是否正确、
- 密码长度范围为[1,8],测试字符串长度在边界外、边界内、边界上时，处理是否正确、
- 一页有10条记录，当系统有9条、10条、11条记录时，添加一条记录，记录能否正确显示。
5.2.2用户修改功能；
1.界面测试
- 检查界面布局是否美观，是否符合用户使用习惯；
- 检查界面是否有别字。
- 检查界面风格是否与系统保持一致。
2.功能测试
- 测试选中用户信息修改时，窗口显示的用户信息是否正确；
- 测试不修改直接保存时，能否正确保存；
- 测试修改所有字段为有效信息保存时，能够正确保存；
- 测试修改账号为已经存在的账号时，是否给出错误提示；
- 测试必填字段不完整、输入信息非法，保存修改时是否给出错误提示；
3.边界测试
- 测试修改第一条、中间一条、最后一条记录是否正确；
- 当用户信息有多页时，测试修改第二页、最后一页上的用户可否正确显示和保存。
5.2.3用户删除功能；
1.界面测试
- 检查界面布局是否美观，是否符合用户使用习惯；
- 检查界面是否有别字。
- 检查界面风格是否与系统保持一致。
2.功能测试
- 测试删除时，是否会弹出确认提示。根据用户的选项删除或者取消删除；
- 测试不选中、选中3条记录时，能否正确删除。
- 测试删除用户时，该用户相关的记录信息是否正确。例如测试员删除后，他创建的缺陷是否仍能显示他的姓名。
3.边界测试
- 删除删除第一条、中间一条、最后一条记录时，能否正确删除；
- 测试删除第一页、中间一页、最后一页的记录时能否删除掉。
5.2.4用户查询功能；
1.界面测试
- 检查界面布局是否美观，是否符合用户使用习惯；
- 检查界面是否有别字。
- 检查界面风格是否与系统保持一致。
2.功能测试
- 不输入条件直接查询，是否查询到所有记录；
- 验证是否是模糊查询。姓名中输入“张”，是否查询到所有包含“张”的用户；
- 同时设置多个查询条件，能否正确查询到信息；
- 查询条件中输入特殊字符时，系统处理结果是否正确；
5.3 数据上报功能
【描述功能对应的需求章节、需要覆盖的主要测试点】
追踪需求章节：3.2.1 数据上报
1.界面测试
- 检查界面布局是否美观，是否符合用户使用习惯；
- 检查界面是否有别字。
- 检查界面风格是否与系统保持一致。
2.功能测试
- 对三种报文的各个字段各种错误情况进行测试，确认系统能给出预期错误提示；
- 对ods到dw的数据进行比对，确保数据完整、准确的拷贝到dw。
5.4 兼容性测试
【描述功能对应的需求章节、需要覆盖的主要测试点】
追踪需求章节：4.1 非功能性需求
测试系统在IE11.0,、chrome 90下界面是否正常，功能是否正确。
5.5 安全性测试
【描述功能对应的需求章节、需要覆盖的主要测试点】
追踪需求章节：4.1 非功能性需求
使用Appscan扫描，验证系统是否有。
6.测试进度安排
| 工作内容 | 负责人/参与人 | 开始时间 | 结束时间 | 工期（人.天） | |
| 熟悉系统 | 张三、李四 | XXXX-XX-XX | XXXX-XX-XX | XX | |
| 测试计划编制 | XXX xxx | XXXX-XX-XX | XXXX-XX-XX | XX | |
| 测试用例设计、测试数据准备、测试脚本准备 | XXX、XXX | XXXX-XX-XX | XXXX-XX-XX | XX | |
| 编制测试说明文档 | XXX、XXX | XXXX-XX-XX | XXXX-XX-XX | XX | |
| 测试执行 | XXX、XXX | XXXX-XX-XX | XXXX-XX-XX | XX | |
| 回归测试 | XXX/、XX | XXXX-XX-XX | XXXX-XX-XX | XX | |
| 测试报告编制 | XXX | XXXX-XX-XX | XXXX-XX-XX | XX |
| 风险 | 应对措施 | |
| 需求不明确 | 将问题在禅道里指派给需求人员，并通知需求人员，请他们确认需求，并要求其在禅道中回复解决办法。若有需求修改及时补充需求，并更新到SVN。 | |
| 需求变化 |
| |
| 基本功能不正常 | 如果影响流程，终止测试； | |
| 测试时间不足 (如bug太多） |
|
附件1 缺陷优先级和严重程度
缺陷优先级
表3 缺陷的优先级
| 优先级 | 描述 |
| P1 | 严重级别比较高的，影响测试进行或者系统无法继续操作，立即修复，1天。 |
| P2 | 基本功能没有实现，对系统操作有影响，2－3天。 |
| P3 | 一般性功能，页面缺陷，4－5天。 |
| P4 | 准备在下一轮测试前修改完毕，准备在下一版本中修改。 |
严重程度定义
表5 陷的优先级
| 优先级 | 描述 |
| S1 | 致命: 系统任何一个主要功能完全丧失,用户数据受到破坏,系统崩溃、悬挂、死机、或... |
| S2 | 严重: 系统的主要功能部分丧失,数据不能保存,系统的次要功能完全丧失,... |
| S3 | 一般: 系统的次要功能没有完全实现。如:新增时主要信息已保存但次要信息未保存等。 |
| S4 | 较小: 使用户操作不方便或感到麻烦,但不影响正常功能的执行。如: 错别字、文字重... |
| S5 | 建议: 建议级别的缺陷,如不易使用、操作习惯不符合常规等。 END |
附件2 需求与测试项间的追踪关系
附表1 需求和测试项间的追踪关系
| 序号 | 需求章节 | 测试项名称 |
| 1 | 2.1 用户管理 小节 | 用户添加-界面测试/CT-ZHMRYUI |
| 2 | 用户添加-功能测试/CT-ZHMRYGN | |
| 3 | 用户添加-边界测试/CT-ZHMRYBJ | |
|
|
| 用户修改-界面测试/CT-YHXGUI |
|
|
| 用户修改-功能测试/CT-YHXGGN |
|
|
| 用户修改-边界测试/CT-YHXGBJ |
| 4 | 3.2 非功能性需求 | 兼容性测试/CT-JRXCS |
| 7 | 安全测试/CT-AQCS |
扫一扫
1436
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
