软件测试笔记(五)- 动态黑盒测试

了解在没有代码的情况甚至不懂得编程的情况下的软件测试技术。

一、动态黑盒测试:戴上眼罩测试软件

不深入代码细节测试软件的方法称为 动态黑盒测试 。它是动态的,因为程序在运行——软件测试员像用户一样使用它。同时,它是黑盒子,因为测试时不知道程序如何工作——带上了眼罩。动态黑盒测试常常被称为 行为测试 ,因为测试的是软件在使用过程中的实际行为。

  1. 有效的动态测试需要关于软件行为的一些定义——即需求文档或者产品说明书。
  2. 清楚了被测试软件的输入和输出之后,开始定义测试用例。准确评估风险,把无穷尽的可能性减少到可以控制的范围是成功的诀窍。
  3. 测试用例(testing cases) :是指进行测试时使用特定输入,以及测试软件的过程步骤。
  4. 在没有产品说明书时使用 探索测试 :了解软件、设计测试、执行测试同时进行。把软件产品当作产品说明书来对待。系统地逐项了解软件的功能、记录软件的执行情况、详细描述功能。

二、通过性测试和失效性测试

  1. 通过性测试(test-to-pass) :在通过性测试中,实际上是确认软件至少能做什么,而不会考验其能力。测试包括审查软件、描述状态、尝试各种合法可能性、确认状态及其转换正常。
  2. 失效性测试(test-to-fail) :纯粹为了破坏软件而设计和执行的测试用例,或者又叫错误强制性测试。蓄意攻击软件最薄弱环节。

注意:在设计和执行测试用例时,总是首先进行通过性测试。在破坏性测试之前看看软件基本功能是否实现很重要,软件测试员可能会吃惊的发现仅仅正常使用软件就会发现那么多软件缺陷。

三、等价类划分

选择测试用例的方法是 等价类划分(equivalence partition) ,或者称为 等价分类(equivalence classing) :分步骤地把海量(无限)的测试用例集间的很小,但过程同样有效。

注意:

  1. 一个等价类或者等价分类是指测试相同目标或者暴露相同软件缺陷的一组测试用例。
  2. 在寻找等价划分是,考虑把软件具有相似输入、相似输出、相似操作的分一组。
  3. 等价划分的目标是把可能的测试用例集缩减到可控制且仍然足以测试软件的小范围内。因为选择了不完全测试,就要冒一定的风险,所以在选择分类时必须仔细。

四、数据测试

对软件最简单的认识就是将其分成两部分:数据(或其范围)和程序。

  1. 数据(data) :键盘输入、鼠标单击、磁盘文件、打印输出等。
  2. 程序(program) :是指可执行的流程、转换、逻辑和运算。

技巧:对数据进行软件测试,就是在检查用户输入的信息,返回的结果以及中间计算结果是否正确。可以根据一些关键的原则进行等价划分,以合理减少测试用例。

  • 边界条件

如果对一定范围的数据惊醒操作,程序员往往在处理大量中间数值时都是对的,但是可能在边界处出现错误。

边界条件(boundary condition) :是指软件在运行在计划操作界限的边界的情况。

  1. 边界条件类型,考虑以下数据类型:
    数值
    速度
    字符
    地点
    位置
    尺寸
    数量

    同时,考虑这些类型的下述特征:
    开始/完成
    超过/在内
    空/满
    相邻/最远

技巧:如果选择在等价划分中包含哪些数据,就根据边界来选择。

  1. 测试边界
  • 为软件操作的各种数据集合建立等价划分,从等价划分中心选择包含的数据,从边界条件中选择会找出更多的软件缺陷。
  • 建立两个等价划分就可以找出更多的软件缺陷。第一个划分包含认为应该正确的数据——在边界内部最后一两个合法的数据点。第二个区间包含认为可能出现错误的数据——边界之外——一到两个非法的数据点。

技巧:提出边界条件时,一定要测试临近边界的有效数据,测试最后一个可能有效的数据,同时测试刚超过边界的无效数据。

注意:缓冲区溢出(buffer overrun) :是由边界条件缺陷引起的,它是指造成软件安全问题的头号原因。

  • 次边界条件

有些边界在软件内部,最终用户几乎看不到,但是软件测试仍然很有必要。这样的边界条件叫做 次边界条件(sub-boundary condition) 或者 内部边界条件(internal boundary condition)

技巧:寻找这样的边界不要求软件测试员称为程序员或者具有阅读源代码的能力,但是确实要求大体了解软件的工作方式。所以,软件测试员应该和开发小组的程序员交流,看看他们能否对其他应该测试的次边界条件提供建议。

  1. 2的幂:
    计算机和软件的基础时二进制数——用位(bit)来表示0和1,一个字节(byte)有8位组成,(在32位系统上)一个字(words)由4个字节组成。
  2. ASCII表:
    / :47
    0 ~ 9 :48 ~ 57
    :58
    @:64
    A ~ Z :65~ 90
    [ :91
    ’ :96
    a ~ z :97 ~ 122
    { :123
  • 默认、空白、空值、零值和无

技巧:一定要考虑建立默认值、空白、空值、零值或者无输入等条件的等价划分。因为这些值在软件中通常进行不同的处理,所以,不要把它们和合法情况和非法情况混在一起,而要建立单独的等价划分。

  • 非法、错误、不正确和垃圾数据

数据测试的最后一种类型是垃圾数据。这是失效行测试的对象。

在经过边界测试、次边界测试、默认值测试等通过性测试证实软件可以工作之后,就该进行垃圾数据测试了。在现实中,考虑到软件要应付用户千奇百怪的使用方式,对软件进行破坏实验肯定没错。

五、状态测试

  1. 软件状态(Software state) :是指软件当前所处的条件或者模式。

一旦选中了其中使软件改变了外观、菜单或者某些操作,就是改变了该软件的状态。软件通过代码执行进入某个分支,出发某些数据位,设置某些变量,读取某些数据,转入一个新的状态。

  • 测试软件的逻辑流程

软件的日益复杂化,尤其是为了迎合日益丰富的用户界面,提供太多的选择和选项,致使程序分支数量呈指数式增长。

对于软件测试,解决方法是运用等价划分技术选择状态和分支。因为选择不做完全测试,所以要承担一定的风险,但是通过合理选择减少风险。

  1. 建立状态转换图
    状态状态转换图应该表示出以下项目:
    (1)软件可能进入的每一种独立状态。
    (2)从一种状态转入另一种状态所需的输入和条件。
    (3)进入或者推出某种状态时的设置条件及输出结果。

  2. 减少要测试的状态及转换的数量
    将大量的可能性减少到可以操作的测试用例集合,有以下5种方式:
    (1)每种状态至少访问一次。
    (2)测试看起来时最常见和最普遍的状态转换。
    (3)测试状态之间最不常用的分支。
    (4)测试所有错误状态及其返回值。
    (5)测试随即状态转换。

  3. 进行具体测试
    测试状态及其转换包括检查所有的 状态变量(state variables) ——与进入和退出状态相关的静态条件、信息、值、功能等。
    技巧:把对状态及其转换的假定与项目小组的产品说明书作者和程序员讨论是个好主意。他们可以提供软件测试员可能想不到的、表面现象背后的状态内幕。

  • 失败状态的测试

找到使测试软件失败的案例:竞争条件、重复、压迫和重负。

  1. 竞争条件和时序错乱。
    (1)多任务(multitasking) :是指操作系统设计用来同时执行多个独立的进程。
    (2)设计多任务操作系统并不繁琐,设计充分利用多任务的软件才是艰巨的任务。在真正的多任务环境中,软件设计绝不能想当然,必须处理随时被中断的清理,能够与其他任何软件在操作系统中同时运行,并且共享内存、磁盘、通信以及其他硬件资源。
    (3)竞争条件(race condition)问题 :是指几个事件恰巧挤在一起,由于软件未预料到运行过程会被中断,一致造成混乱,也就是说,时序发生错乱。

  2. 重复、压迫和重负。
    (1)反复测试(repetition testing) :是不断执行同样的操作。最简单的是不停地启动、关闭程序。
    目的:检查是否存在***内存泄漏(memory leaks)*** ,如果计算机内存被分配进行某些操作,但是操作完成时,欸有完全释放,就会产生一个常见的软件问题。
    (2)压迫测试(stress testing) :是使软件在不够理想的条件下运行——内存小、磁盘空间小、CPU速度慢、调制调节器速率低等。观察软件对外部资源的要求和依赖的程度。
    目的:尽可能地压制软件地必要条件。
    (3)重负测试(load testing) :与压迫测试相反。压迫测试是尽量限制软件,而重负测试时尽量提供条件任其发挥。让软件处理尽可能大地数据文件。
    目的:最大限度地发掘软件地能力,让他不堪重负。

注意:重复、压迫和重负测试应该联合使用,同时进行。这是找出以其他方式难以发现的严重缺陷的一个可靠的方法。

对于重复、压迫、重负测试有两个重要事项:

  1. 项目经理和小组程序员可能不完全接受软件测试员这样破坏软件的做法。软件测试员的任务时确保软件在这样恶劣的条件下仍能正常工作,否则就报告软件缺陷。
  2. 无数次打开和关闭程序对于手工操作时不可能的。

六、其他黑盒测试技术

  • 像无经验的用户那样做
  1. 无经验的用户(inexperienced user) 或者 新用户(new user) :这些用户不遵循任何规则,也不做任何假定。

技巧:如果可能,找一个其他专业的朋友来整理思路。假设他什么也不会。把这些测试用例加入到已经设计好的测试用例库中。就会更加全面。

  • 在已经找的软件缺陷的地方再找找

在已经找到软件缺陷的地方再找的原因:

  1. ”找到的软件缺陷越多,就说明哪里的软件缺陷越多“。
  2. 许多程序员倾向于只修复报告出来的软件缺陷,不多不少。在这个范围之外极有可能存在其他可能的内存泄漏问题。
  • 像黑客一样考虑问题

想一想软件里面有哪些有价值的东西,为什么有人要像获得其访问权限,黑客进入的方法有哪些。不要绅士,黑客不会绅士。

  • 凭借经验、直觉和预感

随着在职业生涯中逐步提高,学习测试不同类型和规模的软件产品,就会得到各种提示和技巧以便更有效地找出令人棘手的软件缺陷。

参考文献

  1. 《软件测试(原书第2版)》
  2. 《软件测试的艺术(原书第3 版)》

你可能感兴趣的:(软件测试基础)