软件测试方案.docx

软件测试方案.docx

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

软件测试方案

XXXXXX

测试方案

部门：

_____

编写：

__

审核：

____

批准：

日期：

_

文档历史信息

文档名称：

XXXXX测试方案

文档生成日期：

2015年XX月XX日

版本

日期

备注

1.0

2015年XX月XX日

根据《XXXXXX》及《XXXXX》编写测试方案初稿

1.引言4

1.1文档目的4

1.2项目背景4

1.3测试目的4

1.4参考资料4

2.测试资源6

2.1.人员角色分配6

2.2.测试环境6

2.3.测试工具6

3.测试进度8

4.测试需求分析9

5.测试策略12

5.1.功能测试12

5.2.性能测试12

5.3.安全性测试13

5.4.兼容性测试13

5.5.可靠性测试14

5.6.健壮性测试14

5.7.易用性测试15

6.验收标准16

7.可交付成果17

8.缺陷管理18

9.风险估计19

1.引言

1.1文档目的

本文测试方案针对《XXXXXX》，依据软件需求规格说明书进行编写，是开展测试工作的指导性文档。

1.2项目背景

1.3测试目的

1.4参考资料

列出所要参考的文档，比如需求说明书、用户手册、签订的合同约定等。

序号

资料名称

1

表格1参考资料

2.测试资源

2.1.人员角色分配

序号

角色

人员

职责

1

表格2人员角色分配

注：

除以上各岗位工作职责外，工作内容还有在项目例会上安排的其他工作。

2.2.测试环境

终端类别

配置说明

数据服务器（虚拟机）

应用服务器（实体机）

测试机

网络

表格3测试环境

注：

服务器由测试部门自行筹备，系统搭建由开发负责搭建。

2.3.测试工具

测试工具

描述

表格4测试工具

3.测试进度

事件

预计工作日

备注

表格5测试进度

4.测试需求分析

测试模块

测试功能项

测试功能点

表格6测试需求分析

5.测试策略

5.1.功能测试

测试方法

描述

备注

等价类划分法

根据软件概要设计说明书对系统中输入域的定义，将输入数据划分为有效等价类及无效等价类，以此来检验程序是否实现了软件需求规格说明书中所规定的功能。

边界值分析法

根据软件概要设计说明书对系统中输入域的定义，确定输入域的边界情况，选取等于、刚刚大于及刚刚小于边界的值作为测试数据，以此来检验程序是否实现了软件需求规格说明书中所规定的功能。

错误推测法

基于经验及直觉推测程序中可能存在的各种错误。

场景法

模拟用户的使用场景，以检验程序是否能够实现基本的业务流程及软件需求规格说明书中所规定的功能。

表格7功能测试

5.2.性能测试

使用自动化性能测试工具LoadRunner，对系统前台的资源检索、资源导航及专题展现等功能进行多用户并发下的压力测试，通过不断调整并发用户数并调优性能，以期性能达到预期指标。

性能指标

描述

评价

响应时间

小于2秒

好

2~5秒

良

5~10秒

坏

大于10秒

很差

CPU占用率

小于80%

好

80~90%

坏

大于90%

很差

内存占用率

小于70%

好

70%~85%

良

85%~90%

坏

大于90%

很差

表格8基础性能指标

5.3.安全性测试

使用工具AppScan对系统进行SQL注入、恶意内容测试、LDAP注入等方式攻击系统，并根据攻击系统时检查到的问题进行修复。

测试需求

测试分类要求

测试重点说明

防SQL注入

SQL注入

首先找到带有参数传递的URL页面,如搜索页面,登录页面,提交评论页面等等。

其次,在URL参数或表单中加入某些特殊的SQL语句或SQL片断。

最后,验证是否能入侵成功或是出错的信息是否包含关于数据库服务器的相关信息;如果能说明存在SQL安全漏洞。

防跨站点脚本攻击

跨站点脚本攻击

首先,找到带有参数传递的URL,如登录页面,搜索页面,提交评论,发表留言页面等等。

其次,在页面参数中输入如下语句（如:

Javascript,VBscript,HTML,ActiveX,Flash）来进行测试。

最后,当用户浏览时便会弹出一个警告框，内容显示的是浏览者当前的cookie串,这就说明该网站存在XSS漏洞。

防目录遍历

目录遍历

在URL中输入一定数量的“../”和“./”，验证系统是否ESCAPE掉了这些目录跳转符。

防错误信息不正确提示

错误信息提示

首先找到一些错误页面，比如404、500页面。

验证在调试未开通过的情况下，是否给出了友好的错误提示信息比如“你访问的页面不存在”等，而并非曝露一些程序代码。

超时限制

超时限制

WEB应用系统需要有是否超时的限制，当用户长时间不作任何操作的时候，需要重新登录才能使用其功能。

表格9安全性测试

注：

AppScan中攻击策略过多，故在此列出部分内容。

5.4.兼容性测试

使用多种主流浏览器（如Firefox、GoogleChrome、IE等），浏览系统并进行业务操作，查看页面布局，文字及图片的显示情况。

测试需求

测试重点说明

兼容性

不同浏览器下页面布局显示一致。

不同浏览器下图标显示完整无锯齿。

不同浏览器下字段显示完整，无断字、折行。

不同浏览器下颜色显示一致。

不同浏览器下跳转正确。

不同浏览器下操作方法一致。

不同浏览器下操作后无JS错误。

不同分辨率下字体、图片等显示一致。

表格10兼容性测试

5.5.可靠性测试

测试需求

测试重点说明

成熟性

产品描述中列出的其他程序或用户造成的错误输入时，系统不崩溃也不丢失数据。

输入用户文档中明确规定的非法指令时，系统不崩溃也不丢失数据。

不会因掉电、异常退出、网络异常中断等原因而使软件或数据遭到破坏。

易恢复性

系统运行失效后，应能较快重建系统。

数据校验机制

应对数据项之间的逻辑关系进行校验，保证数据的有效性。

应保证数据的完整性和一致性，不会因删除或反复的更新而被破坏或留下垃圾数据。

对不符合要求的输入数据，系统应使用中文给出简洁、准确的提示信息，必要时应给出帮助。

稳定性

系统在测试过程中运行稳定。

表格11可靠性测试

5.6.健壮性测试

测试需求

测试重点说明

健壮性或容错性

能屏蔽用户的误操作。

输入错误数据时，系统不崩溃、不异常退出也不丢失数据。

对错误有正确提示。

有错误操作时，系统不崩溃、不异常退出也不丢失数据。

测试系统在出现故障时，是否能够自动恢复或者忽略故障继续运行。

对关键进程或线程杀死，然后观察系统行为，是否能够正常恢复。

对关键进程或线程挂起，然后观察系统行为，是否能够正常恢复。

网络不通，然后观察系统行为，是否能够正常恢复。

数据库不通，然后观察系统行为，是否能够正常恢复。

表格12健壮性测试

5.7.易用性测试

测试需求

测试重点说明

易理解性

通过选择适当的术语、图形表示、背景信息和帮助，帮助用户理解、使用出错消息中提供差错产生的原因和纠正的详细信息。

易浏览性

数据媒体具有产品标识，可辨别编号或文本。

具有必要的信息，指导用户使用程序。

输入、输出设计规矩，输出结果应简洁、直观、美观、方便阅读、易懂和使用。

人机界面简洁、美观、实用，风格相对一致，符合办公习惯。

在界面、人机交互、输出中的用语应与业务用语一致。

易操作性

具有严重后果的功能执行可逆，或者给出明显警告，执行前要求确认。

软件操作简便，系统支持标准的鼠标、键盘操作，支持鼠标的单击、双击和右键操作，支持快捷键操作。

提供辅助输入手段（如选择输入、默认值等），数据检索方便、灵活。

根据用户熟练程度（外行、初学、熟练）和使用频度，能提供不同的操作方式或用户界面。

表格13易用性测试

6.验收标准

测试用例覆盖《XXXXX软件需求规格说明书》中的所有功能点，且测试用例执行率达到100%，至最后一次回归测试，缺陷级别为Blocker、Critical的缺陷要全部关闭（缺陷级别见表14），所有的测试用例要全部通过。

7.可交付成果

《XXXX测试方案》

《XXXX测试计划》

《XXXX测试用例》

《XXXX测试报告》

8.缺陷管理

依照设计好的测试用例对产品进行测试，将发现的缺陷，包括功能、效率和界面，对应用例中的测试号分别记录，保证各类缺陷记录的维护、分配和修改。

使用JIRA管理工具对缺陷进行跟踪和管理，项目完成时所有缺陷处于关闭状态。

缺陷级别

描述

Blocker

阻塞开发或测试的工作进度，或影响系统无法运行的错误；

Critical

系统崩溃，丢失数据或内存溢出等严重错误、或者必需完成的任务；

Major

主要的功能无效、新增功能建议；

Minor

功能部分无效或对现有系统的改进；

Trivial

拼写错误，文本未对齐等。

表格14缺陷级别

9.风险估计

软件测试风险管理主要是对测试计划执行的风险分析与制定要采取应急措施，防止软件测试的产生的风险造成的危害。

在软件测试过程中常见的计划风险主要有以下七类：

（1）测试时间进度风险：

用户需求发生重大变更或设计计划的大幅调整压缩了测试时间，测试人员、测试环境、测试资源的不能准时到位也会对测试计划造成影响。

（2）测试范围认知风险：

对产品质量需求或产品特性理解不准确，造成测试范围分析误差，出现测试盲区或验证标准错误。

（3）测试人员风险：

测试开始后，测试人员、技术支持人员因故不能及时到位。

（4）测试充分性风险：

部分测试用例设计时忽视了边界条件和深层次的逻辑关系；部分测试用例被测试人员有意无意的忽略执行。

（5）测试环境风险：

测试环境无法与生产环境一致，致使性能测试的结果存在误差。

（7）测试工具风险：

能否及时准备相关测试工具，测试人员对新工具无法熟练运用等情况也时有发生等。

针对以上的风险，分析及可采取的应对预防、应对措施如下：

风险类型

风险表现

措施

测试时间进度风险

开发需求增加

严格按已定流程执行测试，对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险

增加测试时间、人员、资源

与相关人员协商，顺延交付日期

将已有的低优先级的功能或者特性推迟

测试范围认知风险

测试实际范围与期望的测试范围不一致

测试计划时详细描述测试需求范围，经过评审后方可执行测试

如有更新，则及时补充到测试管理平台中，并通过所有项目中的测试人员

测试人员风险

测试人员突然离开

对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司，项目不会受到严重影响，仍能可以继续下去

从其它项目中抽调测试人员

删除某些风险级别较低的功能或者特性

测试充分性风险

测试用例只进行了部分性的测试或者测试用例未覆盖所有业务逻辑

用例设计覆盖所有需求，并在设计时注重运用边界值、等价类等测试设计方法

做好日常的测试执行记录

测试人员参与项目的需求分析和讨论，全面理解产品功能和实现逻辑

测试环境风险

测试环境不到位或测试环境与生产系统不一致

通过事先列出要检查的所有条目，在测试环境设置好后，按已列出条目逐条检查

增加测试资源，如请求用户团队对测试工作提供更多支持

测试工具风险

工具不能满足测试需要，工具的使用产生交流沟通上的障碍

工具使用前进行测试工具的评估

对项目中使用的工具做好相应的培训，并制定相应的使用标准

表格15风险估计