xxxx系统测试方案
变更记录
| 状态 | 版本 | 变更内容概述 | 变更人/日期 | 审核人/日期 | 批准人/日期 |
注：状态分四种：C——创建，A——增加，M——修改，D——删除
1.概述
测试是质量保证的重要手段。相关统计资料表明，优秀软件开发机构40%的工作量花在软件测试上，软件测试费用占软件开发总费用的30%至50%。对于一些要求高可靠、高安全的软件，测试费用可能相当于整个软件项目开发所有费用的3至5倍。由此可见，要成功开发出高质量的应用信息系统，必须重视并加强测试工作。
xx公司有严格的测试管理体系，遵循国际最先进的面向对象软件测试标准，采用先进的自动测试软件，拥有一批专业的测试工程师，对软件产品进行“苛刻”的测试。
本次测试为系统试运行前的系统测试，通过手工和测试工具相结合的方式在公司内部测试环境上从 “模块功能”、“整体业务流程”、“界面UI”、“兼容性”、“整体性能表现”等方面对程序进行全面的检验、评估，目的在于验证系统已经符合用户方验收标准，同时提供客观、真实、详尽的测试数据供用户方进行评判。
2.阅读人群
公司方项目相关人员，系统最终用户。
3.名词解释
| 等价类划分法 | 等价列划分设计方法是把所有可能的输入数据划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例，测试某等价类的代表值就等于对这一类其他值的测试。 |
| 边界值分析法 | 边界条件指的是输入和输入等价类中刚好处于边界、或超过边界或小于边界的状态，使用边界值分析方法设计测试用例应先确定边界情况，然后选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。 |
| 因果图法 | 因果图法是一种适合于描述对于多种条件的组合、相应产生多个动作的形式的测试用例设计方法。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。 |
| 判定表驱动分析法 | 判定表是分析和表达多逻辑条件下执行不同操作的情况下的工具。在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了。由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。 |
| 错误推测法 | 错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。 |
| 正交实验设计方法 | 正交实验设计方法：依据Galois理论，从大量的（实验）数据（测试例）中挑选适量的，有代表性的点（例），从而合理地安排实验（测试）的一种科学实验设计方法。 |
| 场景法 | 通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。 |
4.测试目的
从 “模块功能”、“整体业务流程”、“界面UI”、“兼容性”、“整体性能表现”等多方面对“xxx系统”软件进行测试，验证系统功能上符合需求设计标准且满足用户的实际业务需求，整体性能表现满足用户方标准。
5.测试资源
在测试设计活动中，如果没有测试数据，测试过程和测试用例将无法实施和执行。本次测试数据由xx部各项目提供业务数据，例如Oracle数据，MySQL数据等。确定实际的测试数据后，我们将围绕测试数据的以下四个属性来进行准备：
1、深度——测试数据中数据的容量或数量
深度是一个需要考虑的重要事项，在测试过程中，我们将首先使用一个较小的支持关键测试用例的数据集（即正面测试用例）。随着测试过程的不断持续，逐步增加测试数据，直到数据深度完全体现出实际环境为止。
2、宽度——测试数据中数据的变化程度
宽度是指测试数据值变化的程度。创建更多的记录就可以增加测试数据的深度。但是它无法解决我们期望在实际数据中看到的数据真实变化的问题。因此我们会首先生成一版基础测试数据，并在实际测试过程当中通过手工测试以及利用自动化工具的方式使基础数据产生不同范围的变化，以此来模拟实际生产环境中的数据变化。
3、范围——测试数据与测试目标的相关性
范围和测试深度和测试宽度相关。具有许多数据并不意味着其数据一定正确。与处理测试数据的宽度一样，我们会确保测试数据和测试目标相关，也就是说，能够保证支持特定测试目标的测试数据。
4、构架——测试数据的物理结构
本次测试将需要在迭代中以及各个迭代之间重复执行。为统一、有效、可控地执行测试，测试数据应在测试执行前返回其初始状态。在自动执行测试时，这一点尤其重要。
因此，为了确保测试的完整性、把握性和有效性，测试数据不受外部的任何影响，并且了解测试执行在开始、期间和结束阶段的状态，这两点异常重要。为了达到测试目标，我们将在整体测试开始前将测试数据进行备份，在每一轮迭代测试完成后恢复数据。
6.测试环境
| 软件环境 | |||||
| 设备用途 | 操作系统 | IP地址 | 服务软件 | 测试软件 | 硬件参数 |
| 硬件环境 | |||||
7.测试人员构成
为了保证软件的开发质量，软件测试应贯穿于软件定义与开发的整个过程。因此，对分析、设计和实现等各阶段所得到的结果，包括需求规格说明、设计规格说明及源程序都应进行软件测试。基于此，从广义上，我们将需求评审组、设计评审组也视为测试人员组织，因此我们将不同阶段的测试组织分为：
1、需求评审小组
需求分析规格说明是否完整、正确、清晰是软件开发成败的关键。为了保证需求定义的质量，应对其进行严格的审查。审查小组由下列人员组成：
组长：1人，项目技术总监兼任；
成员：技术委员会所有成员、开发组组长、测试组组长、系统分析员、软件架构师、用户及其它相关人员等。
2、设计评审小组
软件设计是将软件需求转换成软件表示的过程。主要描绘出系统结构、详细的处理过程和数据库模式。按照需求的规格说明对系统结构的合理性、处理过程的正确性进行评价，同时利用关系数据库的规范化理论对数据库模式进行审查。评审小组由下列人员组成：
组长：1人，由项目技术总监兼任；
成员：技术委员会所有成员、测试组组长、开发组组长、高级系统分析师、软件架构师、测试工程师、用户及其它相关人员等。。
3、程序功能测试组
软件测试在软件生存周期中横跨两个阶段：在编写出每一个模块之后，就对它进行单元测试。该阶段的测试工作，由编程组内部人员进行交叉测试（避免编程人员测试自己的程序）。这一阶段结束后，进入软件生存周期的测试阶段，由专门的测试人员对软件系统进行各种综合测试。
组长：1人
成员：测试工程师、需求人员等。
8.测试步骤
1、制定测试计划
不管是单元测试、集成测试、系统测试、还是压力测试，验收测试，都需要制定详细的测试计划，对测试的目的和内容、测试的环境、人员、时间、方法和步骤，以及测试的准则等作出具体安排。
2、设计和实现测试用例
测试用例是测试的具体指导方案。一般包括白盒测试和黑盒测试两种。
白盒测试的进入前提是在测试人员已经对被测试对象有了一定的了解，基本上明确了被测软件的逻辑结构。通过针对程序的逻辑结构设计和加载测试用例，驱动程序执行，检查在不同点程序的状态，以确定实际状态是否与预期状态一致。
白盒测试主要测试以下项目：
对程序模块的所有独立的执行路径至少覆盖一次。
对所有的逻辑判定，真假两种情况都至少覆盖一次。
在循环的边界和运行界限内执行循环体。
测试内部数据结构的有效性。
白盒测试要达到的目标：语句覆盖率达到100％，分支覆盖率达到100％，覆盖程序中主要的路径（主要路径指完成需求和设计功能的代码所在的路径和程序异常处理执行到的路径）。
黑盒测试要根据系统的功能和性能需求来设计测试用例，以验证程序内部活动是否符合客户要求的活动。
黑盒测试主要测试以下项目：
被测单元的功能是否实现。
被测单元的性能是否满足要求。
可选的其他测试项，如边界、安全性、可靠性、强度测试、人机交互界面测试等。
黑盒测试要达到的目标：系统正确的实现了需求和设计上要求的功能，满足性能要求，同时程序可靠和安全。
3、测试执行
根据测试用例执行测试，并记录测试结果。
4、测试报告与总结
对测试结果进行整理、分析，形成报告
9.测试通过标准
功能上无业务逻辑错误和严重错误、较严重错误、一般性错误，所有业务流程均测试通过且不存在功能缺陷。
10.缺陷管理流程
11.测试计划
| 测试类型 | 测试时间 | 参与测试人员 |
| 模块功能测试 | ||
| 系统整体流程测试 | ||
| 系统界面UI及友好性测试 | ||
| 兼容性测试 |
注：说明测试的各个阶段的预期时间范围。 表 10.1
12.测试方案
测试方案提供了对测试对象进行测试的推荐方法。对于每种测试，都应提供测试说明，并解释其实施的原因。制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、有控制的数据库来执行。
12.1.模块测试
模块测试的目的是保证每个模块作为一个单元能正确运行，在这个测试步骤中所发现的往往是编码和详细设计的错误。本次通过对“xxxx系统”软件提供的所有模块进行测试，目标是核实被测试模块是否满足开发要求，是否能够提供设计所描述的功能，用户的需求是否都能够得到满足。
12.1.1.测试范围
“xxx系统”软件提供的所有功能模块，不包含接口相关的功能
12.1.2.测试目标
验证被测试模块是否符合用户实际需求且测试优先级为“高”、“中”的关键项没有任何缺陷，测试优先级为“低”的关键项缺陷率低于5%。
12.1.3.测试方法
主要采取手工执行测试用例的方法来进行测试，对于大量的重复性的操作以测试工具代替手工执行。
12.1.4.测试内容
| 编号 | 模块名称 | 关键项 | 优先级 |
12.2.业务流程测试
业务流程测试主要针对系统的业务流程流转是否正常，单个模块没有问题，不代表模块之间的调用也没有问题，所以需要测试各个模块之间的业务流程是否通顺。
12.2.1.测试范围
“xx系统”软件提供的全部功能模块对应的所有流程，不包含接口相关的功能对应的交互流程。
12.2.2.测试目标
验证系统的业务流程能够正确执行且满足用户的实际业务需求。
12.2.3.测试方法
手工测试
12.2.4.测试内容
| 编号 | 业务流程 | 关键项 |
12.3.界面测试
界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
界面测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。除此之外，界面测试还要确保界面功能内部的对象符合预期要求，并遵循公司或行业的标准。
12.3.1.测试范围
“xx系统”软件提供的全部功能模块
12.3.2.测试目标
各模块风格（包括颜色、字体、提示信息、图标、TITLE等）应保持一致，或符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯。
12.3.3.测试方法
手工测试
12.3.4.测试内容
| 编号 | 关键项 | 检验内容 |
| 1 | 导航 |
|
| 2 | 链接 |
|
| 3 | 菜单 | 系统中所有菜单的显示风格应一致。菜单显示的颜色、样式应符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯。 |
| 4 | 页面背景颜色 | 系统中所有页面都应有默认的背景颜色且符合可接受标准，能够保证用户界面的友好性。 |
| 5 | 页面字体 | 系统中所有字体显示的字号、样式、字体等格式应保持统一且符合可接受标准，能够保证用户界面的友好性。 |
| 6 | 按钮 | 系统中所有按钮被点击后所执行的操作应与按钮本身显示的文字能够对应，不存在无效按钮，按钮样式、按钮文字应保持统一风格。 |
| 7 | TITLE | 系统中所有页面应具有TITLE且风格统一。 |
| 8 | 系统提示信息 |
|
12.4.兼容性测试
兼容性测试是指待测试项目在特定的硬件平台上，不同的应用软件之间，不同的操作系统平台上，在不同的网络等环境中能正常的运行的测试。
兼容性测试的目的：待测试项目在不同的操作系统平台上正常运行，包括待测试项目能在同一操作系统平台的不同版本上正常运行；待测试项目能与相关的其他软件或系统的“和平共处”；待测试项目能在指定的硬件环境中正常运行；待测试项目能在不同的网络环境中正常运行。
Web兼容性测试主要是针对不同的操作系统平台，浏览器，以及分辨率进行的测试。
操作系统兼容性测试：
常见的操作系统有Windows，Unix，Linux等，对于普通用户来讲，最常用的是Windows操作系统。Windows操作系统包括Windows XP，Windows 7，Windows 8等等。用户使用操作系统的类型，直接决定了我们操作系统平台兼容性测试的操作系统平台数量，进行操作系统平台的兼容性测试的主要目的就是保证我们的待测试项目在该操作系统平台下能正常运行。
浏览器兼容性测试：
浏览器是Web系统中对核心的组成构件，来自不同厂家的浏览器对Javascript、ActiveX或不同的HTML规格有不同的支持，即使是同一厂家的浏览器，也存在不同的版本的问题。不同的浏览器对安全性和JAVA的设置也不一样。
12.4.1.测试范围
“xx系统”软件提供的所有功能模块，不包含接口相关的功能
12.4.2.测试目标
验证系统在不同的终端操作系统、浏览器版本的组合下能够正确运行
12.4.3.测试方法
手工测试
12.4.4.测试内容
| 序号 | 方案 | 条件组合 |
| 1 | 方案1 | 浏览器：IE10 |
| 操作系统：WIN 8 | ||
| 2 | 方案2 | 浏览器：火狐28及以上 |
| 操作系统：WIN 8 |
13.测试提交文档
下面应当列出在测试阶段结束后，所有可提交的文档，可根据实际情况进行修改。
《xx测试计划》
《xx测试用例》
《xx测试报告》
14.问题严重度描述
Bug的严重程度依据该项bug对系统造成的影响程度来划分为5级，QC中的定义及划分标准如下：
| QC中级别定义 | 具体说明 |
| 5_致命 | 五级bug：系统崩溃或挂起等导致系统不能继续运行。包括以下各种错误： 1）由于程序所引起的死机，非法退出 2）死循环 3）数据库发生死锁 4）因错误操作导致的程序中断 5）与数据库连接错误 6）数据通讯错误 7）与需求不一致 |
| 4_严重 | 四级bug：即严重地影响系统要求或基本功能的实现，且没有更正办法。使系统不稳定、或破坏数据、或产生错误结果，或导致部分功能无法执行，而且是常规操作中经常发生的主要问题。包括以下各种错误： 1）程序接口错误 2）因错误操作迫使程序中断 3）业务流程实现不正确 4）用户权限无法实现 5）功能实现不完整，如删除时没有考虑数据关联 6）基本功能未实现，影响流程或其他重要功能的进行。 |
| 3_高 | 三级bug：即严重地影响系统要求或基本功能的实现，但存在合理的更正办法，产生错误的中间结果但不影响最终结果等影响有限的问题。包括以下各种错误： 1）功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现 2）基本功能未实现，但不影响执行工作功能或重要功能 3）字段输入内容未作验证判断，导致错误内容出现 4）操作界面错误（包括数据窗口内列名定义、含义是否一致） 5）打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误） 6）删除操作未给出提示 |
| 2_中 | 二级bug：即易用性差，或界面拼写错误及用户使用不方便小问题。包括以下各种错误： 1）界面不规范 2）辅助说明描述不清楚 3）长时间操作未给用户提示 4）提示窗口文字未采用行业术语 5）可输入区域和只读区域没有明显的区分标志 6）必填项与非必填项应加以区别 7）滚动条无效 8）键盘支持不好，如在可输入多行的字段中，不支持回车换行；或对相同字段，在不同界面支持不同的快捷方式 9）界面不能及时刷新，影响功能实现 10）错别字 |
| 1_低 | 一级bug：其他错误。包括以下各种错误： 1）光标跳转设置不好，鼠标（光标）定位错误 2）一些建议性问题 |
Bug的修改优先级依据bug是否将影响测试流程继续进行下去的程度来划分为5级，QC中的定义及划分标准如下：
| QC中级别定义 | 具体说明 |
| 高级 |
|
| 中级 |
|
| 低级 |
|
备注：
1、本项目测试工作将按照公司《软件测试过程》要求进行。
2、测试进度依赖于开发提交的版本时间、版本内容及缺陷修改及时性，缺陷修改正确性，故请开发组保证好以上前提，请xxx及时跟踪项目进度，以确保测试计划顺利进行。
扫一扫
9419
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
