欢迎您访问山东道普测评技术有限公司!
信息化百科
  • 没有分类目录
信息化百科

软件验收测试

发布时间:08-07-2014    来源:山东省道普测评技术有限公司    

验收测试是部署软件之前的最后一个测试操作。在软件产品完成了单元测试、集成测试和系统测试之后,产品发布之前所进行的软件测试活动它是技术测试的最后一个阶段,也称为交付测试。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。

验收测试,系统开发生命周期方法论的一个阶段,这时相关的用户和独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

1常用策略

实施验收测试的常用策略有三种,它们分别是:

• 正式验收

• 非正式验收或 Alpha 测试

• Beta 测试

您选择的策略通常建立在合同需求、组织和公司标准以及应用领域的基础上。

正式测试

正式验收测试是一项管理严格的过程,它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向,这一点很重要。在很多组织中,正式验收测试是完全自动执行的。

对于系统测试,活动和工件是一样的。在某些组织中,开发组织(或其独立的测试小组)与最终用户组织的代表一起执行验收测试。在其他组织中,验收测试则完全由最终用户组织执行,或者由最终用户组织选择人员组成一个客观公正的小组来执行。

这种测试形式的优点是

• 要测试的功能和特性都是已知的。

• 测试的细节是已知的并且可以对其进行评测。

• 这种测试可以自动执行,支持回归测试。

• 可以对测试过程进行评测和监测。

• 可接受性标准是已知的。

缺点包括

• 要求大量的资源和计划。

• 这些测试可能是系统测试的再次实施。

• 可能无法发现软件中由于主观原因造成的缺陷,这是因为您只查找预期要发现的缺陷。

非正式测试

在非正式验收测试中,执行测试过程的限定不象正式验收测试中那样严格。在此测试中,确定并记录要研究的功能和业务任务,但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不象正式验收测试那样组织有序,而且更为主观。

大多数情况下,非正式验收测试是由最终用户组织执行的。

这种测试形式的优点是

• 要测试的功能和特性都是已知的。

• 可以对测试过程进行评测和监测。

• 可接受性标准是已知的。

• 与正式验收测试相比,可以发现更多由于主观原因造成的缺陷。

缺点包括

• 要求资源、计划和管理资源。

• 无法控制所使用的测试用例。

• 最终用户可能沿用系统工作的方式,并可能无法发现缺陷。

• 最终用户可能专注于比较新系统与遗留系统,而不是专注于查找缺陷。

• 用于验收测试的资源不受项目的控制,并且可能受到压缩。

Beta 测试

在以上两种验收测试策略中,Beta 测试需要的控制是最少的。在 Beta 测试中,采用的细节多少、数据和方法完全由各测试员决定。各测试员负责创建自己的环境、选择数据,并决定要研究的功能、特性或任务。各测试员负责确定自己对于系统当前状态的接受标准。

Beta 测试由最终用户实施,通常开发(或其他非最终用户)组织对其的管理很少或不进行管理。Beta 测试是所有验收测试策略中最主观的。

这种测试形式的优点是

• 测试由最终用户实施。

• 大量的潜在测试资源。

• 提高客户对参与人员的满意程度。

• 与正式或非正式验收测试相比,可以发现更多由于主观原因造成的缺陷。

缺点包括

• 未对所有功能和/或特性进行测试。

• 测试流程难以评测。

• 最终用户可能沿用系统工作的方式,并可能没有发现或没有报告缺陷。

• 最终用户可能专注于比较新系统与遗留系统,而不是专注于查找缺陷。

• 用于验收测试的资源不受项目的控制,并且可能受到压缩。

• 可接受性标准是未知的。

• 您需要更多辅助性资源来管理 Beta 测试员。

2、总体思路

用 户验收测试是软件开发结束后,用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求,以及用户能否 接受的问题。由于它不只是检验软件某个方面的质量,而是要进行全面的质量检验,并且要决定软件是否合格,因此验收测试是一项严格的正式测试活动。需要根据 事先制订的计划,进行软件配置评审、功能测试、性能测试等多方面检测。

用户验收测试可以分为两个大的部分:软件配置审核和可执行程序测试,其大致顺序可分为:文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、可执行程序测试。

要注意的是,在开发方将软件提交用户方进行验收测试之前,必须保证开发方本身已经对软件的各方面进行了足够的正式测试(当然,这里的“足够”,本身是很难准确定量的)。

用户在按照合同接收并清点开发方的提交物时(包括以前已经提交的),要查看开发方提供的各种审核报告和测试报告内容是否齐全,再加上平时对开发方工作情况的了解,基本可以初步判断开发方是否已经进行了足够的正式测试。

用户验收测试的每一个相对独立的部分,都应该有目标(本步骤的目的)、启动标准(着手本步骤必须满足的条件)、活动 (构成本步骤的具体活动)、完成标准(完成本步骤要满足的条件)和度量(应该收集的产品与过程数据)。在实际验收测试过程中,收集度量数据,不是一件容易 的事情。

配置审核

对于一个外包的软件项目而言,软件承包方通常要提供如下相关的软件配置内容:

●可执行程序、源程序、配置脚本、测试程序或脚本。

●主要的开发类文档:《需求分析说明书》、《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》、《测试计划》、《测试报告》、《程序维护手册》、《程序员开发手册》、《用户操作手册》、《项目总结报告》。

●主要的管理类文档:《项目计划书》、《质量控制计划》、《配置管理计划》、《用户培训计划》、《质量总结报告》、《评审报告》、《会议记录》、《开发进度月报》。

在开发类文档中,容易被忽视的文档有《程序维护手册》和《程序员开发手册》。

相关文章

信息化相关文章