qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

用户验收测试介绍

 验收测试的主要内容
  验收测试过程
  验收测试的常用策略
  验收测试报告
  用户验收测试实例

  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个步骤:

  计划

  预备会议(可选):对审核内容进行介绍并讨论

  准备阶段:各责任人事先审核并记录发现的问题

  审核会议:最终确定工作产品中包含的错误和缺陷

  问题追踪

  审核要达到的基本目标是:

  根据共同制定的审核表,尽可能地发现被审核内容中存在的问题,并最终得到解决。

  在根据相应的审核表进行文档审核和源代码审核时,还要注意文档与源代码的一致性。

  在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成后,就可以进行验收测试的最后一个步骤—可执行程序的测试。

  可执行程序的测试包括功能、性能等方面的测试,每种测试也都包括目标、启动标准、活动、完成标准和度量等五部分。

  要注意的是不能直接使用开发方提供的可执行程序用于测试,而要按照开发方提供的编译步骤,从源代码重新生成可执行程序。

  在真正进行用户验收测试之前一般应该已经完成了以下工作(也可以根据实际情况有选择地采用或增加):

  软件开发已经完成,并全部解决了已知的软件缺陷。

  验收测试计划已经过评审并批准,并且置于文档控制之下。

  对软件需求说明书的审查已经完成。

  对概要设计、详细设计的审查已经完成。

  对所有关键模块的代码审查已经完成。

  对单元、集成、系统测试计划和报告的审查已经完成。

  所有的测试脚本已完成,并至少执行过一次,且通过评审。

  使用配置管理工具且代码置于配置控制之下。

  软件问题处理流程已经就绪。

  已经制定、评审并批准验收测试完成标准。

  具体的测试内容通常可以包括:

  ● 安装(升级)

  ● 启动与关机

  ● 功能测试(正例、重要算法、边界、时序、反例、错误处理)

  ● 性能测试(正常的负载、容量变化)

  ● 压力测试(临界的负载、容量变化)

  ● 配置测试、平台测试、安全性测试、恢复测试(在出现掉电、硬件故障或切换、网络故障等情况时,系统是否能够正常运行)、可靠性测试等。

  如果执行了所有的测试案例、测试程序或脚本,用户验收测试中发现的所有软件问题都已解决,而且所有的软件配置均已更新和审核,可以反映出软件在用户验收测试中所发生的变化,用户验收测试就完成了。


posted on 2013-06-27 10:57 顺其自然EVO 阅读(793) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年6月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜