qileilove

精通软件性能测试与LoadRunner最佳实战 连载八

　9.5.4  验收测试方案索引目录结构

　　也许，有很多测试同行非常关心测试方案的编写内容，这里以我的方案为样本，给大家做一些介绍。

　　以下内容为某项目的验收测试方案索引目录结构。

　　1. 引言

　　1.1 编写目的

　　1.2 项目背景

　　1.3 预期读者

　　1.4 参考文档

　　1.5 名词定义

　　1.5.1 验收测试

　　1.5.2 管理方

　　1.5.3 用户方

　　1.5.4 开发方

　　1.5.5 应用系统

　　2. 系统简介

　　2.1 某系统说明

　　3. 测试目标和标准

　　3.1 测试目标

　　3.2 测试重点

　　3.3 项目进入标准

　　3.4 项目完成标准

　　4. 测试需求分析

　　4.1 某系统的功能测试范围

　　4.1.1 ……功能

　　…… ……功能

　　4.2 某系统的文档测试范围

　　4.3 某系统的性能测试范围

　　5. 测试策略

　　5.1 策略说明

　　5.2 性能测试

　　5.2.1 测试内容

　　5.2.2 测试方法

　　5.2.3 性能验证指标

　　5.2.4 性能测试前提条件

　　5.2.5 性能测试通过标准

　　5.3 功能测试

　　5.3.1 测试内容

　　5.3.2 测试方法

　　5.3.3 功能指标

　　5.3.4 功能测试问题级别定义

　　5.3.5 功能测试通过标准

　　5.3.6 功能测试中止条件

　　5.4 文档验收

　　5.4.1 验收文档内容

　　5.4.2 验收文档要求

　　5.4.3 文档测试问题级别定义

　　5.4.4 文档测试通过标准

　　5.4.5 文档测试中止条件

　　6. 项目实施阶段

　　6.1 项目实施阶段描述

　　6.1.1 测试计划阶段

　　6.1.2 测试需求阶段

　　6.1.3 测试设计阶段

　　6.1.4 测试环境部署

　　6.1.5 第一轮测试执行阶段

　　6.1.6 第二轮测试执行阶段

　　6.1.7 测试总结阶段

　　6.2 测试里程碑

　　6.2.1 进入标准测试

　　6.2.2 测试环境的搭建

　　6.2.3 业务培训

　　6.2.4 制定测试计划、测试需求准备

　　6.2.5 测试设计

　　6.2.6 必要测试工具的开发

　　6.2.7 用例评审

　　6.2.8 测试执行

　　6.2.9 测试总结

　　7. 测试实施安排

　　7.1 工作流程

　　7.2 人员组织

　　7.3 人员配置

　　8. 测试计划

　　8.1 测试工作量估算

　　8.2 测试时间进度表

　　9. 质量保证

　　9.1 需求与变更管理

　　9.2 配置管理

　　9.2.1 主要配置项

　　9.2.2 配置管理员的职责

　　9.2.3 配置库结构

　　9.2.4 需提交的文档名称

　　9.2.5 文档编码规范

　　9.2.6 账号管理

　　9.2.7 权限管理

　　9.2.8 备份计划

　　9.3 项目变更管理

　　9.4 风险管理

　　9.4.1 风险类型

　　9.4.2 发生概率

　　9.4.3 风险影响

　　9.4.4 项目风险

　　10. 缺陷管理

　　10.1 管理权限

　　10.2 缺陷问题级别

　　10.2.1 功能测试问题级别定义

　　10.2.2 文档测试问题级别定义

　　10.2.3 性能测试问题级别定义

　　10.3 缺陷的跟踪与记录

　　10.4 缺陷状态定义

　　10.5 缺陷管理的流程

　　11. 项目沟通

　　11.1 例会

　　11.2 周报

　　12. 工作产品

　9.5.5  验收测试方案的“引言”部分

　　下面针对该索引目录结构的12个索引段落进行介绍。

　　“引言”主要包含了编写目的、项目背景、预期读者、参考文档、名词定义5部分内容。该索引段内容主要是介绍该方案的基本信息，明确相关需求的来源文档（这些文档的来源主要是3部分：甲方、系统研发单位和根据沟通后由我方编写被确认的文档），同时这部分内容阐述了项目的背景明确了预期的读者、相关专业术语，使得相关读者都能够通过阅读该文档掌握整体方案的内容。

　　示范性文档编写内容介绍如下。

　　1.1 编写目的

　　《甲方公司某系统验收测试方案》（以下简称测试方案）阐述了乙方公司对本项目的理解，是测试工作实施的基本依据，提供测试方案文档有助于使客户了解如下内容：

　　明确的测试需求；

　　可采用的测试策略；

　　所需的资源及测试的工作量；

　　测试工作最终应达到的目的；

　　测试工作的风险及规避方法；

　　测试项目的可交付内容；

　　这里将甲方单位名称以“甲方公司”进行替代，系统名称也以“某”进行替代。而本单位名称则以“乙方公司”进行替代，后续均以该处理方式进行，不再赘述。

　　1.2 项目背景

　　该部分内容主要对被测试的系统进行介绍，以及甲方为什么进行该系统进行测试进行描述，鉴于安全性等方面考虑，这里不再详细赘述，读者朋友依据项目实际情况进行编写该部分内容。

　　1.3 预期读者

　　甲方项目管理人员

　　甲方项目实施人员

　　乙方项目管理人员

　　乙方项目实施人员

　　项目开发方项目相关人员

　　1.4 参考文档

　　参考文档主要来源于甲方、系统研发单位和根据沟通后由我方编写被确认的文档，需要特别指出的是，您在列举参考文档时，需要明确文档的作者、文档文件最后修改的时间、文件存放的位置等，以便想读者可以快速得到正确的文档，进行阅读。

　　1.5 名词定义

　　1.5.1　验收测试

　　验收测试是系统开发生命周期方法论的一个阶段，这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。通常验收测试是由具有计算机应用系统测试评估能力具有法人资格的、独立于用户单位及开发单位的第三方来进行，一般对应用系统的需求分析、设计方案以及相关应用软件和硬件设备的功能、性能、安全性等方面进行科学、公正和相对独立的综合测试评估。

　　1.5.2　管理方

　　管理方在这里是指负责组织和管理执行验收测试的单位。

　　1.5.3　用户方

　　用户方在这里是指应用系统的最终使用单位和运行维护单位。

　　1.5.4　开发方

　　开发方在这里是指承担被测试的应用系统开发的单位。

　　1.5.5　应用系统

　　应用系统在这里是指由相关的软、硬件构成，能够为企业解决流程或工作中特定问题的系统，在本方案中指被测试的某系统。

　9.5.6  验收测试方案的“系统介绍”部分

　　“系统简介”索引段落内容主要是对被测试应用系统的功能、性能、文档特性进行概括性的介绍。

　　9.5.7  验收测试方案的“测试目标和标准”部分

　　“测试目标和标准”索引段落内容主要包括4部分内容：测试目标、测试重点、项目进入标准、项目完成标准。

　　示范性文档编写内容介绍如下。

　　3.1 测试目标

　　某单位某系统验收测试的目标是：以《某单位某系统需求规格说明书》、《某单位某系统程序设计说明书》及所有经某单位确认的需求为基准，在规定的时间范围内，从应用系统的功能性开展验收测试，以验证系统功能、文档、性能是否符合用户要求，按约定期限提交被测系统是否可以进入生产运行的评估报告，为用户是否接受系统提供决策依据。

　　3.2 测试重点

　　该部分内容您可以依据验收测试的用户实际需求，进行描述，这里不再赘述。

　　3.3 项目进入标准

　　项目进入标准是接收被测系统进入测试的必要条件和基础，项目进入标准的主要内容如下：

　　合同签署完毕，并开始执行合同；

　　管理方已认可测试方的项目测试计划（包括时间计划）；

　　管理方准备好测试方要求的技术文档、用户文档及相关说明书；

　　管理方及管理方协调的有关支持人员和相关业务人员已明确并到位；

　　管理方提供被测试的应用系统软件的测试环境（包括软件和硬件）；

　　管理方提交开发方的测试计划、测试用例和测试报告；

　　管理方成立测试领导小组，指明专门负责人；

　　测试方相关人员到位。

　　3.4 项目完成标准

　　符合以下全部条件时，验收测试工作视同结束：

　　系统不存在致命性错误和严重性错误；

　　告警性错误在测试用例数的1%以内；

　　系统重要功能模块不再含有告警性错误；

　　通过管理方的验收工作。

　　9.5.8  验收测试方案的“测试需求分析”部分

　　“测试需求分析”索引段落内容，结合此次验收测试的内容主要包括3部分内容，即：功能测试、文档测试和性能测试。通常在这部分我们要明确测试的功能点、测试的文档和性能测试需求范围，以表格的形式列出相关内容（请参见表9-2、表9-3和表9-4），特别是在做性能测试相关内容时，因为很多用户甚至是系统的研发方都没有一个清晰明确的性能需求描述，这是就需要项目经理或者相应的技术人员明确该部分内容，以避免验收测试完成后，产生不必要的分歧或者矛盾情况。

表9-2 功能测试范围表

表9-3 测试文档范围表

注：在没有特殊说明的情况下，所有文档均从配置管理工具中获取，请参考相关获取路径。

表9-4 性能测试范围表

　　9.5.9  验收测试方案的“测试策略”部分

　　“测试策略” 索引段落内容主要针对功能、文档和性能测试的内容、测试方法、缺陷级别定义、测试前提条件和测试通过标准等内容进行了较详细的描述。

　　示范性文档编写内容介绍如下。

　　5.1 策略说明

　　根据国家标准《GB/T16260—2006软件工程产品质量》，软件质量主要考察功能、效率、可靠、易用、移植、可维护等六个方面。同时结合本次测试的性质、系统特点和时间要求，以及对测试需求的分析，本次我方计划针对某单位某系统从性能、文档、功能三方面进行验收测试工作。

　　5.2 性能测试

　　5.2.1 测试内容

　　根据需求分析报告和设计文档提出的各项性能指标及某单位某系统一般性要求，检测系统在各种负载情况下的响应、处理时间，及在业务量高峰期的承受能力等指标是否符合需求。性能测试分为性能测试、负载测试、压力测试、配置测试、并发测试、容量测试、可靠性测试、失败测试八种类型。

　　（1）性能测试是一种“正常”的测试，主要是测试正常使用时，系统是否满足要求，同时可能为了保留系统的扩展空间进行一些稍稍超出“正常”范围的测试。

　　（2）负载测试：通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量。简而言之，负载测试是通过逐步加压的方式来确定系统的处理能力，确定系统能够承受的各项阈值。例如，逐步加压，从而得到“响应时间不超过10秒”，“服务器平均CPU利用率低于85%”等指标的阈值。

　　（3）压力测试：通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并获得系统能提供的最大服务级别。压力测试是逐步增加负载，使系统某些资源达到饱和甚至失效的测试。

　　其他的性能测试分类为。

　　（4）配置测试：主要是通过对被测试软件的软、硬件配置的测试，找到系统各项资源的最优分配原则。

　　（5）并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，几乎所有的性能测试都会涉及一些并发测试。

　　（6）容量测试：测试系统能够处理的最大会话能力，确定系统可处理同时在线的最大用户数，通常和数据库有关。

　　（7）可靠性测试：通过给系统加载一定的业务压力（如CPU资源在70%～90%的使用率）的情况下，运行一段时间，检查系统是否稳定。因为运行时间较长，通常可以测试出系统是否有内存泄漏等问题。

　　（8）失败测试：对于有冗余备份和负载均衡的系统，通过这样的测试来检验如果系统局部发生故障，用户是否能够继续使用系统，用户受到多大的影响，如几台机器做均衡负载，测试一台或几台机器垮掉后，系统能够承受的压力。

　　5.2.2 测试方法

　　分析、调研阶段统计用户使用习惯，编写性能测试计划；

　　结合业务分析、调研情况，设计系统性能模型；

　　设计阶段将性能模型转化为测试场景，使用压力测试工具录制并调试测试脚本，或自行编制压力测试程序，同时准备测试数据；

　　实施阶段运行测试场景，按照实际运行中统计的用户并发量，设定每项压力测试的起始业务并发数量，以及并发量递增的梯度；参照系统的峰值设计需求，逐步对系统加压至性能拐点；

　　针对性能测试执行结果，进行分析，定位问题，对系统调优，同环境回归测试（可能进行多次，根据实际情况需要确定）；

　　编写性能测试总结报告。

　　5.2.3 性能验证指标

　　本次性能测试验证如下指标：

　　系统业务处理容量（TPS）；

　　业务响应时间（秒）；

　　系统CPU占用率；

　　系统内存占用率；

　　系统I/O使用率。

　　5.2.4　性能测试前提条件

　　测试环境准备就绪（最好为生产环境或近似环境）；

　　应用系统开发完成，发布正式版本；

　　已经完成安装配置测试，且系统可用；

　　应用系统经过软、硬件配置调优工作。

　　5.2.5　性能测试通过标准

　　在指定测试环境下，软件性能等与业务需求一致；

　　没有严重影响系统运行的性能问题。

5.3 功能测试

　　5.3.1 测试内容

　　功能测试分GUI测试、业务测试、异常测试、易用性测试四部分进行。

　　GUI测试检验用户界面是否满足用户需求，是否符合软件界面的通用设计原则。

　　业务测试检验软件业务功能和业务流程是否满足用户需求，此项测试依据用户需求说明进行。

　　异常测试检验在多用户同时使用系统的情况下，业务功能是否可以正常执行，是否会产生资源竞争、互斥等现象。

　　易用性测试从以下三个方面考虑：易操作性、易理解性、易学性。根据以上三个原则对系统进行测试。

　　易操作性的测试目的在于增加软件操作的简易性，让用户容易接受软件，也方便用户的日常使用；易理解性测试目的在于让用户能迅速了解软件的操作流程；易学性测试目的在于让用户迅速学会操作软件。

　　5.3.2 测试方法

　　采用黑盒测试技术，手工模式执行测试，着眼于系统的功能，不考虑内部逻辑结构，针对软件界面和业务功能进行测试。在充分了解系统架构和业务逻辑的基础上，从不同的运行与控制条件等角度组合不同的输入条件和预定结果，测试功能的执行情况、业务流程执行情况和信息反馈情况等，以找出软件中可能存在的缺陷。按照系统功能说明，逐一设计正常测试用例和错误操作测试用例并执行，测试中发现的问题及时提交到缺陷管理系统。

　　5.3.3 功能指标

　　本次功能测试验证如下指标。

　　功能完整性：软件产品完全满足用户要求的业务处理实现。

　　适合性：软件产品为指定的任务和用户要求提供了合适功能的实现。

　　准确性：软件产品提供具有所需要精度的正确或相符的结果或效果的能力，特别是在多用户使用情况下功能和业务流程是否能正常和准确执行。

　　互操作性：软件产品与相关系统进行交互的能力。

　　易用性：软件产品易操作性、易理解性、易学性方面的能力。

　　可维护性：软件产品可测试性、可修改性、可使用性。

　　5.3.4　功能测试问题级别定义

表9-5 功能测试问题级别定义

　　5.3.5 功能测试通过标准

　　软件功能与业务需求要求一致；

　　没有P1（致命性）问题与P2（严重性）问题，且P3（告警性）问题和P4（建议性）问题数量不高于测试方与用户的预先协商值。

　　5.3.6 功能测试中止条件

　　功能测试过程中，如发生以下情况，则中止测试活动：

　　发现程序不是最新版本；

　　正确安装后，发现主要模块功能不能正常运行，且影响其他模块的功能测试；

　　发现大量致命性问题，需要开发方立即修改。

　　测试中止后，开发方修改时间由某单位、测试方和开发方共同商定，修改完成后继续实施功能测试。

　　5.4 文档验收

　　5.4.1　审查内容

　　文档审查针项目立项、实施、运营维护等各环节中的关键文档进行，受审查的文档类型如表9-6所示，具体实施内容需与客户协商后决定。

表9-6 受审查的文档类型

　　目前已知需要验收测试的文档如表9-7所示。

表9-7 测试文档范围表

　　5.4.2　文档要求

　　文档完备性；

　　文档内容充分性；

　　文字明确性；

　　文档描述的正确性，联机帮助文档中链接的正确性；

　　易读性；

　　检查文档间的一致性；

　　检查程序和文档的一致性；

　　检查文档间的可追溯性；

　　检查文档是否符合指定的相应模板和规范。

　　5.4.3 文档测试问题级别定义

表9-8 文档测试问题级别定义

　　5.4.4　文档测试通过标准

　　文档测试通过标准为，文档测试关闭时不允许存在1、2级问题，3、4级问题的出现频率为平均每6页3个以内。

　　5.4.5 文档测试中止条件

　　如任何一个被测试文档在一页当中出现超过16个任何等级的问题，该文档即被视为不可用，立刻停止对该文档的测试，交由文档作者修改后再重新测试。

　　（未完待续）

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。

相关链接：

精通软件性能测试与LoadRunner最佳实战 连载一

精通软件性能测试与LoadRunner最佳实战 连载二

精通软件性能测试与LoadRunner最佳实战 连载三

精通软件性能测试与LoadRunner最佳实战 连载四

精通软件性能测试与LoadRunner最佳实战 连载五

精通软件性能测试与LoadRunner最佳实战 连载六

精通软件性能测试与LoadRunner最佳实战 连载七

posted on 2013-07-05 10:49 顺其自然EVO 阅读(357) 评论(0)  编辑  收藏 所属分类: loadrunner