测试工程师信息
修订历史记录 版本 日期 添加/修改/删除 修订者 说明
1. 简介
1.1目的
测试计划文档有助于实现以下目标：
1、确定测试工程师信息的信息和该系统的软件构件 2、列出推荐的测试需求
3、推荐可采用的测试策略，并对这些策略加以说明 4、确定所需的资源，并对测试的工作量进行估计 5、列出测试工程师信息的可交付元素
1.2背景
项目名称：测试工程师信息管理系统 开发者： 用 户：个人
项目背景：：测试工程师信息管理系统.是一款灵活、通用的管理软件，适用于本地小型人
员管理. 使管理者能更轻松快速地对员工信息进行管理.
基本功能：
对测试工程师信息进行查询、录入、修改、导入、导出数据 统计报表的功能就是利用数据表中已有的数据，生成各类报表。
1.3范围
测试的各个阶段：
测试计划：根据需求规格说明书和最终的系统设计，制定测试计划、测试方案，包括收集测
试方法、测试用例及可能的测试工具等。
测试设计：前期主要针对单个的功能和模块及简单的功能组合，后期主要针对基本的流程，
同时对新加入的测试人员进行培训。
系统测试：前期根据需求规格说明书进行功能测试，中期是针对重点模块的性能测试，后期
是模拟用户的业务测试，并结合可能的用户测试。
测试总结：根据用户手册对功能进行检查，复查报告库中的所有BUG。对上一阶段的测试发
现的问题进行分析，为下一步测试提出参考意见。
2. 测试参考文档和测试提交文档
2.1. 测试参考文档
[下表列出了制定测试计划时所使用的文档，并标明了各文档的可用性.
文档（版本/日期） 可行性分析报告 软件需求定义 软件系统分析 软件概要设计 软件详细设计 软件测试需求 模块开发手册 用户操作手册 已创建或可用 否□ 否□ 否□ 否□ 否□ 否□ 否□ 是√ 已被接收或已经过复审 否□ 否□ 否□ 否□ 否□ 否□ 否□ 是√ 来源 备注
2.2. 将要提交文档
[下表列出了测试项目实训将要用到的文档，测试用例根据项目进度逐步完成] 文档（版本/日期） 测试计划 测试用例模板 测试报告单模板 测试用例通过情况统计表 各模块的测试用例 已创建或可用 是√ 是√ 否□ 否□ 是√ 已被接收或已经过复审 是√ 否□ 是√ 否□ 否□ 否□ 是√ 否□ 来源 备注
2.3. 测试提交文档
[下面应当列出在测试项目实训结束后，所有可提交的文档] 文档（版本/日期） 测试计划 测试用例 缺陷报告单 测试总结 已创建或可用 是√ 是√ 是√ 是√ 已被接收或已经过复审 是√ 否□ 是√ 否□ 是√ 否□ 是√ 否□ 来源 备注
3.测试进度
3.1 测试项目里程碑 里程碑任务 制订测试计划 设计测试用例 系统测试 测试总结
工作量 开始日期 结束日期
3.2 各测试阶段资源要求及时间安排 测试计划 测试设计 系统测试 测试总结 人员 … 设备 测试用机5台 时间安排
2.6. 问题优先级描述 问题严重程度 P5 P4 P3 P2 P1
描述 响应时间 4. 测试策略
[测试策略提供了对测试对象进行测试的推荐方法。对于每种测试，都应提供测试说明，并解释其实施的原因。制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。] 注意：对于应该实施而由于某些原因不能实施的测试，则应该用一句话加以说明，并陈述这样的理由。例如：“将不实施该测试。没有足够的资源进行测试”。
4.1. 测试策略1 1、功能测试 测试目标： 方法： 系统提供的功能与需求或用户手册相符 完成标准： 需考虑的特殊事项： 系统测试阶段依据需求规格说明书逐项测试，验收测试阶段依据说明书逐项测试 重要的功能应该投入更多的精力进行测试，并及时小结 功能实现，且可以正确执行 所发现的缺陷尽量解决，留下的问题已经进行相应的处理或提供其他的解决方法 注意其中一些重要功能是与实际效果相关，并不是简单的功能实现 注意值域测试的提示信息
2、界面测试 测试目标： 方法： 程序界面符合个关的规范 完成标准： 需考虑的特殊事项： 按照相规定逐项检查，包括按钮，版权信息等 检查提示信息中的文字和标点符号，图标等 程序界面符合相关的规范 注意启动画面的安装程序的版权信息 注意版式本信息
3、安装测试 测试目标： 方法： 安装程序安装后程序可以正常运行，也能正常卸载 分以下几种情况进行安装和卸载测试 完成标准： 需考虑的特殊事项： 首次安装。以前从未安装过测试工程师管理系统的新计算机 更新1：以前安装过相同版本的测试工程师管理系统的计算机 更新2：以前安装过罗早版本的测试工程师管理系统的计算机 更新3：不卸载直接覆盖安装 证明程序在新安装的操作系统上可以正常运行 注意通过比较文件的数量和大小，检查注册表路径等等方式，难程序安装否完整 注意检查卸载后的剩余文件是否正常 注意非默认路径的安装是否正确 4、安全性测试 测试目标： 方法： 程序提供的安全性功能符合需求的设计 完成标准： 需考虑的特殊事项： 测试用户的安全性，包括用户的创建，权限设置，权限的验证（更换用户，用户类型变化等），权限级别等 测试数据库的安全性，主要是文件的保存和修改 程序的安全性功能可以保证用户的正常使用 此方面经验比较少，需要摸索和总结 5、强度测试 测试目标： 方法： 通过此类测试，找出一般测试不能（易）发现的问题 在各模块具有一定稳定性的基础上，开始模拟用户的测试，并与可能的用户测试相结合，进行整个系统的稳定性测试，同样包括加载测试。同时尽可能地针对不同的用户，最好能够有不同的用户原型来模拟 完成标准： 尽可能有用户测试，对用户反馈的问题进行验证 有关容量的测试，包括硬盘容量，数据库的大小等 测试死机或程序出错时的系统自我全面提高的能力，包括数据训出现错误数据后的容错性能等 连续正常使用不死机的时间在允许范围之内（一天死机一次），出错后数据不丢失或丢失的情况在允许的范围内 需考虑的特殊事项： 响应时间，事务处理速率等与时间相关的方面是否在允许范围内 注意内存和CPU的使用情况 注意数据的保存情况 注意及时总结经验 如果时间不够，可以缩减或转给用户测试
6、值域测试 测试目标： 对于所有需要输入数据的地方，进行数据输入并检查其输出结果，进行值域测试不但要验证正确的输入数据能否得到正确的输出结果，同样也一定要检查输入错误的数据是否可以得到应该的反应，给出的错误提示是否正确和友善等。 · 逐一对每个需要输入数据的地方进行检查，包括键入和粘贴方式。 · 检查出错是否有提示，提示信息是否正确。 常用的输入项可以实现测试目标。 · 注意小键盘输入是否正常。 · 注意边界值的测试。 验证开发组提交的版本是否值得进行系统测试。 · 返测随版本提交的测试报告。 · 测试系统的基本功能。 得出继续测试或退回开发组的结论。 · 此阶段时间不超过一天。 · 注意及时总结经验。 程序提供的安全性功能符合需求的设计。 · 测试用户的安全性，包括用户创建，权限设置，权限的验证（更换用户，用户类型变化等），权限级别等。 · 测试项目、素材库、节目的安全性，主要针对是权限的验证。 · 测试数据库的安全性，主要是文件的保存和修改。 程序的安全性功能可以保证用户的正常使用。 · 此方面经验比较少，需要摸索和总结。 方法： 完成标准： 需考虑的特殊事项： 7、版本验证测试 测试目标： 方法： 完成标准： 需考虑的特殊事项： 8、安全性测试 测试目标： 方法： 完成标准： 需考虑的特殊事项： 9、裸机测试 测试目标： 方法： 完成标准： 需考虑的特殊事项：
4.2. 工具
在干净的环境上，进行与其他测试环境相同的测试，应包括所有的测试内容。标准是裸机环境上程序运行正常。 ·在干净的环境上，进行与其他测试环境相同的测试，应包括所有测试内容（一般有一台机器专门用于裸机测试）。· 证实干净系统的程序使用也是正常的。 · 每个新的版本安装前，系统也必须重装（使用GHOST）。 · 注意必要的文件的安装（数据库支持文件等）。 此项目将使用以下工具： 测试管理 缺陷跟踪 工具 Word和Excel Bugzilla 厂商/自行研制 Microsoft 版本 Windows 2000
4
模块名称 “信息管理”菜单 1、 输入信息 2、 查询信息 3、 删除信息 4、 修改信息 主要功能 5、 信息导出 6、 信息导入 7、 显示所有信息 8、 退出系统 1、 输入工程师信息 2、 查询指定工程师信息 3、 删除指定工程师信息 4、 修改指定工程师信息 测试内容 5、 把工程师信息保存到各个文件夹 6、 把工程师信息导入到系统中 7、 显示所有工程师信息 8、 退出系统 优先级 对应测试用例编号 01-01
5. 资源
5.1. 角色
下表列出了在此项目的人员配备方面所作的各种假定。 [注：可适当地删除或添加角色项。] 角色 推荐的最少资源（所分配的专职角色数量） 具体职责或注释
测试组长： … 进行管理监督的职责如下 1、 提供技术指导 2、 获取适当的资源 3、 生成测试计划，测试方案 4、 管理测试数据 5、 收集用例 6、 参与测试 测试员 …… 负责执行测试的职责如下 1、 执行测试 2、 记录结果 3、 从错误中恢复（返测报告） 4、 收集测试用例 测试管理员 … 确保测试环境和资产得到管理和维护的职责如下 1、 管理测试系统 2、 授予和管理角色对测试系统的访问权
5.2. 系统
测试项目所需的系统资源。
1、 硬件资源：
CPU： Pentium 133 MHz 或以上
内存： 256MB 或以上。
2、软件环境：
服务器软件环境：
操作系统：Windows 2000 (Advanced) Server/2003 Server/XP Professional（中文版）
IIS:5.0 或更高版本
MS Office: 2000 或更高版本(统计报表中的透视分析表需要利用 Excel 程序)
客户端软件环境：
操作系统： Windows 98 SE/ Windows 2000/ Windows XP
IE：6.0 或更高版本（纯 HTML，无需任何安装）
6. 测试员的任务分配 测试员 测试任务
7. 可能的影响或风险：
计划的测试时间，不能满足测试组的要求，主要是功能冻结后的系统测试的时间可
能不够。
测试资源的及时到位（设备和人员）。 测试人员的熟练程度。
开发进度的变化，需求或设计的变更。
开发组的版本控制。
8. 文档模板
7.1. 测试用例 7.2. 工作日志 7.3. 例会记录 7.4. 测试总结
5.3.2.
项目名称 软件测试用例模板
特殊规程说明 测试结果 缺陷编号 备注 编制时间 程序版本 功能模块名 编制人 功能特性 测试目的 预置条件 参考信息 用例编号 相关用例 用例说明 输入数据 预期结果
（通过/不通过）
5.3.3.
姓名 工作日志模板
测试组编号 日期 当日工作任务： 1. 2. 3. …… 完成情况（％） 未完成任务的原因： 1. 2. 3. …… 工作成果： 1. 2. 3. …… 遇到的问题： 1. 2. 3. …… 备注：
5.3.4. 例会记录模板
1. 2. 3. …… 例会时间 测试组编号 主持人 会议记录人 参加人员 例会议题 议题1讨论结果： 1. 2. 3. …… 议题2讨论结果： 1. 2. 3. …… 议题n讨论结果： 1. 2. 3. ……
5.3.5. 测试总结模板
□系统测试 □用户测试 □评估产品测试 □母盘内容更换测试 中文： 英文： 测试期产品名称： 测试类型 产品正式名称 产品简称(中文、英文)： 版本号： 构造号： 人日 千行 发组： 语种： 中文/英文 项目组开发工作量：(人日) 本次版本升级修改过的代码行数（千行）（含增加、删除、修改）： 产品总的代码行数（千行）： 千行 产品简介： 产品建议配置： 产品组成模块清单： 产品(主要)组成文件清单： 产品组成介质清单： 中文版： 英文版： 实际测试时间段： 实际测试人员： 实际测试工作量：(人日) 实际测试环境： 测试活动简述： 人日 测试错误分类 软件继发现 改正 死机 致命 严重 版本号： 一般 继承软件名称：
承性 对继承软件的改进/改变处： BUG的修改： 功能的改进： 新功能的增加： 为配合相关的插件或软件做的改动： 针对某些功能模块做的优化： 其他： 软件遗留问题（发生原因、对功能性能有何影响、解决措施）： 测试组测试结论： 测试期发现的bug共 个；建议共 个,采纳 个。 Bug密度（系统测试的Bug数/修改的代码行数）： 个/千行 Bug密度（系统测试的Bug数/总的代码行数）： 个/千行 产品度量 待发行产品遗留bug共 个；严重及严重以上遗留Bug共 个。 Bug密度(遗留Bug数/修改的代码行数)： 个/万行 Bug密度（遗留Bug数/总的代码行数）： 个/万行 Bug密度（严重及严重以上遗留Bug数/总的代码行数）: 个/万行 测试综合 报告评审 测试经理 系统分析员 评审方式、人员、时间： 评审结论： 签名: 意见： 签名： 意见： 签名： 意见： 签名： 日期： 年 月 日 日期： 年 月 日 日期： 年 月 日 日期: 年 月 日 开发经理 项目经理 备注：
