软件测试方案

测试方案

部 门： ____ _ 编 写： 审 核：

>

批 准： 日 期：

__ ____

_

文档历史信息

文档名称：XXXXX测试方案 文档生成日期： 2015年XX月XX日 版 本 ^ 备 注 日 期 2015年XX月XX日 根据《XXXXXX》及《XXXXX》编写测试方案初稿 ， ！ @ 目 录

1. 引言 .............................................. 错误!未定义书签。

文档目的 .......................................... 错误!未定义书签。

项目背景 .......................................... 错误!未定义书签。

测试目的 .......................................... 错误!未定义书签。

参考资料 .......................................... 错误!未定义书签。

~

2. 测试资源 .......................................... 错误!未定义书签。

. 人员角色分配 ...................................... 错误!未定义书签。

. 测试环境 .......................................... 错误!未定义书签。

. 测试工具 .......................................... 错误!未定义书签。

3. 测试进度 .......................................... 错误!未定义书签。

4. 测试需求分析 ...................................... 错误!未定义书签。

5. 测试策略 .......................................... 错误!未定义书签。

. 功能测试 .......................................... 错误!未定义书签。

<

. 性能测试 .......................................... 错误!未定义书签。

. 安全性测试 ........................................ 错误!未定义书签。

. 兼容性测试 ........................................ 错误!未定义书签。

. 可靠性测试 ........................................ 错误!未定义书签。

. 健壮性测试 ........................................ 错误!未定义书签。

. 易用性测试 ........................................ 错误!未定义书签。

6. 验收标准 .......................................... 错误!未定义书签。

7. 可交付成果 ........................................ 错误!未定义书签。

，

8. 缺陷管理 .......................................... 错误!未定义书签。

9. 风险估计 .......................................... 错误!未定义书签。

1. 引言 1.1 文档目的

本文测试方案针对《XXXXXX》，依据软件需求规格说明书进行编写，是开展测试工作的指导性文档。 1.2 项目背景 1.3 测试目的 1.4 参考资料

￥

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

序 资料名称 号 表格 1参考资料

2. 测试资源 2.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秒 很差 小于80% 好 80~90% 坏 CPU占用率 大于90% <很差 内存占用率 小于70% 好 70%~85% 良 ~坏 85%~90% 大于90% 很差 表格 8基础性能指标

5.3. 安全性测试

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

\\ 测试分类要测试重点说明 求 测试需求 首先找到带有参数传递的URL页面,如搜索页面,登录页面,提交评论页面等等。 ·防SQL注入 SQL注入 其次,在URL参数或表单中加入某些特殊的SQL语句或SQL片断。 最后,验证是否能入侵成功或是出错的信息是否包含关于数据库服务器的相关信息;如果能说明存在SQL安全漏洞。 首先,找到带有参数传递的URL,如登录页面,搜索页面,提交评论,发表留言页面等等。 其次,在页面参数中输入如下语句防跨站点脚本攻击 跨站点脚本攻击 (如:Javascript,VBscript, HTML,ActiveX, Flash)来进行测试。 最后,当用户浏览时便会弹出一个警告框，内容显示的是浏览者当前的cookie串,这就说明该网站存在XSS漏洞。 在URL中输入一定数量的“../”和“./”，验证防目录遍历 目录遍历 系统是否ESCAPE掉了这些目录跳转符。 首先找到一些错误页面，比如404、500页面。 * 错误信息提防错误信息不正确提示 示 验证在调试未开通过的情况下，是否给出了友好的错误提示信息比如“你访问的页面不存在”等，而并非曝露一些程序代码。 *超时 超时 WEB应用系统需要有是否超时的，当用户长时间不作任何操作的时候，需要重新登录才能使用其功能。 表格 9安全性测试

注：AppScan中攻击策略过多，故在此列出部分内容。 5.4. 兼容性测试

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

测试需求 测试重点说明 。不同浏览器下页面布局显示一致。 不同浏览器下图标显示完整无锯齿。 不同浏览器下字段显示完整，无断字、折行。 不同浏览器下颜色显示一致。 兼容性 ： 不同浏览器下跳转正确。 不同浏览器下操作方法一致。 不同浏览器下操作后无JS错误。 不同分辨率下字体、图片等显示一致。 表格 10兼容性测试

5.5. { 5.6. 可靠性测试

测试需求 测试重点说明 产品描述中列出的其他程序或用户造成的错误输入时，系统不崩溃也不丢失数据。 输入用户文档中明确规定的非法指令时，系统不崩溃也不丢成熟性 失数据。 .不会因掉电、异常退出、网络异常中断等原因而使软件或数据遭到破坏。 易恢复性 系统运行失效后，应能较快重建系统。 应对数据项之间的逻辑关系进行校验，保证数据的有效性。 应保证数据的完整性和一致性，不会因删除或反复的更新而数据校验机制 被破坏或留下垃圾数据。 、对不符合要求的输入数据，系统应使用中文给出简洁、准确的提示信息，必要时应给出帮助。 稳定性 系统在测试过程中运行稳定。 表格 11可靠性测试

5.7. 健壮性测试

测试需求 测试重点说明 `能屏蔽用户的误操作。 输入错误数据时，系统不崩溃、不异常退出也不丢失数据。 对错误有正确提示。 有错误操作时，系统不崩溃、不异常退出也不丢失数据。 健壮性或容错性 /测试系统在出现故障时，是否能够自动恢复或者忽略故障继续运行。 对关键进程或线程杀死，然后观察系统行为，是否能够正常恢复。 对关键进程或线程挂起，然后观察系统行为，是否能够正常恢复。 网络不通，然后观察系统行为，是否能够正常恢复。 >数据库不通，然后观察系统行为，是否能够正常恢复。 表格 12健壮性测试

5.8. 易用性测试

测试需求 测试重点说明 通过选择适当的术语、图形表示、背景信息和帮助，帮助用易理解性 户理解、使用出错消息中提供差错产生的原因和纠正的详细信息。 ~数据媒体具有产品标识，可辨别编号或文本。 具有必要的信息，指导用户使用程序。 输入、输出设计规矩，输出结果应简洁、直观、美观、方便易浏览性 阅读、易懂和使用。 人机界面简洁、美观、实用，风格相对一致，符合办公习惯。 `在界面、人机交互、输出中的用语应与业务用语一致。 具有严重后果的功能执行可逆，或者给出明显警告，执行前要求确认。 软件操作简便，系统支持标准的鼠标、键盘操作，支持鼠标的单击、双击和右键操作，支持快捷键操作。 易操作性 提供辅助输入手段（如选择输入、默认值等），数据检索方便、灵活。 %根据用户熟练程度（外行、初学、熟练）和使用频度，能提供不同的操作方式或用户界面。 表格 13易用性测试

6. 验收标准

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

7. 可交付成果

《XXXX测试方案》

《XXXX测试计划》

《XXXX测试用例》

)

《XXXX测试报告》

8. 缺陷管理

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

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

缺陷级别 描述 Blocker 阻塞开发或测试的工作进度，或影响系统无法运行的错误； 《 系统崩溃，丢失数据或内存溢出等严重错误、或者必需完成的任务； Critical Major 主要的功能无效、新增功能建议； Minor 功能部分无效或对现有系统的改进； Trivial 拼写错误，文本未对齐等。 <

表格 缺陷

级别

149. 风险估计

软件测试风险管理主要是对测试计划执行的风险分析与制定要采取应急措施，防止软件测试的产生的风险造成的危害。在软件测试过程中常见的计划风险主要有以下七类：

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

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

（3）测试人员风险：测试开始后，测试人员、技术支持人员因故不能及时到位。

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

（5）测试环境风险：测试环境无法与生产环境一致，致使性能测试的结果存在误差。

【

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

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

风险类型 风险表现 措施 测试时间进度风 开发需求增加 严格按已定流程执行测试，对所有过程进行日常跟踪，及时发现风险险 出现的征兆，避免风险 增加测试时间、人员、资源 与相关人员协商，顺延交付日期 将已有的低优先级的功能或者特性推迟 测试计划时详细描述测试需求范围，经过评审后方可执行测试 测试范围认知风险 测试实际范围与期望的测试范围不一致 如有更新，则及时补充到测试管理平台中，并通过所有项目中的测试人员 对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司，项目不会受到严重影响，仍能可以继测试人员风险 测试人员突然离开 续下去 从其它项目中抽调测试人员 删除某些风险级别较低的功能或者特性 测试充分性风险 测试用例只进行了部分性的测试或者测试用例设计覆盖所有需求，并在设计时注重运用边界值、等价类等测试用例未覆盖所有业务逻辑 设计方法 做好日常的测试执行记录 测试人员参与项目的需求分析和讨论，全面理解产品功能和实现逻辑 通过事先列出要检查的所有条目，测试环境不到位或测测试环境风险 试环境与生产系统不一致 在测试环境设置好后，按已列出条目逐条检查 增加测试资源，如请求用户团队对测试工作提供更多支持 工具不能满足测试需测试工具风险 要，工具的使用产生交流沟通上的障碍 工具使用前进行测试工具的评估 对项目中使用的工具做好相应的培训，并制定相应的使用标准 表格 15风险估计