测试计划模板.docx

1、测试计划模板 项目编号：XX系统测试计划文档编号：版本信息：建立日期：创 建 人：审 核 人： 批 准 人： 批准日期：保 管 人：存放位置： 公司LOGO文档修订记录版本号变化状态变更内容修改日期变更人*变化状态：C创建，A增加，M修改，D删除文档审批信息版本号审核人审核日期批准人批准日期备注目 录1 概述 11.1 目的 11.2 假定和约束 11.2.1 假设条件. 11.2.2 约束条件. 11.3 参考资料 22 测试需求 22.1 产品描述 22.2 测试范围 22.3 测试内容 32.3.1 功能测试. 32.3.2 数据和数据库完整性测试 32.3.3 接口测试. 32.3.4

2、 功能测试. 42.3.5 用户界面测试. 42.3.6 安全性和访问控制测试 42.3.7 故障转移和恢复测试 52.3.8 性能测试. 52.3.9 系统部署测试. 52.4 测试优先级 53 项目标准 64 交付工件 65 估算 65.1 规模估算 65.2 工作量估算 66 组织结构和角色 66.1 特殊技能要求 66.2 角色职责 67 资源计划 77.1 软件资源 77.2 硬件资源 77.3 人力资源 78 生命周期 79 测试策略 710 测试进度计划 810.1 里程碑计划 810.2 测试进度计划 911 监控计划 911.1 监控计划 911.2 评审计划 911.3 项

3、目风险 912 质量保证计划 912.1 质量目标 912.2 过程检查 1012.3 产品检查 1012.4 质量报告 1013 培训计划 1014 度量分析计划 1015 附件 1015.1 缺陷级别定义 1015.2 再现程度定义 1115.3 缺陷状态定义 1115.4 测试风险评估 1115.5 附录 111 概述1.1 目的简单介绍被测系统以及被测系统的应用。1.2 假定和约束1.2.1 假设条件1.2.1.1 测试人员本次测试开始之前，要求测试人员： 已阅读需求规格说明书等相关文档； 熟悉被测系统，能够独立进行操作并且完成测试； 能够编写有效的测试用例； 能够正确描述Bug现象，

4、正确选择Bug属性。1.2.1.2 测试环境 测试环境干净、独立、稳定； 测试数据足够且准确、有效；1.2.2 约束条件下面是一些可能会导致计划不准确或影响测试过程的制约条件，这些情况会影响测试进度和测试效果。遇到下列问题，由XX协商解决。 测试数据不充分； 测试环境不稳定或配置不到位； 测试过程中遇到重大阻塞性的问题； 软件的缺陷比较严重，直接影响到测试的继续进行； 开发人员或测试支持人员支持、配合不到位；另外，需要长时间地进行系统稳定性测试，可能导致测试工期延长。1.3 参考资料2 测试需求2.1 产品描述对于测试产品的相关描述信息。2.2 测试范围系统测试、多操作系统平台测试（Windw

5、osXP、Windows2000、Windows98）、性能测试（压力测试、负载测试）、稳定性测试、兼容性测试（与windows2000、XP兼容性）、安装卸载测试和易用性测试。1) 单元测试单元测试主要由开发人员来完成。2) 集成测试集成测试的主要目的是检测系统是否达到需求对业务流程及数据流的处理是否符合标准，检测系统对业务流处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准及要求。此阶段测试基于功能完成的测试。测试的内容包括单元间的接口以及集成后的功能，本项目采用渐增式集成方式。3) 系统测试系统测试是通过与系统的需求规格作比较，发现软件与系统需求规格不相符合或与之矛盾的地方。它将

6、通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在模拟实际运行（使用）环境下，对系统进行的测试。2.3 测试内容 下面列出所有测试点均为测试内容，未列出的本次测试不予考虑。2.3.1 功能测试详见需求功能矩阵.xls。2.3.2 数据和数据库完整性测试数据库和数据库进程作为一个子系统来进行测试。在将测试对象的用户界面用作数据的接口的同时，还将考虑对数据库管理系统（DBMS）进行相关的存储测试。测试目标：方法：完成标准：需考虑的特殊事项：2.3.3 接口测试由于XX其它系统协同工作，所以系统在实际工作中会调中其它系统，同时

7、系统内部功能模块的调用。测试目标：方法：完成标准：需考虑的特殊事项：2.3.4 功能测试试对象的功能测试侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。这种类型的测试基于黑盒方法，即通过图形用户界面 (GUI) 与应用程序交互并分析输出结果来验证应用程序及其内部进程。以下列出的本系统的测试方法概要：测试目标：方法：完成标准：需考虑的特殊事项：2.3.5 用户界面测试通过用户界面 (UI) 测试来核实用户与软件的交互。UI 测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。测试目标

8、：方法：完成标准：需考虑的特殊事项：2.3.6 安全性和访问控制测试由于题库管理系统主要用于组织统考或入学测试，对于安全性要求较高。对于整个系统，需要完整的权限控制，防止某些人恶意的攻击系统，修改原始记录。同时对于数据库中的数据需要定时备份，防止系统数据丢失。此外，系统要求用户在登陆时需要身份验证，严格区分每个角色的使用权限, 安全性的访问控制测试主要集中在对用户权限管理测试模块中。2.3.7 故障转移和恢复测试出现故障时及时方便地找到产生故障的原因和位置，并能方便地进行局部修改。具有对于系统数据丢失的补救措施，保证系统的安全性，可靠性。 此项测试主要集中在数据备份恢复功能模块中。2.3.8

9、性能测试采用测试工具LoadRunner进行测试，测试包括：负载测试、强度测试和稳定性测试。找出系统瓶颈，并进行优化，但系统能达到，要求XX个用户并发情况下，响应时间小于等于15秒。系统支持最高XX个并发，在XXM带宽下，支持XX左右用户的同时访问。2.3.9 系统部署测试系统开发测试完毕后，进行系统部署测试，确保系统的正常运行。测试目标：方法：完成标准：需考虑的特殊事项：2.4 测试优先级测试类型优先级说明3 项目标准达到本次系统测试预定的质量标准：不允许出现“致命”BUG和“严重”BUG；一般“BUG”不超过6个；可以出现微小级别的BUG不超过10个；功能点覆盖率务必达到100%；无易用性

10、问题。4 交付工件 过程工作产品5 估算5.1 规模估算测试用例数：XX条说明：根据题库子系统功能列表.doc功能范围说明：这次开发所要实现22个功能点。加上故障转移和恢复测试、系统部署测试、数据和数据库完整性测试和安全性和访问控制测试。总共要进行测试的功能点为XX个。每个功能点平均用例数在XX条左右，一个功能点包涵，功能测试、流程测试和性能测试三部，此外，还要在WindwosXP、Windows2000、Windows98三个平台上进行测试。因此，测试用例数=XX条：此外三个平台测试用例可以重用，因此实际用例数为XX条，执行用例数为：XX条；此外测试用例数跟着需求变更，做出相应调整。最终用例

11、数，以最终需求为准。1.1 工作量估算 测试工作量：（待定）人月。2 组织结构和角色2.1 特殊技能要求项目中要用到熟练使用自动化测试工具、熟悉在线考务系统经验的人。2.2 角色职责角色职责描述姓名联系方式测试PM 批准测试计划、配置管理计划、质量保证计划 确定测试用例、确定测试用例的优先级并实施测试用例。 制定和修改项目的组织结构和配置管理策略； 负责管理项目成员严格按照测试计划进行测试。Tester 编写测试用例。 开发自动化测试脚本。 执行测试。CM 负责编写和维护配置管理计划； 负责配置库的建议和维护； 负责配置项的建立和维护； 负责配置库权限的分配； 软件配置管理工具的日常管理与维护

12、； 负责基线的标识及发布； 负责开发人员软件配置管理方面的培训工作； 上报配置状态报告。Developer 测试支持工作 修改bug3 资源计划3.1 软件资源软件资源版本获取方式与时间使用说明3.2 硬件资源硬件资源配置获取方式与时间使用说明3.3 人力资源 测试周期为XX年XX月XX日XX年XX月XX日； 测试人员每日工作时间为9:0018:00，每周工作五天； 测试人员正常每天的工作时间平均8小时。封闭开发期间每天的工作时间13小时4 生命周期生命周期模型：V模型。原因：本项目的需求明确、理解充分，并且较为稳定，由于工期比较紧，确保测试能按时完成，测试在开发工作的始执行。需求阶段进行测试

13、准备工作。5 测试策略下面是本测试各执行阶段的主要活动预计的流程图开发必要的测试工具准备测试数据填写需求功能矩阵编写测试报告获取测试需求编写测试报告测试评估本次测试只做系统测试。主要是以手工和自动化工具相结合的方式测试系统在基本功能和性能方面符合需求规格说明书和用户普遍期望的程度。找出系统在功能和性能方面与需求不符合的地方。关于功能测试的测试用例，请参见测试用例文档题库管理系统测试用例；6 测试进度计划6.1 里程碑计划里程碑名称时间6.2 测试进度计划7 监控计划7.1 监控计划 项目组成员每天填写工作日志，项目经理根据项目组成员提交的日志汇总成项目日报； 项目每周召开一次项目例会。每周提交

14、项目周报。 根据不同的时机项目经理召集项目组成员召开会议，通报阶段性工作情况及下阶段计划安排7.2 评审计划评审对象评审时机评审方式评审参加人评审确认人7.3 项目风险8 质量保证计划8.1 质量目标文档错误率文档名称错误数测试用例目标测试用例密度覆盖率目标测试阶段覆盖率BUG率目标测试阶段Bug摘出目标8.2 过程检查过程检查时机检查要点需求获取测试设计测试执行测试评估测试总结8.3 产品检查工作产品 检查时机检查要点需求跟踪矩阵测试计划测试用例缺陷报告测试报告8.4 质量报告9 培训计划10 度量分析计划11 附件11.1 缺陷级别定义 致命BUG：直接发生导致系统死机、蓝屏、响应时间过长

15、、主要功能没有实现、重大的阻塞性的问题（即：后续依赖此操作的其他重要操作无法进行）。 严重BUG：程序发生错误，但不影响系统和其它程序运行的，次要功能没有实现或间接发生的（经过几步不相关操作后发生的）导致主要需求不能实现，包括主要界面的文字错误等。 一般BUG：间接发生的（经过几步不相关操作后发生的）导致次要需求不能正常实现。 微小BUG：不影响软件的功能，但影响软件的品质。11.2 再现程度定义 每次出现：出现概率100% 经常出现：出现概率大于20% 很少出现：出现概率小于20% 出现一次：在整个测试工作中只出现一次11.3 缺陷状态定义 待修复：测试人员发现的，开发人员还没有修复的缺陷

16、待验证：开发人员已经修改，测试人员还没有验证的缺陷 已解决：已经修复的缺陷 遗留：经评审后认定在本版本中可以不修改的缺陷11.4 测试风险评估根据项目测试任务量大，测试时间紧张的特点，以下列出项目测试中可能存在的风险： 在执行测试过程中由于测试人员的离职或请假，导致测试周期的延长； 测试过程中非人为因素的测试用例的丢失（数据备份失效、病毒攻击等），导致执行测试周期延长；， 测试数据设计覆盖率未达到相应的及别，再次整理测试数据导致测试时间延长；针对以上可能存在的风险，采取的措施为： 部门备有项目测试机动人员，确保项目测试过程中不会因测试人员的缺岗而导致测试周期的延长； 在测试过程中，由专人负责项目配置，以防止非人为因素造成的测试用例丢失；为项目测试配备资深的测试人员，确保测试数据的高覆盖率11.5 附录以下是一些与测试有关的任务： 制定测试计划- 确定测试需求- 评估风险- 制定测试策略- 确定测试资源- 创建时间表- 生成测试计划 设计测试- 准备工作量分析文档- 确定并说明测试用例- 确定并结构化测试过程- 复审和评估测试覆盖 执行测试- 执行测试过程- 评估测试的执行情况- 恢复暂停的测试- 核实结果- 调查意外结果- 记录缺陷 评估测试- 评估测试用例覆盖- 评估代码覆盖- 分析缺陷确定是否达到了测试完成标准与成功标准