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