测试工程师管理系统测试计划(黄雷)

1、测试工程师信息修订历史记录 版本日期添加/修改/删除修订者说明1. 简介1.1目的测试计划文档有助于实现以下目标：1、确定测试工程师信息的信息和该系统的软件构件2、列出推荐的测试需求3、推荐可采用的测试策略，并对这些策略加以说明4、确定所需的资源，并对测试的工作量进行估计5、列出测试工程师信息的可交付元素1.2背景项目名称：测试工程师信息管理系统开发者：用户：个人项目背景：测试工程师信息管理系统.是一款灵活、通用的管理软件，适用于本地小型人员管理. 使管理者能更轻松快速地对员工信息进行管理.基本功能：· 对测试工程师信息进行查询、录入、修改、导入、导出数据· 统计报表的功能

2、就是利用数据表中已有的数据，生成各类报表。1.3范围测试的各个阶段：测试计划：根据需求规格说明书和最终的系统设计，制定测试计划、测试方案，包括收集测试方法、测试用例及可能的测试工具等。测试设计：前期主要针对单个的功能和模块及简单的功能组合，后期主要针对基本的流程，同时对新加入的测试人员进行培训。系统测试：前期根据需求规格说明书进行功能测试，中期是针对重点模块的性能测试，后期是模拟用户的业务测试，并结合可能的用户测试。测试总结：根据用户手册对功能进行检查，复查报告库中的所有BUG。对上一阶段的测试发现的问题进行分析，为下一步测试提出参考意见。 2. 测试参考文档和测试提交文档2.1. 测试参考文

3、档下表列出了制定测试计划时所使用的文档，并标明了各文档的可用性.文档（版本/日期）已创建或可用已被接收或已经过复审来源备注可行性分析报告否否软件需求定义否否软件系统分析否否软件概要设计否否软件详细设计否否软件测试需求否否模块开发手册否否用户操作手册是 是 2.2. 将要提交文档下表列出了测试项目实训将要用到的文档，测试用例根据项目进度逐步完成文档（版本/日期）已创建或可用已被接收或已经过复审来源备注测试计划是是 否测试用例模板是 是 否测试报告单模板否否测试用例通过情况统计表否否各模块的测试用例是 是 否2.3. 测试提交文档下面应当列出在测试项目实训结束后，所有可提交的文档文档（版本/日期）

4、已创建或可用已被接收或已经过复审来源备注测试计划是 是 否测试用例是 是 否缺陷报告单是 是 否测试总结是 是 否3.测试进度3.1 测试项目里程碑里程碑任务工作量开始日期结束日期制订测试计划设计测试用例系统测试测试总结3.2 各测试阶段资源要求及时间安排人员设备时间安排测试计划测试设计系统测试测试用机5台测试总结2.6. 问题优先级描述问题严重程度描述响应时间P5P4P3P2P1 4. 测试策略测试策略提供了对测试对象进行测试的推荐方法。对于每种测试，都应提供测试说明，并解释其实施的原因。制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。 注意：对于应该实施而由于某

5、些原因不能实施的测试，则应该用一句话加以说明，并陈述这样的理由。例如：“将不实施该测试。没有足够的资源进行测试”。4.1. 测试策略11、功能测试测试目标：系统提供的功能与需求或用户手册相符方法：· 系统测试阶段依据需求规格说明书逐项测试，验收测试阶段依据说明书逐项测试· 重要的功能应该投入更多的精力进行测试，并及时小结完成标准：· 功能实现，且可以正确执行· 所发现的缺陷尽量解决，留下的问题已经进行相应的处理或提供其他的解决方法需考虑的特殊事项：· 注意其中一些重要功能是与实际效果相关，并不是简单的功能实现· 注意值域测试的提示信息

6、2、界面测试测试目标：程序界面符合个关的规范方法：· 按照相规定逐项检查，包括按钮，版权信息等· 检查提示信息中的文字和标点符号，图标等完成标准：程序界面符合相关的规范需考虑的特殊事项：· 注意启动画面的安装程序的版权信息· 注意版式本信息3、安装测试测试目标：安装程序安装后程序可以正常运行，也能正常卸载方法：分以下几种情况进行安装和卸载测试· 首次安装。以前从未安装过测试工程师管理系统的新计算机· 更新1：以前安装过相同版本的测试工程师管理系统的计算机· 更新2：以前安装过罗早版本的测试工程师管理系统的计算机·

7、更新3：不卸载直接覆盖安装完成标准：证明程序在新安装的操作系统上可以正常运行需考虑的特殊事项：· 注意通过比较文件的数量和大小，检查注册表路径等等方式，难程序安装否完整· 注意检查卸载后的剩余文件是否正常· 注意非默认路径的安装是否正确4、安全性测试测试目标：程序提供的安全性功能符合需求的设计方法：· 测试用户的安全性，包括用户的创建，权限设置，权限的验证（更换用户，用户类型变化等），权限级别等· 测试数据库的安全性，主要是文件的保存和修改完成标准：程序的安全性功能可以保证用户的正常使用需考虑的特殊事项：此方面经验比较少，需要摸索和总结5、强度

8、测试测试目标：通过此类测试，找出一般测试不能（易）发现的问题方法：· 在各模块具有一定稳定性的基础上，开始模拟用户的测试，并与可能的用户测试相结合，进行整个系统的稳定性测试，同样包括加载测试。同时尽可能地针对不同的用户，最好能够有不同的用户原型来模拟· 尽可能有用户测试，对用户反馈的问题进行验证· 有关容量的测试，包括硬盘容量，数据库的大小等· 测试死机或程序出错时的系统自我全面提高的能力，包括数据训出现错误数据后的容错性能等完成标准：连续正常使用不死机的时间在允许范围之内（一天死机一次），出错后数据不丢失或丢失的情况在允许的范围内需考虑的特殊事项：&#

9、183; 响应时间，事务处理速率等与时间相关的方面是否在允许范围内· 注意内存和CPU的使用情况· 注意数据的保存情况· 注意及时总结经验· 如果时间不够，可以缩减或转给用户测试6、值域测试测试目标：对于所有需要输入数据的地方，进行数据输入并检查其输出结果，进行值域测试不但要验证正确的输入数据能否得到正确的输出结果，同样也一定要检查输入错误的数据是否可以得到应该的反应，给出的错误提示是否正确和友善等。方法：· 逐一对每个需要输入数据的地方进行检查，包括键入和粘贴方式。· 检查出错是否有提示，提示信息是否正确。完成标准：常用的输入项可以

10、实现测试目标。需考虑的特殊事项：· 注意小键盘输入是否正常。· 注意边界值的测试。7、版本验证测试测试目标：验证开发组提交的版本是否值得进行系统测试。方法：· 返测随版本提交的测试报告。· 测试系统的基本功能。完成标准：得出继续测试或退回开发组的结论。需考虑的特殊事项：· 此阶段时间不超过一天。· 注意及时总结经验。8、安全性测试测试目标：程序提供的安全性功能符合需求的设计。方法：· 测试用户的安全性，包括用户创建，权限设置，权限的验证（更换用户，用户类型变化等），权限级别等。· 测试项目、素材库、节目的安全性，主

11、要针对是权限的验证。· 测试数据库的安全性，主要是文件的保存和修改。完成标准：程序的安全性功能可以保证用户的正常使用。需考虑的特殊事项：· 此方面经验比较少，需要摸索和总结。9、裸机测试测试目标：在干净的环境上，进行与其他测试环境相同的测试，应包括所有的测试内容。标准是裸机环境上程序运行正常。方法：·在干净的环境上，进行与其他测试环境相同的测试，应包括所有测试内容（一般有一台机器专门用于裸机测试）。· 完成标准：证实干净系统的程序使用也是正常的。需考虑的特殊事项：· 每个新的版本安装前，系统也必须重装（使用GHOST）。· 注意必要的

12、文件的安装（数据库支持文件等）。4.2. 工具此项目将使用以下工具：工具厂商/自行研制版本测试管理Word和ExcelMicrosoftWindows 2000缺陷跟踪Bugzilla4模块名称“信息管理”菜单对应测试用例编号01-01主要功能1、 输入信息2、 查询信息3、 删除信息4、 修改信息5、 信息导出6、 信息导入7、 显示所有信息8、 退出系统测试内容1、 输入工程师信息2、 查询指定工程师信息3、 删除指定工程师信息4、 修改指定工程师信息5、 把工程师信息保存到各个文件夹6、 把工程师信息导入到系统中7、 显示所有工程师信息8、 退出系统优先级5. 资源5.1. 角色下表列出

13、了在此项目的人员配备方面所作的各种假定。注：可适当地删除或添加角色项。 角色推荐的最少资源（所分配的专职角色数量）具体职责或注释测试组长： 进行管理监督的职责如下1、 提供技术指导2、 获取适当的资源3、 生成测试计划，测试方案4、 管理测试数据5、 收集用例6、 参与测试测试员负责执行测试的职责如下1、 执行测试2、 记录结果3、 从错误中恢复（返测报告）4、 收集测试用例测试管理员确保测试环境和资产得到管理和维护的职责如下1、 管理测试系统2、 授予和管理角色对测试系统的访问权5.2. 系统测试项目所需的系统资源。1、 硬件资源：CPU：Pentium 133 MHz 或以上内存：256M

14、B 或以上。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. 可能的影响或风险：· 计划的测试时间，不能满足测试组的要求，主要是功能冻结后的系统测试的时

15、间可能不够。· 测试资源的及时到位（设备和人员）。· 测试人员的熟练程度。· 开发进度的变化，需求或设计的变更。· 开发组的版本控制。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.

16、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密度（系统测试的B