免费智能真题库 > 历年试卷 > 信息系统运行管理员 > 2018年下半年 信息系统运行管理员 上午试卷 综合知识
  第69题      
  知识点:   系统用户对验收测试的支持   测试过程   配置脚本   审核   验收测试
  关键词:   测试过程   配置脚本   文档   用户验收测试   源代码   测试   脚本   验收   验收测试        章/节:   对系统测试工作支持       

 
用户验收测试过程中,在文档审核、源代码审核配置脚本审核、测试程序或脚本审核等顺利完成后,即可进行验收测试的最后一个步骤:(69)。
 
 
  A.  单元测试
 
  B.  系统功能测试
 
  C.  系统运行测试
 
  D.  测试报告提供
 
 
 

   知识点讲解    
   · 系统用户对验收测试的支持    · 测试过程    · 配置脚本    · 审核    · 验收测试
 
       系统用户对验收测试的支持
        验收测试是部署软件之前的最后一个测试操作,验收测试为系统准备实际投入使用提供最终的证明。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行系统的既定功能和任务。它不是检验系统某个方面的质量,而是要进行全面的质量检验,最终决定所开发的系统是否合格,因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划,进行软件配置评审、功能测试、性能测试等多方面检测。验收测试由用户评估,当用户认为各个部分都令人满意时,则该系统达到了验收的标准,可以被实际安装部署了。
        用户验收测试可以分为两个大的部分:软件配置审核和系统运行测试。其大致顺序可分为:文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、系统运行测试。
        要注意的是,在系统开发方将所开发的信息系统提交用户方进行验收测试之前,必须保证开发方本身已经对软件的各方面进行了足够的正式测试。用户在按照合同接收并清点开发方的提交物时(包括以前已经提交的),要查看开发方提供的各种审核报告和测试报告内容是否齐全,再加上平时对开发方工作情况的了解,基本可以初步判断开发方是否已经进行了足够的正式测试。
        用户验收测试的每一个相对独立的部分,都应该有目标(本步骤的目的)、启动标准(执行本步骤必须满足的条件)、活动(构成本步骤的具体活动)、完成标准(完成本步骤要满足的条件)和度量(应该收集的产品与过程数据)。在实际验收测试过程中,收集度量数据,不是一件容易的事情。
               软件配置审核
               对于一个信息系统开发项目而言,系统开发方通常要提供如下相关的软件配置内容。
               可执行程序、源程序、配置脚本、测试程序或脚本。
               主要的开发类文档:《需求分析说明书》《概要设计说明书》《详细设计说明书》《数据库设计说明书》《测试计划》《测试报告》《程序维护手册》《程序员开发手册》《用户操作手册》《项目总结报告》。
               主要的管理类文档:《项目计划书》《质量控制计划》《配置管理计划》《用户培训计划》《质量总结报告》《评审报告》《会议记录》《开发进度月报》。
               在开发类文档中,容易被忽视的文档有《程序维护手册》和《程序员开发手册》。
               《程序维护手册》的主要内容包括:系统说明(包括程序说明)、操作环境、维护过程、源代码清单等,编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。
               《程序员开发手册》的主要内容包括:系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等,实际上就是程序员的培训手册。
               对于不同大小的信息系统开发项目,都必须具备上述的文档内容,只是可以根据实际情况进行重新组织。对上述的提交物,最好在合同中规定阶段提交的时机,以免发生纠纷。
               通常,正式的审核过程分为5个步骤:计划、预备会议(可选)、准备阶段、审核会议和问题追踪。预备会议是对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是最终确定工作产品中包含的错误和缺陷。
               审核要达到的基本目标是:根据共同制定的审核表,尽可能地发现被审核内容中存在的问题,并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时,还要注意文档与源代码的一致性。
               在实际的验收测试执行过程中,常常会发现文档审核是最难的工作,一方面由于市场需求等方面的压力使这项工作常常被弱化或推迟,造成持续时间变长,加大文档审核的难度;另一方面,文档审核中不易把握的地方非常多,每个项目都有一些特别的地方,而且也很难找到可用的参考资料。
               系统运行测试
               在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成,就可以进行验收测试的最后一个步骤——系统运行测试,它包括功能、性能等方面的测试,每种测试也都包括目标、启动标准、活动、完成标准和度量等五部分。
               要注意的是不能直接使用开发方提供的可执行程序用于测试,而要按照开发方提供的编译步骤,从源代码重新生成可执行程序。
               在真正进行用户验收测试之前一般应该已经完成了以下工作(也可以根据实际情况有选择地采用或增加)。
               软件开发已经完成,并全部解决了已知的软件缺陷。
               验收测试计划已经过评审并批准,并且置于文档控制之下。
               对软件需求说明书的审查已经完成。
               对概要设计、详细设计的审查已经完成。
               对所有关键模块的代码审查已经完成。
               对单元、集成、系统测试计划和报告的审查已经完成。
               所有的测试脚本已完成,并至少执行过一次,且通过评审。
               使用配置管理工具且代码置于配置控制之下。
               软件问题处理流程已经就绪。
               已经制定、评审并批准验收测试完成标准。
               具体的测试内容通常可以包括:安装(升级)、启动与关机、功能测试(正例、重要算法、边界、时序、反例、错误处理)、性能测试(正常的负载、容量变化)、压力测试(临界的负载、容量变化)、配置测试、平台测试、安全性测试、恢复测试(在出现掉电、硬件故障或切换、网络故障等情况时,系统是否能够正常运行)、可靠性测试等。
               性能测试和压力测试一般情况下是在一起进行,通常还需要辅助工具的支持。在进行性能测试和压力测试时,测试范围必须限定在那些使用频度高的和时间要求苛刻的软件功能子集中。由于开发方已经事先进行过性能测试和压力测试,因此可以直接使用开发方的辅助工具。也可以通过购买或自己开发来获得辅助工具。
               进行系统测试时所采用的测试用例应该以实际应用数据为基础,而不再使用模拟数据,并且还应该设计一些与用户使用步骤和操作相关的测试用例。由于系统测试中采用的方法、标准和技巧在很大程度上依赖于具体的被测试系统,因此应该根据被测系统的实际特点和运行环境,以及用户的特殊需求进行系统测试,以使系统真正满足用户的需求。
               如果执行了所有的测试案例、测试程序或脚本,用户验收测试中发现的所有软件问题都已解决,而且所有的软件配置均已更新和审核,可以反映出软件在用户验收测试中所发生的变化,用户验收测试就完成了。
 
       测试过程
        软件测试过程一般包括:测试需求分析、测试策划、测试设计和实现、测试执行、测试总结(包括评价过程和总结),如下图所示。
        
        软件测试过程
               测试需求分析
               根据被测软件的需求规格说明或设计文档,进行测试需求分析,包括:
               (1)确定需要的测试类型及其测试要求并进行标识(编号),标识应清晰、便于识别。测试类型包括功能测试、性能测试等类型;测试要求包括状态、接口、数据结构、设计约束等要求。确定的测试类型和测试要求均应与要求的测试级别(单元测试、部件测试、配置项测试、系统测试)、测试类型相匹配。
               (2)确定每个测试项的优先级。
               (3)确定每个测试项的测试充分性要求。
               (4)根据被测软件的重要性、测试目标和约束条件,确定每个测试项应覆盖的范围及范围所要求的覆盖程度。
               (5)确定每个测试项测试终止的要求,包括测试过程正常终止的条件(如测试充分性是否达到要求)和导致测试过程异常终止的可能情况。
               (6)确定测试项与软件需求规格说明或设计文档的追踪关系。
               将测试需求分析结果按所确定的文档要求,形成测试需求规格说明或写入测试计划。
               应对测试需求规格说明或测试需求分析结果进行评审,评审内容如下:
               (1)测试级别和测试对象所确定的测试类型及其测试要求是否恰当。
               (2)每个测试项是否进行了标识,并逐条覆盖了测试需求和潜在需求。
               (3)测试类型和测试项是否充分。
               (4)测试项是否包括了终止要求。
               (5)文档是否符合规定的要求。
               测试策划
               根据软件需求规格说明或设计文档等进行测试策划,策划一般包括:
               (1)确定测试策略,如部件或配置项测试策略。
               (2)确定测试需要的技术或方法,如测试数据生成与验证技术、测试数据输入技术、测试结果获取技术。
               (3)确定要受控制的测试工作产品,列出清单。
               (4)确定用于测试的资源要求,包括软硬件设备、环境条件、人员数量和技能等要求。
               (5)进行测试风险分析,如技术风险、人员风险、资源风险和进度风险等。
               (6)确定测试任务的结束条件。
               (7)确定被测软件的评价准则和方法。
               (8)确定测试活动的进度。应根据测试资源和测试项,确定进度。
               应将测试策划结果,按所确定的文档要求形成测试计划。
               测试设计和实现
               应根据测试需求规格说明和测试计划进行测试设计和实现,应完成如下工作:
               (1)按需要分解测试项。将需要测试的测试项进行层次化的分解并进行标识,若有接口测试,还应有高层次的接口图说明所有接口和要测试的接口。
               (2)说明最终分解后的测试项。说明测试用例设计方法的具体应用、测试数据的选择依据等。
               (3)设计测试用例。
               (4)确定测试用例的执行顺序。
               (5)准备和验证所有的测试用数据。针对测试输入要求,设计测试用的数据,如数据类型、输入方法等。
               (6)准备并获取测试资源,如测试环境所必须的软、硬件资源等。
               (7)必要时,编写测试执行需要的程序,如开发部件测试的驱动模块和桩模块以及测试支持软件等。
               (8)建立和校核测试环境,记录校核结果,说明测试环境的偏差。
               应将测试设计与实现的工作结果,按照所确定的文档要求编写测试说明,测试说明一般应包括:
               (1)测试名称和项目标识。
               (2)测试用例的追踪。说明测试所依据的内容来源,并跟踪到相应的测试项的标识(编号)。
               (3)测试用例说明。简要描述测试的对象、目的和所采用的测试方法。
               (4)测试用例的初始化要求,包括硬件配置、软件配置(包括测试的初始条件)、测试配置(如用于测试的模拟系统和测试工具)、参数设置(如测试开始前对断点、指针、控制参数和初始化数据的设置)等的初始化要求。
               (5)测试用例的输入。每个测试用例输入的描述中应包括的内容:
               ①每个测试输入的名称、用途和具体内容(如确定的数值、状态或信号等)及其性质(如有效值、无效值、边界值等)。
               ②测试输入的来源(如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等),以及选择输入所使用的方法(如等价类划分、边界值分析、猜错法、因果图以及功能图等)。
               ③测试输入是真实的还是模拟的。
               ④测试输入的时间顺序或事件顺序。
               (6)测试用例的期望测试结果。期望测试结果应有具体内容(如确定的数值、状态或信号等),不应是不确切的概念或笼统的描述。必要时,应提供中间的期望结果。
               (7)测试用例的测试结果评估准则。评估准则用以判断测试用例执行中产生的中间或最后结果是否正确。评估准则应根据不同情况提供相关信息,如:
               ①实际测试结果所需的精确度。
               ②允许的实际测试结果与期望结果之间差异的上、下限。
               ③时间的最大或最小间隔。
               ④事件数目的最大或最小值。
               ⑤实际测试结果不确定时,重新测试的条件。
               ⑥与产生测试结果有关的出错处理。
               ⑦其他有关准则。
               (8)实施测试用例的执行步骤。编写按照执行顺序排列的一系列相对独立的步骤,执行步骤应包括:
               ①每一步所需的测试操作动作、测试程序输入或设备操作等。
               ②每一步期望的测试结果。
               ③每一步的评估准则。
               ④导致被测程序执行终止伴随的动作或指示信息。
               ⑤需要时,获取和分析中间结果的方法。
               (9)测试用例的前提和约束。在测试用例中还应说明实施测试用例的前提条件和约束条件,如特别限制、参数偏差或异常处理等,并要说明它们对测试用例的影响。
               (10)测试终止条件。说明测试用例的测试正常终止和异常终止的条件。
               (11)确定测试说明与测试计划或测试需求规格说明的追踪关系,给出清晰、明确的追踪表。
               (12)测试说明应经过评审,得到相关人员的认同,测试说明评审内容如下:
               ①测试说明是否完整、正确和规范。
               ②测试设计是否完整和合理。
               ③测试用例是否可行和充分。
               测试执行
               应按照测试计划和测试说明的内容和要求执行测试,主要完成下列工作:
               如实填写测试记录,当结果有量值要求时,应准确记录实际的量值。
               (1)测试记录应受到严格管理,并规范格式,至少包括测试用例标识、测试结果和发现的缺陷。
               (2)应根据每个测试用例的期望测试结果、实际测试结果和评估准则,判定测试用例是否通过。
               (3)当测试用例不通过时,应根据不同的缺陷类型,采取相应的措施:
               ①对测试工作中的缺陷,如测试说明的缺陷、测试数据的缺陷、执行测试步骤时的缺陷、测试环境中的缺陷等,记录到相应的表格中,并实施相应的变更。
               ②对被测软件的缺陷应记录到软件问题报告中。
               ③软件问题报告的格式应规范。
               (4)当所有的测试用例都执行完毕后,实验室应根据测试的充分性要求和有关记录,分析测试工作是否充分,是否需要进行补充测试:
               ①当测试过程正常终止时,如果发现测试工作不足,或测试未达到预期要求时,应进行补充测试。
               ②当测试过程异常终止时,应记录导致终止的条件、未完成的测试或未被修正的错误。
               测试总结
               应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录、测试问题及变更报告和软件问题报告等,对测试工作和被测软件进行分析和评价,主要完成下列工作:
               (1)对测试工作进行分析和评价,分析和评价内容应包括:
               ①总结测试需求规格说明、测试计划和测试说明的变化情况及其原因。
               ②在测试异常终止时,说明未能被测试活动充分覆盖的范围及其理由。
               ③确定无法解决的软件测试事件并说明不能解决的理由。
               (2)对被测软件进行分析和评价,分析和评价内容应包括:
               ①总结测试中所反映的被测软件与软件需求(或软件设计)之间的差异。
               ②可能时,根据差异评价被测软件的设计与实现,提出改进的建议。
               ③当进行配置项测试或系统测试时,当需要时,测试总结中应对配置项或系统的性能做出评估,指明偏差、缺陷和约束条件等对于配置项或系统运行的影响。
               (3)分析测评项目中的数据和文档,以供以后的测试使用。数据如:缺陷数据(包括缺陷描述、类型、严重性等)、用例数据、管理数据(如生产率、工作量、进度等);文档如:好的用例设计、好的需求规格说明等。
               (4)应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录和软件问题报告等有关文档,对测试结果和问题进行分类和总结,按所确定的文档要求编写测试报告。测试报告除了应包括对测试结果的分析,还应包括对被测软件的评价和建议。
               测试总结评审应在测试报告编制工作完成后进行,以确定是否达到测试目的,给出评审结论。评审的具体内容和要求包括:
               (1)审查测试文档与记录内容的完整性、正确性和规范性。
               (2)审查测试活动的独立性和有效性。
               (3)审查测试环境是否符合测试要求。
               (4)审查软件测试报告与软件测试原始记录和问题报告的一致性。
               (5)审查实际测试过程与测试计划和测试说明的一致性。
               (6)审查测试说明评审的有效性,如是否评审了测试项选择的完整性和合理性、测试用例的可行性和充分性。
               (7)审查测试结果的真实性和正确性。
 
       配置脚本
        为Vuser或Vuser组选择了脚本后,可以编辑脚本或查看所选脚本的详细信息。
 
       审核
        依据知识库内容加入的审核标准,由资深技术人员审核内容的正确性和完整性,避免与原有的知识库内容重复或冲突,给出审核意见后提交批准加入知识库中。
 
       验收测试
        验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求的那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统了,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能是否如同用户所合理期待的那样。
        验收测试的结果有两种可能:一种是功能和性能指标满足软件需求说明的要求,用户可以接受;另一种是软件不满足软件需求说明的要求,用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正,因此必须与用户协商,寻求一个妥善解决问题的方法。
               验收测试的常用策略
               验收测试通常可以分为正式验收和非正式验收,具体选择的策略通常建立在合同需求、组织和公司标准,以及应用领域的基础上。
                      正式验收测试
                      正式验收测试是一项管理严格的过程,它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向,这一点很重要。在很多组织中,正式验收测试是完全自动执行的。
                      在某些组织中,开发组织(或其独立的测试小组)与最终用户组织的代表一起执行验收测试。在其他组织中,验收测试则完全由最终用户组织执行,或者由最终用户组织选择人员组成一个客观公正的小组来执行。这种测试形式的优点是:
                      .要测试的功能和特性都是已知的。
                      .测试的细节是已知的,并且可以对其进行评测。
                      .这种测试可以自动执行,支持回归测试。
                      .可以对测试过程进行评测和监测。
                      .可接受性标准是已知的。
                      缺点包括:
                      .要求大量的资源和计划。
                      .这些测试可能是系统测试的再次实施。
                      .可能无法发现软件中由于主观原因造成的缺陷,这是因为只查找了预期要发现的缺陷。
                      非正式验收测试
                      在非正式验收测试中,执行测试过程的限定不像正式验收测试中那样严格。在此测试中,确定并记录要研究的功能和业务任务,但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不像正式验收测试那样组织有序,而且更为主观。
                      大多数情况下,非正式验收测试是由最终用户组织执行的。这种测试形式的优点是:
                      .要测试的功能和特性都是已知的。
                      .可以对测试过程进行评测和监测。
                      .可接受性标准是已知的。
                      .与正式验收测试相比,可以发现更多由于主观原因造成的缺陷。
                      缺点包括:
                      .要求资源、计划和管理资源。
                      .无法控制所使用的测试用例。
                      .最终用户可能沿用系统工作的方式,并可能无法发现缺陷。
                      .最终用户可能专注于比较新系统与遗留系统,而不是专注于查找缺陷。
                      .用于验收测试的资源不受项目的控制,并且可能受到压缩。
               验收测试的条件
               在真正进行用户验收测试之前,一般应该已经完成了以下工作(也可以根据实际情况有选择地采用或增加)。
               (1)软件开发已经完成,并全部解决了已知的软件缺陷。
               (2)验收测试计划已经过评审和批准,并且置于文档控制之下。
               (3)对软件需求说明书的审查已经完成。
               (4)对概要设计及详细设计的审查已经完成。
               (5)对所有关键模块的代码审查已经完成。
               (6)对单元、集成、系统测试计划和报告的审查已经完成。
               (7)所有的测试脚本已完成,并至少执行过一次,且通过评审。
               (8)使用配置管理工具且代码置于配置控制之下。
               (9)软件问题处理流程已经就绪。
               (10)已经制定、评审并批准验收测试完成标准。
               验收测试的过程
               (1)软件需求分析:了解软件功能和性能要求、软硬件环境要求等,并特别要了解软件的质量要求和验收要求。
               (2)编制《验收测试计划》和《项目验收准则》:根据软件需求和验收要求编制测试计划,制定需测试的测试项,制定测试策略及验收通过准则,并制订出经过客户参与评审的计划。
               (3)测试设计和测试用例设计:根据《验收测试计划》和《项目验收准则》编制测试用例,并经过评审。
               (4)测试环境搭建:,建立测试的硬件环境和软件环境等(可在委托客户提供的环境中进行测试)。
               (5)测试实施:测试并记录测试结果。
               (6)测试结果分析:根据验收通过准则分析测试结果,做出验收是否通过的决定,给出测试评价。
               (7)测试报告:根据测试结果编制缺陷报告和验收测试报告,并提交给客户。
               软件配置审核
               软件配置审核包括审查和审核。
               审查是指审查可执行程序、源程序、配置脚本、测试程序或脚本、主要的开发类文档和主要的管理类文档。
               通常,正式的审核过程分为5个步骤,即计划、预备会议(可选)、准备阶段、审核会议和问题追踪。预备会议是指对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是指最终确定工作产品中包含的错误和缺陷。
               审核要达到的基本目标是根据共同制定的审核表,尽可能地发现被审核内容中存在的问题,并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时,还要注意文档与源代码的一致性。
               在实际的验收测试执行过程中,常常会发现文档审核是最难的工作,一方面,由于市场需求等方面的压力使这项工作常常被弱化或推迟,造成持续时间变长,加大文档审核的难度;另一方面,文档审核中不易把握的地方非常多,每个项目都有一些特别的地方,而且也很难找到可用的参考资料。
               对软件需求说明书的审查,可以从清晰性、完整性、依从性、一致性、可行性和可管理性等几个方面考虑。对软件设计说明书(详细设计说明书、概要设计说明书)的审查,可以从清晰性、完整性、依从性、一致性、可行性、数据使用性、功能性、接口、可维护性、性能、可靠性、易测性和可追溯性等方面考虑。对测试计划(单元测试计划、集成测试计划、确认测试计划、系统测试计划)的审查,可以从完整性、依从性、一致性、正确性、详细级别/程度、易测性/可行性和可追溯性等方面考虑。对软件编码规范的审查,可以考虑源程序文档化、数据说明、输入输出等方面,评审的目的是为了使程序具有良好的风格,便于阅读。
               可执行程序的测试
               在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成后,就可以进行验收测试的最后一个步骤——可执行程序的测试了,包括功能、性能等方面的测试,每种测试也都包括目标、启动标准、活动、完成标准和度量5个部分。
               不能直接使用开发方提供的可执行程序用于测试,而要按照开发方提供的编译步骤,从源代码重新生成可执行程序。
               验收测试的内容
               具体的测试内容通常可以包括安装(升级)、启动与关机、功能测试(正例、重要算法、边界、时序、反例、错误处理)、性能测试(正常的负载、容量变化)、压力测试(临界的负载、容量变化)、配置测试、平台测试、安全性测试、恢复测试(在出现掉电、硬件故障或切换、网络故障等情况时,系统是否能够正常运行)及可靠性测试等。
               如果执行了所有的测试案例、测试程序或脚本,用户验收测试中发现的所有软件问题也都已解决,而且所有的软件配置均已更新和审核,可以反映出软件在用户验收测试中所发生的变化,用户验收测试就完成了。
   题号导航      2018年下半年 信息系统运行管理员 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第69题    在手机中做本题