|
|
知识路径： > 信息系统开发的用户支持 > 对系统测试工作支持 > 系统用户对系统测试的支持 > 系统用户对系统测试的支持 >
|
被考次数：1次
被考频率：低频率
总体答错率：19%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：2个
|
|
|
|
|
验收测试是部署软件之前的最后一个测试操作，验收测试为系统准备实际投入使用提供最终的证明。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行系统的既定功能和任务。它不是检验系统某个方面的质量，而是要进行全面的质量检验，最终决定所开发的系统是否合格，因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划，进行软件配置评审、功能测试、性能测试等多方面检测。验收测试由用户评估，当用户认为各个部分都令人满意时，则该系统达到了验收的标准，可以被实际安装部署了。
|
|
|
|
用户验收测试可以分为两个大的部分：软件配置审核和系统运行测试。其大致顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、系统运行测试。
|
|
|
|
要注意的是，在系统开发方将所开发的信息系统提交用户方进行验收测试之前，必须保证开发方本身已经对软件的各方面进行了足够的正式测试。用户在按照合同接收并清点开发方的提交物时（包括以前已经提交的），要查看开发方提供的各种审核报告和测试报告内容是否齐全，再加上平时对开发方工作情况的了解，基本可以初步判断开发方是否已经进行了足够的正式测试。
|
|
|
|
用户验收测试的每一个相对独立的部分，都应该有目标（本步骤的目的）、启动标准（执行本步骤必须满足的条件）、活动（构成本步骤的具体活动）、完成标准（完成本步骤要满足的条件）和度量（应该收集的产品与过程数据）。在实际验收测试过程中，收集度量数据，不是一件容易的事情。
|
|
|
|
|
|
对于一个信息系统开发项目而言，系统开发方通常要提供如下相关的软件配置内容。
|
|
|
|
|
|
主要的开发类文档：《需求分析说明书》《概要设计说明书》《详细设计说明书》《数据库设计说明书》《测试计划》《测试报告》《程序维护手册》《程序员开发手册》《用户操作手册》《项目总结报告》。
|
|
|
|
主要的管理类文档：《项目计划书》《质量控制计划》《配置管理计划》《用户培训计划》《质量总结报告》《评审报告》《会议记录》《开发进度月报》。
|
|
|
|
在开发类文档中，容易被忽视的文档有《程序维护手册》和《程序员开发手册》。
|
|
|
|
《程序维护手册》的主要内容包括：系统说明（包括程序说明）、操作环境、维护过程、源代码清单等，编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。
|
|
|
|
《程序员开发手册》的主要内容包括：系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等，实际上就是程序员的培训手册。
|
|
|
|
对于不同大小的信息系统开发项目，都必须具备上述的文档内容，只是可以根据实际情况进行重新组织。对上述的提交物，最好在合同中规定阶段提交的时机，以免发生纠纷。
|
|
|
|
通常，正式的审核过程分为5个步骤：计划、预备会议（可选）、准备阶段、审核会议和问题追踪。预备会议是对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是最终确定工作产品中包含的错误和缺陷。
|
|
|
|
审核要达到的基本目标是：根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。
|
|
|
|
在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。
|
|
|
|
|
|
在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成，就可以进行验收测试的最后一个步骤——系统运行测试，它包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量等五部分。
|
|
|
|
要注意的是不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。
|
|
|
|
在真正进行用户验收测试之前一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）。
|
|
|
|
|
|
验收测试计划已经过评审并批准，并且置于文档控制之下。
|
|
|
|
|
|
|
|
|
|
|
|
所有的测试脚本已完成，并至少执行过一次，且通过评审。
|
|
|
|
|
|
|
|
|
|
具体的测试内容通常可以包括：安装（升级）、启动与关机、功能测试（正例、重要算法、边界、时序、反例、错误处理）、性能测试（正常的负载、容量变化）、压力测试（临界的负载、容量变化）、配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）、可靠性测试等。
|
|
|
|
性能测试和压力测试一般情况下是在一起进行，通常还需要辅助工具的支持。在进行性能测试和压力测试时，测试范围必须限定在那些使用频度高的和时间要求苛刻的软件功能子集中。由于开发方已经事先进行过性能测试和压力测试，因此可以直接使用开发方的辅助工具。也可以通过购买或自己开发来获得辅助工具。
|
|
|
|
进行系统测试时所采用的测试用例应该以实际应用数据为基础，而不再使用模拟数据，并且还应该设计一些与用户使用步骤和操作相关的测试用例。由于系统测试中采用的方法、标准和技巧在很大程度上依赖于具体的被测试系统，因此应该根据被测系统的实际特点和运行环境，以及用户的特殊需求进行系统测试，以使系统真正满足用户的需求。
|
|
|
|
如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题都已解决，而且所有的软件配置均已更新和审核，可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。
|
|
|
