验收测试的主要内容
验收测试过程
验收测试的常用策略
验收测试报告
用户验收测试实例
1、验收测试的主要内容
● 验收测试是部署软件之前的最后一个测试操作。
● 验收测试的目的是：确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试的任务
● 验收测试是向未来的用户表明系统能够像预定要求那样工作。也就是验证软件的有效性。
● 验收测试的任务，即验证软件的功能和性能如同用户所合理期待的那样。
验收测试的主要内容
● 验收测试的主要内容有以下几个方面：
1.制定验收测试标准
2.配置项复审
3.实施验收测试
验收测试主要内容——制定验收标准
● 实现软件确认要通过一系列测试。验收测试同样需要制订测试计划和过程。
● 测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，为的是在说明软件与合同要求是否一致。
● 无论是计划还是过程，都应该着重考虑以下几个方面：
1.软件是否满足合同规定的所有功能和性能
2.文档资料是否完整
3.准确人机界面
4.其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。
● 验收测试主要内容——实施验收测试
● 验收测试的准备工作做好之后，就要进入验收测试的实施阶段。
● 在此阶段里，需要采用一些常用的验收测试策略进行，例如：α测试，β测试等。
● 实施验收测试是整个验收测试过程中的核心部分。
验收测试主要内容——配置项复审
● 验收测试的另一个重要环节是配置项复审。在进行验收测试之前，必须保证所有软件配置项都能进入验收测试，只有这样才能保证最终交付给用户的软件产品完整性和有效性。
● 复审的目的：保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。
2、验收测试过程
● 进行验收测试，必须要了解验收测试的过程。只有按照验收过程的步骤进行，才能保证验收测试的顺利实施。
验收测试过程的主要内容
1.软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。
2.编制《验收测试计划》和《项目验收准则》：根据软件需求和验收要求编制测试计划，制定需测试的测试项，制定测3.试策略及验收通过准则，并经过客户参与的计划评审。
3.测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编制测试用例，并经过评审。
4.测试环境搭建：建立测试的硬件环境、软件环境等。（可在委托客户提供的环境中进行测试）
5.测试实施：测试并记录测试结果。
6.测试结果分析：根据验收通过准则分析测试结果，作出验收是否通过及测试评价。
7.测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。
验收测试过程流程图
验收测试步骤
步骤1：验收测试业务恰谈
双方就测试项目及合同进行洽谈
步骤2：签订测试合同
步骤3：开发方提交测试样品及相关资料
开发方需提交的文档有：
基本文档：（验收测试必需的文档），用户手册，安装手册，操作手册，维护手册，软件开发合同，需求规格说明书，软件设计说明，软件样品（可刻录在光盘）
特殊文档：（根据测试内容不同，委托方所需提交下列相应的文档），软件产品开发过程中的测试记录，软件产品源代码。
步骤4：开发方提交测试样品及相关资料
步骤5：编制测试计划并通过评审
步骤6：进行项目相关知识培训
步骤7：测试设计
评测中心编制测试方案和设计测试用例集。
步骤8：方案评审
评测中心测试组成员、委托方代表一起对测试方案进行评审。
步骤9：实施测试
评测中心对测试方案进行整改，并实施测试。在测试过程中每日提交测试事件报告给委托方。
步骤10：编制验收测试报告并组织评审
评测中心编制验收测试报告，并组织内部评审。
步骤11：提交验收测试报告
评测中心提交验收测试报告。
3、验收测试的常用策略
● 施验收测试的常用策略有三种，它们分别是：
1.正式验收测试
2.非正式验收或 α 测试
3.β 测试
● 选择的策略通常建立在合同需求、组织和公司标准以及应用领域的基础上。
正式验收测试
● 正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集
1.正式验收测试的两种方式：
2.在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。
在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。
● 正式验收测试形式的优点包括：
1.要测试的功能和特性都是已知的。
2.测试的细节是已知的并且可以对其进行评测。
3.这种测试可以自动执行，支持回归测试。
4.可以对测试过程进行评测和监测。
5.可接受性标准是已知的。
● 正式验收测试形式的缺点包括：
1.要求大量的资源和计划。
2.这些测试可能是系统测试的再次实施。
3.可能无法发现软件中由于主观原因造成的缺陷，这是因为您只查找预期要发现的缺陷。
非正式验收或 α 测试
● 在非正式验收测试中，执行测试过程的限定不象正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。
● 这种验收测试方法不象正式验收测试那样组织有序，而且更为主观。
● 大多数情况下，非正式验收测试是由最终用户组织执行的。
● 非正式验收或 α 测试的优点包括：
1.要测试的功能和特性都是已知的。
2.可以对测试过程进行评测和监测。
3.可接受性标准是已知的。
4.与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
● 非正式验收或 α 测试的缺点包括：
1.要求资源、计划和管理资源。
2.无法控制所使用的测试用例。
3.最终用户可能沿用系统工作的方式，并可能无法发现缺陷。
4.最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。
5.用于验收测试的资源不受项目的控制，并且可能受到压缩。
● β 测试
在上述三种验收测试策略中， β 测试需要的控制是最少的。在 β测试中，采用的细节多少、数据和方法完全由各测试员决定。各测试员负责创建自己的环境、选择数据，并决定要研究的功能、特性或任务。各测试员负责确定自己对于系统当前状态的接受标准。
● β 测试由最终用户实施，通常开发（或其他非最终用户）组织对其的管理很少或不进行管理。
● β测试是所有验收测试策略中最主观的。
● β 测试的优点是：
1.测试由最终用户实施。
2.大量的潜在测试资源。
3.提高客户对参与人员的满意程度。
4.与正式或非正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
● β 测试的缺点是：
1.未对所有功能和/或特性进行测试。
2.测试流程难以评测。
3.最终用户可能沿用系统工作的方式，并可能没有发现或没有报告缺陷。
4.最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。
5.用于验收测试的资源不受项目的控制，并且可能受到压缩。
6.可接受性标准是未知的。
7.需要更多辅助性资源来管理β 测试员。
4、验收测试报告
● 做为测试的结果，需要给出测试报告。验收测试也不例外。
● 在验收测试的结束部分，需要以文档的形式提供“验收测试报告”做为对验收测试结果的一个书面说明。
验收报告的模板
● 验收报告一般分为三个部分：头部，主体，尾部
● 验收报告的头部应该标明项目的一些基本信息，参考格式如下：
项目验收报告
项目名称：
产品名称：
产品版本：
客户名称：
供应方：
验收日期：
● 验收报告主体内容可以参考以下的模板格式：
目录
....
1 前言
1.1 编写目的
...
1.2 项目背景
...
2 功能验收
验收项类别 验收项名称 说明 是否通过验收 备注
3 性能验收
验收项类别 验收项名称 说明 是否通过验收 备注
4 交付物验收
验收项类别 验收项名称 说明 是否通过验收 备注
硬 件
软 件(安装光盘)
文 档
......
5 验收结论
......
● 在验收报告的尾部，需要注明验收报告的时间，验收单位（个人）等验收测试相关信息。参考格式如下：
验收方： 提供方：
项目负责人签字： 项目负责人签字：
日期： 日期：
5、用户验收测试实施
用户验收测试可以分为两个大的部分：软件配置审核和可执行程序测试，其大致顺序可分为：
1.文档审核
2.源代码审核
3.配置脚本审核
4.测试程序或脚本审核
5.可执行程序测试。
软件配置审核：
对于一个外包的软件项目而言，软件承包方通常要提供如下相关的软件配置内容：
―可执行程序
―源程序
―配置脚本
―测试程序或脚本。
● 主要的开发类文档：
《需求分析说明书》
《概要设计说明书》
《详细设计说明书》
《数据库设计说明书》
《测试计划》
《测试报告》
《程序维护手册》
《程序员开发手册》
《用户操作手册》
《项目总结报告》
● 主要的管理类文档：
《项目计划书》
《质量控制计划》
《配置管理计划》
《用户培训计划》
《质量总结报告》
《评审报告》
《会议记录》
《开发进度月报》
● 在开发类文档中，容易被忽视的文档有《程序维护手册》和《程序员开发手册》。
《程序维护手册》的主要内容包括：系统说明（包括程序说明）、操作环境、维护过程、源代码清单等，编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。
《程序员开发手册》的主要内容包括：系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等，实际上就是程序员的培训手册。
● 通常，正式的审核过程分为5个步骤：
计划
预备会议（可选）：对审核内容进行介绍并讨论
准备阶段：各责任人事先审核并记录发现的问题
审核会议：最终确定工作产品中包含的错误和缺陷
问题追踪
审核要达到的基本目标是：
根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。
在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。
在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成后，就可以进行验收测试的最后一个步骤—可执行程序的测试。
可执行程序的测试包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量等五部分。
要注意的是不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。
在真正进行用户验收测试之前一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）：
软件开发已经完成，并全部解决了已知的软件缺陷。
验收测试计划已经过评审并批准，并且置于文档控制之下。
对软件需求说明书的审查已经完成。
对概要设计、详细设计的审查已经完成。
对所有关键模块的代码审查已经完成。
对单元、集成、系统测试计划和报告的审查已经完成。
所有的测试脚本已完成，并至少执行过一次，且通过评审。
使用配置管理工具且代码置于配置控制之下。
软件问题处理流程已经就绪。
已经制定、评审并批准验收测试完成标准。
具体的测试内容通常可以包括：
● 安装（升级）
● 启动与关机
● 功能测试（正例、重要算法、边界、时序、反例、错误处理）
● 性能测试（正常的负载、容量变化）
● 压力测试（临界的负载、容量变化）
● 配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）、可靠性测试等。
如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题都已解决，而且所有的软件配置均已更新和审核，可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。