验收测试

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