（4）原有测试和审核结果凡可用的就利用，不必重作该项测试或审核。同时可根据业主单位的要求临时增加一些测试和审核内容；
（5）测试组在完成验收测试的同时，完成功能配置审核，即验证软件功能和接口与“合同”的一致性；
（6）配置审核组完成物理配置审核，检查程序和文档的一致性、文档和文档的一致性、交付的产品与“合同”要求的一致性及符合有关标准的情况。
7.3.2 验收测试和配置审核步骤
（1）制订验收测试计划、配置审核计划，作好验收测试、配置审核准备；
（2）验收委员会审定测试计划、配置审核计划和测试准备、配置审核准备情况；
（3）进行验收测试、配置审核，建立完整的测试、配置审核记录；
（4）编写测试报告、配置审核报告；
（5）验收委员会评审。
7.3.3 验收测试和配置审核内容
（1）检查“合同”或“验收标准”要求的所有功能；
（2）检查“合同”或“验收标准”要求的所有质量特性；
（3）检查开发各个阶段的文档、评审结论是否齐全规范；
（4）验证功能和接口与需求规格说明的一致性；检查程序和文档的一致性、文档和文档的一致性、交付的产品与“合同”或“验收标准”要求的一致性及符合有关标准的情况；
（5）由双方商定所进行的一些特殊测试和配置审核。
7.4 配置审核
7.4.1 审查
承建单位应当在验收前提供相应软件配置内容，监理单位应对其进行审查，审查的内容主要包括以下几个部分。
（1）可执行程序、源程序、配置脚本、测试程序或脚本。
（2）主要的开发类文档：《需求说明书》、《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》、《测试计划》、《测试报告》、《程序维护手册》、《程序员开发手册》、《用户操作手册》、《项目总结报告》。
（3）主要的管理类文档：《项目计划书》、《质量控制计划》、《配置管理计划》、《用户培训计划》、《质量总结报告》、《评审报告》、《会议记录》、《开发进度月报》。
在开发类文档中，容易被忽视的文档有《程序维护手册》和《程序员开发手册》。
《程序维护手册》的主要内容包括：系统说明（包括程序说明）、操作环境、维护过程、源代码清单等，编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。
《程序员开发手册》的主要内容包括：系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等，实际上就是程序员的培训手册。
不同大小的项目，都必须具备上述的文档内容，只是可以根据实际情况进行重新组织。
7.4.2 审核
通常，正式的审核过程分为5个步骤：计划、预备会议（可选）、准备阶段、审核会议和问题追踪。预备会议是对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是最终确定工作产品中包含的错误和缺陷。
审核要达到的基本目标是：根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。
在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。
7.5 验收测试
在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成，就可以进行验收测试的最后一个步骤——可执行程序的测试，它包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量等五部分。
7.5.1 测试的前提条件
在真正进行用户验收测试之前一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）：
（1）软件开发已经完成，并全部解决了已知的软件缺陷。
（2）验收测试计划已经过评审并批准，并且置于文档控制之下。
（3）对软件需求说明书的审查已经完成。
（4）对概要设计、详细设计的审查已经完成。
（5）对所有关键模块的代码审查已经完成。
（6）对单元、集成、系统测试计划和报告的审查已经完成。
（7）所有的测试脚本已完成，并至少执行过一次，且通过评审。
（8）使用配置管理工具且代码置于配置控制之下。
（9）软件问题处理流程已经就绪。
<<上一页
1
2
3
下一页>>
