软件测试之软件项目的用户验收测试

1、软件项目的用户验收测试随着当今技术和市场环境的变化，越来越多的企业选择将软件项目外包，同时也有更多成熟的大型软件企业加入到软件项目的承包队伍中。外包的软件项目越来越多，如何对这些外包的项目进行验收测试日益成为企业的一个关键问题。 用户验收测试的总体思路用户验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划，进行软件配置评审、功能测试、性能测试等多方

2、面检测。 用户验收测试可以分为两个大的部分：软件配置审核和可执行程序测试，其大致顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、可执行程序测试。 要注意的是，在开发方将软件提交用户方进行验收测试之前，必须保证开发方本身已经对软件的各方面进行了足够的正式测试（当然，这里的“足够”，本身是很难准确定量的）。 用户在按照合同接收并清点开发方的提交物时（包括以前已经提交的），要查看开发方提供的各种审核报告和测试报告内容是否齐全，再加上平时对开发方工作情况的了解，基本可以初步判断开发方是否已经进行了足够的正式测试。 用户验收测试的每一个相对独立的部分，都应该有目标（本步骤的目的）、启

3、动标准（着手本步骤必须满足的条件）、活动（构成本步骤的具体活动）、完成标准（完成本步骤要满足的条件）和度量（应该收集的产品与过程数据）。在实际验收测试过程中，收集度量数据，不是一件容易的事情。 软件配置审核对于一个外包的软件项目而言，软件承包方通常要提供如下相关的软件配置内容： 可执行程序、源程序、配置脚本、测试程序或脚本。 主要的开发类文档：需求分析说明书、概要设计说明书、详细设计说明书、数据库设计说明书、测试计划、测试报告、程序维护手册、程序员开发手册、用户操作手册、项目总结报告。 主要的管理类文档：项目计划书、质量控制计划、配置管理计划、用户培训计划、质量总结报告、评审报告、会议记录、开

4、发进度月报。 在开发类文档中，容易被忽视的文档有程序维护手册和程序员开发手册。 程序维护手册的主要内容包括：系统说明（包括程序说明）、操作环境、维护过程、源代码清单等，编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。 程序员开发手册的主要内容包括：系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等，实际上就是程序员的培训手册。 不同大小的项目，都必须具备上述的文档内容，只是可以根据实际情况进行重新组织。 对上述的提交物，最好在合同中规定阶段提交的时机，以免发生纠纷。 通常，正式的审核过程分为5个步骤：计划、预备会议（可选）、准备阶段、审核会议和问题追踪。预备会议

5、是对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是最终确定工作产品中包含的错误和缺陷。 审核要达到的基本目标是：根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。 在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。 可执行程序的测试在文档审核、源代码审核、配置

6、脚本审核、测试程序或脚本审核都顺利完成，就可以进行验收测试的最后一个步骤可执行程序的测试，它包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量等五部分。 要注意的是不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。 在真正进行用户验收测试之前一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）： 软件开发已经完成，并全部解决了已知的软件缺陷。 验收测试计划已经过评审并批准，并且置于文档控制之下。 对软件需求说明书的审查已经完成。 对概要设计、详细设计的审查已经完成。 对所有关键模块的代码审查已经完成

7、。 对单元、集成、系统测试计划和报告的审查已经完成。 所有的测试脚本已完成，并至少执行过一次，且通过评审。 使用配置管理工具且代码置于配置控制之下。 软件问题处理流程已经就绪。 已经制定、评审并批准验收测试完成标准。 具体的测试内容通常可以包括：安装（升级）、启动与关机、功能测试（正例、重要算法、边界、时序、反例、错误处理）、性能测试（正常的负载、容量变化）、压力测试（临界的负载、容量变化）、配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）、可靠性测试等。 性能测试和压力测试一般情况下是在一起进行，通常还需要辅助工具的支持。在进行性

8、能测试和压力测试时，测试范围必须限定在那些使用频度高的和时间要求苛刻的软件功能子集中。由于开发方已经事先进行过性能测试和压力测试，因此可以直接使用开发方的辅助工具。也可以通过购买或自己开发来获得辅助工具。具体的测试方法可以参考相关的软件工程书籍。 如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题都已解决，而且所有的软件配置均已更新和审核，可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。软件异常测试地址：北京市海淀区学院路40号大唐电信测试空间楼软件交付最终用户使用之前，需要进行各种类型的测试，其中就包括异常测试。异常测试，是检测系统对异常情况的处理。

9、异常测试覆盖硬件或软件异常时的处理。测试方应通过人为制造错误情况测试系统对错误操作、错误报文的反应，检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束；一旦出现错误情况，系统是否能正常报告，并检查系统的错误提示是否清晰且充分；测试系统是否处理了用户的异常操作，还是造成死机或处理错误。只有通过异常测试的软件产品，才可以保证软件在正式上线后长时间的保持良好的运营状态，给最终用户以信心。异常测试的结果也有助于为我们进一步的系统优化设计积累经验，设计和测试是一个相互反馈的过程。这里我们只针对异常测试案例的设计进行讨论。为了验证软件的健壮性、可靠性，我们需要对软件进行异常测试，设计软件异常测试的测试

10、用例。为了更清晰的分析和解决问题，我们从四个方面入手，他们分别是：业务需求、操作需求、标准需求和经验需求。下面我们就从这四个方面详细阐述如何设计异常测试用例。从业务需求方面：业务需求是开发之源，也是测试之源。测试人员对业务需求的了解是非常非常重要的，针对于异常测试更是如此。进行正常测试可以对软件进行“扫菜单”式的测试，但是进行异常测试就必须要熟悉所测软件的业务流程、相关业务领域知识等信息，只有这样才可以知道系统在什么情况下会发生异常，什么情况下容易发生人为错误。这需要测试人员和开发人员或者系统分析员甚至真正的业务人员一起讨论，根据软件的类型与特点设计测试案例，不能凭空猜想。只有这样设计出的案例

11、才能够真正的测试到，由于关键业务需要或者变化发生了异常，在此时软件的处理能力。这一类的测试案例可以包括：特殊业务流程测试：测试软件不按照正规的流程，而是按照可能的但非正规的业务流程运行，是否会生成错误数据，或者造成原有数据的错误，甚至造成系统的瘫痪；压力测试：压力测试又称强度测试，主要是检查系统某些关键业务在极限情况下运行的能力，测试在这种情况下系统的运行、处理数据的情况，是否会造成系统瘫痪；业务模块的添加、删除测试：根据实际情况，增加或删除业务模块，测试系统的运行状况；删除或修改系统的重要配置文件测试：测试情况发生时系统是否能够正确的提示，指明系统的错误。在进行相应修补后，系统是否能够正常运

12、行；修改系统的重要配置信息测试：在软件的配置界面进行重要信息的修改或删除，测试系统是否有相关限制提示，并测试如果修改错误，系统是否能够进行错误提示，引导用户修改，而不至于系统瘫痪；违规操作：这类测试可以包括，对现有重要业务数据的违规操作、用户越权业务操作等，测试系统是否有相关约束。如果发生类似事件，系统是否有补救措施，而不导致系统的瘫痪。从操作需求方面：用户正确的操作是系统正常运行的前提。所以在测试的时候，一定要进行错误操作来测试软件系统的健壮性。在从操作需求方面设计异常测试的测试用例时，需要从用户或者操作者的每一步的操作中进行提炼，而且这些测试用例一定要可操作性强，输入、输出、操作步骤都应该

13、明确。实际上这部分测试用例也是功能测试用例的一部分，只是他不是正常、按照用户需求说明书的操作而已。这一类的测试案例可以包括：单引号操作：大多数基于SQL的数据库系统在用户存储包含一个英文单引号的信息时会出现问题，所以每一个可以接受文字数字型的条目都要有包含一个或多个单引号的文本案例。当然，这类问题还应该包括英文双引号、等特殊字符。在测试的时候应该注意其之前的提示和错误操作之后的恢复与补救措施等；必填项输入测试：测试每一个功能说明书上指出的屏幕上必须输入数据的字段和屏幕上每一个被说明为必须输入的字段，以保证它强制要求你在字段中输入数据。测试其如果没有输入相关数据的提示和后续操作；特殊字段类型测试

14、：准备每一个功能说明书或界面中规定的特殊数据输入要求（身份证、日期、电话号码、邮编等）的字段的测试案例，输入的数据包括它不应该接受的数据类型，测试软件对错误输入的提示和后续操作；字段长度测试：准备功能说明书或者界面上要求的字段最大长度的测试案例，输入数据应该大于这个最大长度，测试软件对错误输入的提示和后续操作；数字类型的边界测试：如果是数字类型，长度往往不能测试出问题，要准备数字类型的边界值测试案例，测试软件对越界错误输入的提示和后续操作；日期类型测试：日期类型要测试其边界值和日期格式类型的有效性测试。对于日期类型的边界值可能根据数据库不同而不同，比如sqlserver的最小日期是1753年1

15、月1日；而对于有效性最常用的就是闰年的有效日期问题，准备这类测试用例来测试软件对于错误输入的提示和后续操作；web会话测试：对于采用bs结构的软件，应该注意web会话测试。比如：在空白的浏览器中输入比较敏感的页面的URL，软件是否有相应的提示、强调应该先进行登录才能访问该界面。从标准需求方面：在软件界中被广泛使用的质量标准是ISOIEC9126，而其中对于异常测试最相关的质量特性就是可靠性（reliability），它的定义是：在指定条件使用时，软件产品维持规定的性能级别的能力。他下面又有四个子特性：成熟性、容错性、易恢复性、可靠性依从性。下面我们就从这四方面来设计异常测试案例。1.成熟性：软

16、件产品为避免由软件中错误而导致失效的能力2.容错性：在软件失效或者违反规定的接口的情况下，软件产品维持规定的性能级别的能力3.易恢复性：在发生故障的情况下，软件重建规定的性能级别并恢复受直接影响的数据的能力4.可靠性依从性：软件产品依附于同可靠性相关的标准、约定或规定的能力。实际以上四条是我们进行异常测试的目的和依据，我们之前的测试案例都是在验证这四条特性。根据这些标准，我们可以进一步准备异常测试案例，其中包括：数据库服务器死机测试：在测试过程中强行关闭软件的数据库服务器或者用其它方式导致数据库死机，测试被测系统的提示是否准确以及其后的相关补救提示或操作；数据表毁坏测试：非法删除或修改数据库中的表数据或者表，测试被测系统的提示是否准确以及其后的相关补救提示或操作；网络故障测试：在测试中中断网络或者人工增加网络流量，测试被测系统的提示是否准确以及其后的相关补救提示或操作；软件服务器故障测试：在测试过程中，强行重启软件的web服务器或者中间件服务器，测试系统的恢复能力；从经验需求方面：对于测试人员，经验是十分重要的。测试是有规律可循的，对软件测试、软件相关业务与流程熟悉的测试人员，测试肯定会事半功倍。根据以往的经验，异常测试案例的设计，除了上面提及的各个案例，还有一些补充的被广泛采纳的测试案例。这些案例包括以下几类：文件丢失测试：强行删除被测软件的一些文件，测试被