工厂验收测试

工厂验收测试是部署软件之前的最后一个测试操作。工厂验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。工厂验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是工厂验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步——工厂验收测试即可开始。工厂验收测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。

实现软件确认要通过一系列墨盒测试。验收测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。验收测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。

验收测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。

事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。一般包括功能度、安全可靠性、易用性、可扩充性、兼容性、效率、资源占用率、用户文档八个方面。

施验收测试的常用策略有三种，它们分别是：正式验收，非正式验收或Alpha测试，Beta测试。

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

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

这种测试形式的优点是： 要测试的功能和特性都是已知的。 测试的细节是已知的并且可以对其进行评测。 这种测试可以自动执行，支持回归测试。 可以对测试过程进行评测和监测。 可接受性标准是已知的。

缺点包括： 要求大量的资源和计划。 这些测试可能是系统测试的再次实施。 可能无法发现软件中由于主观原因造成的缺陷，这是因为只查找预期要发现的缺陷。

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

这种测试形式的优点是： 要测试的功能和特性都是已知的。 可以对测试过程进行评测和监测。 可接受性标准是已知的。 与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。

缺点包括 要求资源、计划和管理资源。 无法控制所使用的测试用例。 最终用户可能沿用系统工作的方式，并可能无法发现缺陷。 用于验收测试的资源不受项目的控制，并且可能受到压缩。

Beta测试：在以上三种验收测试策略中，Beta测试需要的控制是最少的。在Beta测试中，采用的细节多少、数据和方法完全由各测试员决定。各测试员负责创建自己的环境、选择数据，并决定要研究的功能、特性或任务。各测试员负责确定自己对于系统当前状态的接受标准。Beta测试由最终用户实施，通常开发（或其他非最终用户）组织对其的管理很少或不进行管理。Beta测试是所有验收测试策略中最主观的。

这种测试形式的优点是： 测试由最终用户实施。 大量的潜在测试资源。 提高客户对参与人员的满意程度。 与正式或非正式验收测试相比，可以发现更多由于主观原因造成的缺陷。

缺点包括： 未对所有功能和/或特性进行测试。 测试流程难以评测。 最终用户可能沿用系统工作的方式，并可能没有发现或没有报告缺陷。 最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。 用于验收测试的资源不受项目的控制，并且可能受到压缩。 可接受性标准是未知的。 您需要更多辅助性资源来管理Beta测试员。

1.软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。 2.编制《验收测试计划》和《项目验收准则》：根据软件需求和验收要求编制测试计划，制定需测试的测试项，制定测试策略及验收通过准则，并经过客户参与的计划评审。 3.测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编制测试用例，并经过评审。 4.测试环境搭建：建立测试的硬件环境、软件环境等。（可在委托客户提供的环境中进行测试） 5.测试实施：测试并记录测试结果。 6.测试结果分析：根据验收通过准则分析测试结果，作出验收是否通过及测试评价。 7.测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。

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

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

要注意的是，在开发方将软件提交用户方进行验收测试之前，必须保证开发方本身已经对软件的各方面进行了足够的正式测试（当然，这里的“足够”，本身是很难准确定量的）。用户在按照合同接收并清点开发方的提交物时（包括以前已经提交的），要查看开发方提供的各种审核报告和测试报告内容是否齐全，再加上平时对开发方工作情况的了解，基本可以初步判断开发方是否已经进行了足够的正式测试。用户验收测试的每一个相对独立的部分，都应该有目标（本步骤的目的）、启动标准（着手本步骤必须满足的条件）、活动（构成本步骤的具体活动）、完成标准（完成本步骤要满足的条件）和度量（应该收集的产品与过程数据）。在实际验收测试过程中，收集度量数据，不是一件容易的事情。

对于一个外包的软件项目而言，软件承包方通常要提供如下相关的软件配置内容：可执行程序、源程序、配置脚本、测试程序或脚本。

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

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

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

《程序维护手册》的主要内容包括：系统说明（包括程序说明）、操作环境、维护过程、源代码清单等，编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。

《程序员开发手册》的主要内容包括：系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等，实际上就是程序员的培训手册。

不同大小的项目，都必须具备上述的文档内容，只是可以根据实际情况进行重新组织。

对上述的提交物，最好在合同中规定阶段提交的时机，以免发生纠纷。