测试方案Word格式.docx

测试方案Word格式.docx

《测试方案Word格式.docx》由会员分享，可在线阅读，更多相关《测试方案Word格式.docx（11页珍藏版）》请在冰豆网上搜索。

第1章文档概述1

1.1测试环境：

1

1.2测试工具：

1.3参考文献1

1.4限制条件2

1.5测试范围2

3.测试目标4

4.测试的内容及步骤5

4.1测试内容5

4.1.1接口测试5

4.1.2界面测试6

4.1.3功能测试7

4.1.4系统测试8

4.1.5兼容性测试9

4.1.6权限测试10

4.1.7回归测试11

4.2测试步骤12

5.测试执行进入与退出标准14

5.1进入准则14

5.2退出准则14

6.测试执行15

6.1测试执行目标15

6.2测试执行中Bug管理流程15

6.3暂停标准和再启动要求15

7.测试风险17

8.测试提交文档18

第1章文档概述

硬件环境：

客户机：

CPU2.0GHz+内存2G+硬盘空间200G

服务器：

6c3.7ghz+内存8gb+1快73gb15000转sas硬盘+双口千兆电口网卡

软件环境：

WindowsXP/Vista/7+IE8浏览器

服务器：

AIX6.1+Oracle10g+Java1.6+Tomcat6.0

服务器IP地址：

192.168.1.188

端口号：

80

测试入口地址：

http:

//192.168.1.188/communication/formlogin.jsp

资源管理工具：

TortoiseSVN

缺陷管理工具：

QualityCenter9.0

1.3参考文献

《软件需求规格说明书》

《软件概要设计说明书》

《软件详细设计说明书》

《软件测试计划书》

1.4限制条件

（1）需求的更改；

（2）提交测试的内容；

（3）提交测试的时间。

1.5测试范围

第2章测试目标

通过测试达到以下目标：

（1）测试已实现的产品是否达到设计的要求，包括：

各功能点是否实现，业务流程是否正确；

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

（3）Bug数和缺陷率在可接受的范围内。

第3章测试内容及步骤

3.1测试内容

（1）接口测试

（2）界面测试

（3）功能测试

（4）系统测试

（5）兼容性测试

（6）权限测试

（7）回归测试

3.1.1接口测试

接口测试的目的是测试接口，尤其是那些与系统相关联的外部接口，测试的重点是要检查数据的交换，传递和控制管理过程，还包括处理的次数。

外部接口测试一般是作为系统测试来看待的。

测试目的：

确保接口调用的正确性

测试范围：

所有涉及到第三方接口的功能

技术：

根据接口规范进行调用，核实内容如下：

与农合的接口

与一卡通的接口

开始条件：

数据完整性测试完成之后

完成标准：

所有涉及到第三方接口的功能都能正常使用达到预期效果

需考虑的特殊事项：

接口的限制条件

3.1.2界面测试

用户界面（UI）测试用于核实用户与软件之间的交互。

UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。

UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。

核实以下内容：

通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括——

窗口与窗口之间的浏览

字段与字段之间的浏览

各种访问方法（Tab键、鼠标移动和快捷键）的使用窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。

在需求中明确出的功能模块

为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。

接口测试完成之后

成功地核实出各个窗口都与基准版本保持一致，符合可接受标准

并不是所有定制或第三方对象的特征都可访问

3.1.3功能测试

对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。

测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。

功能测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。

以下为各种应用程序列出了推荐使用的测试概要。

确保测试的功能正常。

包括：

导航功能正常

数据输入功能正常

数据处理功能正常

检索功能正常

利用有效的和无效的数据来执行各个用例、业务流或功能，以核实以下内容：

在使用有效数据时得到预期的结果

在使用无效数据时显示相应的错误消息或警告消息

各业务规则都得到了正确的应用

开始标准：

界面测试完成之后

功能流程及操作使用达到预期设计标准

确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）

3.1.4系统测试

系统测试主要目的：

检测系统是否达到需求对业务流程及数据流的处理是否符合标准；

检测系统对业务流处理是否存在逻辑不严谨及错误；

检测需求是否存在不合理的标准及要求。

此阶段测试基于功能完成的测试。

检测需求中业务流程，数据流的正确性

需求明确业务流程并组合不同功能模块而形成大的功能进行模块测试

利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：

在使用有效数据时得到预期的结果。

在使用无效数据时显示相应的错误消息或警告消息。

各业务规则都得到了正确的应用。

功能测试通过，各功能都可以正常实现

所计划的测试已全部执行。

所发现的缺陷已全部解决

测试重点和优先级：

测试重点指在测试过程中需着重测试的地方，优先级可以根据需求及严重来定

3.1.5兼容性测试

兼容性指能同时容纳多个方面，在多个软件之间的相互配合程度。

兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能更好地运行的测试。

确保系统可以在不同的操作系统平台和浏览器中可以运行

系统实现的各功能模块

测试软件是否能在不同的操作系统平台上兼容

测试软件能否与其他相关的软件兼容

功能测试完成之后

可以实现需求规格说明书中得要求

不同的操作系统平台

浏览器内核不同

3.1.6权限测试

根据需求等相关文档，查看程序设置权限级别是否正确，即每一级别的用户所能执行的功能是否分配正确。

每一级别的用户所能执行的功能是否分配正确

建立不同权限级的用户进入系统，查看菜单、操作命令有效、无效设置是否正确

权限测试应该分为两部分，一部分是权限分配的功能；

还有一部分是分配后的权限使用。

1.首先分析登陆系统的有哪些人员，需要设计多少个岗位，每个岗位的权限是不一样。

2.分析每个岗位所包含的权限，同时注意，有些岗位的权限存在交叉的情况。

3.把设计的登陆系统的测试人员添加到不同的岗位上。

4.根据上面的测试分析，设计测试用例。

既要测试这个岗位包含的权限能不能正常使用，也保验证岗位不包含的权限能否使用。

5.登陆系统，把设计好的测试数据添加到系统中，执行测试用例。

6.口令锁定：

即输入口令次数的限制，据说这是对付远程暴力攻击猜测密码的有效技术

不同权限级的用户进入系统，查看菜单、操作命令有效、无效设置正确

访问权限、操作权限。

如果权限设计是基于以上两种中的任何一种，可以包含在单一的功能测试中；

如果权限设计是基于两种的组合控制权限，最佳方案是独立的权限案例

3.1.7回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。

在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。

因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

验证修改的正确性，以及修改带来的影响。

确保软件既定功能和任务

完全回归测试是指重复以前的全部或部分的相同测试；

新加入测试的模组，可能对其他模组产生副作用，故须进行某些程度的回归测试；

回归测试的重心，以关键性模组为核心

各测试阶段完成；

测试过程中出现缺陷，并修改；

添加新组件、新功能或者新模块；

软件交付用户前

回归了所有的测试案例、测试程序或脚本；

多次回归中发现的所有软件问题都已解决；

所有的软件配置均已更新和审核

各测试阶段发生的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段

回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归

3.2测试步骤

（1）编写测试计划并通过评审

（2）设计测试重点并通过评审

（3）设计测试用例并通过评审

（4）编写测试用例并通过评审

（5）执行测试用例（首先要搭建测试用环境）

（6）提交测试时发现的Bug

（7）跟踪Bug进度,对修复的Bug进行再次测试

（8）回归测试并通过评审

（9）提交测试报告并通过评审

第4章测试执行进入与退出标准

4.1进入准则

开发组根据业务需求已完成可以测试的软件版本。

完成测试计划、测试数据准备。

测试环境搭建完成，测试软件版本发布到测试环境中。

4.2退出准则

通过测试，达到以下目标：

（1）测试范围覆盖主要产品的关键业务流程

（2）所有测试用例全部执行成功（排除由于不能修复的缺陷而不能执行的）

（3）优先级较高的错误得到修复并且通过回归测试。

第5章测试执行

5.1测试执行目标

通过执行相应测试用例的测试，对测试结果进行对比验证，以发现系统的问题，并执行缺陷的修复，以确保整体系统的质量。

5.2测试执行中Bug管理流程

Bug管理流程说明：

（1）测试人员在提供的Bug模板中新建记录，包括详细记录问题的所在的功能模块，详细问题描述（现象、操作步骤、特殊的配置和输入、使用图片等附件），记录人，版本，严重级别等

（2）测试人员提交的Bug将反馈给项目负责人，由项目负责人安排开发处理解决Bug

（3）开发人员修复好Bug后，记录解决时间级解决情况，并将文档及时反馈给测试人员验证

（4）测试人员验证Bug后，记录验证时间及验证情况。

并提交给项目负责人。

如需再修改的重复以上1—4步骤

5.3暂停标准和再启动要求

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

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

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

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

（5）项目现启动时，测试进度重新安排或顺延

（6）项目需暂停调整时，测试应随之暂停，并备份暂停点数据

第6章测试风险

通过分析已具备的测试资源、本项目的测试规模及难度、可预计的变动因素，提出完成本项目存在的风险程度。

（1）需求变更

（2）人力、时间资源方面，测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏；

测试时间的缩短导致某些测试计划无法执行

（3）测试环境方面，与实际运行环境不能完全一致，造成测试结果的误差

（4）部门配合方面

第7章测试提交文档

下面应列出测试阶段结束后，需要提交的文档：

（1）测试计划

（2）测试方案

（3）测试用例

（4）缺陷记录（提交至QC）

（5）测试总结