zoukankan      html  css  js  c++  java
  • 【软件工程】软件测试目标定义 黑盒测试、白盒测试

    记录 软件工程-软件测试技术课件

    著名的软件错误案例研究

    1、迪斯尼的狮子王

    1994年秋天,迪斯尼公司发布了第一个面向儿童的多媒体光盘游戏LionKing
    Animated Storybook(狮子王动画故事书)。这次是迪斯尼公司首次进军游戏市场。他们进行了大力宣传促销。结果,销售额非常可观。该游戏成为孩子们那个夏季的“必买游戏”。后来却飞来横祸。12月26日,圣诞节后的一天,迪斯尼公司的客户支持部电话开始响个不停。很快,电话支持部门就淹没在愤怒的家长和哭诉玩不成游戏的孩子们的电话狂潮之中。报纸和电视中涌现了各种故事。

    原因:迪斯尼公司没有对市场上投入使用的各种PC机型进行正确的测试。软件在少数系统中工作正常——例如迪斯尼的程序员用于开发游戏的系统——但在大众使用的常见系统中却不行。

    没有在各种PC上正确的测试,软件只能在少数机器上正常运行。

    兼容性测试

    2、美国航天局火星基地登陆,1999

    1999年12月3日,美国航天局的火星基地登陆飞船在试图登陆火星表面时失踪。错误修正委员会观测到故障,并认定出现误动作的原因极可能是某一个数据被意外更改。

    大家一致声讨,问题为什么没有在内部测试时解决。

    从理论上看,登陆计划是:当飞船降落在火星表面时,它将打开降落伞减缓飞船的下落速度。降落伞打开后的几秒种内,飞船的三条腿将迅速撑开,并在预定地点着陆。当飞船离地面1800米时,它将丢弃降落伞,点燃登陆推进器,在余下的高度缓缓降落地面。
    美国航天局为了省钱,简化了确定何时关闭推进器的装置。为了替代其他太空船上使用的贵重雷达,他们在飞船的脚上装了一个廉价的触点开关,在计算机中设置一个数据位来关掉燃料。即,飞船的脚不“着地”,引擎就会着火。
    错误修正委员会在测试中发现,当飞船的脚迅速撑开并准备着陆时,机械震动在大多数情况下也会触发着地开关,设置错误的数据位。设想飞船开始着陆时,计算机极有可能关闭推进器,而火星登陆飞船下坠1800米之后冲向地面,撞成碎片。

    原因:登陆飞船经过了两个小组测试,其中一个小组测试飞船的脚落地过程,另一个小组测试此后的着陆过程。前一个小组不去注意着地数据位是否置位,后一个小组总是在开始测试之前重置计算机、清除数据位。双方独立工作很好,但从未在一起进行集成测试。

    单个测试 从未在一起进行集成测试。

    3、爱国者导弹防御系统,1991

    ​ 美国爱国者导弹防御系统是里根总统提出的主动战略防御(即星球大战)程序的缩略版本。它首次应用在海湾战争中对抗伊拉克飞毛腿导弹的防御战争中。尽管关于此系统的赞誉不绝于耳,但是它确实在几次对抗导弹战役中失利,其中一枚在沙特阿拉伯的多哈击毙28名美国士兵。

    原因:存在一个软件缺陷。一个很小的系统时钟错误积累起来就可能拖延14小时,造成跟踪系统失去准确度。在多哈袭击战中,系统被拖延100多小时。

    缺陷 错误的累积 一直积累 最终影响很大很大。

    4、千年虫,大约1974

    4、千年虫,大约1974
    20世纪70年代某位程序员——假设他叫Dave——负责本公司的工资系统。他使用的计算机存储空间很小,迫使他尽量节省每一个字节。Dave自豪地将自己的程序压缩得比其他人都小。
    他使用的其中一个办法是把4位数日期,例如1973缩减为2位数,例如73。因为工资系统极度依赖数据处理,Dave得以节省可观的存储空间。他认为只有在到达2000年时程序计算00或01这样的年份时才会出现问题。他知道这样会出问题,但是在25年之内程序肯定会更改或升级,而且眼前的任务比现在计划遥不可及的未来更加重要。
    这一天毕竟是要到来的。1995年,Dave的程序仍然在使用,而Dave退休了,谁也不会想到进入程序检查2000年兼容问题,更不用说去修改了。
    估计世界各地更换或升级类似Dave程序以解决原有2000年错误的费用以及超过数亿美元了。

    尽可能节省空间 四位数日期 减为二位 到00年时程序计算会出错,还有几十年不要紧软件程序会升级修改的,眼前的任务要求更重要,那一天到了,00兼容问题。

    软件测试的定义和目标

    定义

    软件测试:检测和评价软件以确定其质量的过程和方法,即评价软件或程序的属性和能力,以确定它是否满足所需结果的过程与方法。

    软件测试可分为静态分析和动态测试:

    只是检查和审阅 运行和使用软件

    (1)进行静态分析时,不必运行软件,只是通过对源代码进行分析,检测程序的控制流和数据流,以及发现执行不到的“死代码”、无限循环、未初始化的变量、未使用的数据、重复定义的数据等;也可能包括对多种复杂性度量值的计算。静态分析虽然不能取代动态测试,但它是动态测试开始前有用的质量检测手段。
    (2)动态测试技术借助于输入样例(即测试用例)来执行软件,一般又分为功能测试(即黑盒测试)以及结构测试(即白盒测试)。

    From:《计算机科学技术百科全书》(第二版),张效祥主编,清华大学出版社,2005年11月。

    目标

    软件测试目标:
    (1)预防错误
    (2)发现错误

    发现错误 预防错误

    一般只有符合下列5个规则才叫软件错误:
    1.软件未达到产品说明书标注的功能.
    2.产品出现了产品说明书指明不会出现的错误.
    3.软件功能超出产品说明书的范围.
    4.软件未达到产品说明书虽未指出但应达到的目标.
    5.软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好。
    From:《软件测试》,(美)Patton, R.著,北京:机械工业出版社,2002.2.

    满足不了产品说明书的要求

    软件测试与软件调试的区别

    软件调试

    软件调试:发现所编写软件中的错误,确定错误的位置并加以排除,使之能由计算机或相关软件正确理解与执行的方法与过程。

    ​ 在进行调试工作以前,首先要发现存在着某种错误的迹象。随后的调试过程通常分为两步:

    (1)确定问题的性质并且找到该错误在软件中所处的位置;

    (2)修正这一错误。

    From:《计算机科学技术百科全书》(第二版),张效祥主编,清华大学出版社,2005年11月。

    发现所编写程序错误,确定位置加以改正。

    确定问题的性质找到错误位置,修正这一错误。

    软件测试和软件调试的主要区别:

    (1)测试从一个侧面证明程序员的“失败”,而调试是为了证明程序员的正确。
    (2)测试以已知条件开始,使用预先定义的程序,且有预知的结果,不可预见的仅是程序是否通过测试。调试一般是以不可知的内部条件开始,除统计性调试外,结果是不可预见的。
    (3)测试是有计划的,并要进行测试设计;而调试是不受时间约束的。
    (4)测试是一个发现错误、改正错误、重新测试的过程;而调试是一个推理过程。
    (5)测试的执行是有规律的,而调试的执行往往要求程序员进行必要推理以至知觉的“飞跃”。
    (6)测试经常是由独立的测试组在不了解软件设计的条件下完成的;而调试必须由了解详细设计的程序员完成。
    (7)大多数测试的执行和设计可由工具支持,而调试时,程序员能利用的工具主要是调试器。

    证明 推理 调试器 未知

    软件测试过程模型

    在这里插入图片描述

    软件测试过程所涉及的要素,以及这些要素之间的关系 。

    环境:包括支持其运行的硬件、固件和软件;
    被测对象模型:为了测试,形成被测对象的简化版本。不同的测试技术,对同一被测对象(程序),可产生不同的对象模型:
    简化注重程序的控制结构---形成“白盒”测试
    简化注重程序的处理过程---形成“黑盒”测试
    错误模型:为了统一认识,定义“什么是错误”。

    不同的测试,可产生不同的对象模型

    控制结构 白盒测试

    处理过程 黑盒测试

    什么是错误?

    几个关键性的概念:

    错误 error

    错误(error)是指“与所期望的设计之间的偏差,该偏差可能产生不期望的系统行为或失效”。

    期望

    失效 failure

    失效(failure)是指“与所规约的系统执行之间的偏差”。失效是系统故障或错误的后果。

    失效 系统故障 错误的后果

    故障 fault

    故障(fault)是指“导致错误或失效的不正常的条件”。故障可以是偶然性的或是系统性的。

    故障 不正常或导致错误的条件

    三者的关系

    三者关系:
    程序员编写程序,在这个过程中,他无意或有意地犯一个错误(error)。故障(fault)是一个或多个错误的表现。
    当执行程序中那段有故障的代码时,就会引起失效(failure),导致程序出现不正确的状态,影响程序的输出结果。

    一个个错误 表现故障了 引起失效

    error fault failure

    软件测试的原则

    软件测试的原则
    (1)所有的测试都应当追朔到用户需求。软件测试的目的在于发现错误,而从用户角度看,最严重的错误就是那些致使程序无法满足需求的错误。

    无法满足需求的错误 这软件不能做到我想要的结果 解决我要解决的问题

    (2)在测试工作开始前,要进行测试计划的设计。测试计划可以在需求分析一完成时开始,详细的测试用例定义可以在设计模型被确定后立即开始。

    测试计划 需求分析 测试用例 设计模型

    (3)测试应从小规模开始,逐步转向大规模。最初的测试通常放在单个程序模块上,测试焦点逐步转移到在集成的模块簇内寻找错误,最后在整个系统中寻找错误。

    小 到 大 单个模块 集成模块 整个系统 找错误

    (4)穷举测试是不可能的。一个大小适度的程序,其路径排列的数量是惊人的。

    穷举测试是不可能的 适度的

    (5)为了尽可能发现错误,应由独立的第三方来测试。

    第三方来测试 独立的

    (6)在一般情况下,在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的bug, 而系统测试又能找出其余一些bug,最后剩下的bug可能只能在用户的大范围、长时间的使用后才会暴露。因此测试只能保证尽可能多地发现错误,无法保证能够发现所有的错误。

    尽早找出错误

    软件测试技术

    黑盒测试

    黑盒测试:
    黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。

    功能 数据驱动 测试 已知功能来测试检测功能正常使用

    不考虑程序内部结构 内部特性 直接根据功能来测试

    程序功能是否正常使用 接收输入数据产生正确的输出

    ​ 黑盒测试方法主要有等价类划分、边界值分析、因果图、错误推测等,主要用于软件确认测试。
    ​ “黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。

    等价类划分 边界值分析 黑盒测试 软件确认测试

    穷举输入方测试 尽可能多的输入 测试 合法的 不合法 输入

    黑盒测试试图发现以下错误类型:
    (1)功能不对或遗漏;
    (2)界面错误;
    (3)数据结构或外部数据库访问的错误;
    (4)性能错误;
    (5)初始化和终止错误.

    功能不对 遗漏 界面 数据结构 访问数据库 性能 初始化 终止

    问题:黑盒测试依据是什么?

    白盒测试

    白盒测试:

    ​ 白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能.
    ​ 白盒测试的主要方法有逻辑覆盖、基本路径测试等,主要用于软件验证。

    问题:白盒测试依据什么?

    结构 逻辑驱动 知道内部工作过程 测试来检测产品内部动作

    程序中每条通路是否按预定要求正确工作。

    逻辑覆盖 基本路径测试 用于软件验证

    白盒测试技术

    依据程序的逻辑结构-白盒测试技术

    (1)关于建立被测对象模型

    ​ 控制流程图:一种表示程序控制结构的图形工具,其基本元素是节点、判定、过程块。
    其中:过程块是既不能由判定、也不能由节点分开的一组程序语句;
    ​ 判定:是一个程序点,此处控制流可以分叉;
    ​ 节点:是一个程序点,此处控制流可以结合。
    ​ 、在这里插入图片描述

    例如:以下为一个程序流程图,其中该例子中有两个判断,
    每个判断都包含复合条件的逻辑表达式。

    在这里插入图片描述

    在这里插入图片描述

    (2)各种测试方法

    该控制流程图有4条不同的路径。4条路径可表示为:
    L1(a→c→e)简写ace 、L2(a→b→d)简写abd
    L3(a→b→e)简写abe 、L4(a→c→d)简写acd
     路径测试(PX):执行所有可能的穿过程序的控制
    流程路径。
    一般来说,这一测试严格地限制为所有可能的入口/出
    口路径。如果遵循这一规定,则我们说达到了100%路径覆盖
    率。在路径测试中,该策略是最强的,但一般是不可实现的。
    针对该例子,要想实现路径覆盖,可选择以下一组测试
    用例(规定测试用例的设计格式为:【输入的(A,B,X),
    输出的(A,B,X)】)。

    在这里插入图片描述

    语句测试(P1):至少执行程序中所有语句一次。

    如果遵循这一规定,则我们说达到了100%语句覆盖率(用C1表达)。
    在该例子中,只要设计一种能通过路径ace的测试用例,
    就覆盖了所有的语句。所以可选择测试用例如下:
    【(2,0,4),(2,0,3)】 覆盖L1
    语句覆盖是最弱的逻辑覆盖准则。

    问题:就该程序而言,如果两个判断的逻辑运算写错,

    例如,第一个判断中的逻辑运算符“∧”错写成了“∨”,或
    者第二个判断中的逻辑运算符“∨”错写成了“∧”,利用上面
    的测试用例,仍可覆盖其中2个语句,而发现不了判断中逻辑
    运算符出现的错误。

     分支测试(P2):至少执行程序中每一分支一次。如果
    遵循这一规定,则我们说达到了100%分支覆盖率(用C2表示)。
    分支覆盖是一种比语句覆盖稍强的逻辑覆盖。但若程序中
    分支的判定是由几个条件联合构成时,它未必能发现每个条件
    的错误。
    例如对于以上例子,如果选择路径L1和L2,就可得到实现
    分支覆盖的测试用例:
    【(2,0,4),(2,0,3)】 覆盖L1
    【(1,1,1),(1,1,1)】 覆盖L2
    如果选择路径L3和L4,还可得另一组可用的测试用例:
    【(2,1,1),(2,1,2)】 覆盖L3
    【(3,0,3),(3,1,1)】 覆盖L4
    问题:分支覆盖还不能保证一定能查出在判断的条件中存
    在的错误。例如,在该例子中,若第二个分支X>1错写成X<1,
    利用上述两组测试用例进行测试,无法查出这一错误。因此,
    需要更强的逻辑覆盖准则去检验判定的内部条件。

     条件组合测试
    条件组合测试是一种具有更强逻辑覆盖的测试。
    条件组合测试,就是设计足够的测试用例,使每个判定
    中的所有可能的条件取值组合至少执行一次。如果遵循这一
    规定,则我们说就实现了条件组合覆盖。只要满足了条件组
    合覆盖,就一定满足分支覆盖。
    在条件组合覆盖技术发展过程中,最初,在设计测试用
    例时,人们只考虑使分支中各个条件的所有可能结果至少出
    现一次。但发现该测试技术未必能覆盖全部分支。例如,在
    上图的例子中,程序段中有四个条件:A>1,B=0,A=2,X>1。
    条件A>1 取真值标记为T1,取假值标记为F1
    条件B=0 取真值标记为T2,取假值标记为F2
    条件A=2 取真值标记为T3,取假值标记为F3
    条件X>1 取真值标记为T4,取假值标记为F4
    在设计测试用例时,要考虑如何选择测试用例实现T1、
    F1、T2、F2、T3、F3、T4、F4的全部覆盖:

    例如,可设计如下测试用例实现条件覆盖:
    测 试 用 例 通过路径 条件取值 覆盖分支

    【(1,0,3),(1,0,4)】 L3 F1 T2 F3 T4 b,e
    【(2,1,1),(2,1,2)】 L3 T1 F2 T3 F4 b,e
    从上面的测试用例,可以看到该组测试用例虽然实现了
    判定中各条件的覆盖,但没有实现分支覆盖,因为该组测试
    用例只覆盖了第一个判断的取假分支和第二个判断的取真分
    支。为此,人们又进一步提出了条件组合覆盖技术。
    例如,在该例子中,前一个判定有4种条件组合:
    (1)(A>1),(B=0), 标记为 T1 、T2;
    (2)(A>1),(B≠0),标记为 T1 、F2,;
    (3)(A≤1),(B=0), 标记为 F1 、T2;
    (4)(A≤1),(B≠0),标记为 F1 、F2;
    后一个判定又有4种条件组合:
    (5)(A=2), (X>1), 标记为 T3、T4;
    (6)(A=2), ( X≤1),标记为 T3、F4;
    (7)(A≠2),( X>1),标记为 F3、T4;
    (8)(A≠2),( X≤1),标记为 F3、F4。

    在这里插入图片描述

    在这里插入图片描述

    黑盒测试(功能测试)-依据软件行为的描述的测试

    黑盒测试(功能测试)-依据软件行为的描述的测试

    事务流测试技术

    ( 1 )基本概念:
    事务:以用户的角度所见的一个工作单元。
    一个事务由一系列操作组成。其中某些操作可含有系统执行成分,或含有设备执行成分,它们共同协作,完成用户的一项工作。
    事务处理流程(图):系统行为的一种表示方法,为功 能测试建立了软件动作模式。其中使用了白盒测试中的一些概念,例如:操作(如下图1、3、6、5)、分支(下图2),节点(下图7),链(下图中 )等。

    在这里插入图片描述

    在这里插入图片描述

    (3)测试步骤
    第一步:获取事务流程图,即建立被测对象模型;
    第二步:浏览与复审
    主要对事务进行分类,为设计用例奠定基础;
    第三步:用例设计
    设计足够测试用例,实现基本事务覆盖。
         涉及:覆盖策略,事务选取等;
    第四步:测试设备开发:
    路径分析器,测试用例数据库,
    测试执行调度器, …
    第五步:测试执行;
    第六步:测试结果比较。

    等价类划分技术

    等价类划分技术
    (1) 基本概念
    等价类:输入域的一个子集,在该子集中,各个输入
    数据对于揭示程序中的错误都是等效的。即:以等价类中
    的某代表值进行的测试,等价于对该类中其他取值的测试。
    有效等价类:指那些对于软件的规格说明书而言,是
    合理的、有意义的输入数据所构成的集合。
    -用于实现功能和性能的测试。
    无效等价类:指那些对于软件的规格说明书而言,是
    不合理的、无意义的输入数据所构成的集合。
    -用于测试那些所实现的功能和性能不符合规格说明
    书的要求。

    (2)等价类划分原则(指南)

    在这里插入图片描述

    如果输入条件是一个布尔量,则可以确定一个有效等价
    类和一个无效等价类。
    如果输入条件规定了输入值必须符合的条件,则可以确定
    一个有效等价类(符合条件)和一个无效等价类(不符合条件)。
    例如:“标识符是一字母打头的…串。” 则
    字母打头的–为一个有效等价类,而
    其余的–为一个无效等价类

    注意:如果在已确定的等价类中各元素在软件中的处理方
    式不同,则应根据需要对等价类进一步进行划分。

    在这里插入图片描述
    ​ (3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止。

    问题:为什么设计无效等价类的测试用例时仅包括一个未被覆盖的无效等价类?

    因为某些程序中对某一输入错误的检查往往会屏蔽对其它输入错误的检查。因此设计无效等价类的测试用例时应该仅包括一个未被覆盖的无效等价类。

    边界值分析

    边界值分析
    边界值分析是一种最常用的黑盒测试技术。因为测试工作经验表明,大量的错误经常发生在输入或输出范围的边界上。因此设计一些测试用例,使程序运行在边界情况附近,这样揭露错误的可能性比较大。

    边界值分析 最常用 黑盒测试技术 大量的错误经常发生在输入或输出范围的边界上 设计一些测试用例 边界上 设计一些测试用例 揭露错误 可能性比较大

    ​ 使用边界值分析设计测试用例可遵循以下原则:
    (1)如果某个输入条件规定了输入值的范围,则应选择正好等于边界值的数据,以及刚刚超过边界值的数据作为测试数据。
    (2)如果某个输入条件规定了值的个数,则可用最大个数、最小个数、比最大个数多1、比最小个数少1的数作为测试数据。
    (3)根据规格说明的每个输出条件,使用前面的原则(1)。
    (4)根据规则说明的每个输出条件,使用前面的原则(2)。

    (5)如果程序的规格说明中,输入域或输出域是一个有序集合,在实践中,则经常选取集合的第一个元素、最后一个元素以及典型元素作为测试用例。
    (6)如果程序中使用了内部数据结构,则应选择这个内部数据结构的边界上的值作为测试用例。
    (7)分析规则说明,找出其他可能的边界条件。

    边界范围 超一点

    因果图

    因果图
    因果图:是设计测试用例的一种工具,它着重检查各种输入条件的组合。例如,两个输入值的乘积超过了存储器的限制,程序将发生错误。等价划分和边界值分析够不能发现这类错误,因为它们未考虑输入情况的各种组合。
    因果图的基本原理是通过画因果图,把用自然语言描述的功能说明转换为判定表,最后为判定表的每一列设计一个测试用例。

    输入条件的组合 各种组合

    判定表

    参考资料

    [1]-北京大学软件工程 http://www.icourses.cn/sCourse/course_6305.html

    [2] 张海藩,吕云翔. 软件工程(第4版)[M]. 北京:人民邮电出版社,2013 软件工程

  • 相关阅读:
    BZOJ1527 : [POI2005]Pun-point
    2016-2017 ACM-ICPC Southwestern European Regional Programming Contest (SWERC 2016)
    2016-2017 ACM-ICPC Northwestern European Regional Programming Contest (NWERC 2016)
    NAIPC-2016
    BZOJ2498 : Xavier is Learning to Count
    ACM ICPC Vietnam National Second Round
    XVI Open Cup named after E.V. Pankratiev. GP of Ukraine
    XVI Open Cup named after E.V. Pankratiev. GP of Peterhof
    HDU5509 : Pattern String
    BZOJ4583 : 购物
  • 原文地址:https://www.cnblogs.com/liuawen/p/11930141.html
Copyright © 2011-2022 走看看