测试计划初稿

1、测试计划测试计划第一章第一章 引言引言1.1 目的目的为了使系统测试阶段工作能够有条理的进行，同时系统测试能够有依据的标准， 特编写此计划书。 预期读者：项目经理、测试组所有成员。1.2 参考资料参考资料测试风险的管理 http:/ 测试摘要测试摘要本次针对的测试系统是 Amaze APP 系统，主要进行测试阶段包括单元测试，集 成测试，系统测试以及验收测试，开发完成一模块的开发就可进行该模块单元测试， 集成测试；当开发完成整个系统的研发将最终的转测版本交付于测试后，测试就可 以开始三轮的系统测试以及最后的验收测试；1.3.11.3.1 重点事项重点事项本次测试的重点事项包括了测试用例的编写，接口测试，基本功能测试，兼容性测 试，缺陷验证，BUG 管理跟踪等事项；1.3.21.3.2 时间进度时间进度参照项目开发计划中开发组提出的测试时间，我们提出测试进度如下：测试阶段测试阶段起始日期起始日期负责人负责人系统测试计划2017/09/062017/09/08宁志晴系统测试设计2017/09/112017/09/22宁志晴系统测试实施2017/09/252017/10/25宁志晴完成测试分

2、析报告2017/10/262017/10/27宁志晴注： 1）每次测试组测试和开发组修改的时间均不宜超过 3 天。 2）该测试进度完全依赖于项目开发小组的开发计划和实际进度，若开发小组 调整计划或改变进度，测试进度亦将作相应的调整。 3）如遇项目开发计划发生更改，测试计划相应更改。 4）如有项目变更测试计划同时更改。1.3.31.3.3 测试目标测试目标测试发布的质量目标： 测试计划中所有测试方法和模块已经执行通过 所有的测试用例已经执行过 所有的重要等级为 1/2 的 Bug 已经解决并由测试验证 所有的 Bug 已经解决并由测试验证第二章第二章 项目背景项目背景2.1 测试范围测试范围本计划涵盖的测试范围，包括接口测试，功能测试、集成测试、系统测试、兼容性 测试，验收测试等。测试重点包括接口测试，功能测试，系统测试； 2.2 联系方式联系方式职务姓名Email电话前台开发工程师张少鹏、陈安后台开发工程师周帅鹏开发经理周帅鹏测试人员宁志晴2.3 风险及约束风险及约束由于需求变动引起的开发交付推迟，测试活动也需要相应延期； 测试环境的影响：测试硬件是否及时到位，测试软件环境不一致，硬件

3、资源准备是否充 足，造成的开发测试延期； 测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏；测试用例设 计不到位，部分场景用例的缺失；有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被 漏检的缺陷可能性就大； 回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。2.4 测试文档测试文档包括测试过程中用到的参考文档、相关的设计文档以及保存位置，测试完成后应产生 的文档。文档说明作者文档位置App 需求分析陈安原型图设计陈安/张少鹏第三章第三章 质量目标质量目标质量目标包括产品的质量目标和测试小组的质量目标。 质量不仅是衡量系统的功能或性能是否正常。对系统来说，在开发过程中尽早建立全 面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具，应该在系 统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例 如，系统是否能够正式发行？在代码完成后，应该修复那些缺陷？在系统完成后那种类型 的测试是最合适的？3.1 产品质量目标产品质量目标可以是产品的质量达到什么样的目标，产品的流程联通性达到什么样的要求。

4、测试质量目标确认者（如需说明）测试已实现的产品是否达到设计的要求， 包括：各个功能点是否以实现，业务流程 是否正确宁志晴产品规定的操作和运行稳定宁志晴3.2 测试质量目标测试质量目标评价测试质量的目标可以有：测试质量目标 确认者所有的测试案例已经执行过宁志晴所有的 Bug 已经解决并由测试验证宁志晴每一部分的测试已经被 Test Lead 确认完成宁志晴重要的功能不允许有等级为 1/2/3 的 Bug宁志晴一般的功能或与最终使用者不直接联系的 功能不允许有等宁志晴轻量的功能允许有少量 2/3 等级的错误宁志晴发现错误等级为 1/2/3 的 Bug 的速率正在下 降并接近 0宁志晴在最后的三天内没有发现错误等级为 1/2/3 类的 Bug宁志晴第四章第四章 资源需求资源需求4.1 培训资料培训资料培训需求培训内容培训人员开始时间完成时间业务流程安装配置工具使用暂无4.2 测试环境测试环境4.2.14.2.1 硬件测试环境硬件测试环境测试客户机： Intel（R） Core(TM) i5-4460 CPU 3.20GHz 测试用服务器： 3.3GHz 以上 CPU，8G 以上内存，硬盘内存

5、 500G 。4.2.2 软件测试环境服务器： CentOS。 客户机： CentOS。第五章第五章 测试策略测试策略5.1 整体测试策略整体测试策略这一阶段在于需求、详细设计、测试计划完成之后，主要是本次测试的策略阶段。 很 多公司少这个一个阶段，需要有计划性的分出产品的功能扣出测试的功能点，现阶段大多 公司都是直接拿着文档就开始做用例设计。对需求进行分析，列出具体的功能列表。（一 般根据功能交互文档就能明确出此功能的大体功能，一层层的分下去，一直到没个功能表 单。然后考虑到使用那些测试方法？工作一旦做到执行阶段，我们可以更好的根据这些功 能表一点一点的覆盖。也能让我们在用例评审时，充分的证实我们的工作是有效的能够保 证产品的质量。）一般在此之前，一些业务培训和需求评审是有必要是听一下的。这样能 够更早更熟练的理解需求，也能保证产品设计中出现的一些误区。 对于一个个测试该如何进行测试？如下：a)功能测试 功能范围（划分出各自负责的功能模块） 使用测试方法（等价类、边界值等测试方法） 测试标准（符合设计、需求和规范文档对该功能的描述） b)界面测试 c)兼容性测试 d)接口测试5.2

6、测试类型测试类型测试类型测试类型是否采用是否采用说明说明功能测试采用根据系统需求文档和设计文档，检查 产品是否正确实现了功能。界面测试采用检查界面是否美观合理接口测试采用检查系统能否与外部接口正常工作安全性和访问控制测试未采用应用程序级别的安全性：检查 Actor 只能访问其所属用户类型已被授权访 问的那些功能或数据。 系统级别的安全性：检查只有具备系 统和应用程序访问权限的 Actor 才能 访问系统和应用程序。性能测试未采用提取系统性能数据，检查系统是否满 足在需求中所规定达到的性能。兼容性测试采用对于 C/S 架构的系统来说，需 要考虑客户端支持的系统平台。 对于 B/S 架构的系统来说需要 考虑用户端浏览器的版本。回归测试采用检查程序修改后有没有引起新的 错误、是否能够正常工作以及能 否满足系统的需求5.3 测试技术 测试技术测试技术是否采用是否采用说明说明里程碑技术采用里程碑的达成标准及验收方法在测 试完后制订自动测试技术未采用核心业务流程采用自动测试技术审评测试采用对软件产品功能说明文档和设计说 明文档进行检查，在需求与设计阶 段进行编写测试用例采用在产品编码阶段编写测试用

7、例单元测试采用由开发人员进行集成测试采用检测模块集成后的系统是否达到需 求对业务流程及数据流的处理是否 符合标准、系统对业务流处理是否 存在逻辑不严谨及错误以及是否存 在不合理的标准及要求。确认测试采用在产品发布前，对照 feature list 进行基本需求的确认，确认产品是 否正确实现了功能。系统测试采用包括性能测试、压力测试和回归测 试验收测试采用由工程实施人员进行Comment W用1: 开始时间延期第六章第六章 测试计划测试计划6.1 进度计划进度计划在此章节，对各阶段的测试给出里程碑计划，包括阶段、里程碑、资源等。6.1.16.1.1 测试时间进度测试时间进度测试阶段测试阶段开始时间开始时间完成时间完成时间测试人员测试人员阶段完成标志阶段完成标志制定测试计划2017/09/07 2017/09/08 宁志晴需求 Review 2017/09/08 2017/09/12 宁志晴 设计 Review 2017/09/08 2017/09/13 宁志晴 设计测试用例 2017/09/11 2017/09/22 宁志晴 测试开发 2017/09/11 2017/09/22 宁志晴 测试环境准备 2017/09/22 2017/09/22 宁志晴 测试实施 2017/09/25 2017/10/25 宁志晴 文档编写 2017/10/26 2017/10/27 宁志晴 6.2 测试准备测试准备6.2.16.2.1 测试环境准备测试环境准备准备事项准备事项开始时间开始时间完成时间完成时间测试人员测试人员阶段完成标志阶段完成标志 测试环境准备 2017/09/22 2017/09/22 宁志晴 6.2.26.2.2 安装测试安装测试准备事项准备事项开始时间开始时间完成时间完成时间测试人员测试人员阶段完成标志阶段完成标志 安装测试 2017/XX/XX 2017/XX/XX 宁志晴 6.3 具体测试实施任务和时间人员安排具体测试实施任务和时间人员安排测试功能点测试功能点开始时间开始时间完成时间完成时间测试人员测试人员说明说明搜索 2017/09/25 2017/09/29宁志晴 关注 2017/10/16 2017/10/18宁志晴 我的 2017/10/19 2017/10/20宁志晴 注：此处时间安排是执行测试的时间安排；不包括测试用例的设计。

《测试计划初稿》由会员一只****的猪分享，可在线阅读，更多相关《测试计划初稿》请在金锄头文库上搜索。