测试计划

 

 

XXXXXX科技公司

 

 

 

名称：XXXX测试计划 

 

 

 

 

 

 

                            

                      

                    

                

 

 

 

 

 

 

 

目  录

 

 

1 概  述 1

1.1目的 1

1.2范围 1

1.3限制条件 1

1.4参考资料 1

2.约定 1

2.1测试目标 1

2.2接收标准 1

2.3资源和工具 1

2.3.1 资源 1

2.3.2 工具 1

2.4 送测要求 1

2.5 测试规则 2

3.测试类型 2

4.预测风险 3

5.暂停标准和再启动要求 3

6.测试任务和进度 3

7.质量标准 4

7.1产品质量目标 4

7.2测试质量目标 4

8.测试提交物 5

1 概  述

1.1目的

简述本计划的目的，旨在说明各种测试阶段任务、人员分配和时间安排、工作规范等。

测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。在计划目的中需要指明读者对象。

1.2范围

本测试计划是针对《   产品规格说明书》中规定的内容的测试计划，包括：

各个功能模块名称

1.3限制条件

本测试计划受限于产品开发人员提交测试的内容和时间的事实，根据开发人员提交模块的实际情况，本计划会做出相应修改。

1.4参考资料

列出本计划各处参考的经过核准的全部文档和主要文献。

2.约定

2.1测试目标

通过测试达到以下目标：

（1）测试已实现的产品是否达到设计的要求，包括：各个功能点是否已实现，业务流程是否正确。

（2）产品规定的操作和运行稳定。

（3）Bug数和缺陷率控制在可接收的范围之内。

2.2接收标准

     本节所述的接收标准是指可测试的标准，这个标准以测试组接收测试为限。

2.3资源和工具

2.3.1 资源

（1）测试服务器：稳定的测试服务器，IP地址：

（2）人员：测试审核人一名，测试实施人员一名

2.3.2 工具

（1）测试中使用的bug管理工具：

（2）性能测试工具：

2.4 送测要求

开发人员提交的测试按以下要求进行：

 

步骤	动作	负责人	相关文档或记录	要求
1	打包、编译	开发人员	无	确认可测试
2	审核并提交测试	王罗炜	无
3	接收测试	测试人员	经xx审核并签字的上一级测试报告
4	开始测试	测试人员	Bug单、小结	测试小结个人编写个人的内容

2.5 测试规则

与本测试计划相关的编号规则如下：

（1）测试用例中的编号：项目名称+类型+编号

     例如：

（2）测试用例文件名命名规则：项目名称+测试用例

例如：

3.测试类型

测试类型	是否采用	说明
功能测试	采用	根据系统需求文档和设计文档，检查产品是否正确实现了功能
流程测试	采用	按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程、正反流程，检查软件在按流程操作时是否能够正确处理
边界值测试	采用	选择边界数据进行测试，确保系统功能正常，程序无异常
容错性测试	采用	检查系统的容错能力，错误的数据输入不会对功能和系统产生非正常的影响，且程序对错误的输入有正确的提示信息
异常测试	采用	检查系统能否处理异常
启动停止测试	采用	检查每个模块能否正常启动停止、异常停止后能否正常启动
安装测试	采用	检查系统能否正确安装、配置
易用性测试	采用	检查系统是否易用友好
界面测试	采用	检查界面是否美观合理
接口测试	采用	检查系统能否与外部接口正常工作
配置测试	采用	检查配置是否合理、配置是否正常
安全性和访问控制测试	采用	应用程序级别的安全性：检查Actor只能访问其所属用户类型已被授权访问的那些功能或数据 系统级别的安全:检查只有具备系统和应用程序访问权限的Actor才能访问系统和应用程序
性能测试	采用	提取性能测试数据，检查系统是否满足在需求中所规定达到的性能
压力测试	采用	检查系统能否承受大压力，测试产品应该能够在高强度条件下正常运行，不会出现任何错误
兼容性测试	采用	对于C/S架构的系统来说，需要考虑客户端支持的系统平台 对于B/S架构的系统来说需要考虑用户端浏览器的版本 对于APP软件来说考虑手机的型号、版本号、手机的分辨率、网络兼容性（2G\3G\4G\WIFI、弱网、断网）
文档测试	采用	检查文档是否足够、描述是否合理
回归测试	采用	检查程序修改后有没有引起新的错误、是否能够正常工作及能否满足系统的需求

4.预测风险

本次测试过程中，可能出现的风险如下:

（1）bug的修复情况

（2）模块功能的实现情况

（3）系统整体功能的实现情况

（4）代码的编写质量

（5）人员经验以及对软件的熟悉度

（6）开发人员、测试人员关于项目预定的执行情况

（7）人员调整导致研发周期延迟

（8）开发时间的缩短导致某些测试计划无法执行

（9）由于客观存在的设备、网络等资源原因，使得测试不全面。明确说明哪些资源欠缺，产生什么约束

（10）由于研发模式为现场定制，且上线时间压力大，使得测试不充分。明确说明在此中约束下，测试如何应对

（11）只针对专门的客户群需求的测试。明确说明此约束下的客户群和业务范围。

5.暂停标准和再启动要求

（1）软件系统在进行单元测试、集成、确认、系统、安装、验收测试时，发现一级错误、二级错误暂停测试返回开发。

（2）软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。

（3）软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据。

（4）如有新的项目需求，则在原测试计划下做相应的调整。

（5）若开发暂停，则相应测试也暂停，并备份暂停点数据。

（6）若项目中止，则对已完成的测试工作做测试活动总结。

（7）项目再启动时，测试进度重新安排或顺延。

6.测试任务和进度

测试阶段	测试任务	工作量估计	人员分配	起止时间
第一阶段单元测试	对各个功能模块进行测试	1日		1.1至1.2
	单元测试bug审核	5日
第二阶段集成测试		5日
第三阶段业务测试	业务流程测试	8日
	关注数据的准确性，特别是报表
第四阶段性能测试	性能测试	2日
第五阶段帮助测试	帮助测试
第六阶段审核bug	审核单元测试以外的bug
第七阶段安装测试	程序的安装过程
第八阶段验收测试	模仿用户使用过程的测试
第九阶段附加测试
测试总结	测试总结和分析、问题反馈	1日

7.质量标准

描述本阶段测试目标和要求。质量目标应该包括产品的质量目标和测试小组的质量目标。

质量不仅是衡量系统的功能或性能是否正常。对系统来说，在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具，应该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例如，系统是否能够正式发行？在代码完成后，应该修复那些缺陷？在系统完成后那种类型的测试是最合适的？

7.1产品质量目标

可以是产品的质量达到什么样的目标，产品的流程联通性达到什么样的要求。

测试质量目标	确认者（如需说明）
测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确
产品规定的操作和运行稳定

7.2测试质量目标

评价测试质量的目标可以有：

测试质量目标	确认者（如需说明）
所有的测试案例已经执行过
所有的自动测试脚本已经执行通过
所有的重要等级为1/2的Bug已经解决并由测试验证
每一部分的测试已经被Test Lead确认完成
重要的功能不允许有等级为1/2/3的Bug
一般的功能或与最终使用者不直接联系的功能不允许有等级为1/2的bug,且bug等级为3的问题不得超过1/功能
轻量的功能允许有少量2/3等级的错误
发现错误等级为1/2/3的Bug的速率正在下降并接近0
在最后的三天内没有发现错误等级为1/2/3类的Bug

 

 

8.测试提交物

本次测试完成后的提交物：

 

文档说明	作者	文档位置
测试计划
测试用例
测试bug单
性能测试报告
测试总结