测试方案模板.docx
《测试方案模板.docx》由会员分享，可在线阅读，更多相关《测试方案模板.docx（16页珍藏版）》请在冰点文库上搜索。
测试方案模板
XX市XX软件开发项目
内部测试方案
修订人签字：
审核人签字：
批准人签字：
日期：
日期：
日期：
修订历史纪录变更类型：
增加/修订/删除
版本号
日期
变更类型
修改人
摘要
备注
V1.0
1
引言
1.1系统概述
随着广大XX市民百姓对住房需求的增加，住房市场呈现高速发展趋势，管理中心各项业务得到了快速发展。
业务的发展与信息系统的发展是相辅相成的，住房资金业务的快速发展、信息技术日新月异的发展和广大市民百姓对政府服务水平预期的不断提高，对管理中心信息化系统的建设提出了更高要求。
为实现管理中心未来五年业务发展目标，通过业务需求驱动和先进技术需求驱动重构管理中心核心业务系统。
本次系统重建的业务需求主要包括创新面向个人办理业务的业务模式、丰富服务渠道、优化业务流程、提高资金管理水平、有效管控风险、提高办公效率，促进信息共享等方面；技术需求包括构建全新技术架构重构核心系统、运用云计算和大数据技术有效处理数据支持决策分析、持续提升安全体系建设、持续提升IT服务保障体系建设、升级基础设施条件等。
1.2文档概述
本文档描述了XX市XX管理中心系统内部测试阶段工作的相关情况，内容包括进行测试的环境、测试工作的标识以及测试工作的时间安排等，在实际工作中指导测试人员完成测试工作。
主要包括以下几点目的：
●尽可能发现被测试软件中的错误，以便开发人员进行修正，提高软件的可靠性；
●确定测试策略，并对测试策略加以说明。
另，本文档不涉及性能测试，具体内容见性能测试方案；
●确定所需资源，对测试工作量进行估计；
●客观反映产品中存在的缺陷，为提高产品质量服务；
●完成本阶段的测试工作，为产品交付做准备。
1.3范围
设计针对XX市XX中心业务系统的系统测试—功能测试方案。
通过上述方案用以验证：
●产品功能是否满足需求规定并能够正常运行——功能测试；
●用户界面是否与需求保持一致，保证用户界面的友好性、易操作性——用户界面测试；
●产品性能是否满足需求规定并能够正常运行——性能测试；
1.4目标读者及阅读建议
目标读者
阅读建议
项目经理及评审人员
全文档仔细阅读
测试负责人及测试工程师
全文档仔细阅读
开发工程师
仔细阅读“章节2”-“章节4”，其他部分了解性阅读
1.5参考文档
文档
参考内容
作者或来源
使用备注
GBT-8567-2006计算机软件文档编制规范：
软件测试计划（STP）
文档格式
确定文档格式及涉及内容
需求规格说明书
项目组
确定测试需求及策略
大/中日程计划
测试计划
项目组
确定测试计划及人员安排
2软件测试环境
2.1测试环境
硬件用途
客户端
硬件
配置信息
数量
软件分类
软件名称
版本
操作系统
浏览器
数据库客户端
服务器
硬件
配置信息
数量
软件分类
软件名称
版本
操作系统
WEB中间件
数据库
2.2参与组织
参与方
人员
提供资源
参与工作
参与阶段
参与时间
备注
∙
∙
∙
∙
∙
∙
∙
∙
∙
∙
2.3人员角色
下表列出了在项目内部测试工作过程中的人员配备：
角色
人员
职责
项目经理
∙提供技术指导并获取适当资源
∙负责整个项目中的协调工作
测试负责人
∙编写测试方案、计划
∙项目测试的日常管理工作
∙监控测试工作，规避风险
∙编写系统测试报告等
测试工程师
∙编制和维护测试用例
∙执行测试并记录结果
∙缺陷跟踪
开发工程师
∙对程序缺陷进行修改
∙程序新版本发布
∙必要时参加进行功能测试
2.4测试工具
工具类型
工具名称
版本
备注
用例管理工具
缺陷管理工具
数据库
项目管理
3计划
3.1总体计划
该系统测试的策略有功能测试、用户界面测试和性能测试，功能测试要覆盖系统中的每个功能。
在功能测试时既要输入正确的数据，测试功能是否满足，也要对每个功能中的每个数据输入域故意输入错误的数据，测试系统的健壮性。
用户界面测试核实各个窗口风格（包括颜色、字体、提示信息、图标、Title等）都与需求保持一致，或符合可接受标准，保证用户界面的友好性、易操作性，而且符合用户操作习惯。
性能测试往往针对软件的一部分功能，进行专项测试。
执行完一组工作后，及时检查是否已达到预定目标，是否已执行完该过程所有的步骤等，如实际情况与计划出入较大，应及时调整计划。
考虑到各种因素和条件的限制，采用黑盒测试方案，即根据软件所需要的输入数据的格式以及应该完成的功能，设计一些合法的测试用例和不合法的测试用例，特别是根据边界条件设计一些边界测试用例，以检查系统是否能正确地完成预期功能，得到希望的输出；或者是对不合法的输入和操作能够正确地识别和防御。
3.1.1测试级
执行的测试级别为系统级。
3.1.2测试准备
●测试方案编写完成并邮件告知项目组成员；
●测试组根据需求规格说明书完成测试内容确认和重点交易列表，需项目经理或开发人员确认；
●项目经理安排相关人员完成内部测试环境的配置；
●测试开始前将与开发人员配合将“测试相关信息.xls”文档整理完成，包括测试环境配置、Bugfree用户信息，柜员信息等；
3.1.3测试类别
3.1.3.1功能测试
功能测试侧重于可以被直接追踪利用例或业务功能和业务规则的所有测试需求。
这些测试的目标在于核实能否正确的接受、处理和检索数据以及业务规则是否正确实施。
这种类型的测试基于黑盒方法，即通过图形用户界面（GUI）与应用程序交互并分析输出结果来验证应用程序及其内部进程。
以下列出测试方法概要：
测试范围：
验证数据精确度、数据类型、业务功能等相关方面的正确性
测试目标：
核实所有功能均已正常实现，且与需求一致。
方法：
利用有效的和无效的数据来执行各个用例或功能，以核实以下内容：
∙在使用有效的数据时得到预期结果；
∙在使用无效的数据时显示相应的错误信息或警告；
∙各业务规则都得到了正确的应用；
依据：
测试用例
完成标准：
∙所计划的测试已全部执行
∙所发现的缺陷已全部解决（无1,2级遗留缺陷）
需考虑的特殊事项
3.1.3.2用户界面（UI）测试
用户界面（UI）测试用于核实用户与软件之间的交互。
UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。
另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。
测试范围：
1、导航、链接、Cookie、页面结构（包括菜单、背景、颜色）、字体、按钮名称、Title、提示信息的一致性等
2、友好性、可操作性、易用性
测试目标：
核实各个窗口风格（包括颜色、字体、提示信息、图标、Title等）都与需求保持一致，或符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯。
方法：
WEB非功能性通用测试方法，手工测试
完成标准：
UI符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯
需考虑的特殊事项
重点测试网上业务平台、政务网站等对外门户的用户界面。
3.1.3.3性能测试
性能测试对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。
性能测试的目标是核实性能需求是否都已满足。
实施和执行性能测试的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行测试和微调。
测试范围：
多用户长时间在线操作时性能方面的测试
测试目标：
核实系统在大流量的数据与多用户操作时软件性能的稳定性，不造成系统崩溃或相关的异常现象。
方法：
使用loadrunner工具进行测试
完成标准：
系统满足用户需求中所要求的性能要求
需考虑的特殊事项
3.2计划执行的测试
3.2.1测试范围
序号
分类
核心
用例来源
用例编写人员
测试策略
备注
1
功能测试、用户界面测试、性能测试
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
注：
具体各核心内容下的交易见“交易测试情况一览表”，此处不逐一列出。
3.2.2测试重点
测试重点主要从以下几个方面考虑，针对测试重点，在用例的编写与评审、人员安排、测试轮次、Bug解决要求等方面都应高于其他部分。
●需求中，优先级高的重点功能或用户的常用功能；
●开发过程中，重点关注的模块、功能及特性（此项通过交易的代码修改量等内容确定，由项目经理提供）；
●相关领导的关注点和意见；
●开发人员的能力和水平差异；
●以往版本或其他项目中的常见问题；
注：
此项内容由项目经理配合进行确认，具体交易列表及重点测试交易，见“交易测试情况一览表”，此处不逐一列出。
3.2.3测试入口准则
●在提交测试组进行系统测试前，开发工程师需要经过自测试以及开发组组内互测；
●测试组接收测试，且通过冒烟测试后，方可进行系统测试。
3.2.4测试通过标准
●系统无业务逻辑错误和二级缺陷，经确定的所有缺陷都已得到商定的解决结果；
●设计的测试用例全部执行完成，由于其他因素导致未能执行的用例有相应记录；
●2.1节中规定的所有功能点，测试覆盖率=100%，有效Bug的关闭率>=90%；
●满足联合测试和第三方测评要求。
3.3测试用例
1测试用例分类
●测试用例与测试类型对应：
功能测试用例、用户界面测试用例及性能测试用例
●重点用例通过用例中的用例级别进行标记：
A-关键业务正常流测试
B-功能点详细测试
C-交互测试：
主要测试界面、易用性等内容
D-异常测试
2测试用例评审
●组内评审：
测试组内部采用交叉评审方式，对已做成测试用例进行评审；
●组外评审：
开发组的相关人员（由项目经理或部门经理指定），对测试一览表中重点交易的用例进行评审；
4测试实施
4.1轮次执行
轮次
内容
备注
第一轮
1、
第二轮
1、
第三轮
1.
其他注意事项：
1测试工程师根据测试用例进行测试，并将测试中发现的Bug，记录到Bugfree中；
2开发工程师对Bug进行修改，并说明Bug产生的原因及产生阶段；
3如果对需要修改的Bug意见不统一，则由项目经理确认修改意见；
4第二轮系统测试开始，测试工程师首先对第一轮测试中遗留的问题进行回归验证，即验证上一轮发现的Bug是否已经全部得到解决。
回归测试完成后，测试工程师再根据测试用例，开展新的系统测试工作；
5第三轮系测试，结合核心系统进行测试，同时加强对业务系统中重点交易的测试。
4.2测试计划
项目
里程碑
任务
开始时间
结束时间
输出物
执行人员
备注
制定测试方案
编写测试方案
内部测试方案
设计测试
测试用例编写
测试用例
测试用例评审
测试用例评审记录表
执行测试
内部测试第一轮
缺陷记录、轮次测试报告
内部测试第二轮
缺陷记录、轮次测试报告
内部测试第三轮
缺陷记录、轮次测试报告
评估测试
测试总结
内部测试报告
注：
轮次测试的具体内容会根据各子系统开发进度做适当调整。
4.3缺陷管理
参见《03Bugfree填写规范V1.0.4.doc》。
5测试评价
系统测试完毕，提供以下度量指标结果用以评估项目质量并输出测试报告：
度量指标名称
定义/计算公式
指标目的
数据主要来源
测试功能点总数（个）
测试功能点总数＝各级测试功能点数之和；
统计测试规模
“附件1：
交易测试情况一览表.xls”
功能点测试生产率（个/人月）
功能点测试生产率=测试功能点总数/测试组实际总工作量；
衡量测试组的生产率
系统功能测试轮次（轮）
指测试组实际进行的系统功能测试轮数；
预估类似项目的平均测试轮数
Bugfree
测试覆盖率（100%）
功能点测试覆盖率=测试功能点总数/功能点总数；
衡量测试的覆盖程度
“附件1：
交易测试情况一览表.xls”
功能点测试通过率（100%）
完全通过功能点数/测试功能点总数
由此指标，可衡量代码开发的质量。
Bug关闭率（100%）
Bug总关闭率=已关闭Bug总数/有效Bug总数*100%
1、衡量开发人员对Bug的解决程度；
2、判断产品交付时的遗留Bug数
BugFree
测试密度（个/功能）
测试密度=实际测试用例数/功能点总数
衡量测试用例颗粒度是否适当
测试用例
Bug密度1（个/功能）
Bug密度1=实际Bug数/功能点总数
衡量bug产出是否在合理范围内
BugFree
Bug密度2（个/功能）
Bug密度2=实际Bug数/代码变动数
衡量代码变动产生的bug数是合理
BugFree
6风险预估和应对
下表列出了在项目测试工作中存在的各种风险的假定，需要考虑项目测试过程中可能发生的具体事务，分别分析并加以应对，然后体现到测试计划中。
风险类型
风险责任方
风险内容
处理优先级
应对措施
备注
时间计划
人员风险
资源协调
插入事务
任务超预期
注：
各个风险类型解释如下：
Ø时间计划：
关键MileStone无法匹配的延期风险；
Ø人员风险：
测试人员和需配合方的人员的变动导致的工作任务无法按计划完成或者完成质量无法保证的风险，包括新人风险、人员变化、投入不足、投入质量不高等；
Ø资源协调：
包括所需资源不能如期到位，或者资源质量低于预期等风险。
比如测试工具开发的风险、各个阶段交付物的质量风险等；
Ø插入事务：
包括临时插入高优先级的事务，打乱原有计划等风险；
Ø任务超预期：
实际执行时的工作复杂程度、结果的质量同预期不符所带来的风险。
属于不可预期的风险，只能待出现时及时合理地调整。
风险分为可预期的和不可预期的，对于可预期的风险，可以要求资源，制定提前的应对措施。
但是对于不可预期的风险，只能待出现时，充分考虑各方因素，及时调整。
所以，对于可预期的风险，需要的能力是充分预估，对于不可预期的风险，需要的是及时察觉并调整应对。
7测试输出物
1内部测试方案
2测试用例
3测试报告
●轮次测试报告
●内部测试报告
●测试总结——邮件发送
●附件1：
交易测试情况一览表
●附件2：
交易品质分析数据
4缺陷列表
升级会员 