5软件工程基础知识(2)

• 系统测试

  信息系统测试应包括软件测试、便件测试和网络测试。硬件测试、网络测试可以根据具体的性能指标进行，此处所说的测试更多的是指软件测试。

  • 意义

    • 为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。

  • 目的

    • 希望能以最少的人力和时间发现潜在的各种错误和缺陷。用户应根据开发各阶段的需求、设计等文档或程序的内部结构精心设计测试实例，并利用这些实例来运行程序，以便发现错误的过程。

  • 原则

    • (1)应尽早并不断地进行测试

      • 测试不是在应用系统开发完之后才进行的。由于原始问题的复杂性、开发各阶段的多样性以及参加人员之间的协调等因素，使得在开发的各个阶段都有可能出现错误。因此，测试应贯穿在开发的各个阶段，应尽早纠正错误，消除隐患。

    • (2)测试工作应该避免由原开发软件的人或小组承担

      • 一方面，开发人员往往不愿否认自己的工作，总认为自己开发的软件没有错误；另一方面，开发人员的错误很难由本人测试出来，很容易根据自己编程的思路来制定测试思路，具有局限性。测试工作应由专门人员来进行，这样会更客观、更有效。

    • (3)在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出结果

      • 将实际输出结果与预期结果相比较就能发现测试对象是否正确。

    • (4)在设计测试用例时，不仅要设计有效、合理的输入条件，也要包含不合理、失效的输入条件

      • 在测试的时候，人们往往习惯按照合理的、正常的情况进行测试，而忽略了对异常、不合理、意想不到的情况进行测试，而这可能就是隐患。

    • (5)在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事

      • 多余的工作会带来副作用，影响程序的效率，有时会带来潜在的危害或错误。

    • (6)严格按照测试计划来进行，避免测试的随意性

      • 测试计划应包括测试内容、进度安排、人员安排、测试环境、测试工具和测试资料等。严格地按照测试计划可以保证进度，使各方面都得以协调进行。

    • (7)妥善保存测试计划、测试用例，作为软件文档的组成部分，为维护提供方便。

    • (8)测试例子都是精心设计出来的，可以为重新测试或追加测试提供方便。

      • 当纠正错误、系统功能扩充后，都需要重新开始测试，而这些工作的重复性很高，可以利用以前的测试用例，或在其基础上修改，然后进行侧试。

    • (9)：系统测试阶段的测试目标来自于【需求分析】阶段。

  • 传统软件的测试策略

    • 1.单元测试

      单元测试也称为模块测试，在模块编写完成且无编译错误后就可以进行。单元测试侧重于模块中的内部处理逻辑和数据结构。如果选用机器测试，一般用白盒测试法。这类测试可以对多个模块同时进行。

      • 1)测试内容

        单元测试主要检查模块的以下5个特征。

        • (1)模块接口

          模块的接口保证了测试模块的数据流可以正确地流入、流出。在测试中应检查以下要点：

          • ①测试模块的输入参数和形式参数在个数、属性、单位上是否一致。
          • ②调用其他模块时，所给出的实际参数和被调用模块的形式参数在个数、属性、单位上是否一致。
          • ③调用标准函数时，所用的参数在属性、数目和顺序上是否正确。
          • ④全局变量在各模块中的定义和用法是否一致。
          • ⑤输入是否仅改变了形式参数。
          • ⑥开/关的语句是否正确。
          • ⑦规定的/O格式是否与输入输出语句一致。
          • ⑧在使用文件之前是否己经打开文件或使用文件之后是否己经关闭文件。

        • (2)局部数据结构

          在单元测试中，局部数据结构出错是比较常见的错误，在测试时应重点考虑以下因素。

          • ①变量的说明是否合适。
          • ②是否使用了尚未赋值或尚未初始化的变量。
          • ③变量的初始值或默认值是否正确。
          • ④变量名是否有错（例如拼写错）。

        • (3)重要的执行路径

          在单元测试中，对路径的测试是最基本的任务。由于不能进行穷举测试，需要精心设计测试例子来发现是否有计算、比较或控制流等方面的错误。

          • ①计算方面的错误。

            • 算术运算的优先次序不正确或理解错误；精度不够：运算对象的类型彼此不相容：算法错：表达式的符号表示不正确等。

          • ②比较和控制流的错误。

            • 本应相等的量由于精度造成不相等：不同类型进行比较：逻辑运算符不正确或优先次序错误：循环终止不正确（如多循环一次或少循环一次）、死循环：不恰当地修改循环变量：当遇到分支循环时出口错误等。

        • (4)出错处理

          • 好的设计应该能预测到出错的条件并且有对出错处理的路径。虽然计算机可以显示出错信息的内容，但仍需要程序员对出错进行处理，保证其逻辑的正确性，以使于用户维护。

        • (5)边界条件

          • 边界条件的测试是单元测试的最后工作，也是非常重要的工作。软件容易在边界出现错误。

      • 2)单元测试过程

        • 由于模块不是独立运行的程序，各模块之间存在调用与被调用的关系。在对每个模块进行测试时，需要开发两种模块。单元测试环境如图5-9所示。

        • 驱动模块

          • 相当于一个主程序，接收测试例子的数据，将这些数据送到测试模块，输出测试结果。

        • 桩模块（也称为存根模块）

          • 桩模块用来代替测试模块中所调用的子模块，其内部可进行少量的数据处理，目的是为了检验入口，输出调用和返回的信息。

        • 提高模块的内聚度可以简化单元测试。如果每个模块只完成一种功能，对于具体模块来讲，所需的测试方案数据会显著减少，而且更容易发现和预测模块中的错误。

    • 2.集成测试

      • 集成测试就是把模块按系统设计说明书的要求组合起来进行测试。即使所有的模块都通过了测试，在集成之后，仍然可能出现问题：

        • 穿过模块的数据丢失；
        • 一个模块的功能对其他模块造成有害的影响；
        • 各个模块集成起来没有达到预期的功能；
        • 全局数据结构出现问题。
        • 另外，单个模块的误差可以接受，但模块组合后，可能会出现误差累积，最后累积到不能接受的程度。集成测试是构造软件体系结构的系统化技术，同时也是进行一些旨在发现与接口相关的错误的测试，其目标是利用已通过单元测试的构件建立设计中描述的程序结构。

      • 通常，集成测试有两种方法：

        • 一种是非增量集成，分别测试各个模块，再把这些模块组合起来进行整体测试；

          • 非增量式集成可以对模块进行并行测试，能充分利用人力，并加快工程进度。但这种方法容易混乱，出现错误不容易查找和定位。

        • 另一种是增量集成，即以小增量的方式逐步进行构造和测试。

          • 增量式测试的范围一步步扩大，错误容易定位，更易于对接口进行彻底测试，并且可以运用系统化的测试方法。

      • 增量集成策略

        • 1)自顶向下集成测试

          • 自顶向下集成测试是一种构造软件体系结构的增量方法。模块的集成顺序为从主控模块（主程序）开始，沿着控制层次逐步向下，以深度优先或广度优先的方式将从属于（或间接从属于）主控模块的模块集成到结构中。

          • 如图5-10所示，深度优先集成是首先集成位于程序结构中主控路径上的所有构件，也可以根据特定应用系统的特征进行选择。

          • 例如，选择最左边的路径，首先集成构件M1、M2和M5:其次，集成M8或M6(若M的正常运行是必需的)，然后集成中间和右边控制路径上的构件。广度优先集成首先沿着水平方向，将属于同一层的构件集成起来。例如图5-10中，首先将构件M2、M3和M4集成起来：其次是控制成M5、M6、M7,依此类推。集成过程可以通过下列5个步骤完成。

            • (1)主控模块用作测试驱动模块，用这些从属于主控模块的所有模块代替桩模块。
            • (2)依靠所选择的集成方法（即深度优先或广度优先），每次用实际模块替换一个从属桩模块。
            • (3)在集成每个模块后都进行测试。
            • (4)在完成每个测试集之后，用实际模块替换另一个桩模块。
            • (5)可以执行回归测试，以确保没有引入新的错误。
            • 回到第(2)步继续执行此过程，直到完成了整个程序结构的构造。

        • 2)自底向上集成测试

          • 自底向上集成测试就是从原子模块（程序结构的最底层构件）开始进行构造和测试。由于构件是自底向上集成的，在处理时所需要的从属于给定层次的模块总是存在的，因此，没有必要使用桩模块。自底向上集成策略可以利用以下步骤来实现。

            • (1)连接低层构件以构成完成特定子功能的簇。
            • (2)编写驱动模块（测试的控制程序）以协调测试用例的愉入和输出。
            • (3)测试簇。
            • (4)去掉驱动程序，沿着程序结构向上逐步连接簇。

        • 3)回归测试

          • 每当加入一个新模块作为集成测试的一部分时，软件发生变更，建立了新的数据流路径，

          • 可能出现新的I/O,以及调用新的控制逻辑。这些变更可能会使原来可以正常工作的功能产生问题。在集成测试策略的环境下，回归测试是重新执行己测试过的某些子集，以确保变更没有传播不期望的副作用。

          • 回归测试有助于保证变更不引入无意识行为或额外的错误。回归测试可以手工进行，方法是重新执行所有测试用例的子集，或者利用捕捉回放工具自动执行。捕捉回放工具使软件工程师能够为后续的回放与比较捕捉测试用例和测试结果。回归测试要执行的测试子集包含以下3种测试用例。

            • 能够测试软件所有功能的具有代表性的测试样本。
            • 额外测试，侧重于可能会受变更影响的软件功能。
            • 侧重于已发生变更的软件构件测试。

          • 随着集成测试的进行，回归测试的数量可能变得相当庞大，因此，应将回归测试用例设计成只包括设计每个主要程序功能的一个或多个错误类的测试。一旦发生变更，对每个软件功能重新执行所有的测试是不切实际的，而且效率很低。

        • 4)冒烟测试

          • 当开发软件产品时，冒烟测试是一种常用的集成测试方法，是时间关键项目的决定性机制，它让软件团队频繁地对项目进行评估。本质上，冒烟测试方法包括下列活动：

            • (1)将已经转换为代码的软件构件集成到构建中。

              • 一个构建包括所有的数据文件、库、可复用的模块以及实现一个或多个产品功能所需的工程化构件。

            • (2)设计一系列测试以暴露影响构建正确的完成其功能的错误，其目的是为了发现极有可能造成项目延迟的业务阻塞错误。

            • (3)每天将该构建与其他构建及整个软件产品（以其当前形势）集成起来进行冒烟测试。这种集成方法可以自顶向下，也可以自底向上。

    • 确认测试

    • 系统测试

  • 测试方法

    • 在软件测试过程中，应该为定义软件测试模板，即将特定的测试方法和测试用例设计放在一系列的测试步骤中。

    • (1)静态测试。

      • 静态测试是指被测试程序不在机器上运行，而是采用人工检测和计算机铺助静态分析的手段对程序进行检测。

        • ①人工检测。

          • 人工检测不依靠计算机而是依靠人工审查程序或评审软件，包括代码检查、静态结构分析和代码质量度量等。

        • ②计算机辅助静态分析。

          • 利用静态分析工具对被测试程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。

    • (2)动态测试。

      • 动态测试是指通过运行程序发现错误。

        • 黑盒测试法

          • 黑盒测试也称为功能测试，在完全不考虑软件的内部结构和特性的情况下，测试软件的外部特性。进行黑盒测试主要是为了发现以下几类错误。

            • (1)是否有错误的功能或遗漏的功能？
            • (2)界面是否有误？输入是否正确接收？输出是否正确？
            • (3)是否有数据结构或外部数据库访问错误？
            • (4)性能是否能够接受？
            • (5)是否有初始化或终止性错误？

          • 常用的黑盒测试技术有等价类划分、边界值分析、错误推测和因果图等。

            • (1)等价类划分。

              • 等价类划分法将程序的输入域划分为若干等价类，然后从每个等价类中选取一个代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值，这样就可以用少量代表性的测试用例取得较好的测试效果。等价类划分有两种不同的情况：有效等价类和无效等价类。在设计测试用例时，要同时考虑这两种等价类。

              • 定义等价类的原则

                • ①在输入条件规定了取值范围或值的个数的情况下，可以定义一个有效等价类和两个无效等价类。
                • ②在输入条件规定了输入值的集合或规定了“必须如何”的条件的情况下，可以定义一个有效等价类和一个无效等价类。
                • ③在输入条件是一个布尔量的情况下，可以定义一个有效等价类和一个无效等价类。
                • ④在规定了输入数据的一组值(假定”个)，并且程序要对每一个输入值分别处理的情况下，可以定义n个有效等价类和一个无效等价类。
                • ⑤在规定了输入数据必须遵守的规则的情况下，可以定义一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
                • ⑥在确知己划分的等价类中，各元素在程序处理中的方式不同的情况下，则应将该等价类进一步划分为更小的等价类。

              • 定义好等价类之后，建立等价类表，并为每个等价类编号。在设计一个新的测试用例时，使其尽可能多地覆盖尚未覆盖的有效等价类，不断重复，最后使得所有有效等价类均被测试用例覆盖。然后设计一个新的测试用例，使其只覆盖一个无效等价类。

            • (2)边界值分析。

              • 输入的边界比中间更加容易发生错误，因此用边界值分析来补充等价类划分的测试用例设计技术。边界值划分选择等价类边界的测试用例，既注重于输入条件边界，又适用于输出域测试用例。

              • 对边界值设计测试用例应遵循的原则

                • ①如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
                • ②如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数据作为测试数据。
                • ③根据规格说明的每个输出条件使用上述两条原则。
                • ④如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
                • ⑤如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。
                • ⑥分析规格说明，找出其他可能的边界条件。

            • (3)错误推测。

              • 错误推测是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。其基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

            • (4)因果图。

              • 因果图法是从自然语言描述的程序规格说明中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表。

              • 步骤

                • ①分析程序规格说明的描述中哪些是原因，哪些是结果，原因常常是输入条件或是输入条件的等价类，而结果是输出条件。
                • ②分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。
                • ③标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用若干个标准的符号标明约束条件。
                • ④把因果图转换成判定表。
                • ⑤为判定表中每一列表示的情况设计测试用例。

              • 这样生成的测试用例(局部，组合关系下的)包括了所有输入数据的取“真”和取“假”的情况，构成的测试用例数据达到最少，且测试用例数据随输入数据数目的增加而增加。