测试计划
1.1 目的
简述本计划的目的,旨在说明各种测试阶段任务、人员分配和时间安排、工作规范等 ,提出对各项任务的评估、风险分析和需求管理 。
测试计划是组织管理层面的文件,从组织管理的角度对一次测试活动进行规划 。测试计划包含足够的信息使测试人员明白项目需要做什么以及如何运作测试。另外,清晰的文档结构能使任何一个 读者在浏览计划的前面几页后,就能对项目有一个大概的认识。
1.2 名词解释
列出本计划中使用的专用术语及其定义
列出本计划中使用的全部缩略语全称及其定义
缩写词或术语 | 英文解释 | 中文解释 |
|
|
|
|
|
|
1.3 参考资料
列出本计划各处参考的经过核准 的全部文档和主要文献。
1.4 测试摘要
这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员(比如经理或开发项目的负责人)。
列出测试的重点事项。可以将问题按重要程度和优先级罗列出来,然后在后面的章节中再对这些问题进行详细说明,这样就能让对这些问题有重要影响的人员知道问题的所在
简要说明争议事项。
通过对技术文档的阅读,对被测系统可能存在的问题:系统设计,数据库设计,响应时间,计费策略,因测试环境不足可能存在的测试缺陷事先评估出来,以指导测试方案,进行有重点的测试.
简要说明测试开始时间与发布时间。
简要说明测试发布的质量目标:
测试计划中所有测试方法和模块已经执行通过;所有的测试案例已经执行过;所有的重要等级为 1/2 的 Bug 已经解决并由测试验证
第 2 章 项目背景
2.1 测试范围
说明本计划涵盖的测试范围,比如功能测试、集成测试、系统测试、验收测试等。通常说明什么是要测试的,什么是不要测试的是非常重要的。明确规定这些问题后,测试人员对该做什么有一个清晰的认识。
( 1 )简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。
( 2 )如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施,则列出所有这些假设。
( 3 )列出可能会影响测试设计、开发或实施的所有风险或意外事件。
( 4 )列出可能会影响测试设计、开发或实施的所有约束。
提示和技巧:
需要测试和特别注意测试那些部分?
测试是否专门针对与某些问题的解决 ?
哪些部分不需要测试,为什么?
哪些部分需要推迟测试 , 为什么 ?
是否要验证每个模块的稳定性?
测试的优先级和先后顺序
2.2 测试目标
系统目标对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通,以取得相关资料。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后,要确保所有的测试人员都知道项目和系统的目标。
通常情况下项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标,你将无法完成部分任务。而且,你会发现很难将对产品的认识向别人转述。
2.3 联系方式
列出项目参与人员的职务、姓名、 E-mail 和电话。
职务 | 姓名 | | 电话 |
开发工程师 |
|
|
|
CVS Builder |
|
|
|
开发经理 |
|
|
|
测试负责人 |
|
|
|
测试人员 |
|
|
|
2.4 风险及约束
列出测试过程中可能存在的一些风险和制约因素,并给出规避方案。如:
Ä 由于客观存在的设备、网络等资源原因,使得测试不全面。明确说明哪些资源欠缺,产生什么约束
Ä 由于研发模式为现场定制,且上线时间压力大,使得测试不充分。明确说明在此中约束下,测试如何应对
Ä 只针对专门的客户群需求的测试。明确说明此约束下的客户群和业务范围。
2.5 测试文档
列出测试过程中可能用到的参考文档、相关的设计文档以及保存位置,测试完成后应产生的文档。
文档说明 | 作者 | 文档位置( CVS ) |
需求文档 |
|
|
总体设计 |
|
|
白皮书 |
|
|
使用手册 |
|
|
管理手册 |
|
|
测试文档 |
|
|
API 文档 |
|
|
|
|
|
文档说明 | 作者 | 文档位置( CVS ) |
《总体测试计划》 |
|
|
《总体测试方案》(可根据项目情况进行裁剪) |
|
|
测试用例 |
|
|
《性能测试方案(报告)》 |
|
|
《测试报告》 |
|
|
《 Readme 》 |
|
|
《产品操作手册 ( 后台 ) 》 |
|
|
《产品操作手册 ( 前台 ) 》 |
|
|
《产品安装维护手册》 |
|
|
《产品错误代码说明文档》 |
|
|
第 3 章质量目标
描述本阶段测试目标和要求。质量目标应该包括产品的质量目标和测试小组的质量目标。
质 量不仅是衡量系统的功能或性能是否正常。对系统来说,在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具,应 该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例如,系统是否能够正式发行?在代码完成后,应该修复那些缺陷?在 系统完成后那种类型的测试是最合适的?
3.1 产品质量目标
可以是产品的质量达到什么样的目标,产品的流程联通性达到什么样的要求。
测试质量目标 | 确认者(如需说明) |
测试已实现的产品是否达到设计的要求,包括:各个功能点是否以实现,业务流程是否正确 |
|
产品规定的操作和运行稳定 |
|
3.2 测试质量目标
评价测试质量的目标可以有:
测试质量目标 | 确认者(如需说明) |
所有的测试案例已经执行过 |
|
所有的自动测试脚本已经执行通过 |
|
所有的重要等级为 1/2 的 Bug 已经解决并由测试验证 |
|
每一部分的测试已经被 Test Lead 确认完成 |
|
重要的功能不允许有等级为 1/2/3 的 Bug |
|
一般的功能或与最终使用者不直接联系的功能不允许有等级为 1/2 的 bug, 且 bug 等级为 3 的问题不得超过 1/ 功能 |
|
轻量的功能允许有少量 2/3 等级的错误 |
|
发现错误等级为 1/2/3 的 Bug 的速率正在下降并接近 0 |
|
在最后的三天内没有发现错误等级为 1/2/3 类的 Bug |
|
通过标准:系统测试覆盖了所有测试需求, 1 、 2 、 3 级用例全部执行并通过。
失败标准:基本功能测试出现致命问题,导致后续用例无法执行;
版本质量太差, 25 %的用例执行失败;
挂起标准:测试过程中发生致命问题,导致 50 %用例堵塞无法执行;
测试环境出现故障,导致测试无法执行;
其他突发事件,如需要优先测试其它产品;
恢复条件:等待上述问题解决并通过预测试项
第 4 章 资源需求
4.1 培训资料
培训需求 | 培训内容 | 培训人员 | 开始时间 | 完成时间 |
业务流程 |
|
|
|
|
安装配置 |
|
|
|
|
工具使用 |
|
|
|
|
4.2 测试环境
描述建立测试环境所需要的设备、用途及软件部署计划。
“ 机型(配置) ”:此处说明所需设备的机型要求以及内存、 CPU 、硬盘大小的最低要求。
“ 用途及特殊说明 ”:此设备的用途,如数据库服务器, Web 服务器,后台开发等;如有特殊约束,如开放外部端口,封闭某端口,进行性能测试等,也写在此列;
“ 软件及版本 ”:详细说明每台设备上部署的自开发和第三方软件的名称和版本号,以便系统管理员按照此计划分配测试资源;
“ 预计空间 ”:说明第三方软件和应用程序的预计空间;
“ 环境约束说明 ”:建立此环境时的特殊约束。如需要开发外部访问端口,需要进行性能测试等。
硬件环境:
终端类别 | 机器名 | 设备编号 | 配置说明 |
服务器端 | 联想开天 4600 | PC-N0001 | P4/1.8G 128M RAM 20G |
客户端 | HP P7374AVL430 | PC-N0002 | P4/1.8G 128M RAM 20G |
联想开天4500 | PC-N0003 | P4/1.8G 256M RAM |
平台 1 : SUN | |||||
机型(配置) | IP 地址 | 操作系统 | 用途及特殊说明 | 软件及版本 | 预计空间 |
SUN450 | 10.1.1 .1 |
|
| Oracle8.1.2 | 2G |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
平台 2 : IBM | |||||
机型 | IP 地址 | 操作系统 | 用途 | 第三方软件及版本 | 预计空间 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
软件环境:
终端类别 | 操作系统 | 相关应用软件 |
服务器端 | Windows 2000 Server | OfficeXP ,Oracle 9i |
客户端 | Linux 2.0 | Redoffice 1.2.5 |
软件需求 | 用途 |
|
|
网络类型 | 带宽 | 设备 | 数量 |
以太网 | 全/ 半双工 1000M /100M/10M | CISCO CATALYST 6500 系列交换机 CISCO CATALYST 3500 系列交换机 |
|
DDN | 2M |
|
|
ISDN | 64K/128K |
|
|
ADSL | 512K/2M |
|
|
设备名称 | 规格型号 | 数量 | 备注 |
摄像头 |
|
|
|
耳机 |
|
|
|
秒表 |
|
|
|
4.3 测试工具
此项目将列出测试使用的工具以及用途:
测试工具 | 用途 |
自动测试工具 |
|
与测试相关的岗位和人员定义,以及他们的职责
角色 | 人员 | 职责 |
项目经理 |
| 评 审并批准项目计划及有关报告; 组织并确保团队工作; 控制项目执行; 评估项目绩效; 与有关人员进行沟通。 |
测试组长 |
| 项目计划编制; 协调并实施项目计划中确定的活动; 识别测试环境需求; 负责设计测试用例; 为其他人员提供技术支持 。 |
测试人员 |
| 执行测试活动; 在项目计划制订阶段,识别项目活动 , 估计每项活动所需的时间。 |
环境准备 人员 |
| 提供资源保障; 建立并维护测试环境。 |
质量保证 人员 |
| 确定项目质量目标; 制订并实施质量计划; 监督、指导项目活动的执行过程。 |
4.5 测试启动条件
测试计划、测试流程、测试进度的制订已完成,并经过严格评审;
缺陷跟踪与管理系统已搭建;
测试所需的资源已经到位;
测试组人员配置合理,测试人员的工作技能符合测试要求;
测试所需的软、硬件和操作系统等测试环境准备完毕。
第 5 章 测试策略
5.1 整体测试策略
本节的目的是说明计划中使用的基本的测试过程。
使用里程碑技术在测试过程中验证每个模块,测试人员在需求阶段参与测试工作,进行需求 review 、设计 review 、测试案例设计和测试开发,在系统开发完成之后,正式执行测试。产品达到软件产品质量要求和测试要求后发布,并提交相关的测试文档。
5.2 开始 / 中断 / 完成标准
说明中断 / 开始 / 完成测试的标准。
开始 / 中断 / 完成测试 | 标准说明 |
开始测试标准 | 硬件环境可用且软件正确安装完成 |
中断测试标准 | 安装无法正确完成或程序的文档有相当多的失误或系统服务异常或发现 Block Bug |
完成测试标准 | 完成测试计划中的测试规划并达到程序和测试质量目标 , 并由 Test Lead/R&D Manager 确认 |
5.3 测试类型
测试类型 | 是否采用 | 说明 |
功能测试 | 采用 | 根据系统需求文档和设计文档,检查产品是否正确实现了功能。 |
流程测试 | 采用 | 按操作流程进行的测试,主要有业务流程、数据流程、逻辑流程、正反流程,检查软件在按流程操作时是否能够正确处理 |
边界值测试 | 采用 | 选择边界数据进行测试,确保系统功能正常,程序无异常。 |
容错性测试 | 采用 | 检查系统的容错能力,错误的数据输入不会对功能和系统产生非正常的影响,且程序对错误的输入有正确的提示信息 |
异常测试 | 采用 | 检查系统能否处理异常 |
启动停止测试 | 采用 | 检查每个模块能否正常启动停止、异常停止后能否正常启动 |
安装测试 | 采用 | 检查系统能否正确安装、配置 |
易用性测试 | 采用 | 检查系统是否易用友好 |
界面测试 | 采用 | 检查界面是否美观合理 |
接口测试 | 采用 | 检查系统能否与外部接口正常工作 |
配置测试 | 采用 | 检查配置是否合理、配置是否正常 |
安全性和访问控制测试 | 采用 | 应用程序级别的安全性:检查 Actor 只能访问其所属用户类型已被授权访问的那些功能或数据。 系统级别的安全性:检查只有具备系统和应用程序访问权限的 Actor 才能访问系统和应用程序。 |
性能测试 | 采用 | 提取系统性能数据,检查系统是否满足在需求中所规定达到的性能。 |
压力测试 | 采用 | 检查系统能否承受大压力,测试产品应该能够在高强度条件下正常运行,不会出现任何错误。 |
兼容性测试 | 采用 | 对于 C/S 架构的系统来说,需要考虑客户端支持的系统平台。 对于 B/S 架构的系统来说需要考虑用户端浏览器的版本。 |
割接/ 升级测试 | 采用 | 进行专门的割接测试或升级测试,提供工程升级割接方案 |
文挡测试 | 采用 | 检查文档是否足够、描述是否合理 |
回归测试 | 采用 | 检查程序修改后有没有引起新的错误、是否能够正常工作以及能否满足系统的需求 |
5.4 测试内容
表 1 用户文档 | 第 1页 | 共 1页 | |
测试需求 | 测试过程说明 | 过程 标 引 | |
完整性 | 软件使用所需信息 | UD-01 | |
产品描述中说明的所有功能 | UD-02 | ||
程序中 用户可调用的所有功能 | UD-03 | ||
说明产品描述中给出的所有边界值 | UD-04 | ||
软件安装所需要的信息 | UD-05 | ||
软件维护所需要的信息 | UD-06 | ||
正确性 | 文档中所有信息正确,没有歧义和错误的 表达 | UD-07 | |
一致性 | 文档自身 内容或相互 之间 以及 与产品描述之间,相互不矛盾,且术语一致 | UD-08 | |
用户手册和操作手册与软件实际运行情况相符 | UD-09 | ||
易理解程度 | 文档对正常使用其产品的一般用户是容易理解的 | UD-10 | |
易浏览程度 | 用户文档易于浏览,相互关系明确 | UD-11 | |
用户文档有目录表或索引表 | UD-12 | ||
在线帮助 | 在线帮助应详细、准确、快速、直观、易懂 | UD-13 | |
能根据帮助点直接定位查询内容 | UD-14 | ||
内容不少于用户手册和操作手册的内容 | UD-15 | ||
表 2.1 安装与卸载 | 第 1页 | 共 1页 | |
测试需求 | 测试过程说明 | 过程 标 引 | |
安装 | 典型安装 | F-01 | |
完全安装 | F-02 | ||
卸载 | 提供图像化的卸载方法 | F-03 | |
表 2.2 功能表现 | 第 1页 | 共 1页 | |
测试需求 | 测试过程说明 | 过程 标 引 | |
功能点 | 根据用户文档列出所有功能点,检验其正确性 | F-04 | |
验证程序与产品描述、用户文档中的全部说明相对应,一致性 | F-05 | ||
表 3 可靠性 | 第 1页 | 共 1页 | |
测试需求 | 测试过程说明 | 过程 标 引 | |
成熟性 | 使用的容量达到规定的极限时 , 系统不崩溃、不异常退出也不丢失数据 | R-01 | |
试图使用的容量超出规定极限时,系统不崩溃、不异常退出也不丢失数据 | R-02 | ||
产品描述中列出的其他程序或用户造成的错误输入时,系统不崩溃也不丢失数据 | R-03 | ||
输入用户文档中明确规定的非法指令时,系统不崩溃也不丢失数据 | R-04 | ||
不会因掉电、异常退出、网络异常中断等原因而使软件或数据遭到破坏 | R-05 | ||
容错性 | 能屏蔽用户的误操作 | R-06 | |
对错误有正确提示 | R-07 | ||
输入错误数据时,系统不崩溃、不异常退出也不丢失数据 | R-08 | ||
有错误操作时,系统不崩溃、不异常退出也不丢失数据 | R-09 | ||
易恢复性 | 系统运行失效后,应能较快重建系统 | R-10 | |
数据校验机制 | 应对数据项之间的逻辑关系进行校验,保证数据的有效性 | R-11 | |
应保证 数据 的 完整性 和 一致性 , 不会因删除或反复的更新而被破坏或留下垃圾数据 | R-12 | ||
对不符合要求的输入数据 ,系统 应使用中文给出简洁、准确的提示信息 , 必要时应给出帮助 | R-13 | ||
5.4.4 易用性
表 4 易用性 | 第 1页 | 共 1页 | |
测试需求 | 测试过程说明 | 过程 标 引 | |
易理解性 | 通过 选择 适当的术语、图形 表示 、背景信息和帮助,帮助用户理解、使用 | U-01 | |
出错消息中提供差错产生的原因和纠正的详细信息 | U-02 | ||
易浏览性 | 数据媒体具有产品标识,可辨别编号 或 文本 | U-03 | |
具有必要的信息,指导用户使用程序 | U-04 | ||
输入、输出设计规矩,输出结果应简洁、直观、美观、方便阅读、易懂和使用 | U-05 | ||
人机界面简洁、美观、实用,风格相对一致,符合办公习惯 | U-06 | ||
在界面、人机交互、输出中的用语应与业务用语一致 | U-07 | ||
易 操作性 | 具有严重后果的功能执行可逆,或者给出明显警告,执行前要求确认 | U-08 | |
软件操作简便,系统支持标准的鼠标、键盘操作,支持鼠标的单击、双击和右键操作,支持快捷键操作 | U-09 | ||
提供辅助输入手段(如选择输入、默认值等),数据检索方便、灵活 | U-10 | ||
安装参数应当给出默认值或提示,需要用户干预的地方应尽量少,操作方便 | U-11 | ||
根据用户熟练程度(外行、初学、熟练)和使用频度,能提供不同的操作方式或用户界面 | U-12 | ||
表 5 可维护性 | 第 1页 | 共 1页 | |
测试需求 | 测试过程说明 | 过程 标 引 | |
易分析性 | 系统可以正确判断缺陷或失效原因 | M-01 | |
对于软件运行错误,应当提示清晰,为用户和系统管理员自己解决问题提供可能 | M-02 | ||
易改变性 | 对相关配置文件、库、表的参数可以提供方便的修改 | M-03 | |
对于非程序内部错误,由数据元素属性设置、控制规则不当而引起的软件运行错误,软件应为系统管理员提供自行修正的手段 | M-04 | ||
软件应充分考虑在设计环境与适用范围下不同用户的要求,为用户进行本地化配置提供手段 | M-05 | ||
稳定性 | 系统在测试过程中运行稳定 | M-06 | |
5.4.6 可移植性
表 6 可移植性 | 第 1页 | 共 1页 | |
测试需求 | 测试过程说明 | 过程 标 引 | |
适应性 | 软件可适应不同的规定环境(如:不同的网络环境) | P-01 | |
兼容性 | 硬件设备兼容性 | P-02 | |
软件(如:操作系统、数据库、 WEB 服务器等)兼容性 | P-03 | ||
5.4.7 效率
表 7 效率 | 第 1页 | 共 1页 | |
测试需求 | 测试过程说明 | 过程标引 | |
时间特性 | 软件各个功能点的响应时间 | E-01 | |
资源特性 | 软件安装后占用磁盘空间情况 | E-02 | |
软件启动后系统内存占用情况 | E-03 | ||
软件停止后内存释放情况 | E-04 | ||
5.4.8 中文特性
表 8 中文特性 | 第 1页 | 共 1页 | |
测试需求 | 测试过程说明 | 过程 标 引 | |
中文显示 | 对话框、菜单、图标、窗口等界面 | CC-01 | |
信息提示,帮助文档符合中文使用习惯 | CC-02 | ||
汉化程度 | 系统全部中文汉化 | CC-03 | |
编码支持程度 | 支持 GB 2312 编码 | CC-04 | |
支持 GB 13000.1 编码 | CC-05 | ||
支持 GB 18030 编码 | CC-06 | ||
5.4.9 安全性
表 安全性 | 第 1页 | 共 2页 | ||
测试需求 | 测试过程说明 | 过程标引 | ||
身份认证 | 用户权限 管理 | 提供客户端用户身份识别 | S-01 | |
提供用户功能权限管理 | S-02 | |||
提供用户数据访问权限管理 | S-03 | |||
授权(功能授权、数据授权)机制是否灵活安全 | S-04 | |||
验证控制 | 身份验证不成功有次数限制及相应处理措施 | S-05 | ||
用户唯一 | 用户名称应具有唯一性 | S-06 | ||
用户在被删除或被停用后,保留该用户记录,新增用户不得与该用户同名 | S-07 | |||
电子签名 | 对电子签名进行验证 | S-08 | ||
客户端用户 身份识别 | 是否提供USBkey加密验证、提供数字证书验证或提供其他加密验证方式 | S-09 | ||
数据加密及安全传输 | 对于有特殊安全要求的数据,应在传输中进行必要的加密处理 | S-10 | ||
提供数据的安全可靠传输,支持断点续传、屏蔽线路瞬间故障和主机故障 | S-11 | |||
数据加密使用的算法应符合国家规定 | S-12 | |||
安全缺陷屏蔽 | 对非法访问有识别和屏蔽功能 | S-13 | ||
授权(功能授权、数据授权)机制是否灵活安全 | S-14 | |||
软件程序本身不存在可能引起安全缺陷的语句、命令 | S-15 | |||
日志和审计 | 对关键数据的变更应记入日志 | S-16 | ||
对日志信息进行查询、统计、分析和分类管理 | S-17 | |||
提供安全审计功能 | S-18 | |||
表 安全性 | 第 2页 | 共 2页 | |
测试需求 | 测试过程说明 | 过程标引 | |
密码设置 | 进入系统需要密码身份验证 | S-19 | |
应有密码设置策略,包括有效期、最小长度、复杂度、非空设置、大小写敏感度等 | S-20 | ||
所有的密码不得明码显示、存储与传输 | S-21 | ||
数据备份与还原 | 是否 提供数据备份与 还原 手段 | S-22 | |
超时自动退出 | 超过一定的时限未进行操作,系统自动退出 | S-23 | |
安全补丁检查 | 操作系统是否安装所有安全补丁 | S-24 | |
对于使用IE的客户端,是否安装所有IE安全补丁 | S-25 | ||
5.5 测试技术
测试技术 | 是否采用 | 说明 |
里程碑技术 | 采用 | 里程碑的达成标准及验收方法在测试完后制订 |
自动测试技术 | 采用 | 核心业务流程采用自动测试技术 |
审评测试 | 采用 | 对软件产品功能说明文档和设计说明文档进行检查,在需求与设计阶段进行 |
编写测试用例 | 采用 | 在产品编码阶段编写测试用例 |
单元测试 | 不采用 | 由开发人员进行 |
集成测试 | 采用 | 检测模块集成后的系统是否达到需求对业务流程及数据流的处理是否符合标准、系统对业务流处理是否存在逻辑不严谨及错误以及是否存在不合理的标准及要求。 |
确认测试 | 采用 | 在产品发布前,对照feature list 进行基本需求的确认,确认产品是否正确实现了功能。 |
系统测试 | 采用 | 包括性能测试、压力测试和回归测试 |
验收测试 | 不采用 | 由工程实施人员进行 |
第 6 章 测试计划
6.1 进度计划
在此章节,对各阶段的测试给出里程碑计划,包括阶段、里程碑、资源等。
测试阶段 | 开始时间 | 完成时间 | 测试人员 | 阶段完成标志 |
制定测试计划 |
|
|
|
|
测试培训 |
|
|
|
|
测试方案编制 |
|
|
|
|
需求 Review |
|
|
|
|
设计 Review |
|
|
|
|
设计测试用例 |
|
|
|
|
测试开发 |
|
|
|
|
测试环境准备 |
|
|
|
|
测试实施 |
|
|
|
|
功能测试 |
|
|
|
|
集成测试 |
|
|
|
|
性能测试 |
|
|
|
|
系统测试 |
|
|
|
|
验收测试 |
|
|
|
|
编制测试报告 |
|
|
|
|
编制缺陷报告 |
|
|
|
|
提交测试文档 |
|
|
|
|
里程碑 | 完成时间 | 完成标准 |
测试正式开始 |
| 完成可接受性测试和烟雾测试 |
进行CVS LOCK | 进行cvs lock | 完成所有里程碑测试和标准测试, 测试种类包括确认测试和系统测试, 且所有以发现的Bug 等级为1/2/3 的Bug 已修复, 近期内无发现新的Bug 等级为1/2/3 的Bug |
产品Release |
| 重复进行主路径测试和进行Bug 检查测试, 产品处于可交付状态并由测试经理和高级经理确认 |
6.2 测试准备
准备事项 | 开始时间 | 完成时间 | 测试人员 | 阶段完成标志 |
测试环境准备 |
|
|
|
|
准备事项 | 开始时间 | 完成时间 | 测试人员 | 阶段完成标志 |
安装测试 |
|
|
|
|
准备事项 | 开始时间 | 完成时间 | 测试人员 | 阶段完成标志 |
烟雾测试 |
|
|
|
|
6.3 具体测试实施任务和时间人员安排
测试功能点 | 开始时间 | 完成时间 | 测试人员 | 说明 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
第 7 章 测试评审
在此规定测试计划该如何被其他的测试人员、用户或管理层进行评审的事宜
第 8 章 缺陷管理
在此规定本测试项目将使用的缺陷跟踪及管理工具,并对在项目完成时所应提交的图表化的报告进行概要说明。
8.1 测试过程ID命名规则
依照设计好的测试用例对产品进行测试,将发现的缺陷,包括功能、 性能、 界面,按照用例中的测试号分别记录,保证各类缺陷记录的维护、分配和修改。
使用Butterfly 管理工具对缺陷进行跟踪和管理,项目完成时所提交的报告包括如下内容:
Ø 缺陷ID ;
Ø 项目名称;
Ø 样品版本;
Ø 测试平台;
Ø 操作系统;
Ø 功能模块名;
Ø 缺陷优先级;
Ø 可重现性;
Ø 提交人;
Ø 确认人;
Ø 缺陷问题摘要;
Ø 缺陷详细描述。