免费智能真题库 > 历年试卷 > 信息系统运行管理员 > 2020年下半年 信息系统运行管理员 上午试卷 综合知识
  第69题      
  知识点：   系统测试阶段的目标和任务   测试过程   测试阶段   单元测试   集成测试   验收测试
  章/节：   对系统测试工作支持       

 
按照测试阶段划分，测试过程包含单元测试、集成测试、(69)和验收测试。
 
 
  A.  黑盒测试
 
  B.  系统测试
 
  C.  性能测试
 
  D.  功能测试
 
 
 

 
  第69题    2019年下半年  
   100%
(69)的目的是找出模块之间接口规约中不够完全或错误的地方。
 
   知识点讲解    
   · 系统测试阶段的目标和任务    · 测试过程    · 测试阶段    · 单元测试    · 集成测试    · 验收测试
 
       系统测试阶段的目标和任务
        系统测试是信息系统开发周期中一个十分重要的阶段，它是系统质量与可靠性的保证，是对整个信息系统开发过程的最终审查。尽管在系统开发周期的各个阶段均已采取了严格的技术审查，希望尽早发现问题予以修正，但仍然难免遗留下差错，如果在投入运行前的系统测试阶段被发现并纠正，问题迟早会在运行中暴露出来，而到那时再进行纠正错误将会付出更大的代价，甚至会造成严重的后果。
        在很多组织中，软件测试占软件开发费用的30%到50%。但大多数人仍然认为软件在交付之前没有进行充分的测试。这一矛盾源于两个明显的事实。第一，测试软件十分困难。给定程序具有无数的不同行为方式。第二，测试通常是在没有明确的方法，不采用必需的自动化手段和工具支持的情况下进行的。由于软件的复杂性，无法实现完全测试，但采用周密的方法和最新技术水平的工具可以明显提高软件测试的生产率和有效性。
        对于失败将导致人员伤亡这类“安全至上”的系统（如空中交通管制系统、导弹制导系统，或医用输送系统）来说，高质量的软件是系统成功的要素。而对于典型的MIS系统，上述情况不是非常明显，但是消除缺陷造成的影响将需要相当昂贵的开支。在软件生命周期的早期启动的执行良好的测试，将明显降低完成和维护软件的开支。它还可以大大降低与部署质量低劣的软件相关的责任或风险，如用户的生产率低下、数据输入和计算错误，以及令人无法接受的功能行为。现在，许多MIS系统是“任务至上”的，也就是说，当出现失败时，公司将无法正常运转并导致大量损失。例如：银行或运输公司。测试任务至上的系统时，必须使用安全至上的系统所采用的类似严格方法。
        系统测试的对象应该是整个软件，包括需求分析、概要设计、详细设计以及程序设计各个阶段的开发文档，如需求规格说明、总体设计说明、详细设计说明、源程序代码等。系统测试的目的和任务就是尽可能地发现软件中的错误，包括功能错误、系统错误、过程错误、数据错误、程序编码错误等。
        在信息系统测试周期的各个阶段中，通常需要对不同类型的目标应用测试。这些阶段是从测试小的构件（单元测试）到测试整个系统（系统测试）不断向前发展的。
        （1）单元测试。单元测试通常在早期实施，侧重于核实软件的最小可测试元素，一般指程序中的一个模块或一个子程序。单元测试的目的是核实该模块是否已覆盖了逻辑模型中控制流和数据流，以及模块是否可以按照预期工作。测试人员在模块的开发期间执行单元测试。
        （2）集成测试。执行集成测试是为了确保当多个模块集成起来执行测试用例时，这些模块能够正常运行。测试对象是系统中的由多个模块组成的一个包或一组包。集成测试的目的是找出模块之间的接口规约中不够完全或错误的地方。
        （3）系统测试。当将软件作为整体运行或实施明确定义的软件行为子集时，即可进行系统测试。这种情况下的目标是整个待测试的软件系统。
        （4）验收测试。验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以供最终用户用于执行软件的既定功能和任务。
        系统测试的主要活动包括：第一，成立专门的测试小组，测试人员应该避免由原来的软件开发人员担任，必要时应该包括系统最终用户；第二，设计测试方案，不仅要包括确定的输入数据，还要包括从系统功能出发预期的测试结果；第三，设计测试用例，测试用例是指为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求，其中不仅要包括合理、有效的输入数据，还要包括无效的或不合理的数据；第四，进行具体系统测试工作，根据测试方案采用各种测试方法进行测试活动；第五，保留测试文档，并作为软件文档的重要组成部分，以便于进行重复测试和追加测试。
 
       测试过程
        软件测试过程一般包括：测试需求分析、测试策划、测试设计和实现、测试执行、测试总结（包括评价过程和总结），如下图所示。
        
        软件测试过程
               测试需求分析
               根据被测软件的需求规格说明或设计文档，进行测试需求分析，包括：
               （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）审查测试结果的真实性和正确性。
 
       测试阶段
        . 可靠性测试（含于集成测试、系统测试）；
        . 排错；
        . 可靠性建模；
        . 可靠性评价；
        . 调整可靠性活动计划；
        . 收集可靠性数据；
        . 明确后续阶段的可靠性活动的详细计划；
        . 编制可靠性文档。
 
       单元测试
        单元测试是通过对每个最小的软件模块进行测试，对源代码的每一个程序单元实行测试，检查各个程序模块是否正确地实现了规定的功能，确保其能正常工作。
        单元测试由开发人员执行，一般由模块单元开发者设计测试用例并修改缺陷。单元测试具有如下三种行为：
        （1）单元测试是一种验证行为。验证程序中的每项功能的正确性为代码的重构提供了保障。
        （2）单元测试是一种设计行为。软件设计阶段考虑如何实现软件的功能、性能和用户界面等，而不考虑实现的代码。单元测试关注于软件的具体功能实现是否符合需求设计，而不仅仅定位于代码的实现。
        （3）单元测试是一种文档的行为。单元测试是函数或类等软件模块如何设计、实现和使用的最佳文档。
               单元测试的特性
               单元测试具有如下特性：
               （1）单入测试是覆盖代码区间的最小单元。
               （2）单元测试支持组包测试。
               （3）单元测试的执行率为100%。
               （4）单元测试确定变动后的代码对原代码的功能未做修改。
               （5）单元测试提升了软件系统整体的可信赖度。
               （6）单元测试包含对可能出现问题的代码进行排查。
               （7）单元测试支持开发人员先测试后编码的行为。
               （8）单元测试支持变化，任何变化导致的失败情况均会被反映出来。
               （9）单元测试准确地反映了代码设计，便于后期维护。
               单元测试的认识误区
               （1）单元测试是全部规范。单元测试本质上是种特定的测试方式，是系统的实现方法规范的补充，而不是整个规范。
               （2）单元测试浪费时间。单元测试不会浪费太多的时间，反而会节省项目时间。
               （3）单元测试只需使用测试工具就可完成。单元测试工具生成的测试用例往往无法对被测试的程序进行有效覆盖，必须进行人工检查。
               （4）单元测试是针对代码进行的测试。单元测试依据详细设计报告设计测试用例，不仅仅只是对代码的测试。
               单元测试的原则
               单元测试需要遵守如下原则。
               （1）单元测试遵循《软件单元测试计划》和《软件单元测试说明》文档，根据详细设计编写单元测试用例，而不能根据代码编写单元测试用例。
               （2）单元测试执行前先检查单元测试入口条件是否全部满足。
               （3）单元测试必须满足一定的覆盖率，重要的接口函数必须做单元测试。
               （4）单元测试在修改代码后修改测试用例，将全部单元测试用例进行回归测试。
               （5）单元测试必须满足预定的出口条件才能结束。
               （6）在单元测试完成后，记录《单元测试报告》，分析问题的种类和原因。
               （7）单元测试始终在配置管理控制下进行，软件问题的修改必须符合变动规程的要求。
               （8）单元测试文档、测试用例、测试记录和被测程序等齐全，符合规范。
               单元测试的主要任务
               单元测试主要针对程序模块进行测试，主要有5个任务：模块接口、局部数据结构、执行路径、出错处理和边界条件。
                      模块接口测试
                      通过对被测模块的数据流进行测试，检查进出模块的数据是否正确。因此，必须对模块接口，包括参数表、调用子模块的参数、全局变量、文件I/O操作进行测试。具体涉及以下内容：
                      .模块接受输入的实际参数个数与模块的形式参数个数是否一致。
                      .输入的实际参数与模块的形式参数的类型是否匹配。
                      .输入的实际参数与模块的形式参数所使用的单位是否一致。
                      .调用其他模块时，所传送的实际参数个数与被调用模块的形式参数的个数是否相同。
                      .调用其他模块时，所传送的实际参数与被调用模块的形式参数的类型是否匹配。
                      .调用其他模块时，所传送的实际参数与被调用模块的形式参数的单位是否一致。
                      .调用内部函数时，参数的个数、属性和次序是否正确。
                      .在模块有多个入口的情况下，是否引用有与当前入口无关的参数。
                      .是否修改了只读型参数。
                      .全局变量是否在所有引用它们的模块中都有相同的定义。
                      局部数据结构测试
                      测试用例检查局部数据结构的完整性，如数据类型说明、初始化、默认值等方面的问题，并测试全局数据对模块的影响。
                      在模块的工作过程中，必须测试模块内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。
                      局部数据结构应注意以下几类错误：不正确或不一致的类型说明；错误的初始化或默认值；错误的变量名，如拼写错误或书写错误；下溢、上溢或者地址错误。
                      执行路径测试
                      测试用例对模块中重要的执行路径进行测试，其中对基本执行路径和循环进行测试往往可以发现大量的路径错误。测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。
                      常见的错误有误解或不正确的算术优先级；混合模式的运算；错误的初始化；精确度不够精确；表达式的不正确符号表示。
                      针对判定和条件覆盖，测试用例能够发现的错误有：不同数据类型的比较；不正确的逻辑操作或优先级；应当相等的地方由于精确度的错误而不能相等；不正确的判定或不正确的变量；不正确的或不存在的循环终止；当遇到分支循环时不能退出；不适当地修改循环变量。
                      出错处理测试
                      测试出错处理的重点是模块在工作中发生了错误，其中的出错处理设施是否有效。
                      检验程序中的出错处理可能面对的情况有以下几种：
                      .对运行发生的错误描述难以理解。
                      .所报告的错误与实际遇到的错误不一致。
                      .出错后，在错误处理之前就引起系统的干预。
                      .例外条件的处理不正确。
                      .提供的错误信息不足，以致无法找到错误的原因。
                      边界条件测试
                      边界条件测试是单元测试的最后一步，必须采用边界值分析方法来设计测试用例。在为限制数据处理而设置的边界处，测试模块是否能够正常工作。
                      一些与边界有关的数据类型，如数值、字符、位置、数量、尺寸等，以及边界的第一个、最后一个、最大值、最小值、最长、最短、最高和最低等特征。
                      在边界条件测试中，应设计测试用例检查一下情况。
                      .在n次循环的第0次、第1次、第n次是否有错误。
                      .运算或判断中取最大值、最小值时是否有错误。
                      .数据流、控制流中刚好等于、大于、小于确定的比较值是否出现错误。
               单元测试的执行过程
               通常，单元测试在编码阶段进行，在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，开始设计单元测试用例。
               由于模块并不是一个独立的程序，在考虑测试模块时，同时要考虑与其有关的外界联系，因此使用一些辅助模块去模拟与被测模块相关的其他模块。辅助模块分为以下两种：
               （1）驱动（Drive）模块。用于模拟被测试模块的上一级模块，相当于被测模块的主程序，用于接收测试数据，并把这些数据传送给被测模块，启动被测模块，最后输出实测结果。
               （2）桩（Stub）模块。用于模拟被测模块工作过程中所调用的模块。桩模块一般只进行很少的数据处理，不需要把子模块的所有功能都带进来，但不允许什么事情也不做。
               单元测试停止的条件
               单元测试停止的条件如下。
               （1）单元测试用例设计已经通过评审。
               （2）按照单元测试计划完成了所有规定单元的测试。
               （3）达到了测试计划中关于单元测试所规定的覆盖率的要求。
               （4）被测试的单元每千行代码必须发现至少3个错误。
               （5）软件单元功能与设计相一致。
               （6）在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准。
 
       集成测试
        集成测试也叫做组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
        . 组装时需要考虑的问题。
        ①在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
        ②一个模块的功能是否会对另一个模块的功能产生不利的影响；
        ③各个子功能组合起来，能否达到预期要求的父功能；
        ④全局数据结构是否有问题；
        ⑤单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。
        因此，在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。
        子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
        选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。
        . 模块组装成为系统的方式。
        模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。
        ①一次性组装方式（big bang）。
        它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。例如，有一个模块系统结构，如下图（a）所示。其单元测试和组装顺序如下图（b）所示。
        
        一次性组装方式
        在如上图（b）中，模块d1，d2，d3，d4，d5是对各个模块做单元测试时建立的驱动模块，s1，s2，s3，s4，s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。其结果是，发现有错误，却茫然找不到原因。查错和改错都会遇到困难。
        ②增殖式组装方式。
        这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。
        . 自顶向下的增殖方式。这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装。其步骤如下：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先（如下图所示为自顶向下的增殖方式）或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。最后，判断是否所有的模块都已组装到系统中。是，则结束测试；否则，转到B去执行。
        
        自顶向下的增殖方式
        自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而，能够较早地遇到这种问题。如果主要控制有问题，尽早发现它能够减少以后的返工，这是十分必要的。如果选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的正确性，就为其后对主要加工分支的组装和测试提供了保证。此外，功能可行性较早地得到证实，还能够增强开发者和用户成功的信心。
        . 自底向上的增殖方式。这种组装方式是从程序模块结构的最底层模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下：首先由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。再用实际模块代替驱动模块，与它已测试的直属子模块组装成为子系统。然后，为子系统配备驱动模块，进行新的测试。最后判断是否已组装到达主模块。是，则结束测试；否则，执行B。
        以如下图一（a）所示的一次性组装方式系统结构为例，可以用如下图二说明自底向上组装和测试的顺序。
        
        一次性组装方式
        
        自底向上的增殖方式
        . 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲，一种方式的优点是另一种方式的缺点。
        自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难，因为，桩模块在接收了所测模块发送的信息后，需要按照它所代替的实际子模块功能返回应该回送的信息，这必将增加建立桩模块的复杂度，而且导致增加一些附加的测试。同时，涉及复杂算法和真正输入/输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。
        自底向上增殖方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试，提高测试效率。因此，通常是把以上两种方式结合起来进行组装和测试。
        在进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：
        . 满足某些软件需求；
        . 在程序的模块结构中位于较高的层次（高层控制模块）；
        . 较复杂、较易发生错误；
        . 有明确定义的性能要求。
        在做回归测试时，也应该集中测试关键模块的功能。
        . 集成测试的组织和实施。
        集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：
        ①采用何种系统组装方法来进行集成测试。
        ②集成测试过程中连接各个模块的顺序。
        ③模块代码编制和测试进度是否与集成测试的顺序一致。
        ④测试过程中是否需要专门的硬件设备。
        解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
        在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应的测试应安排在这些设备能够投入使用之时，并要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。
        . 集成测试完成的标志。
        集成测试完成的标志主要有以下几项。
        ①成功地执行了测试计划中规定的所有集成测试。
        ②修正了所发现的错误。
        ③测试结果通过了专门小组的评审。
        集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。
        在完成预定的集成测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。
        集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。
 
       验收测试
        验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求的那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统了，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能是否如同用户所合理期待的那样。
        验收测试的结果有两种可能：一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
               验收测试的常用策略
               验收测试通常可以分为正式验收和非正式验收，具体选择的策略通常建立在合同需求、组织和公司标准，以及应用领域的基础上。
                      正式验收测试
                      正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。
                      在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。这种测试形式的优点是：
                      .要测试的功能和特性都是已知的。
                      .测试的细节是已知的，并且可以对其进行评测。
                      .这种测试可以自动执行，支持回归测试。
                      .可以对测试过程进行评测和监测。
                      .可接受性标准是已知的。
                      缺点包括：
                      .要求大量的资源和计划。
                      .这些测试可能是系统测试的再次实施。
                      .可能无法发现软件中由于主观原因造成的缺陷，这是因为只查找了预期要发现的缺陷。
                      非正式验收测试
                      在非正式验收测试中，执行测试过程的限定不像正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不像正式验收测试那样组织有序，而且更为主观。
                      大多数情况下，非正式验收测试是由最终用户组织执行的。这种测试形式的优点是：
                      .要测试的功能和特性都是已知的。
                      .可以对测试过程进行评测和监测。
                      .可接受性标准是已知的。
                      .与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
                      缺点包括：
                      .要求资源、计划和管理资源。
                      .无法控制所使用的测试用例。
                      .最终用户可能沿用系统工作的方式，并可能无法发现缺陷。
                      .最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。
                      .用于验收测试的资源不受项目的控制，并且可能受到压缩。
               验收测试的条件
               在真正进行用户验收测试之前，一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）。
               （1）软件开发已经完成，并全部解决了已知的软件缺陷。
               （2）验收测试计划已经过评审和批准，并且置于文档控制之下。
               （3）对软件需求说明书的审查已经完成。
               （4）对概要设计及详细设计的审查已经完成。
               （5）对所有关键模块的代码审查已经完成。
               （6）对单元、集成、系统测试计划和报告的审查已经完成。
               （7）所有的测试脚本已完成，并至少执行过一次，且通过评审。
               （8）使用配置管理工具且代码置于配置控制之下。
               （9）软件问题处理流程已经就绪。
               （10）已经制定、评审并批准验收测试完成标准。
               验收测试的过程
               （1）软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。
               （2）编制《验收测试计划》和《项目验收准则》：根据软件需求和验收要求编制测试计划，制定需测试的测试项，制定测试策略及验收通过准则，并制订出经过客户参与评审的计划。
               （3）测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编制测试用例，并经过评审。
               （4）测试环境搭建：，建立测试的硬件环境和软件环境等（可在委托客户提供的环境中进行测试）。
               （5）测试实施：测试并记录测试结果。
               （6）测试结果分析：根据验收通过准则分析测试结果，做出验收是否通过的决定，给出测试评价。
               （7）测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。
               软件配置审核
               软件配置审核包括审查和审核。
               审查是指审查可执行程序、源程序、配置脚本、测试程序或脚本、主要的开发类文档和主要的管理类文档。
               通常，正式的审核过程分为5个步骤，即计划、预备会议（可选）、准备阶段、审核会议和问题追踪。预备会议是指对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是指最终确定工作产品中包含的错误和缺陷。
               审核要达到的基本目标是根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。
               在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面，由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。
               对软件需求说明书的审查，可以从清晰性、完整性、依从性、一致性、可行性和可管理性等几个方面考虑。对软件设计说明书（详细设计说明书、概要设计说明书）的审查，可以从清晰性、完整性、依从性、一致性、可行性、数据使用性、功能性、接口、可维护性、性能、可靠性、易测性和可追溯性等方面考虑。对测试计划（单元测试计划、集成测试计划、确认测试计划、系统测试计划）的审查，可以从完整性、依从性、一致性、正确性、详细级别／程度、易测性／可行性和可追溯性等方面考虑。对软件编码规范的审查，可以考虑源程序文档化、数据说明、输入输出等方面，评审的目的是为了使程序具有良好的风格，便于阅读。
               可执行程序的测试
               在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成后，就可以进行验收测试的最后一个步骤——可执行程序的测试了，包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量5个部分。
               不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。
               验收测试的内容
               具体的测试内容通常可以包括安装（升级）、启动与关机、功能测试（正例、重要算法、边界、时序、反例、错误处理）、性能测试（正常的负载、容量变化）、压力测试（临界的负载、容量变化）、配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）及可靠性测试等。
               如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题也都已解决，而且所有的软件配置均已更新和审核，可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。
   题号导航      2020年下半年 信息系统运行管理员 上午试卷 综合知识   本试卷我的完整做题情况  
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题    在手机中做本题