软件测试专项方案.docx

XXXXXX
测试方案

部 门：
____ _
编 写：
__
审 核：
____
批 准：

日 期：
_

文档历史信息

文档名称：XXXXX测试方案
文档生成日期： XX月XX日
版 本
日 期
备 注
1.0
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、谷歌 Chrome、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风险估量