其他分享
首页 > 其他分享> > 《软件测试》第五章 带上眼罩测试软件

《软件测试》第五章 带上眼罩测试软件

作者：互联网

《软件测试》第五章 带上眼罩测试软件

5.0 前言

本章重点包括：

5.1 动态黑盒测试：带上眼罩测试软件

不深入代码细节测试软件的方法称为动态黑盒测试。它是动态的，因为程序在运行——软件测试员像用户一样使用它；同时，它是黑盒，因为测试时不知道程序如何工作——带上了眼罩。测试员输入数据、接受输出、检验结果。动态黑盒测试常常被称为行为测试，因为测试的是软件在使用过程中的实际行为。

有效的动态测试需要关于软件行为的一些定义——需求文档或者产品说明书。不必了解软件“盒子”内发生的事情——而只需要知道输入A输出B或执行操作C得到结果D。好的产品说明书会提供这些细节信息。

清楚了被测试软件的输入和输出之后，接下来要开始定义测试用例。测试用例是指进行测试时使用的特定输入，以及测试软件的步骤。

选择测试用例是软件测试员最重要的一项任务。不正确的选择可能导致测试量过大或者过小，甚至测试目标不对。准确评估风险，把无穷尽的可能性减少到可以控制的范围是成功的诀窍。

在没有产品说明书时使用探索测试

尽管这对于软件测试员不是理想的状况，但是此时可以采取称为探索测试的解决方案——了解软件、设计测试、执行测试同时进行。
这需要把软件当作产品说明书来对待。系统地逐项了解软件的功能，记录软件的执行情况，详细描述功能，运用《软件测试》第四章 检查产品说明书中所讲的静态黑盒技术，把软件当成说明书来分析，然后运用本章所讲的动态黑盒技术进行测试。
在这种情况下，无法像有产品说明书那样完整测试软件——比如无法断定是否遗漏功能，但是可以系统地测试软件，找到软件缺陷几乎是肯定的。

5.2 通过性测试和失效性测试

测试软件有两种基本方法：通过性测试和失效性测试。在进行通过性测试时，实际上是确认软件至少能做什么，而不会考验其能力。软件测试员并不需要想尽办法让软件崩溃，仅仅运用最简单、最直观的测试用例即可。

既然软件测试的目标是找出软件缺陷，为什么还要进行通过性测试呢？为什么不尽量去设法找出软件缺陷呢？不，开始不是这样的。

设想一种类似的情况，即一辆新设计的汽车，如果受命测试刚下生产线从没开过的一辆汽车，测试者可能不会立即坐上去，发动汽车，驶入检测道路，尽全力高速行进。这样可能会撞车，发生生命危险。作为新车，在正常驾驶条件下低速行驶时可能会暴露所有的缺陷。也许轮胎尺寸不对，或者制动力不足，或者发动机噪声过大。在上路冲击极限速度之前是可以发现并解决这些问题的。
在这里插入图片描述

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

确信软件在普通情况下能正确运行之后，就可以采取各种手段搞垮软件来找出软件缺陷了。纯粹为了破坏软件而设计和执行的测试用例称为失效性测试或错误强制测试。失效性测试通常不会突然出现，它蓄意攻击软件的薄弱环节。

5.3 等价类划分

等价类划分是指分步骤地把海量（无限）的测试用例集缩减得很小，但过程同样有效。

一个等价类或者等价划分是指测试相同目标或者暴露相同软件缺陷的一组测试用例。
在寻找等价划分时，考虑把软件中具有相似输入、相似输出、相似操作的分在一组。这些组就是等价划分。

请记住，等价类划分的目标是把可能的测试用例集缩减到可控制且仍然足以测试软件的小范围内。因为选择了不完全测试，就要冒一定的风险，所以选择分类时必须仔细。如果为了减少测试用例的数量过度划分等价类，就有漏掉那些可能暴露软件缺陷的测试的风险。 对于初涉软件测试者，一定要请经验丰富的测试员审查划分好的等价类。

5.4 数据测试

对软件最简单的认识就是将其分成两部分：数据（或其范围）和程序。数据包括键盘输入、鼠标单击、磁盘文件、打印输出等。程序是指可执行的流程、转换、逻辑和运算。软件测试常用的一个方法是把测试工作按同样的形式划分。

对数据进行软件测试，就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。使所有数据得以测试的技巧是：根据一些关键的原则进行等价类划分，以合理减少测试用例，这些关键的原则是：边界条件、次边界条件、空值和无效数据。

5.4.1 边界条件

边界条件是特殊情况，因为程编程从根本上说在边界上容易产生问题。如果软件能够在其边界运行，那么在正常情况下就应该不会有什么问题。

5.4.1.1 边界条件类型

边界条件是指软件运行在计划操作界限的边界的情况。每一个软件测试问题各不相同，可能包含各种不同的数据及其独特的边界。

如果要选择在等价划分中包含哪些数据，就根据边界来选择。

5.4.1.2 测试边界

由于软件容易在边界上产生缺陷，因此，如果要从等价划分中选择包含的数据，从边界条件中选择会找出更多的软件缺陷。然而，仅仅测试边界线上的数据点往往不够充分。如果建立两个等价划分就可以找出更多软件缺陷，第一个软件划分应该包含认为正确的数据——在边界内部最后一两个合法的数据点，第二个划分包含认为可能出现错误的数据——边界之外——一到两个非法的数据点。

提出边界条件时，一定要测试靠近边界的有效数据，即测试最后一个可能有效的数据，同时测试刚超过边界的无效数据。

越界测试的做法通常是简单地对于最大值加1或者很小的数，以及对于最小值减1或者很小的数。

注意：缓冲区溢出是由边界条件缺陷引起的，它是造成软件安全问题的头号原因。

5.4.2 次边界条件

有些边界在软件内部，最终用户几乎看不见，但是软件测试员仍有必要进行检查。这样的边界条件称为次边界条件或者内部边界条件。

5.4.2.1 2的幂

在这里插入图片描述
上表所列的范围和值是作为边界条件的重要数据。除非软件向用户表示出同样的范围，否则在需求文档中不会明确指明。

在建立等价划分时，要考虑等价划分中是否需要包含2的幂的边界条件。
例如，如果软件接受用户输入1~1000范围内的数字，谁都知道在合法区间中包含1和1000，也许还要有2和999。为了覆盖任何可能的2的幂的次边界，还要包含靠近4位边界的14、15和16，以及靠近字节边界的254/255和256。

5.4.2.2 ASCII表

0~9的ASCII值时48~57。斜杠字符（/）在数字0的前面，而冒号字符（：）在数字9的后面。大写字母A~Z对应的ASCII值是65~90。小写字母a~z对应的ASCII值是97~122。这些情况都代表次边界条件。

如果测试进行文本输入或文本转换的软件，在定义数据划分包含哪些值时，参考一下ASCII表时相当明智的。例如，如果测试的文本框只接受用户输入字符A~Z和a~z，就应该在非法划分中包含ASCII表中这些字符前后的值——@、[、’ 和 {。

5.4.3 默认、空白、空值、零值和无

另一种看起来很明显的软件缺陷来源是当软件要求输入时——比如在文本框中——不是没有输入正确的信息，而是根本没有输入任何内容，可能仅仅是按了Enter键。这种情况在产品说明书中常常被忽视，程序员也经常遗忘，但是在实际使用中却时有发生。

好的软件会处理这种情况。它通常将输入内容默认为边界内的最小合法值，或者在合法划分中间的某个合理值，或者返回错误提示信息。

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

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

数据测试的最后一种类型是垃圾数据。这是失效性测试的对象。经过边界测试、次边界测试和默认值测试等通过性测试证实软件能够工作之后，就该进行垃圾数据测试了。

非法、错误、不正确和垃圾数据测试是很有意思的。如果软件要求输入数字，就输入字母；如果软件只接受正数，就输入负数；如果软件对日期敏感，就看它在公元3000年是否还能正常工作；假装有“肥胖的手指”，同时按下多个键。

此类测试没有实际的规则，只是设法破坏软件。要发挥创造力，要会走偏门。

5.5 状态测试

到目前为止，我们测试的是数据——数字、文字、软件输入和输出。软件测试的另一方面是通过不同的状态验证程序的逻辑流程。软件状态是指软件当前所处的条件或者模式。软件测试员必须测试程序的状态及其转换。

5.5.1 测试软件的逻辑流程

对于软件测试，解决方法是运用等价划分技术选择状态和分支。

  1. 建立状态转换图

状态转换图可能作为产品说明的一部分给出。如果是这样，则可以进行静态测试。否则，就需要创建一个状态图。

绘制状态转换图有几种技术，绘图使用的技术并不重要，只要项目小组其他成员可以看懂就行了。状态转换图可能会变得非常庞大，如果预计状态图会如此复杂，那么就找一些商业软件来绘制和管理。

状态转换图应该表示出以下项目：

  • 软件可能进入的每一种独立状态。这里有一个很好的经验是，如果不能断定是否为独立状态，它就可能是。如果以后发现它不是，随时可以将其剔除。
  • 从一种状态转入另一种状态所需的输入和条件。可能是按键、菜单选择、传感器信号或者电话振铃等。状态不可能无缘无故地存在，其原因正是我们在这里要寻找的。
  • 进入或者退出某种状态时的设置条件及输出结果。包括显示的菜单和按钮、设置的标志位、产生的打印输出、执行的运算等。这些是状态转换时发生的部分或全部现象。

注意：因为正在进行黑盒测试，所有不必了解代码中设置的底层变量。从软件用户的角度建立状态图即可。

在这里插入图片描述

  1. 减少要测试的状态及转换的数量

有以下5种实现方法：

  • 每种状态至少访问一次。如果到达的没有关系，但是每一种状态都必须测试。
  • 测试看起来是最常见和最普遍的状态转换。尽管听起来很主观，但是其依据是进行产品说明书的静态黑盒分析时收集到的信息。某些用户情况很可能比其他更常见。希望这样能管用。
    -测试状态之间最不常用的分支。这些分支是最容易被产品设计者和程序员忽视的。软件测试员也许是第一个测试它们的人。
  • 测试所有错误状态及其返回值。出错条件通常难以建立。程序员常常编写代码处理某些错误，但不会测试自己的代码。错误没有得到正确处理、错误提示信息不正确、修复错误时未正确恢复软件等情况常有发生。
  • 测试随机状态转换。如果打印了状态图，就可以在上面任意做各种标记。如果有时间做得更多，执行状态随机转换测试。
  1. 怎样进行具体测试

确定要测试的状态及其转换之后，就可以定义测试用例了。测试状态及其转换包括检查所有的状态变量——与进入和退出状态相关的静态条件、信息、值、功能等。

与项目小组的产品说明书作者和程序员讨论对状态及其转换的假定是个好主意。他们可以提供软件测试员可能想不到的、表面现象背后的状态内幕。

5.5.2 失败状态测试

以上探讨的状态测试都属于通过性测试，测试包括审查软件、描绘状态、尝试各种合法可能性、确认状态及其转换正常。和数据测试一样，相反的做法是找到使测试软件失败的案例。此类案例的例子是竞争条件、重复、压迫和重负。

  1. 竞争条件和时序错乱

当今大多数操作系统，无论是用于个人计算机还是专用设备，都具备多任务执行能力。多任务是指操作系统设计用来同时执行多个独立的进程。这些进程可以是电子表格或者电子邮件这样的独立程序，也可以是同一个程序中的不同部分。

设计多任务操作系统并不繁琐，设计充分利用多任务的软件才是艰巨的任务。在真正的多任务环境中，软件设计绝对不能想当然，必须处理随时被中断的情况，能够与其他任何软件在系统中同时运行，并且共享内存、磁盘、通信以及其他硬件资源。

这一切的结果就是可能导致竞争条件问题。这些问题是指几个事件恰巧挤在一起，由于软件未预料到运行过程会被中断，以致造成混乱。也就是说，时序发生错乱。竞争条件测试难以设计，最好是首先仔细查看状态转换图中的每一个状态，以找出哪些外部影响会中断该状态。考虑要使用的数据没有准备好，或者在用到时发生了变化，状态会怎样。数条弧线或者直线同时相连的情形如何？

以下是可能会面临竞争条件的例子情形：

  • 两个不同的程序同时保存和打开同一个文档。
  • 共享同一台打印机、通信端口或者其他外围设备。
  • 当软件处于读取或者改变状态时按键或者单击鼠标。
  • 同时关闭或者启动软件的多个实例。
  • 同时使用不同的程序访问一个共同的数据库。
  1. 重复、压迫和重负
    这些测试的目标是处理那些程序员没考虑到但在极端恶劣条件下可能发生问题的状态。

重复测试是不断执行同样的操作。最简单的是不停的启动、关闭程序。还可以反复读写数据或者反复选择同一个操作。进行重复测试的主要原因是检查是否存在内存泄漏。

压迫测试是使软件在不够理想的条件下运行——内存小、磁盘空间少、CPU速度慢、调制调解器速率低等。观察软件对外部资源的要求和依赖的程度。压迫测试就是将支持降到最低限度，目的在于尽可能地限制软件的必要条件。

重负测试与压迫测试相反。压迫测试是尽量限制软件，而重负测试是尽量提供条件任其发挥，让软件处理尽可能大的数据文件。如果软件对打印机或者通信端口之类的外设进行操作，就把能连的都连上。如果正在测试的因特网服务器可以处理几千个并发连接，就按它说的做。最大限度地发掘软件的能力，让它不堪重负。

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

注意：

5.6 其他黑盒测试技术

如果对整个程序数据进行了完整的等价划分，创建了详细的状态图，并且开发完成了相关的测试用例，就会发现大多数能由用户发现的软件缺陷。剩下的是找出缺陷中的漏网之鱼的技术。加入这些软件缺陷是有生命的，就应该有自己的思想和行为方式。要找出它们也许有一点主观，没有实实在在的理由根据，但是如果要找出所有的软件缺陷，就必须得有一点创造力。

5.6.1 像笨拙的用户那样做

在设计测试用例或者初次查看软件时，要设法像笨拙的用户那样想问题。抛开关于软件应该如何工作的先入为主。如果可能，找一个其他专业的朋友来整理思路。假设他什么也不会，把这些测试用例加入已经设计好的测试用例库中，就会更加全面。

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

5.6.3 像黑客一样考虑问题

没有软件是100%安全的。黑客知道这一点，会寻找软件的漏洞并利用这些漏洞。作为测试员，需要从另外的角度考虑问题。想想软件里面有哪些有价值的东西，为什么有人想要获得其访问权限，黑客进入的方法有哪些。不要太绅士，黑客不会绅士。

5.6.4 凭借经验、直觉和预感

标签：状态,5.4,测试软件,边界条件,测试,软件,软件测试,眼罩
来源： https://blog.csdn.net/qq_45580956/article/details/118068857