|
|
知识路径： > 信息系统工程技术知识 > 软件与软件工程知识 > 软件测试及主要工具 > 软件测试 >
|
被考次数：1次
被考频率：低频率
总体答错率：36%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：21个
|
|
|
|
|
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求的那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统了，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能是否如同用户所合理期待的那样。
|
|
|
|
验收测试的结果有两种可能：一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
|
|
|
|
|
|
验收测试通常可以分为正式验收和非正式验收，具体选择的策略通常建立在合同需求、组织和公司标准，以及应用领域的基础上。
|
|
|
|
|
|
正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。
|
|
|
|
在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。这种测试形式的优点是：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.可能无法发现软件中由于主观原因造成的缺陷，这是因为只查找了预期要发现的缺陷。
|
|
|
|
|
|
在非正式验收测试中，执行测试过程的限定不像正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不像正式验收测试那样组织有序，而且更为主观。
|
|
|
|
大多数情况下，非正式验收测试是由最终用户组织执行的。这种测试形式的优点是：
|
|
|
|
|
|
|
|
|
|
.与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
|
|
|
|
|
|
|
|
|
|
.最终用户可能沿用系统工作的方式，并可能无法发现缺陷。
|
|
|
|
.最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。
|
|
|
|
.用于验收测试的资源不受项目的控制，并且可能受到压缩。
|
|
|
|
|
|
在真正进行用户验收测试之前，一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）。
|
|
|
|
（1）软件开发已经完成，并全部解决了已知的软件缺陷。
|
|
|
|
（2）验收测试计划已经过评审和批准，并且置于文档控制之下。
|
|
|
|
|
|
|
|
|
|
（6）对单元、集成、系统测试计划和报告的审查已经完成。
|
|
|
|
（7）所有的测试脚本已完成，并至少执行过一次，且通过评审。
|
|
|
|
|
|
|
|
|
|
|
|
（1）软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。
|
|
|
|
（2）编制《验收测试计划》和《项目验收准则》：根据软件需求和验收要求编制测试计划，制定需测试的测试项，制定测试策略及验收通过准则，并制订出经过客户参与评审的计划。
|
|
|
|
（3）测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编制测试用例，并经过评审。
|
|
|
|
（4）测试环境搭建：，建立测试的硬件环境和软件环境等（可在委托客户提供的环境中进行测试）。
|
|
|
|
|
|
（6）测试结果分析：根据验收通过准则分析测试结果，做出验收是否通过的决定，给出测试评价。
|
|
|
|
（7）测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。
|
|
|
|
|
|
|
|
审查是指审查可执行程序、源程序、配置脚本、测试程序或脚本、主要的开发类文档和主要的管理类文档。
|
|
|
|
通常，正式的审核过程分为5个步骤，即计划、预备会议（可选）、准备阶段、审核会议和问题追踪。预备会议是指对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是指最终确定工作产品中包含的错误和缺陷。
|
|
|
|
审核要达到的基本目标是根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。
|
|
|
|
在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面，由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。
|
|
|
|
对软件需求说明书的审查，可以从清晰性、完整性、依从性、一致性、可行性和可管理性等几个方面考虑。对软件设计说明书（详细设计说明书、概要设计说明书）的审查，可以从清晰性、完整性、依从性、一致性、可行性、数据使用性、功能性、接口、可维护性、性能、可靠性、易测性和可追溯性等方面考虑。对测试计划（单元测试计划、集成测试计划、确认测试计划、系统测试计划）的审查，可以从完整性、依从性、一致性、正确性、详细级别／程度、易测性／可行性和可追溯性等方面考虑。对软件编码规范的审查，可以考虑源程序文档化、数据说明、输入输出等方面，评审的目的是为了使程序具有良好的风格，便于阅读。
|
|
|
|
|
|
在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成后，就可以进行验收测试的最后一个步骤——可执行程序的测试了，包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量5个部分。
|
|
|
|
不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。
|
|
|
|
|
|
具体的测试内容通常可以包括安装（升级）、启动与关机、功能测试（正例、重要算法、边界、时序、反例、错误处理）、性能测试（正常的负载、容量变化）、压力测试（临界的负载、容量变化）、配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）及可靠性测试等。
|
|
|
|
如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题也都已解决，而且所有的软件配置均已更新和审核，可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。
|
|
|
