黑盒测试 测试计划(实例).doc

软件测试工程师管理系统
测试计划

文 档 编 号：

版 本 号：1.0
软件产品名称：软件测试工程师管理系统
软件开发部门：
软件测试部门：

编 写： 日 期：
审 核： 日 期：
批 准： 日 期：

目 录
1. 引言 5
1.1 测试计划概述 5
1.2 被测试系统概述 5
1.3 测试计划制定依据 6
1.4 预期读者 6
2. 测试范围 6
2.1 测试特性与软件需求的对应关系 7
2.1.1 安装/卸载测试 7
2.1.2 功能测试 7
3. 术语定义 9
3.1 软件错误与缺陷定义 9
3.2 其他术语的定义 9
4. 测试目标与策略 9
4.1 测试目标 9
4.2 测试方法 9
4.3 测试工具 9
4.4 测试地点 9
5. 测试状态转换标准和再启动要求 9
6. 测试通过准则 9
7. 应提供的测试文档 10
8. 测试资源需求 10
8.1 硬件需求 10
8.2 软件需求 10
8.3 网络需求 10
8.4 人员需求 10
8.5 其他需求 11
9. 人员、职责及培训要求 11
9.1 人员组成 11
9.2 人员分工与职责 11
9.3 培训要求 11
10. 测试进度 11
11. 风险和应急 12
11.1 影响计划的潜在因素 12
11.2 应急措施 12
12. 测试的局限性 12
13. 计划的批准 12
14. 参考文档 13

1 引言
1.1 测试计划概述
计划名称： 软件测试工程师管理系统测试计划
文档编号：
测试部门：
计划作者：
计划审核：

本测试计划将对软件测试工程师管理系统的测试方法、测试工具、测试范围、测试种类、测试的软件硬件环境、测试进度、测试人员的分工和职责以及测试流程进行详细的定义和整体的描述。
对软件测试工程师管理系统将采用黑盒测试方法，完成第一轮测试。
1.2 被测试系统概述
产品名称： 软件测试工程师管理系统
开发部门：
测试版本： V1.0
最新版本： V1.0
本项目的目标是完成一个计算机人事管理系统，实现人事管理的自动化。系统的主要功能包括：人事信息的录入、管理、查询、删除、生成报表等。
进入本系统提供用户选择菜单，要求人机界面友好，具有错误处理和故障恢复能力。
1.3 测试计划制定依据
本测试计划是依据《软件测试工程师管理系统开发计划》、《软件测试工程师管理系统需求规格说明书》、《软件测试工程师管理项目条款》等。
1.4 预期读者
（1） 项目管理人员；
（2） 测试人员；
（3） 开发人员。
2 测试范围
测试类型
是否计划进行测试
测试的优先级
说明
安装/卸载测试
否
最高优先级
程序的安装与卸载测试
功能测试
是
最高优先级
系统功能的正确实现及与需求是否符合的测试
资源占有测试
否

对系统在安装或运行后对硬盘、内存、CPU及网络占有率测试
兼容性测试
是
低优先级
系统对各种运行环境的兼容性（例如操作系统、浏览器）以及与历史版本的兼容性、与第三方软件的兼容性测试
可靠性/稳定性
测试
是
最高优先级
系统运行的可靠性、对各种异外情况错误处理能力的测试
并发测试
否

系统对并发操作的支持性测试
压力测试
否

系统在大负载量条件的性能测试
用户友好性
测试
是
中等优先级
主要是指测试人员以用户的角度对系统操作的方便性、可使用性、界面友好性的给出评价。
软件安全性
测试
否

主要从软件安全性角度测试系统对业务数据保存、访问及软件系统自身的安全性进行测试。
配置测试
否

指对被测系统使用说明书中要求的软硬件配置进行验证。在此主要指硬件的配置要求验证测试。
恢复测试
否

是指被测试系统的服务器端或客户端或网络在机器突然出故障（例如突然断电或断网）后重新恢复正常的能力测试。
文档检查
否

对提供的用户手册、系统的在线帮助等技术文档进行一致性检查。
其他测试：
否

备注：（1）请在表中选择本次测试计划进行的测试类型，并对测试的优先级给以说明。
（2）测试的优先级分为四个级别，请在表格中填写相应序号。
1 最高优先级：首先测试，并详细测试；
2 中等优先级：正常测试；
3 低优先级： 只需粗略测试，但本次测试必须进行；
4 最低优先级：只需粗略测试，可以留到下轮测试进行；
2.1 测试特性与软件需求的对应关系
2.1.1 安装/卸载测试
安装环境测试需求说明
运行环境
本软件的最终运行环境是操作系统DOS5.0以上，或Windows95/98/2000/me/NT/XP等DOS环境上，要求有中文平台或操作系统为中文的计算机上，配有一台打印机。
运行软件系统所需的设备能力
一台微机：主频>=100，硬盘>=1M，内存>=1M；
一台打印机；
支持软件环境
操作系统：DOS5.0以上，或Windows95/98/2000/me/NT/XP。
开发环境：Microsoft Visual C++6.0；

接口
该系统硬件和软件与外界软件没有接口，也不需要网络环境；
在界面上，要求使用DOS菜单选择，用户可以随时选择菜单进行；
在操作上，要求操作简单，通过少数的选择菜单或单击按钮即可完成操作；
在系统运行任何阶段，提示给用户当前系统的状态。

2.1.2 功能测试
表4 功能测试需求说明
模块名称
测试需求
模块开发人员
备注
输入工程师资料
对这些输入的信息进行合法性检查。

删除指定工程师资料
一是根据编号删除，一是根据姓名删除

查询指定工程师资料
一是根据编号查询，一是根据姓名查询。

修改指定工程师资料
根据姓名和编号找到后并提示用户修改。

计算工程师月薪水
根据当月的月效益，计算工程师的当月工资。

薪水＝（基本工资＋10╳月有效工作日天数＋月效益╳工作年限÷100）╳0.9－月保险金

保存工程师资料

输入工程师资料
对工程师资料进行排序，排序使用三种方式：编号排序（升序）、姓名排序（升序）和工龄排序（降序）。采用哪种排序方式，由用户选择。
重点测试

输出工程师资料

清空所有工程师资料

打印工程师资料信息报表

从文件重新得到工程师资料

退出系统

备注：（1）在测试项一栏中，请填写需要进行测试的主要功能模块，不需要划分太细，以功能模块进行划分即可。（2）在“测试注意事项或特殊说明”一栏，请给出在进行本项测试时，需要重点测试的方面或其他使用说明。
3 术语定义
此部分定义与测试计划执行有关的重要术语和缩略语，其中主要对软件错误与缺陷的划分标准进行定义。
3.1 软件错误与缺陷定义
软件错误与缺陷定义见附录Ⅰ。
3.2 其他术语的定义
无。
4 测试目标与策略
4.1 测试目标
尽可能发现系统中存在的错误和设计缺陷。验证系统的可靠性，检查系统的正确性和系统的友好性。
4.2 测试方法
4．21 使用非法输入。例如，在只允许输入数字的地方，输入英文或特殊字符。
4．22 直接输入默认值。例如，默认值是空，则不改变此默认值，而将空值作为输入值。
4．23 输入临近或者超出程序处理范围的数值。
4．24 使用特殊字符、特殊长度、无效的文件名。
4．25 改变文件访问权限。
4．25 使文件内容错误，并让软件使用这个文件。
4.3 测试工具
主要进行功能的手工测试，所以没有使用特殊的测试工具。
4.4 测试地点
本测试计划的的执行地点在机房。
5 测试状态转换标准和再启动要求
测试状态转换标准和再启动要求见附录Ⅱ。
6 测试通过准则
测试通过准则参见附录Ⅲ。
7 应提供的测试文档
---------------------------------------------------------------------------------------------------
Ø 《软件产品提交测试委托书》
Ø 《软件测试需求说明书》
Ø 《测试计划》
Ø 《测试用例设计与执行报告》
Ø 《测试用例设计评审记录》
Ø 《软件问题清单》
Ø 《测试分析报告》
--------------------------------------------------------------------------------------------------
8 测试资源需求
8.1 硬件需求
根据系统的环境要求，系统运行要求满足的最低硬件配置标准为：
系统环境需求

见安装条件
8.2 软件需求
以上列出了系统运行要求的软件环境。
测试还需要文档处理软件Microsoft Office2003。
8.3 网络需求
无网络需求。
8.4 人员需求
（1） 本测试需要测试人员 三至四名（一名测试负责人、二至三名测试人员）；
（2） 需要该系统开发人员一名，负责对测试人员进行该系统的使用培训和解释测试人员在测试中遇到的各种系统使用问题，同时负责对错误加以确认。
8.5 其他需求
暂无。
9 人员、职责及培训要求
9.1 人员组成
小组成员3-4人。
9.2 人员分工与职责
人员分工与职责见附录Ⅳ。
9.3 培训要求
暂无。
10 测试进度
测试进度计划表
起止日期
测试任务

制定测试计划；
熟悉被测试系统

搭建测试环境

进行测试前被测系统培训;

设计测试用例

测试用例评审

执行测试用例

整理测试结果，出软件问题清单和测试分析报告。

上报测试结果，第一轮测试结束.
注：回归测试时间将在回归测试前进行详细制定。
11 风险和应急
11.1 影响计划的潜在因素
在测试计划执行过程中，可能存在以下因素影响计划的按时完成：
l 测试人员对被测试产品的熟悉进度慢；
l 测试人员对测试工具的使用熟悉程序不够；
l 被测试产品存在重大错误，以致于测试无法继续，需要开发组进行额外的调试和修改才能继续；
l 硬件、软件或网络环境出现故障等。
其中第一点是影响测试进度的最大的因素。
11.2 应急措施
如果上述潜在的可能事件发生，则通过适当加班来保证计划的按时完成。如果是由于被测试产品存在重大错误而严重影响测试进度，则考虑按照测试暂停标准来暂停该测试。
12 测试的局限性
l 系统硬件配置存在不可预测的问题；
l 测试范围不能覆盖所有的可能情况；
l 测试时间的限制；
l 测试数据可能不全面；
l 测试工具自身的缺陷；
l 测试人员的失误。
13 计划的批准
本测试计划需XX批准。
14 参考文档
Ø 《软件测试工程师管理系统开发计划》；
Ø 《软件测试工程师管理系统需求规格说明书》；
Ø 《软件测试工程师管理系统数据库设计说明书》
附录Ⅰ 软件错误与缺陷的定义

对于软件的错误和缺陷，目前主要依据其严重程度划分五个级别：
① 致命性错误
数据丢失，数据计算错误、数据传递错误、对数据库造成破坏，造成操作系统或其他支撑系统崩溃、非正常关闭和非正常死机。
② 严重性错误
应用系统崩溃、非正常关闭和无响应，但没有造成数据丢失。系统的主要功能不能正确实现或不完整。
③ 一般性错误
规定的非主要功能没有实现或不完整、影响系统的运行； 设计不合理造成性能低下。
④ 告警性错误
不影响业务运行的功能问题。
⑤ 建议
软件设计和功能实现等不完全合理之处提出建议。

附录Ⅱ 测试状态转换标准和再启动要求

“测试状态转换标准”用于开始、暂停或结束全部或部分与本计划有关的测试项的测试活动的标准，这三种标准通常指启动标准、暂停标准和退出标准。
“测试再启动要求”规定当测试重启动时必须重复的测试活动。
1 测试启动标准
① 测试部由公司管理层领导，具体由总工负责领导职能。各软件产品或项目组提交测试需经过公司管理层书面指派。
② 公司所研发的各项面向市场的软件系统均需通过测试，才能对外发布，特殊情况由公司管理层书面认可。
③ 公司各项软件产品的开发计划书中均需要列出交付测试时间和测试时间，以及相应的修改和回归测试时间。测试部基于各开发计划制定相应的测试计划，软件系统开发计划的变更必须变更相关的测试安排。
④ 软件产品或项目提交测试部进行测试必须满足以下条件：
Ø 提交测试的软件系统必须是一个稳定的、待发布的版本，必须明确定义系统版本号（即在系统各部分，系统本身、用户手册等方面均表明该版本），如果本版本还没有开发完成或将进行大量的修改，不能提交测试；
Ø 软件产品或项目在提交测试之前，本产品或项目组必须在内部进行自己的单元测试和集成测试；
Ø 提交测试的软件系统必须是商品化包装的，并需附有：
l 用户手册、使用说明书（至少两者必备其一）；
l 软件需求说明书；
l 其它最好还能够提交相关培训教材、演示程序等电子文档。
Ø 软件系统开发组必须向测试部提供足够的培训和技术指导，以便测试工作的顺利开展。在测试期间，开发组必须指定一名骨干开发人员，帮助测试部解决相关问题。
Ø 若是对将发布的产品或将验收的项目进行测试，则必须给测试留出足够的时间，以保证测试的质量。
Ø 提交测试的软件系统版本在测试期间保持稳定，即测试部只对初始提交的系统版本进行测试，产品或项目组在测试期间的修改只在下一轮测试中进行测试。特殊情况（即提交版本无法继续测试，如安装程序错误等问题）下，可以在测试期间更换版本，但必须经过测试部的同意。
Ø 回归测试是指不包含功能修改（含界面修改等）情况下测试部对原来测出的问题进行的再次测试。若引入新功能超过10%，则认为是新的系统测试，测试部必须进行全面测试。
2 测试暂停标准
当在测试过程中出现下列情况之一，则测试将暂停：
① 对于某类测试，测试环境变得（或者测试中发现）没有准备好，则暂停此类测试；
② 对于提交测试的版本而言，如果其预计的功能修改量超过总功能的10%，产品或项目组应即时通报测试部，并向公司相关负责人汇报，测试部有权利向公司领导建议暂停或取消本轮测试，避免测试的无效劳动，避免造成人力、财力等资源的浪费。
③ 发现被测试系统有大量错误或非常严重错误，以至于测试不能继续或继续测试没有意义，则测试部应向总工提交报告，由总工决定是否暂停整个系统测试。
④ 当系统中某个功能模块有非常严重的错误，以致于不能完成预期的功能，则暂停此功能模块的测试。
3 测试退出标准
当出现下列情况之一则退出此系统的本次测试：
① 测试计划中所有规定的测试内容和回归测试都已经运行完成。
② 根据上级主管对测试结果的意见，要求结束本次测试。
4 启动要求
当测试重新启动时，必须重复的主要测试活动有：
① 当是某功能模块的测试重新启动时，则此功能模块的所有测试用例都要重新运行，并且调用此功能模块的其他功能模块的相关测试用例也要重新运行。
② 当是整个系统的测试重新启动时，则发生修改的部分和与之相关联的部分的测试用例都要重新运行。
附录Ⅲ 测试通过准则

1 测试项通过标准
测试项的通过标准目前定义为：
当此项的功能能够正确地完成，并且它的操作没有引起其他功能项或整个系统的错误，则认为此项测试通过。
2 系统测试通过标准
系统测试的通过标准目前定义为：
对于每一类测试，当没有发现致命性错误和严重性错误、一般性错误数量小于测试用例总数的2%，告警性错误数量小于测试用例总数的5%，则认为系统通过本次测试
，但要以测试结果评审会的评审结果为最后标准。
附录Ⅳ 人员分工与职责
1 项目总负责
Ø 负责审定和批准《测试计划》；
Ø 负责审定其他测试文档，包括：《测试用例设计及执行报告》、《软件问题清单》、《测试分析报告》；
Ø 负责测试状态转换（进入、暂停、退出）的最终审定和批准。
2 测试负责人
Ø 负责制定系统测试计划；
Ø 负责组织实施测试计划；
Ø 负责整个测试过程的管理工作；
Ø 负责对被测试产品的评价工作，并编写《测试分析报告》；
Ø 负责与开发组交流测试结果和测试进展情况，并协调错误的修改和测试的矛盾；
Ø 负责对测试人员进行测试工具的培训；
Ø 负责组织被测试产品的培训；
Ø 负责的所有测试文档的管理。
3 测试人员
Ø 负责设计测试用例；
Ø 负责执行测试；
Ø 负责测试用例原始文档的保存和整理工作；
Ø 负责错误的分类和测试结果的统计工作；
Ø 负责编写《测试用例设计与执行报告》。
4 开发人员
Ø 负责软件问题分析、确认；
Ø 进行被测试系统的培训；
Ø 填写《软件问题清单》中相应的栏目。
5 测试用例的评审
测试用例评审会主要由测试部相关人员、开发部相关人员组成，必要时包括质量部相关人员。如果是验收测试还要包括客户、最终用户的有关人员。特殊情况下，还包括有公司相关领导及有关专家。
评审结果报项目总负责人批准。
6 测试结果的评审
测试结果评审会主要由测试组相关人员、开发组相关人员和质量部组成，如果是验收测试还要包括客户、最终用户的有关人员。如果是重要的项目或产品发布前的测试结果评审，还包括有公司相关领导及有关专家。
评审结果报项目总负责人批准。

北京夜场招聘 邹梓菱兂

第 27 页 共 27 页