测试技术方案模板_第1页
测试技术方案模板_第2页
测试技术方案模板_第3页
测试技术方案模板_第4页
测试技术方案模板_第5页
已阅读5页,还剩9页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

10/14XXXX内部测试方案修订人签字:修订人签字:审核人签字:批准人签字:日期:日期:日期:修订历史纪录修订历史纪录版本号V1.0变更类型:增加/修订/删除日期变更类型修改人摘要备注名目\l“_TOC_250015“引言 4\l“_TOC_250014“系统概述 4\l“_TOC_250013“文档概述 4\l“_TOC_250012“范围 4\l“_TOC_250011“目标读者及阅读建议 5参考文档 5软件测试环境 5测试环境 5参与组织 6人员角色 6\l“_TOC_250010“测试工具 6打算 7总体打算 7\l“_TOC_250009“测试级 7\l“_TOC_250008“测试预备 7\l“_TOC_250007“测试类别 7打算执行的测试 9\l“_TOC_250006“测试范围 9\l“_TOC_250005“测试重点 10\l“_TOC_250004“测试入口准则 10\l“_TOC_250003“测试通过标准 10测试用例 11测试实施 11轮次执行 11测试打算 12缺陷治理 12\l“_TOC_250002“测试评价 12\l“_TOC_250001“风险预估和应对 13\l“_TOC_250000“测试输出物 14引言系统概述随着宽阔XX市民百姓对住房需求的增加,住房市场呈现高速进展趋势,治理中心的快速进展、信息技术日月异的进展和宽阔市民百姓对政府效劳水平预期的不断提高,对治理中心信息化系统的建设提出了更高要求。为实现治理中心将来五年业务进展目标业务模式、丰富效劳渠道、优化业务流程、提高资金治理水平、有效管控风险、提高办计算和大数据技术有效处理数据支持决策分析IT效劳保障体系建设、升级根底设施条件等。文档概述本文档描述了XX市XX治理中心系统内部测试阶段工作的相关状况,内容包括进展员完成测试工作。主要包括以下几点目的:尽可能觉察被测试软件中的错误,以便开发人员进展修正,提高软件的牢靠性;见性能测试方案;确定所需资源,对测试工作量进展估量;客观反映产品中存在的缺陷,为提高产品质量效劳;完本钱阶段的测试工作,为产品交付做预备。范围设计针对XX市XX中心业务系统的系统测试—功能测试方案。通过上述方案用以验证:产品功能是否满足需求规定并能够正常运行——功能测试;用户界面是否与需求保持全都,保证用户界面的友好性、易操作性——用户界面测试;产品性能是否满足需求规定并能够正常运行——性能测试;目标读者及阅读建议目标读者工程经理及评审人员测试负责人及测试工程师开发工程师参考文档

阅读建议全文档认真阅读全文档认真阅读认真阅读“章节“章节解性阅读文档GBT-8567-2023计算机软试打算(STP)

参考内容文档格式

作者或来源 使用备注确定文档格式及涉及内容需求规格说明书大/中日程打算 测试打算软件测试环境硬件配置信息硬件配置信息数量客户端软件分类扫瞄器数据库客户端硬件软件名称版本硬件用途配置信息数量效劳器

工程组工程组

确定测试需求及策略确定测试打算及人员安排软件分类软件名称版本操作系统WEB数据库备注参与组织备注参与人员供给资源参与工作参与参与方阶段 时间 2.3人员角色下表列出了在工程内部测试工作过程中的人员配备:角色人员职责工程经理供给技术指导并猎取适当资源负责整个工程中的协调工作测试负责人编写测试方案、打算工程测试的日常治理工作监控测试工作,躲避风险测试工程师编写系统测试报告等编制和维护测试用例执行测试并记录结果开发工程师缺陷跟踪对程序缺陷进展修改程序版本公布必要时参与进展功能测试2.4 测试工具工具类型用例治理工具缺陷治理工具数据库工程治理

工具名称 版本 备注打算总体打算窗口风格〔包括颜色、字体、提示信息、图标、Title等〕都与需求保持全都,或符合打算。的输出;或者是对不合法的输入和操作能够正确地识别和防范。测试级执行的测试级别为系统级。测试预备测试方案编写完成并邮件告知工程组成员;测试组依据需求规格说明书完成测试内容确认和重点交易列表发人员确认;工程经理安排相关人员完成内部测试环境的配置;测试开头前将与开发人员协作将“测试相关信息.xls”文档整理完成,包括测试环境配置、Bugfree用户信息,柜员信息等;测试类别功能测试功能测试侧重于可以被直接追踪利用例或业务功能和业务规章的全部测试需求些测试的目标在于核实能否正确的承受、处理和检索数据以及业务规章是否正确实施。测试范围:测试目标:方法:测试范围:测试目标:方法:依据:完成标准:验证数据准确度、数据类型、业务功能等相关方面的正确性核实全部功能均已正常实现,且与需求全都。利用有效的和无效的数据来执行各个用例或功能,以核实以下内容:在使用有效的数据时得到预期结果;在使用无效的数据时显示相应的错误信息或警告;各业务规章都得到了正确的应用;测试用例所打算的测试已全部执行所觉察的缺陷已全部解决〔无1,2级遗留缺陷〕需考虑的特别事项用户界面〔UI〕测试〔UI〕UI测试的目标是确保用户界面会通过测试对象的功能来为用户供给相应的访问或扫瞄功能。另外,UI测试还可确UI中的对象依据预期的方式运行,并符合公司或行业的标准。测试范围:1Cookie、页面构造〔包括菜单、背景、颜色、字体、按钮名称、Title、提示信息的全都性等2、友好性、可操作性、易用性测试目标: 核实各个窗口风格〔包括颜色、字体、提示信息、图标Title等〕都与需求保持全都,或符合可承受标准,能够保证用户界面的友好性、易操作性,而且符合用户操作习惯。方法:完成标准:需考虑的特别事项性能测试

WEB非功能性通用测试方法,手工测试UI符合可承受标准,能够保证用户界面的友好性、易操作性,而且符合用户操作习惯重点测试网上业务平台、政务网站等对外门户的用户界面。能测试的目标是核实性能需求是否都已满足的性能行为当作条件〔例如工作量或硬件配置〕的一种函数来进展测试和微调。测试范围:测试目标:方法:完成标准:需考虑的特别事项

多用户长时间在线操作时性能方面的测试核实系统在大流量的数据与多用户操作时软件性能的稳定性,不造成系统崩溃或相关的特别现象。使用loadrunner工具进展测试系统满足用户需求中所要求的性能要求打算执行的测试测试范围序号分类核心用例来源用例编写人员测试策略备注1性能测试23456789101112131415161718192021序号分类核心用例来源用例编写人员测试策略备注2223242526272829303132注:具体各核心内容下的交易见“交易测试状况一览表测试重点排、测试轮次、BUG解决要求等方面都应高于其他局部。需求中,优先级高的重点功能或用户的常用功能;〔此项通过交易的代码修改量等内容确定,由工程经理供给;相关领导的关注点和意见;开发人员的力量和水平差异;以往版本或其他工程中的常见问题;注:此项内容由工程经理协作进展确认,具体交易列表及重点测试交易,见“交易测测试入口准则在提交测试组进展系统测试前,开发工程师需要经过自测试以及开发组组内互测;测试组接收测试,且通过冒烟测试后,方可进展系统测试。测试通过标准系统无业务规律错误和二级缺陷,经确定的全部缺陷都已得到商定的解决结果;设计的测试用例全部执行完成,由于其他因素导致未能执行的用例有相应记录;2.1节中规定的全部功能点,测试掩盖率=100%,有效Bug的关闭率>=90%;满足联合测试和第三方测评要求。测试用例测试用例分类例重点用例通过用例中的用例级别进展标记:A- 关键业务正常流测试B- 功能点具体测试C- 交互测试:主要测试界面、易用性等内容D- 特别测试测试用例评审组内评审:测试组内部承受穿插评审方式,对已做成测试用例进展评审;组外评审:开发组的相关人员〔由工程经理或部门经理指定表中重点交易的用例进展评审;测试实施轮次执行轮次轮次内容1、1、1.备注其他留意事项:Bug,记录到Bugfree中;开发工程师对Bug进展修改,并说明Bug产生的缘由及产生阶段;假设对需要修改的Bug意见不统一,则由工程经理确认修改意见;其次轮系统测试开头,测试工程师首先对第一轮测试中遗留的问题进展回归验证,即验证上一轮觉察的Bug是否已经全部得到解决。回归测试完成后,测试工程师再依据测试用例,开展的系统测试工作;测试打算工程任务开头时间完毕时间输出物 执行人员 备注里程碑制定测试编写测内部测试方案试方案方案设计测试测试用例编写测试用例测试用例评审测试用例评审记录表执行测试内部测试第一缺陷记录、轮次测试轮报告内部测试第二轮次测试轮报告内部测试第三轮次测试轮报告评估测试测试总结内部测试报告注:轮次测试的具体内容会依据各子系统开发进度做适当调整。缺陷治理参见《03Bugfree填写标准V1.0.4.doc测试评价系统测试完毕,供给以下度量指标结果用以评估工程质量并输出测试报告:度量指标名称定义/计算公式指标目的数据主要来源测试功能点总数〔个〕之和;统计测试规模“附件1:交易测率〔个/人月〕功能点测试生产率=测试功能点总数/测试组实际总工作率度量指标名称定义/计算公式指标目的数据主要来源量;系统功能测试轮次〔轮〕数;均测试轮数Bugfree测试覆盖率功能点测试掩盖率衡量测试的掩盖程“附件1:交易测〔100%〕/功能点总数;度试状况一览表.xls”功能点测试通过率〔100%〕完全通过功能点数/测试功能点总数码开发的质量。Bug 关闭率〔100%〕Bug总关闭率=已关闭Bug总数/有效Bug总数*100%BugBugBugFree能〕测试密度=实际测试用例数/功能点总数度是否适当测试用例Bug1〔个/功能〕Bug密度1=实际Bug数/功能点总数衡量bug产出是否在合理范围内BugFreeBug2〔个/功能〕Bug密度2=实际Bug数/代码变动数衡量代码变动产生bugBugFree风险预估和应对风险类型风险责任方风险内容风险类型风险责任方风险内容处理优先级应对措施备注时间打算人员风险资源协调插入事务任务超预期注:各个风险类型解释如下:时间打算:关键MileStone无法匹配的延期风险;或者完成质量无法保证的风险,包括人风险、人员变化、投入缺乏、投入质量不高等;资源协调:包括所需资源不能如期到位,或者资源质量低于预期等风险。比方测试工具开发的风险、各个阶段交付物的质量风险等;插入事务:包括临时插入高优先级的事务,打乱原有打算等风险;任务超预期:实际执行时的工作简单程

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论