测试计划模板Word格式文档下载.docx
《测试计划模板Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《测试计划模板Word格式文档下载.docx（15页珍藏版）》请在冰豆网上搜索。
1.3
参考资料
2
2
测试需求
2.1
产品描述
2.2
测试范围
2.3
测试内容
3
2.3.1
功能测试..........
2.3.2
数据和数据库完整性测试
2.3.3
接口测试..........
2.3.4
4
2.3.5
用户界面测试......
2.3.6
安全性和访问控制测试
2.3.7
故障转移和恢复测试
5
2.3.8
性能测试..........
2.3.9
系统部署测试......
2.4
测试优先级
3
项目标准
6
4
交付工件
5
估算
5.1
规模估算
5.2
工作量估算
6
组织结构和角色
6.1
特殊技能要求
6.2
角色职责
7
资源计划
7
7.1
软件资源
7.2
硬件资源
7.3
人力资源
8
生命周期
9
测试策略
10
测试进度计划
8
10.1
里程碑计划
10.2
9
11
监控计划
11.1
11.2
评审计划
11.3
项目风险
12
质量保证计划
12.1
质量目标
12.2
过程检查
10
12.3
产品检查
12.4
质量报告
13
培训计划
14
度量分析计划
15
附件
15.1
缺陷级别定义
15.2
再现程度定义
11
15.3
缺陷状态定义
15.4
测试风险评估
15.5
附录
1概述
1.1目的
简单介绍被测系统以及被测系统的应用。
1.2假定和约束
1.2.1假设条件
1.2.1.1测试人员
本次测试开始之前，要求测试人员：
已阅读需求规格说明书等相关文档；
熟悉被测系统，能够独立进行操作并且完成测试；
能够编写有效的测试用例；
能够正确描述Bug现象，正确选择Bug属性。
1.2.1.2测试环境
测试环境干净、独立、稳定；
测试数据足够且准确、有效；
1.2.2约束条件
下面是一些可能会导致计划不准确或影响测试过程的制约条件，这些情况会影响测试进度和测试效果。
遇到下列问题，由XX协商解决。
测试数据不充分；
测试环境不稳定或配置不到位；
测试过程中遇到重大阻塞性的问题；
软件的缺陷比较严重，直接影响到测试的继续进行；
开发人员或测试支持人员支持、配合不到位；
另外，需要长时间地进行系统稳定性测试，可能导致测试工期延长。
1.3参考资料
2测试需求
2.1产品描述
对于测试产品的相关描述信息。
2.2测试范围
系统测试、多操作系统平台测试（WindwosXP、Windows2000、Windows98）、性能测试（压力测试、负载测试）、稳定性测试、兼容性测试（与windows2000、XP兼容性）、安装卸载测试和易用性测试。
1）单元测试
单元测试主要由开发人员来完成。
2）集成测试
集成测试的主要目的是检测系统是否达到需求对业务流程及数据流的处理是否符合标准，检测系统对业务流处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准及要求。
此阶段测试基于功能完成的测试。
测试的内容包括单元间的接口以及集成后的功能，本项目采用渐增式集成方式。
3）系统测试
系统测试是通过与系统的需求规格作比较，发现软件与系统需求规格不相符合或与之矛盾的地方。
它将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在模拟实际运行（使用）环境下，对系统进行的测试。
2.3测试内容
下面列出所有测试点均为测试内容，未列出的本次测试不予考虑。
2.3.1功能测试
详见《需求功能矩阵.xls》。
2.3.2数据和数据库完整性测试
数据库和数据库进程作为一个子系统来进行测试。
在将测试对象的用户界面用作数据的接口的同时，还将考虑对数据库管理系统（DBMS）进行相关的存储测试。
测试目标：
方法：
完成标准：
需考虑的特殊事项：
2.3.3接口测试
由于XX其它系统协同工作，所以系统在实际工作中会调中其它系统，同时系统内部功能模块的调用。
2.3.4功能测试
试对象的功能测试侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。
这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。
这种类型的测试基于黑盒方法，即通过图形用户界面（GUI）与应用程序交互并分析输出结果来验证应用程序及其内部进程。
以下列出的本系统的测试方法概要：
2.3.5用户界面测试
通过用户界面（UI）测试来核实用户与软件的交互。
UI测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。
2.3.6安全性和访问控制测试
由于题库管理系统主要用于组织统考或入学测试，对于安全性要求较高。
对于整个系统，需要完整的权限控制，防止某些人恶意的攻击系统，修改原始记录。
同时对于数据库中的数据需要定时备份，防止系统数据丢失。
此外，系统要求用户在登陆时需要身份验证，严格区分每个角色的使用权限,安全性的访问控制测试主要集中在对用户权限管理测试模块中。
2.3.7故障转移和恢复测试
出现故障时及时方便地找到产生故障的原因和位置，并能方便地进行局部修改。
具有对于系统数据丢失的补救措施，保证系统的安全性，可靠性。
此项测试主要集中在数据备份\恢复功能模块中。
2.3.8性能测试
采用测试工具LoadRunner进行测试，测试包括：
负载测试、强度测试和稳定性测试。
找出系统瓶颈，并进行优化，但系统能达到，要求XX个用户并发情况下，响应时间小于等于15秒。
系统支持最高XX个并发，在XXM带宽下，支持XX左右用户的同时访问。
2.3.9系统部署测试
系统开发测试完毕后，进行系统部署测试，确保系统的正常运行。
2.4测试优先级
测试类型
优先级
说明
3项目标准
达到本次系统测试预定的质量标准：
不允许出现“致命”BUG和“严重”BUG；
一般“BUG”不超过6个；
可以出现微小级别的BUG不超过10个；
功能点覆盖率务必达到100%；
无易用性问题。
4交付工件
过程
工作产品
5估算
5.1规模估算
测试用例数：
XX条
说明：
根据《题库子系统功能列表.doc》功能范围说明：
这次开发所要实现22个功能点。
加上故障转移和恢复测试、系统部署测试、数据和数据库完整性测试和安全性和访问控制测试。
总共要进行测试的功能点为XX个。
每个功能点平均用例数在XX条左右，一个功能点包涵，功能测试、流程测试和性能测试三部，此外，还要在WindwosXP、Windows2000、Windows98三个平台上进行测试。
因此，测试用例数=XX条：
此外三个平台测试用例可以重用，因此实际用例数为XX条，执行用例数为：
XX条；
此外测试用例数跟着需求变更，做出相应调整。
最终用例数，以最终需求为准。
1.1工作量估算
测试工作量：
（待定）人月。
2组织结构和角色
2.1特殊技能要求
项目中要用到熟练使用自动化测试工具、熟悉在线考务系统经验的人。
2.2角色职责
角色
职责描述
姓名
联系方式
测试PM
✓批准测试计划、配置管理计划、质量保证计划
✓确定测试用例、确定测试用例的优先级并实施测试用例。
✓制定和修改项目的组织结构和配置管理策略；
✓负责管理项目成员严格按照测试计划进行测试。
Tester
✓编写测试用例。
✓开发自动化测试脚本。
✓执行测试。
CM
✓负责编写和维护《配置管理计划》；
✓负责配置库的建议和维护；
✓负责配置项的建立和维护；
✓负责配置库权限的分配；
✓软件配置管理工具的日常管理与维护；
✓负责基线的标识及发布；
✓负责开发人员软件配置管理方面的培训工作；
✓上报配置状态报告。
Developer
✓测试支持工作
✓修改bug
3资源计划
3.1软件资源
软件资源
版本
获取方式与时间
使用说明
3.2硬件资源
硬件资源
配置
3.3人力资源
测试周期为XX年XX月XX日－XX年XX月XX日；
测试人员每日工作时间为9:
00－18:
00，每周工作五天；
测试人员正常每天的工作时间平均8小时。
封闭开发期间每天的工作时间13小时
4生命周期
生命周期模型：
V模型。
原因：
本项目的需求明确、理解充分，并且较为稳定，由于工期比较紧，确保测试能按时完成，测试在开发工作的始执行。
需求阶段进行测试准备工作。
5测试策略
下面是本测试各执行阶段的主要活动预计的流程图
开发必要的测试工具
准备测试数据
填写《需求功能矩阵》
编写测试报告
获取测试需求
测试评估
本次测试只做系统测试。
主要是以手工和自动化工具相结合的方式测试系统在基本功能和性能方面符合需求规格说明书和用户普遍期望的程度。
找出系统在功能和性能方面与需求不符合的地方。
关于功能测试的测试用例，请参见测试用例文档《题库管理系统测试用例》；
6测试进度计划
6.1里程碑计划
里程碑名称
时间
6.2测试进度计划
7监控计划
7.1监控计划
✓项目组成员每天填写工作日志，项目经理根据项目组成员提交的日志汇总成项目日报；
✓项目每周召开一次项目例会。
每周提交《项目周报》。
✓根据不同的时机项目经理召集项目组成员召开会议，通报阶段性工作情况及下阶段计划安排
7.2评审计划
评审对象
评审时机
评审方式
评审参加人
评审确认人
7.3项目风险
8质量保证计划
8.1质量目标
文档错误率
文档名称
错误数
测试用例目标
测试用例
密度
覆盖率目标
测试阶段
覆盖率
BUG率目标
Bug摘出目标
8.2过程检查
过程
检查时机
检查要点
需求获取
测试设计
测试执行
测试总结
8.3产品检查
工作产品
需求跟踪矩阵
测试计划
缺陷报告
测试报告
8.4质量报告
9培训计划
10度量分析计划
11附件
11.1缺陷级别定义
致命BUG：
直接发生导致系统死机、蓝屏、响应时间过长、主要功能没有实现、重大的阻塞性的问题（即：
后续依赖此操作的其他重要操作无法进行）。
严重BUG：
程序发生错误，但不影响系统和其它程序运行的，次要功能没有实现或间接发生的（经过几步不相关操作后发生的）导致主要需求不能实现，包括主要界面的文字错误等。
一般BUG：
间接发生的（经过几步不相关操作后发生的）导致次要需求不能正常实现。
微小BUG：
不影响软件的功能，但影响软件的品质。
11.2再现程度定义
每次出现：
出现概率100%
经常出现：
出现概率大于20%
很少出现：
出现概率小于20%
出现一次：
在整个测试工作中只出现一次
11.3缺陷状态定义
待修复：
测试人员发现的，开发人员还没有修复的缺陷
待验证：
开发人员已经修改，测试人员还没有验证的缺陷
已解决：
已经修复的缺陷
遗留：
经评审后认定在本版本中可以不修改的缺陷
11.4测试风险评估
根据项目测试任务量大，测试时间紧张的特点，以下列出项目测试中可能存在的风险：
在执行测试过程中由于测试人员的离职或请假，导致测试周期的延长；
测试过程中非人为因素的测试用例的丢失（数据备份失效、病毒攻击等），导致执行测试周期延长；
，
测试数据设计覆盖率未达到相应的及别，再次整理测试数据导致测试时间延长；
针对以上可能存在的风险，采取的措施为：
部门备有项目测试机动人员，确保项目测试过程中不会因测试人员的缺岗而导致测试周期的延长；
在测试过程中，由专人负责项目配置，以防止非人为因素造成的测试用例丢失；
为项目测试配备资深的测试人员，确保测试数据的高覆盖率
11.5附录
以下是一些与测试有关的任务：
•
制定测试计划
-
确定测试需求
评估风险
制定测试策略
确定测试资源
创建时间表
生成测试计划
设计测试
准备工作量分析文档
确定并说明测试用例
确定并结构化测试过程
复审和评估测试覆盖
执行测试
执行测试过程
评估测试的执行情况
恢复暂停的测试
核实结果
调查意外结果
记录缺陷
评估测试
评估测试用例覆盖
评估代码覆盖
分析缺陷
确定是否达到了测试完成标准与成功标准
升级会员 