软件测试方案

1. 引言 1.1 文档目的
本文测试方案针对《XXXXXX》，依据软件需求规格说明书 进行编写，是开展测试工作的指导性文档。
1.2 项目背景 1.3 测试目的 1.4 参考资料
列出所要参考的文档，比如需求说明书、用户手册、签订 的合同约定等。
序号 1 表格 1参考资料 资料名称
2. 测试资源 2.1. 人员角色分配
5.6. 健壮性测试
测试需求 测试重点说明
能屏蔽用户的误操作。 输入错误数据时，系统不崩溃、不异常退出也 不丢失数据。 对错误有正确提示。 有错误操作时，系统不崩溃、不异常退出也不 丢失数据。 测试系统在出现故障时，是否能够自动恢复或 健壮性或容错 者忽略故障继续运行。 性 对关键进程或线程杀死，然后观察系统行为， 是否能够正常恢复。 对关键进程或线程挂起，然后观察系统行为， 是否能够正常恢复。 网络不通，然后观察系统行为，是否能够正常 恢复。 数据库不通，然后观察系统行为，是否能够正 常恢复。
7. 可交付成果
《XXXX测试方案》 《XXXX测试计划》 《XXXX测试用例》 《XXXX测试报告》
8. 缺陷管理
依照设计好的测试用例对产品进行测试，将发现的缺陷， 包括功能、效率和界面，对应用例中的测试号分别记录，保证 各类缺陷记录的维护、分配和修改。 使用JIRA管理工具对缺陷进行跟踪和管理，项目完成时所 有缺陷处于关闭状态。
测试环境不到位 测试环境风险 或测试环境与生 产系统不一致
测试工具风险
工具不能满足测 试需要，工具的 使用产生交流沟 通上的障碍
表格 15风险估计
防跨站点 脚本攻击
跨站点脚 本攻击
WEB应用系统需要有是否超时的限制， 超时限制 超时限制 当用户长时间不作任何操作的时候， 需要重新登录才能使用其功能。 表格 9安全性测试 注：AppScan中攻击策略过多，故在此列出部分内容。
5.4. 兼容性测试
使用多种主流浏览器（如Firefox、Google Chrome、IE等）， 浏览系统并进行业务操作，查看页面布局，文字及图片的显示 情况。
5.5. 可靠性测试
测试需求 测试重点说明 产品描述中列出的其他程序或用户造成的错误 输入时，系统不崩溃也不丢失数据。 成熟性 输入用户文档中明确规定的非法指令时，系统 不崩溃也不丢失数据。 不会因掉电、异常退出、网络异常中断等原因 而使软件或数据遭到破坏。 易恢复性 系统运行失效后，应能较快重建系统。 应对数据项之间的逻辑关系进行校验，保证数 据的有效性。 应保证数据的完整性和一致性，不会因删除或 数据校验机制 反复的更新而被破坏或留下垃圾数据。 对不符合要求的输入数据，系统应使用中文给 出简洁、准确的提示信息，必要时应给出帮 助。 稳定性 系统在测试过程中运行稳定。 表 格 11 可 靠 性 测 试
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
2.3. 测试工具
测试工具 描述 表格 4测试工具
3. 测试进度
事件 预计工作日 表格 5测试进度 备注
4. 测试需求分析
测试模 块 测试功能项 测试功能点 表 格 6测 试
需求分析
5. 测试策略 5.1. 功能测试
测试方法 描述 备注 根据软件概要设计说明书对系统 中输入域的定义，将输入数据划 分为有效等价类及无效等价类， 等价类划分法 以此来检验程序是否实现了软件 需求规格说明书中所规定的功 能。 根据软件概要设计说明书对系统 中输入域的定义，确定输入域的 边界情况，选取等于、刚刚大于 边界值分析法 及刚刚小于边界的值作为测试数 据，以此来检验程序是否实现了 软件需求规格说明书中所规定的 功能。 错误推测法 基于经验及直觉推测程序中可能 存在的各种错误。 模拟用户的使用场景，以检验程 序是否能够实现基本的业务流程 及软件需求规格说明书中所规定 的功能。 表 格 7功 能 测 试
表 格 12 健 壮 性 测 试
5.7. 易用性测试
测试需求 易理解性 测试重点说明 通过选择适当的术语、图形表示、背景信息和 帮助，帮助用户理解、使用出错消息中提供差 错产生的原因和纠正的详细信息。 数据媒体具有产品标识，可辨别编号或文本。 具有必要的信息，指导用户使用程序。 易浏览性 输入、输出设计规矩，输出结果应简洁、直 观、美观、方便阅读、易懂和使用。 人机界面简洁、美观、实用，风格相对一致， 符合办公习惯。 在界面、人机交互、输出中的用语应与业务用 语一致。 具有严重后果的功能执行可逆，或者给出明显 表 格 13 易 用 性 测 试
风险类型
风险表现
措施 严格按已定流程执行测 试，对所有过程进行日常 跟踪，及时发现风险出现 的征兆，避免风险
测试时间进度 风险
开发需求增加
增加测试时间、人员、资 源 与相关人员协商，顺延交 付日期 将已有的低优先级的功能 或者特性推迟 测试计划时详细描述测试 需求范围，经过评审后方 可执行测试 如有更新，则及时补充到 测试管理平台中，并通过 所有项目中的测试人员
序号 1 表格 2人员角色分配 注：除以上各岗位工作职责外，工作内容还有在项目例会上安排的其他 工作。 角色 人员 职责
2.2. 测试环境
终端类别 数据服务 器(虚拟 机) 应用服务 器（实体 机） 测试机 网络 表格 3测试环境 注：服务器由测试部门自行筹备，系统搭建由开发负责搭建。 配置说明
用例设计覆盖所有需求， 并在设计时注重运用边界 值、等价类等测试设计方 法 做好日常的测试执行记录 测试人员参与项目的需求 分析和讨论，全面理解产 品功能和实现逻辑 通过事先列出要检查的所 有条目，在测试环境设置 好后，按已列出条目逐条 检查 增加测试资源，如请求用 户团队对测试工作提供更 多支持 工具使用前进行测试工具 的评估 对项目中使用的工具做好 相应的培训，并制定相应 的使用标准
测试需求 测试重点说明
不同浏览器下页面布局显示一致。 不同浏览器下图标显示完整无锯齿。 不同浏览器下字段显示完整，无断字、折行。 兼容性 不同浏览器下颜色显示一致。 不同浏览器下跳转正确。 不同浏览器下操作方法一致。 不同浏览器下操作后无JS错误。 不同分辨率下字体、图片等显示一致。 性测试 表 格 10 兼 容
警告，执行前要求确认。 软件操作简便，系统支持标准的鼠标、键盘操 作，支持鼠标的单击、双击和右键操作，支持 快捷键操作。 提供辅助输入手段（如选择输入、默认值 等），数据检索方便、灵活。 根据用户熟练程度（外行、初学、熟练）和使 用频度，能提供不同的操作方式或用户界面。
易操作性
6. 验收标准
测试用例覆盖《XXXXX软件需求规格说明书》中的所有功能 点，且测试用例执行率达到100%，至最后一次回归测试，缺陷 级别为Blocker、Critical的缺陷要全部关闭（缺陷级别见表 14），所有的测试用例要全部通过。
测试实际范围与 测试范围认知 期望的测试范围 风险 不一致
对每个关键性技术人员培 养后备人员，作好人员流 动的准备，采取一些措施 确保人员一旦离开公司， 测试人员突然离 项目不会受到严重影响， 测试人员风险 仍能可以继续下去 开 从其它项目中抽调测试人 员 删除某些风险级别较低的 功能或者特性
测试用例只进行 了部分性的测试 测试充分性风 或者测试用例未 险 覆盖所有业务逻 辑
9. 风险估计
软件测试风险管理主要是对测试计划执行的风险分析与制 定要采取应急措施，防止软件测试的产生的风险造成的危害。 在软件测试过程中常见的计划风险主要有以下七类： （1）测试时间进度风险：用户需求发生重大变更或设计计 划的大幅调整压缩了测试时间，测试人员、测试环境、测试资 源的不能准时到位也会对测试计划造成影响。 （2）测试范围认知风险：对产品质量需求或产品特性理解 不准确，造成测试范围分析误差，出现测试盲区或验证标准错 误。 （3）测试人员风险：测试开始后，测试人员、技术支持人 员因故不能及时到位。 （4）测试充分性风险：部分测试用例设计时忽视了边界条 件和深层次的逻辑关系；部分测试用例被测试人员有意无意的 忽略执行。 （5）测试环境风险：测试环境无法与生产环境一致，致使 性能测试的结果存在误差。 （7）测试工具风险：能否及时准备相关测试工具，测试人 员对新工具无法熟练运用等情况也时有发生等。 针对以上的风险，分析及可采取的应对预防、应对措施如 下：
首先,找到带有参数传递的URL,如登录 页面,搜索页面,提交评论,发表留言页 面等等。 其次,在页面参数中输入如下语句 (如:Javascript,VBscript, HTML,ActiveX, Flash)来进行测试。 最后,当用户浏览时便会弹出一个警告 框，内容显示的是浏览者当前的 cookie串,这就说明该网站存在XSS漏 洞。 防目录遍 历 目录遍历 在URL中输入一定数量 的“../”和“./”，验证系统是否 ESCAPE掉了这些目录跳转符。 首先找到一些错误页面，比如404、 500页面。 防错误信 息不正确 提示 错误信息 提示 验证在调试未开通过的情况下，是否 给出了友好的错误提示信息比如“你 访问的页面不存在”等，而并非曝露 一些程序代码。
场景法
5.2. 性能测试
使用自动化性能测试工具LoadRunner，对系统前台的资源 检索、资源导航及专题展现等功能进行多用户并发下的压力测 试，通过不断调整并发用户数并调优性能，以期性能达到预期 指标。
性能指标
描述 小于2秒 2~5秒 5~10秒 大于10秒 小于80%
评价 好 良 坏 很差 好 坏 很差 好 良 坏 很差 表 格 8基 础 性 能 指 标
响应时间
CPU占用率
80~90% 大于90% 小于70% 70%~85% 85%~90% 大于90%
内ቤተ መጻሕፍቲ ባይዱ占用率
5.3. 安全性测试
使用工具AppScan对系统进行SQL注入、恶意内容测试、 LDAP注入等方式攻击系统，并根据攻击系统时检查到的问题进 行修复。
测试需求 测试分类 要求 测试重点说明 首先找到带有参数传递的URL页面,如 搜索页面,登录页面,提交评论页面等 等。 防SQL注入 SQL注入 其次,在URL参数或表单中加入某些特 殊的SQL语句或SQL片断。 最后,验证是否能入侵成功或是出错的 信息是否包含关于数据库服务器的相 关信息;如果能说明存在SQL安全漏 洞。
缺陷级别 Blocker Critical Major Minor Trivial 描述 阻塞开发或测试的工作进度，或影响系统无法运行 的错误； 系统崩溃，丢失数据或内存溢出等严重错误、或者 必需完成的任务； 主要的功能无效、新增功能建议； 功能部分无效或对现有系统的改进； 拼写错误，文本未对齐等。 表 格 14 缺 陷 级 别