软件工程导论—软件测试

文章目录

      • 1. 软件测试基础
        • 1.1. 软件测试的目的和准则
        • 1.2. 软件测试方法和步骤
        • 1.3. 测试内容
        • 1.4. 测试阶段的信息流
      • 2. 单元测试
      • 3. 集成测试
        • 3.1. 集成测试概述
        • 3.2. 自顶向下集成
        • 3.3. 自底向上集成
        • 3.4. 不同集成测试策略的比较与回归测试
      • 4. 确认测试
        • 4.1. 确认测试概述
        • 4.2. 确认测试的范围和软件配置复查
        • 4.3. Alpha和Beta测试
      • 5. 白盒测试技术
        • 5.1. 白盒测试技术概述
        • 5.2. 逻辑覆盖
        • 5.3. 控制结构测试
      • 6. 黑盒测试技术
        • 6.1. 黑盒测试概述
        • 6.2. 等价划分
        • 6.3. 边界值分析
        • 6.4. 错误推测
      • 7. 调试
        • 7.1. 调试概述
        • 7.2. 调试过程和途径
      • 8. 软件可靠性
        • 8.1. 软件可靠性相关的几个概念
        • 8.2. 估算平均无故障时间的方法

1. 软件测试基础

1.1. 软件测试的目的和准则

测试是为了发现程序中的错误而执行程序的过程,好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案,成功的测试是发现了至今为止尚未发现的错误的测试。

一般来说,软件测试有以下几条准则:

  1. 所有测试都应该能追溯到用户需求;
  2. 应该远在测试开始之前就制定出测试计划;
  3. 把Pareto原理应用到软件测试中;
  4. 应该从“小规模”测试开始,并逐步进行“大规模”测试;
  5. 穷举测试是不可能的;
  6. 为了达到最佳的测试效果,应该由独立的第三方从事测试工作。

1.2. 软件测试方法和步骤

软件测试方法主要分为黑盒测试和白盒测试:

  1. 黑盒测试(功能测试)
    把程序看作一个黑盒子,完全不考虑程序的内部结构和处理过程,而是在程序接口进行的测试;
  2. 白盒测试(结构测试)
    把程序看成装在一个透明的盒子里,测试者完全知道程序的结构和处理算法,按照程序内部的逻辑测试程序,检测程序中的主要执行通路是否都能按预定要求正确工作。
黑盒测试 白盒测试
优点 适用于各阶段测试
从产品功能角度测试
容易入手生成测试数据
可构成测试数据使特定程序部分得到测试
有一定的充分性度量手段
可获较多工具支持
缺点 某些代码得不到测试
如果规格说明有误,则无法发现
不易进行充分性测试
通常不易生成测试数据
无法对未实现规格说明的部分进行测试
工作量大,通常只用于单元测试,有应用局限
性质 一种确认技术,回答”我们在构造一个正确的系统吗 一种验证技术,回答”我们在正确地构造一个系统吗

一般来说,测试的按照以下步骤进行:

  1. 模块测试(单元测试)
    模块测试主要发现的往往是编码和详细设计的错误,目的是保证每个模块作为一个单元能正确运行;
  2. 子系统测试
    子系统测试把经过单元测试的模块放在一起形成一个子系统来测试,着重测试模块的接口。
  3. 系统测试
    把经过测试的子系统装配成一个完整的系统来测试,发现的往往是软件设计中的错误,也可能发现需求说明中的错误。不论是子系统测试还是系统测试,都兼有检测和组装两重含义,通常也称为集成测试。
  4. 验收测试(确认测试)
    验收测试是在用户积极参与下进行的,而且可能主要使用实际数据(系统将来要处理的信息)把软件系统作为单一的实体进行测试进行测试,它发现的往往是系统需求说明书中的错误
  5. 平行运行
    同时运行新开发出来的系统和将被它取代的旧系统,然后比较新旧两个系统的处理结果。平行运行可以在准生产环境中运行新系统而又不冒风险,同时用户能有一段熟悉新系统的时间,用户可以趁这段时间验证用户指南和使用手册之类的文档。以准生产模式对新系统进行全负荷测试,可以用测试结果验证性能指标。

详细步骤说明如下表所示:

测试阶段 主要依据 测试人员 测试方法 测试内容
单元测试 系统设计文档 开发小组 白盒测试 接口测试
路径测试
子系统测试 系统设计文档
需求文档
独立测试小组 白盒测试
黑盒测试
接口测试
路径测试
功能测试
性能测试
系统测试 需求文档 独立测试小组 黑盒测试 功能测试、健壮性测试
性能测试、用户界面测试
安全性测试、压力测试
可靠性测试、安装/卸载测试
验收测试 需求文档 用户 黑盒测试 功能测试、健壮性测试
性能测试、用户界面测试
安全性测试、压力测试
可靠性测试、安装/卸载测试

1.3. 测试内容

  1. 接口测试
    每个接口可能有多个输入参数,每个参数有 “典型值”、“边界值”、“异常值”之分,根据接口的定义,可以推断某种输入应当产生什么样的输出。输出包括函数的返回值和输出参数。 同时要观察是否有程序语句从来没有被执行过,特别留意函数体内的错误处理程序块。
  2. 路径测试
    路径测试就是测试程序的流程路径,想遍历全部路径几乎是不可能的,不测试或者胡乱找几条路径测试却又不行,输入与对应的输出之间的路径是唯一的。由于接口测试时的输入要有代表性的,因此相应的路径也具有代表性,制定的路径测试检查表应该包括:数据类型、变量值、逻辑判断、循环、内存管理、文件I/O、错误处理。
  3. 功能测试
    功能测试的基本方法是构造一些合理输入(在需求范围之内),检查输出是否与期望相同。有两种比较好的测试方法:等价划分法和边界值分析法,等价划分是指把输入空间划分为几个“等价区间”,在每个“等价区间”中只需要测试一个典型值就可以了;边界值测试法是对等价划分法的补充。除了典型值外还要用边界值作为测试用例。
  4. 健壮性测试
    健壮性是指在异常情况下,软件能正常运行的能力。它有两层含义:(1)容错能力,容错性测试通常构造一些不合理的输入来引诱软件出错;(2)恢复能力,恢复测试重点考察系统能否重新运行、有无重要的数据丢失、是否毁坏了其它相关的软件硬件。
  5. 性能测试
    性能测试即测试软件处理事务的速度,一是为了检验性能是否符合需求,二是为了得到某些性能数据供人们参考,有时人们关心测试的“绝对值” ,有时关心测试的“相对值” 。
  6. 用户界面测试
    绝大多数软件拥有图形用户界面,图形用户界面的测试重点是正确性、易用性和视觉效果,在评价易用性和视觉效果时,主观性非常强,应当考虑多个人的观点。
  7. 信息安全测试
    信息安全性是指防止系统被非法入侵的能力,既属于技术问题又属于管理问题。主要有如下步骤:(1)为非法入侵设立目标、(2)邀请一些人扮演黑客,让他们想尽办法入侵系统,实现“目标”、(3)如果有人成功了,请他详述入侵的过程。
  8. 压力测试
    压力测试也叫负荷测试,即获取系统能正常运行的极限状态。 主要任务是:构造正确的输入,使劲折腾系统却让它刚好不瘫痪。 压力测试的一个变种是敏感测试,敏感测试目的是发现什么样的输入可能会引发不稳定现象。
  9. 可靠性测试
    可靠性是指在一定的环境下、给定的时间内、系统不发生故障的概率。软件可靠性测试可能会花费很长时间。 比较实用的办法是,让用户使用该系统,记录每一次发生故障的时刻。计算出相邻故障的时间间隔,注意要去掉非工作时间。然后统计出不发生故障的“最小时间间隔”、“最大时间间隔”和“平均时间间隔”。
  10. 安装/卸载测试
    目前市面上有非常流行的、专门制作安装/卸载程序的一些工具,如Install Shelled。主要的测试工作是:(1)至少在标准配置和最低配置两种环境下测试;(2)如果有安装界面,应当尝试各种选项,如选择“全部”、“部分”、“升级”等。

1.4. 测试阶段的信息流

测试阶段输入的信息有两类: 软件配置测试配置,其中软件配置包括需求说明书、设计说明书和源程序清单等,测试配置包括测试计划和测试方案。

软件工程导论—软件测试
在把附属于主控制模块的那些模块组装到程序结构中去时,可以使用深度优先的策略或者使用宽度优先的策略。

所谓深度优先,就是先组装在软件结构的一条主控制通路上的所有模块;宽度优先就是沿软件结构水平地移动,把处于同一个控制层次上的所有模块组装起来。

软件工程导论—软件测试
用下述步骤可以实现自底向上的结合策略:
  1. 把低层模块组合成实现某个特定的软件子功能的族;
  2. 写一个驱动程序(用于测试的控制程序),协调测试数据的输入和输出;
  3. 对由模块组成的子功能族进行测试;
  4. 去掉驱动程序,沿软件结构自下向上移动,把子功能族组合起来形成更大的子功能族。
  5. 不断重复2~4步,直到构造起完整的软件结构为止。
    软件工程导论—软件测试

    5.2. 逻辑覆盖

    有选择地执行程序中某些最有代表性的通路是对穷尽测试的惟一可行的替代办法。从覆盖源程序语句的详尽程度分析,大致有以下一些不同的覆盖标准:

    1. 语句覆盖
      选择足够多的测试数据,使被测程序中每个语句至少执行一次。语句覆盖对程序的逻辑覆盖很少。语句覆盖只关心判定表达式的值,而没有分别测试判定表达式中每个条件取不同值时的情况。语句覆盖是很弱的逻辑覆盖标准。
    2. 判定覆盖
      不仅每个语句必须至少执行一次,而且每个判定的每种可能的结果都应该至少执行一次。
    3. 条件覆盖
      不仅每个语句至少执行一次,而且使判定表达式中的每个条件都取到各种可能的结果。条件覆盖通常比判定覆盖强,因为它使每个条件都取到了两个不同的结果,判定覆盖却只关心整个判定表达式的值。但也有反例,总之,判定覆盖不一定包含条件覆盖,条件覆盖也不一定包含判定覆盖。
    4. 判定/条件覆盖
      使得判定表达式中的每个条件都取到各种可能的值,每个判定表达式也都取到各种可能的结果。
    5. 条件组合覆盖
      要求选取足够多的测试数据,使得每个判定表达式中条件的各种可能组合都至少出现一次。条件组合覆盖是前述几种覆盖标准中最强的。满足条件组合覆盖标准的测试数据,也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。但是,条件组合覆盖标准的测试数据并不一定能使程序中的每条路径都执行到,是从对程序路径的覆盖程度分析的逻辑覆盖标准。
    6. 点覆盖
      选取足够多的测试数据,使得程序执行路径至少经过流图的每个结点一次。由于流图的每个结点与一条或多条语句相对应,因此点覆盖标准和语句覆盖标准是相同的。
    7. 边覆盖
      选取足够多测试数据,使得程序执行路径至少经过流图中每条边一次。通常边覆盖和判定覆盖是一致的。
    8. 路径覆盖
      选取足够多测试数据,使程序的每条可能路径都至少执行一次(如果程序图中有环,则要求每个环至少经过一次。

    软件工程导论—软件测试

    6. 黑盒测试技术

    6.1. 黑盒测试概述

    黑盒测试着重测试软件功能,主要的错误类型为: 功能不正确或遗漏了功能、界面错误、数据结构错误或外部数据库访问错误、性能错误、初始化和终止错误

    黑盒测试的公认标准主要有两个:(1)测试用例尽可能少;(2)一个测试用例能指出一类错误。

    6.2. 等价划分

    使用等价划分法设计测试方案首先需要划分输入数据的等价类,等价划分是一种黑盒测试技术,把程序的输入域划分成若干个数据类,据此导出测试用例。设计测试方案时尽量设计出能发现若干类错误的测试用例,从而减少测试用例的数目,每类中的一个典型值在测试中的作用要与这一类中所有其他值的作用相同。此外常常还需要分析输出数据的等价类,以便根据输出数据的等价类导出对应的输入数据等价类。

    等价类划分的启发式规则

    1. 如果规定了输入值的范围,则可划分出一个有效的等价类(输入值在此范围内),两个无效的等价类(输入值小于最小值或大于最大值);
    2. 如果规定了输入数据的个数,则类似地也可划分出一个有效的等价类和两个无效的等价类;
    3. 如果规定了输入数据的一组值,而且程序对不同输入值做不同处理,则每个允许的输入值是一个有效的等价类,此外还有一个无效的等价类(任一个不允许的输入值);
    4. 如果规定了输入数据必须遵循的规则,则可以划分出一个有效的等价类(符合规则)和若干个无效的等价类(从各种不同角度违反规则);
    5. 如果规定了输入数据为整型,则可以划分出正整数、零和负整数等3个有效类;
    6. 如果程序的处理对象是表格,则应该使用空表,以及含一项或多项的表。

    使用等价划分法设计黑盒测试的方案时可以按照如下两个步骤进行:

    1. 设计一个新的测试方案以尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步骤直到所有有效等价类都被覆盖为止;
    2. 设计一个新的测试方案,使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类,重复这一步骤直到所有无效等价类都被覆盖为止。

    6.3. 边界值分析

    经验表明,处理边界情况时程序最容易发生错误。例如,许多程序错误出现在下标、纯量、数据结构和循环等等的边界附近。使用边界值分析方法设计测试方案首先应该确定边界情况。选取的测试数据应该刚好等于、刚刚小于和刚刚大于边界值。

    通常设计黑盒测试方案时总是联合使用等价划分和边界值分析两种技术。

    6.4. 错误推测

    不同类型不同特点的程序通常又有一些特殊的容易出错的情况。因此必须依靠测试人员的经验和直觉,从各种可能的测试方案中选出一些最可能引起程序出错的方案。它的基本想法是列举出程序中可能有的错误和容易发生错误的特殊情况,并且根据它们选择测试方案。

    7. 调试

    7.1. 调试概述

    调试是在测试发现错误之后排除错误的过程,软件错误的外部表现和它的内在原因之间可能并没有明显的联系,调试就是把症状和原因联系起来的尚未被人深入认识的智力过程。

    7.2. 调试过程和途径

    调试发生在测试之后,调试过程从执行一个测试用例开始,评估测试结果,如果发现实际结果与预期结果不一致,则这种不一致就是一个症状,它表明在软件中存在着隐藏的问题。

    调试过程试图找出产生症状的原因,以便改正错误。

    软件工程导论—软件测试
    调试可以通过下列途径进行:
    1. 蛮干法
      蛮干法可能是寻找软件错误原因的最低效的方法。其他方法都失败时才使用这种方法,这种方法印出内存的内容,激活对运行过程的跟踪,在程序中到处都写上WRITE(输出)语句。更多情况下这种方法只会浪费时间和精力。必须首先进行周密的思考,有明确的目的,尽量减少无关信息的数量。
    2. 回溯法
      回溯是一种相当常用的调试方法,当调试小程序时这种方法是有效的。具体做法是,从发现症状的地方开始,人工沿程序的控制流往回追踪分析源程序代码,直到找出错误原因为止。但是随着程序规模扩大,应该回溯的路径数目也变得越来越大,以至彻底回溯大程序变成完全不可能了。
    3. 原因排除法
      (1)对分查找法
      如果已经知道每个变量在程序内若干个关键点的正确值,则可以用赋值语句或输入语句在程序中点附近“注入”这些变量的正确值,然后运行程序并检查所得到的输出,如果输出结果是正确的,则错误原因在程序前半部分;反之,错误原因在程序后半部分,对错误原因所在的那部分重复使用这个方法,直到把出错范围缩小到容易诊断的程度为止。
      (2)归纳法
      归纳法是从个别现象推断出一般性结论的思维方法。首先把和错误有关的数据组织起来进行分析,以便发现可能的错误原因,然后导出对错误原因的一个或多个假设,并利用已有的数据来证明或排除这些假设。
      (3)演绎法
      演绎法从一般原理或前提出发,经过排除和精化的过程推导出结论。首先设想出所有可能的出错原因,然后试图用测试来排除每一个假设的原因。

    8. 软件可靠性

    8.1. 软件可靠性相关的几个概念

    软件可靠性:程序在给定的时间间隔内,按照规格说明书的规定成功地运行的概率。

    软件的可用性:程序在给定的时间点,按照规格说明书的规定,成功地运行的概率。

    稳态可用性(Ass):如果在一段时间内,软件系统故障停机时间分别为 t d o w n 1 t_{down1} tdown1/span> t d o w n 2 t_{down2} tdown2/span>,…,正常运行时间分别为 t u p 1 t_{up1} tup1/span> t u p 2 t_{up2} tup2/span>,…,则系统的稳态可用性为:

    A s s = T u p T u p + T d o w n Ass=frac{T_{up}}{T_{up}+T_{down}} Ass=T来源:白水baishui

    声明:本站部分文章及图片转载于互联网,内容版权归原作者所有,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2020年4月10日
下一篇 2020年4月10日

相关推荐