ImageVerifierCode 换一换
格式:DOCX , 页数:12 ,大小:20.57KB ,
资源ID:8302134      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/8302134.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(001A 项目名称测试计划V11.docx)为本站会员(b****5)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

001A 项目名称测试计划V11.docx

1、001A 项目名称测试计划V11【项目名称】项目XXX测试计划文档名称:填写所测项目全称文件编号:-001A密级: (公开,秘密,机密)编制日期:状态: (初稿,修订,发布)编制人员:校核:当前版本:前一版本:评审人:审批:版本号状态内容摘要撰写日期撰写人审查人1.0新建创建文板模板2018-8-9王家明王家明1.1修订根据实际执行情况优化2019-1-23王家明注:初始本版号:1.0;小范围修订批准后,版本号第二位逐增1;状态包括:N-新建(草稿),M-修订,P发布 目录【项目名称】 1项目XXX测试计划 1XXX系统测试计划 31 概述 41.1 目的 41.2 项目背景 41.3 适用范

2、围 42 测试对象 52.1 测试范围 52.2 测试目标 52.3 需求跟踪 53 测试策略 63.1 测试类型 63.1.1 数据与数据库完整性测试 63.1.2 功能测试 63.1.3 业务流程测试 63.1.4 界面测试 63.1.5 性能测试与评估 73.1.6 负载、强度、容量、故障与恢复、安全性 73.1.7 兼容性测试 73.1.8 易用性测试 73.1.9 配置与安装测试 73.1.10 其他专题测试 73.2 工具 74 测试资源 84.1 角色及职责 84.2 测试环境及资源 84.3 培训、演示需求 85 测试计划 95.1 工作量估计 95.2 测试进度计划安排 96

3、 测试管理 106.1 转测试开始 106.2 测试过程控制 106.3 测试活动通过标准 106.4 测试挂起及恢复的条件 106.5 测试失败 107 测试交付件 118 风险及约束 119 附件 11XXX系统测试计划关键词:系统测试计划 测试对象 测试任务 工作量 资源摘要:根据XXX项目用户需求规格说明书、xxx项目概要计划的要求,对项目测试过程中涉及的人力、物力资源,应交付的工作产品,测试通过/失败标准等项做了说明,旨在为相关人员的系统测试活动提供指导。缩略语清单:参考资料清单:名称作者编号XXX需求规格说明书XXXXXX1 概述1.1 目的本文是为了明确系统测试的范围、测试通过/

4、失败标准、工作产品输出,估计系统测试各个任务的工作量和人力物力资源、安排系统测试任务、进度以及各种过程准则。本文需要达到的目标: 所有测试需求都已被标识出来; 测试的工作量已被正确估计并合理地分配了人力、物力资源; 测试的进度安排是基于工作量估计的、适用的; 测试启动、停止的准则已被标识; 测试输出的工作产品是已被标识的、受控的和适用的。1.2 项目背景简要描述测试项目的背景情况,一般从需求文档中有相关描述。例如:新会计制度的执行,主要是为了满足预算单位会计的双重目标,既能满足单位预算管理需要,又要能够反映预算执行情况。但从行政单位制度的细节来看,行政单位会计制度在反映行政单位财务状况的同时更

5、重视预算执行情况,在支出的确认方面,则更强调收付实现制。从会计科目体系设计和核算上看,行政单位会计制度科目体系日趋完善,全面总结了事业单位科目体系中的不足,新行政单位会计制度与预算管理更加吻合,要比事业单位制度更为复杂和完善,不仅仅是颁布部门和时间性的差距,是让制度与经济业务要求更加一致,与财政管理要求更加一致。1.3 适用范围本文档的主要阅读对象为XXX项目组的测试研发人员。通过本文档,为系统测试设计、实现、执行活动提供指导。2 测试对象描述需测试的目标对象2.1 测试范围功能清单一级菜单模块功能测试项测试范围用户登录用户登录基本功能、安全报表管理查询报表基本功能、系统管理-用户管理添加用户

6、基本功能性能测试测试场景指标登录并发50用户并发登录,3s其他测试补充或限制。无需测试部分及原因。其他要求2.2 测试目标满足金政研发体系质量管理规范要求。其他要求2.3 需求跟踪参见XXX需求规格说明书参见XXX变更需求规格说明书参见xxx系统设计原型/填写相关需求文档文件名,全称3 测试策略3.1 测试类型3.1.1 数据与数据库完整性测试作为项目子系统进行测试。测试目标确保数据库访问方法和进程正常运行,数据不会遭到损坏方法调用各个数据库访问方法和进程,并在其中填充有效的和无效的数据或对数据的请求。检查数据库,确保数据已按预期的方式填充,并且所有数据库事件都按正常方式出现;或者检查所返回的

7、数据,确保为正当的理由检索到了正确的数据完成标准所有的数据库访问方法和进程都按照设计的方式运行,数据没有遭到损坏。特殊事项测试可能需要DBMS开发环境或驱动程序以便在数据库中直接输入或修改数据。进程应该以手工方式调用。应使用小型或最小的数据库(其中的记录数很有限)来使所有无法接受的事件具有更大的可见性。3.1.2 功能测试测试目标方法完成标准特殊事项3.1.3 业务流程测试依据具体业务流程进行业务场景测试。3.1.4 界面测试依据界面设计规范进行检视测试。3.1.5 性能测试与评估多维度性能考核与评估,制订计划时应根据具体项目情况进行测试策略。3.1.6 负载、强度、容量、故障与恢复、安全性负

8、载:一定压力下的测试强度:资源不足、资源争用、内存、磁盘不足、带宽等,确定最大工作量容量:软件故障的边界值安全性:网络安全和系统安全等方面故障与恢复:客户机断电、web服务器断电、网络中断、闪断、数据库连接中断、主备切换中断、备份中断、其他意外及其恢复3.1.7 兼容性测试操作系统、浏览器、控件、主要软件版本等3.1.8 易用性测试存在易用性要求的测试3.1.9 配置与安装测试系统首次转测试,需要开发给出安装部署手册或说明文档,测试验证改文档。配置:包括操作系统、主要软件版本、数据库版本、中间件版本等安装:1、首次安装部署;2、更新3.1.10 其他专题测试其他项目过程中需要开展的专项测试活动

9、。3.2 工具1. 测试管理-禅道2. 缺陷跟踪-禅道3. 监控-4. 项目管理-SVN5. 测试工具-Jmeter、loadrunner、6. 其他辅助设备-4 测试资源4.1 角色及职责角色人员联系电话职责项目经理项目过程协调开发负责人技术指导、资源、协调测试负责人计划、策略、执行、跟进、总结评估测试成员执行、汇总、跟进实施人员提供生产环境相关信息及版本发布部署4.2 测试环境及资源注意,此处为测试环境部署的软硬件信息,一般应配置性能应在安装配置要求之上。软件环境:软件名称要求Grid+华表硬件环境:服务器、测试机、相关辅助测试工具及详细要求CPU内存操作系统预装软件4.3 培训、演示需求

10、是否有培训要求?转测试是否系统演示?5 测试计划5.1 工作量估计任务人员安排时间工作量编写测试计划4-131天编写测试用例4-14-5-105测试安装部署手册测试执行预计转测试-系统测试结束时间一般根据开发计划制定编写测试总结报告编写操作手册测试估算:应由经验丰富的测试人员及项目经理、开发经理进行合理评估。5.2 测试进度计划安排测试活动开展详细计划安排测试活动计划开始日期计划结束日期测试人员阶段完成标志编写测试计划编写测试用例部署测试环境确定测试环境资源情况第一轮基本概念测试基本功能可实现第二轮bug回归测试第一轮转测Bug验证完毕第三轮系统功能测试满足客户整体需求第四轮bug回归测试Bu

11、g验证完毕第五轮系统测试实现客户所有需求,无遗留bug(除建议性外)编写测试报告编写操作手册6 测试管理6.1 转测试开始条件:主业务完成、主要功能完整、重要分支功能完成等6.2 测试过程控制测试日进度、例会、工作周报等多维度跟进6.3 测试活动通过标准1. 执行测试过程a) 评估测试的执行情况b) 恢复暂停的测试c) 缺陷记录d) 意外与核查2. 评估测试a) 评估测试用例覆盖,如测试用例执行80%,中高用例全部执行b) 业务功能覆盖率情况c) 缺陷分析收敛,致命严重全部修复,一般遗留不超过5%d) 性能要求e) 产品质量要求此处应遵循金政研发体系质量管理规范规定。6.4 测试挂起及恢复的条

12、件挂起:关键业务路径存在未完成的任务、大量的缺陷、测试环境不具备、资源短缺等恢复:基本功能测试通过,可执行进一步的测试6.5 测试失败1. 未转测试2. 用例未执行3. 缺陷未修复4. 重要用例未执行完此处应遵循金政研发体系质量管理规范规定。7 测试交付件序号名称时间提交人1测试计划2测试用例3测试报告4系统操作手册8 风险及约束序号描写解决办法1需求分析不全面评估未完成的功能,从重要性和时间允许等方面去考虑,是否需要放弃2开发无法按期转测试跟踪开发进度,及时调整测试时间安排3系统的可测性差4模块功能改变积极与开发沟通,重新进行测试任务分配5测试环境与开发环境不同步加强版本管理、数据库版本管理、定期更新6业务专业化程度高、新员工较多加强培训、做好沟通协调和技术支持7此处,在制定计划时应充分考虑项目开展过程中的各种可能导致的风险及规避方法。9 附件XXX项目用户需求规格说明书XXX项目开发进度计划计划所需的相关文档附件信息

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1