项目测试计划Word格式文档下载.docx
《项目测试计划Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《项目测试计划Word格式文档下载.docx（22页珍藏版）》请在冰点文库上搜索。
测试启动条件-8-
5.3
测试用例开发-9-
5.3.1
用户文档-9-
5.3.2
功能性-9-
5.3.3
可靠性-10-
5.3.4
易用性-10-
5.3.5
可维护性-11-
5.3.6
可移植性-12-
5.4
测试过程ID命名规则-12-
5.5
评审-12-
6．测试执行-12-
7．缺陷管理-12-
7.1缺陷报告-12-
7.2缺陷状态-13-
7.3缺陷严重级别-13-
7.4缺陷优先级-14-
8．中止及恢复条件-14-
9．可交付成果-14-
10．假设-14-
1．简介
测试目的
本次测试是针对用户简称数字化校园建设项目进行的系统测试，目的是为判定该系统是否满足《项目全称-需求规格说明书.doc》中规定的功能提供客观的依据。
测试目标
判定测试开发目标中所要求的系统功能是否具备，执行结果是否正确，明确在用户文档、功能性、可靠性、易用性、可维护性、可移植性、性能和安全性八个方面进行测试。
测试范围
参照用户简称数字化校园建设项目需求文档及相关的测试类型，在此确定测试范围，规定测试内容。
测试内容从商业需求或技术需求中归纳提取，在下表逐条表述。
第1页
共1页
序号
测试分类
测试内容
1
T-UD
用户文档评审
2
T-F
功能性测试
3
T-R
可靠性测试
4
T-U
易用性测试
5
T-M
可维护性测试
6
T-P
可移植性测试
7
T-E
性能测试
8
T-S
安全性测试
测试环境配置
软件环境：
终端类别
操作系统
相关应用软件
客户端
WindowsXPprofessional
IE7或IE8
服务器
WindowsServer2008R2
Sunjdk1.6.0_2264bit、apache-tomcat-6.0.2964bit、MicrosoftWindowsSQLserver2008R2、MicrosoftExchangeServer2011、MicrosoftOCS2007
硬件环境：
机器型号
配置说明
DELLOptiPlex380
处理器：
Intel奔腾双核E5300
内存大小：
2048M
DELLPowerEdgeT410
IntelXeonE5504
4096M
1.5测试工具
工具名称
项目用途
工具描述
TestDirector
测试管理工具
TestDirector是全球最大的软件测试工具提供商MercuryInteractive公司生产的企业级测试管理工具，也是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。
通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。
LoadRunner
性能测试工具
LoadRunner是一种预测系统行为和性能的负载测试工具。
通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。
通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。
LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。
参考资料
定义
测试策略的定义：
Ø
T_UD：
T_F：
功能性测试
T_R：
可靠性测试
T_U：
易用性测试
T_M：
可维护性测试
T_P：
可移植性测试
T_E：
性能测试
T_S：
安全性测试
模块名称的定义：
项目编号_CSYL_SZKT：
数字化课堂
项目编号_CSYL_ZZCJ：
资源采集系统
项目编号_CSYL_ZXXX：
在线自主学习平台
项目编号_CSYL_TSZY：
学校特色资源
项目编号_CSYL_SSHP：
师生互评系统
项目编号_CSYL_ZJKS：
组卷考试分校系统
项目编号_CSYL_WZYJ：
无纸化阅卷
项目编号_CSYL_PCFK：
评测反馈系统
项目编号_CSYL_JWGZ：
教务工作管理
项目编号_CSYL_RSGL：
人事管理系统
项目编号_CSYL_JSPC：
教师专业发展评测系统
项目编号_CSYL_XBPX：
校本培训平台
项目编号_CSYL_JSXX：
教师信息管理与检索系统
项目编号_CSYL_XYWH：
校园文化展示系统
项目编号_CSYL_JXHD：
家校互动
项目编号_CSYL_XSGH：
学生生涯规划平台
项目编号_CSYL_XLPC：
心理健康评测系统
项目编号_CSYL_DHD：
少先队活动管理系统
项目编号_CSYL_KFHP：
库房货品管理系统
项目编号_CSYL_SBSS：
设备实施管理系统
项目编号_CSYL_CMIS：
CMIS接口
项目编号_CSYL_PJK：
排监考系统
项目编号_CSYL_JWPK：
教务排课
项目编号_CSYL_KBGL：
课表管理系统
文档
GB/T11457软件工程术语
GB8566计算机软件开发规范
GB8567计算机软件产品开发文件编制指南
GB/T12505计算机软件配置管理计划规范
ISO9001:
2008质量管理体系要求
项目全称-合同
项目全称-需求规格说明书
2.测试策略
2.1功能测试
2.1.1类型简介
类型介绍：
对需求分析说明书中要求的功能进行功能符合性测试。
测试目标：
对系统中划分出来的主要功能进行测试，确保合理准确地完成需求说明。
测试技术：
黑盒测试技术，对系统的主要服务功能进行测试。
完成标准：
主要业务流程能够正确实现业务逻辑。
测试范围：
全部功能。
2.2性能测试
2.2.1性能测试
合理评测系统性能，确保页面响应时间符合要求。
本系统的性能测试包含测试类型有：
恢复/容错/可靠性测试、强度/疲劳测试、并发测试、负载/压力测试、容量/大数据量测试
合理评测系统瓶颈代码部分，确保页面响应时间符合要求。
性能测试工具LoadRunner
关键性能测试点全部通过测试，对相应的问题产生合理的数据评测结果。
主要功能
2.2.2安全性测试
对软件和数据进行非授权的故意或意外访问的测试，验证系统的安全性满足需求分析说明书。
系统中涉及到的用户角色权限控制合理。
系统网络安全性。
数据库的安全保密。
黑盒测试技术。
用户角色权限访问符合需求分析说明。
系统网络安全和数据库安全符合需求分析说明。
重点测试现系统网络安全性和数据库的安全保密机制。
2.2.3强度测试
对功能进行强度测试检查程序对异常情况的抵抗能力。
定量地增长数据输入率，检查系统平台的反映能力。
技术：
对系统需求分析说明书中指定的功能进行了合理的强度测试。
重点功能。
2.2.4疲劳测试
对系统进行长时间连续运行测试，并模拟相当的业务量，从而评价系统是否能够满足长时间连续运行的目标。
按照需求规格说明，设置各种不同业务的混合业务场景，测试长时间运行时系统各项性能指标，考察系统性能指标的变化趋势，统计长时间运行条件下的出错概率。
性能测试工具LoadRunner。
用系统正常业务情况下并发用户数为基础，进行一定时间的疲劳测试。
根据需求要求功能进行对系统最短连续运行时间的要求的测试关键性能测试点全部通过测试，对相应的问题产生合理的数据评测结果。
2.2.5并发测试
测试多用户并发访问同一个应用、同一个模块的问题。
通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
其主要目的是发现系统中可能隐藏的并发访问的问题。
关注系统可能存在的并发问题，例如系统中的内容泄漏、线程锁和资源争用方面的问题。
测试技术：
对系统要求的并发性能点全部通过测试，对相应产生的问题合理的评估结果。
2.2.6负载/压力测试
在一定约束条件下不断地对系统施加压力，通过测试系统反映出来的所能承受的并发用户量、运行时间、数据量，以确定系统所能承受的处理极限。
负载压力测试是性能测试的重要组成部分，负载压力测试包括并发性能测试、疲劳强度测试、大数据量测试等内容。
负载测试是通过逐步增加系统负载，确定测试系统性能的变化。
本测试主要用于验证系统的并发处理能力。
一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。
对系统要求的负载/压力全部通过测试，对相应产生的问题合理的评估结果。
2.3用户接口测试
2.3.1测试类型简介
核实用户与软件之间的交互友好，并符合公司或行业规范。
包括易理解性、易学性、易操作性
系统提供的功能界面能够比较便捷地实现功能需求。
界面友好。
黑盒测试技术
成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准
注意用户特定的使用习惯（例如企业色彩等）
3．人员安排
角色
人员
职责
项目经理
项目经理姓名
评审并批准项目计划及有关报告；
组织并确保团队工作；
控制项目执行；
评估项目绩效；
与有关人员进行沟通。
测试经理
项目计划编制；
协调并实施项目计划中确定的活动；
识别测试环境需求；
负责设计测试用例；
为其他人员提供技术支持。
测试人员
郑海艳、秦建青
翁正然、李灵夏
执行测试活动；
在项目计划制订阶段，识别项目活动，估计每项活动所需的时间。
环境准备人员
秦建青
提供资源保障；
建立并维护测试环境。
质量保证人员
QA姓名
确定项目质量目标；
制订并实施质量计划；
监督、指导项目活动的执行过程。
4．时间安排
事件
开始时间
结束时间
编制测试计划
测试计划评审、修改
编制测试用例
测试用例评审（内部）
测试用例修改
第一轮功能测试
第一轮测试总结评审（内部）
第二轮功能测试
联调测试、压力测试
第二轮测试后总结评审（内部）
系统回归测试
编制测试报告
提交测试文档
5．系统测试
测试方法
在此规定用于用户简称数字化校园建设项目测试的测试方法。
功能测试主要采用手动测试方法，对软件产品进行黑盒测试。
性能测试主要采用自动测试方法，使用工具为LoadRunner。
测试启动条件
在此规定，在开始进行测试时必需满足的条件。
这些条件涉及：
测试计划、测试流程、测试进度的制订已完成，并经过严格评审；
缺陷跟踪与管理系统已搭建；
测试所需的资源已经到位；
测试组人员配置合理，测试人员的工作技能符合测试要求；
测试所需的软、硬件和操作系统等测试环境准备完毕。
测试用例开发
根据测试范围规定的内容，逐条设计测试需求及完成该测试需求的测试过程、测试条件，构造本次测试的测试用例，编写决策树。
用户文档
表1用户文档
第1页
共1页
测试需求
测试过程说明
过程标引
完整性
软件使用所需信息
UD-01
产品描述中说明的所有功能
UD-02
程序中用户可调用的所有功能
UD-03
说明产品描述中给出的所有边界值
UD-04
软件安装所需要的信息
UD-05
软件维护所需要的信息
UD-06
正确性
文档中所有信息正确，没有歧义和错误的表达
UD-07
一致性
文档自身内容或相互之间以及与产品描述之间，相互不矛盾，且术语一致
UD-08
用户手册和操作手册与软件实际运行情况相符
UD-09
易理解程度
文档对正常使用其产品的一般用户是容易理解的
UD-10
易浏览程度
用户文档易于浏览，相互关系明确
UD-11
用户文档有目录表或索引表
UD-12
功能性
表2功能表现
功能点
根据用户文档列出所有功能点，检验其正确性
F-01
验证程序与产品描述、用户文档中的全部说明相对应，一致性
F-02
可靠性
表3可靠性
成熟性
使用的容量达到规定的极限时,系统不能崩溃、不能异常退出也不丢失数据
R-01
试图使用的容量超出规定极限时，系统不能崩溃、不能异常退出也不丢失数据
R-02
产品描述中列出的其他程序或用户造成的错误输入时，系统不能崩溃也不丢失数据
R-03
输入用户文档中明确规定的非法指令时，系统不能崩溃也不丢失数据
R-04
不会因掉电、异常退出、网络异常中断等原因而使软件或数据遭到破坏
R-05
容错性
能屏蔽用户的误操作
R-06
对错误有正确提示
R-07
输入错误数据时，系统不能崩溃、不能异常退出也不丢失数据
R-08
有错误操作时，系统不能崩溃、不能异常退出也不丢失数据
R-09
易恢复性
系统运行失效后，应能较快重建系统
R-10
数据校验机制
应对数据项之间的逻辑关系进行校验，保证数据的有效性
R-11
应保证数据的完整性和一致性，不会因删除或反复的更新而被破坏或留下垃圾数据
R-12
对不符合要求的输入数据，系统应使用中文给出简洁、准确的提示信息，必要时应给出帮助
R-13
易用性
表4易用性
易理解性
通过选择适当的术语、图形表示、背景信息和帮助，帮助用户理解、使用
U-01
出错消息中提供差错产生的原因和纠正的详细信息
U-02
易浏览性
数据媒体具有产品标识，可辨别编号或文本
U-03
具有必要的信息，指导用户使用程序
U-04
输入、输出设计规矩，输出结果应简洁、直观、美观、方便阅读、易懂和使用
U-05
人机界面简洁、美观、实用，风格相对一致，符合办公习惯
U-06
在界面、人机交互、输出中的用语应与业务用语一致
U-07
易操作性
具有严重后果的功能执行可逆，或者给出明显警告，执行前要求确认
U-08
软件操作简便，系统支持标准的鼠标、键盘操作，支持鼠标的单击、双击和右键操作，支持快捷键操作
U-09
提供辅助输入手段（如选择输入、默认值等），数据检索方便、灵活
U-10
根据用户熟练程度（外行、初学、熟练）和使用频度，能提供不同的操作方式或用户界面
U-11
可维护性
表5可维护性
易分析性
系统可以正确判断缺陷或失效原因
M-01
对于软件运行错误，应当提示清晰，为用户和系统管理员自己解决问题提供可能
M-02
易改变性
对相关配置文件、库、表的参数可以提供方便的修改
M-03
对于非程序内部错误，由数据元素属性设置、控制规则不当而引起的软件运行错误，软件应为系统管理员提供自行修正的手段
M-04
软件应充分考虑在设计环境与适用范围下不同用户的要求，为用户进行本地化配置提供手段
M-05
稳定性
系统在测试过程中运行稳定
M-06
可移植性
表6可移植性
适应性
软件可适应不同的规定环境（如：
不同的网络环境）
P-01
兼容性
硬件设备兼容性
P-02
软件（如：
操作系统、数据库、WEB服务器等）兼容性
P-03
测试过程ID命名规则
测试用例ID由四部分组成表示，左起第一部分字符表示项目名称，第二部分字符表示文档类型，第三部分字符表示模块名称，第四部分数字表示测试用例编号。
评审
测试计划由项目经理、技术经理和质量保证人员进行评审。
6．测试执行
根据测试计划中相关测试环境的内容，检查测试环境（包括硬件及软件），确保测试环境符合要求；
对于测试用例的描述信息，按测试意图对每一个测试用例设计操作流程中重要环节的动作、输入数据和预期的反映（注：
此流程可不必详细到每一个具体的步骤，但应确保测试执行人员可以据此信息顺利执行，而不必询问测试用例的开发人员）；
执行测试活动，并记录所使用的机器及执行日期，对于每个测试用例还应记录关键操作步骤、输入数据以及任何与测试人员预期结果不符的系统响应；
每个测试用例执行完毕后，视具体情况对系统进行备份或根据备份数据对系统进行恢复。
7．缺陷管理
依照设计好的测试用例对产品进行测试，将发现的缺陷，包括功能、界面，按照用例中的测试号分别记录，保证各类缺陷记录的维护、分配和修改。
7.1缺陷报告
使用TD管理工具对缺陷进行跟踪和管理，项目完成时所提交的报告包括如下内容：
缺陷ID；
项目名称；
样品版本；
测试平台；
操作系统；
功能模块名；
缺陷优先级；
可重现性；
提交人；
确认人；
缺陷问题摘要；
缺陷详细描述。
7.2缺陷状态
Bug状态（Status）：
指缺陷通过一个跟踪修复过程的进展情况。
包括New、Open、Reopen、Fixed、Closed及Rejected等
New为测试人员新问题提交所标志的状态。
Open为任务分配人（开发组长/经理）对该问题准备进行修改并对该问题分配修改人员所标志的状态。
Bug解决中的状态，由任务分配人改变。
对没有进入此状态的Bug，程序员不用管。
Postponed延后。
由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的Bug。
Fixed为开发人员修改问题后所标志的状态，修改后还未测试。
Rejected开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。
由Bug分配人或者开发人员来设置。
Reopen为测试人员对修改问题进行验证后没有通过所标志的状态；
或者已经修改正确的问题，又重新出现错误。
由测试人员改变。
Closed为测试人员对修改问题进行验证后通过所标志的状态。
7.3缺陷严重级别
Bug严重级别（Severity，Bug级别）：
是指因缺陷引起的故障对软件产品的影响程度。
由测试人员指定。
Crash错误导致了死机、产品失败（“崩溃”）、系统悬挂无法操作；
Major功能未实现或导致一个特性不能运行并且不可能有替代方案；
Minor错误导致了一个特性不能运行但可有一个替代方案；
Trivial错误是表面化或微小的（提示信息不太准确友好、错别字、UI布局或罕见故障等），对功能几乎没有影响，产品及属性仍可使用；
NicetoHave（建议）建设性的意见或建议。
7.4缺陷优先级
Bug优先级（Priority）：
指缺陷必须被修复的紧急程度。
由Bug分配者（开发组长/经理）指定。
5-Urgent阻止相关开发人员的进一步开发活动，立即进行修复工作；
阻止与此密切相关功能的进一步测试
4-VeryHigh必须修改，发版前必须修正
3-High必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正
2-Medium如果时间允许应该修改
Low允许不修改
8．中止及恢复条件
下面任何标准满足时，测试活动就可能暂停：
出现了造成产品不能正确部署的失败；
需求中重要的测试失败，阻止许多其他需求不能执行。
如果测试暂停，下列所有标准满足时，测试重新开始：
开发组和发行工程组成功安装，并测试了产品的基本功能。
9．可交付成果
本项目结束时，应提交下列结果：
《项目全称-测试计划.doc》
《项目全称-测试用例.xls》
《项目全称-测试报告.doc》
10．假设
本测试开始前，系统已通过开发单位的单元测试和集成测试；
在测试执行前，缺陷管理工具准备就绪，有关人员的用户及权限设置完毕；
测试组在测试前必须获得被测软件的需求规格
升级会员 