| 动态黑盒测试 不深入代码细节的软件测试方法。常被称为行为测试，因为测试的是软件在使用过程中的实际行为。 首先，从产品说明书获知测试对象的软件的输入和应该得到的输出。 接下来，开始定义测试案例。 测试案例：指进行实验用的输入，以及测试软件用的程序。 选择测试案例是软件测试员最重要的任务。不正确的选择可能导致测试量过大或者过小，甚至测试目标不对。准确评估风险，把不可穷近的可能性减少到可以控制的范围是成功的诀窍。 测试基本方法：通过测试 vs 失败测试 通过测试：确认软件至少能做什么，而不考验其能力。 失败测试：纯粹为了破坏软件而设计和执行的测试案例，也称为迫使出错测试。蓄意攻击软件的薄弱环节。 在设计和执行测试案例时，总是首先进行通过测试。在破坏性试验之前看看软件基本功能是否实现是很重要的，否则在正常使用软件时就会奇怪为什么有那么多的软件缺陷。 常见的测试案例就是设法迫使软件出现错误提示信息。产品说明书可能会给出这样的功能要求，针对这个问题的测试可能是通过测试也可能是失败测试。可能两者都是。不用去刻意区分，重要的是找到软件缺陷！ 选择测试案例：等价分配 等价分配：是指分步骤地把过多（无限）的测试案例减小到同样有效的小范围的过程。也称等价划分。 等价分配技术提供了一个选择哪些数值、舍弃哪些数值的系统方法。 等价类别或者等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试案例。在寻找等价区间时，想办法把软件的相似输入、输出、操作分成组。这些组就是等价区间。 等价分配的目的是把可能的测试案例组合缩减到仍然足以测试软件的控制范围。因为选择了不完全测试，就要冒一定的风险。如果为了减少测试案例的数量过度进行等价分配，测试的风险就会增加。另外，等价区间的划分没有一定的标准，只要足以覆盖测试对象就行了。 数据测试 软件由数据（包括键盘输入、鼠标单击、磁盘文件、打印输出等等）和程序（可执行的流程、转换、逻辑和运算）两个最基本的要素组成。 对数据进行软件测试，就是在检查用户输入的信息、返回结果以及中间计算结果是否正确。主要根据下列原则来进行等价分配，以合理减少测试案例：边界条件、次边界条件和无效数据。 1. 边界条件测试 程序在处理大量中间数值时都是对的，但是可能在边界处出现错误。比如数组的[0]元素的处理。想要在Basic中定义一个10个元素的数组，如果使用 Dim data(10) As Integer ，则定义的是一个11个元素的数组，在赋初值时再使用 For i =1 to 10 ...来赋值，就会产生权限，因为程序忘记了处理i＝0的0号元素。 边界条件是指软件计划的操作界限所在的边缘条件。 数据类型：数值、字符、位置、数量、速度、地址、尺寸等，都会包含确定的边界。 应考虑的特征：第一个/最后一个、开始/完成、空/满、最慢/最快、相邻/最远、最小值/最大值、超过/在内、最短/最长、最早/最迟、最高/最低。这些都是可能出现的边界条件。 根据边界来选择等价分配中包含的数据。然而，仅仅测试边界线上的数据点往往不够充分。提出边界条件时，一定要测试临近边界的合法数据，即测试最后一个可能合法的数据，以及刚超过边界的非法数据。以下例子说明一下如何考虑所有可能的边界： -------------------------------------------------------------------------------- 如果文本输入域允许输入1－255个字符。 尝试：输入1个字符和255个字符（合法区间），也可以加入254个字符作为合法测试。 输入0个字符和256个字符作为非法区间。 -------------------------------------------------------------------------------- 如果程序读写软盘 尝试：保存一个尺寸极小，甚至只有一项的文件。 然后保存一个很大的——刚好在软盘容量限制之内的文件。 保存空文件。 保存尺寸大于软盘容量的文件。 -------------------------------------------------------------------------------- 如果程序允许在一张纸上打印多个页面 尝试：只打印一页 打印允许的最多页面 打印0页 多于所允许的页面（如果可能的话） -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- 2. 次边界条件测试 上面所讲的是普通的边界条件，在产品说明书中有定义，或者在软件的过程中确定。但有些边界在软件内部，最终用户几乎看不到，但是软件测试仍有必要检查，这样的边界条件成为次边界条件或者内部边界条件。寻找这样的边界条件，不要求软件测试员成为程序员或者具有阅读源代码的能力，但是确实要求大体了解软件的工作方式。2的乘方和ASCII表是这样的两个例子： -------------------------------------------------------------------------------- 2的乘方 术语 范围或值 位bit 0或1 双位doublebit 0～15 字节Byte 0~255 字word 0~65,535或者0～4,294,967,295 千K 1,024 兆M 1,048,576 亿 1,073,741,824 万亿 1,099,511,627,776 计算机和软件的基础是二进制数。因此二的乘方是作为边界条件的重要数据。如：在通讯软件中，带宽或者传输信息的能力总是受限制，因此软件工程师会尽一切努力在通讯字符串中压缩更多数据。其中一个方法就是把信息压缩到尽可能小的单元中，发送这些小单元中最常用的信息，在必要时再扩展为大一些的单元。假设某种通讯协议支持256条命令。软件将发送编码为一个双位数据的最常用的15条命令；如果用到第16到256之间的命令，软件就转而发送编码为更长字节的命令。这样，软件就会根据双位/字节边界执行专门的计算和不同的操作。 在建立等价区间的时候，要考虑是否需要包含2的乘方边界条件。例如：软件接受1～1000范围内的数字，那么合法区间除了1和1000，也许还有2和999之外，还应该有临近2的乘方次边界：14，15，16以及254，255和256。 -------------------------------------------------------------------------------- ASCII表 ASCII码表并不是结构良好的连续表。数字0～9对应48～57；斜杠字符(/)在0的前面，冒号(  在9的后面；大写字母A～Z对应65～90；小写字母对应97～122。这些情况都代表次边界条件。如果测试进行文本输入或文本转换的软件，在定义数据区间包含哪些值时，参考一下ASCII表是相当明智的。例如：测试的文本框只接受用户输入字符A～Z和a～z，就应该在非法区间中包含ASCII表中这些字符前后的值——@，'，[，{。 -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- 3. 默认值测试（默认、空白、空值、零值和无） 好的软件会处理这种情况，常用的方法：一是将输入内容默认为合法边界内的最小值，或者合法区间内某个合理值；二是返回错误提示信息。 这些值在软件中通常需要进行特殊处理。因此应当建立单独的等价区间。在这种默认下，如果用户输入0或－1作为非法值，就可以执行不同的软件处理过程。 -------------------------------------------------------------------------------- 4. 破坏测试（非法、错误、不正确和垃圾数据） 数据测试的这一类型是失败测试的对象。这类测试没有实际规则，只是设法破坏软件。不按软件的要求行事，发挥创造力吧！ -------------------------------------------------------------------------------- 状态测试 状态测试是通过不同的状态验证程序的逻辑流程。软件测试员必须测试软件的状态及其转换。软件状态是指软件当前所处的情况或者模式。软件通过代码进入某一个流程分支，触发一些数据位，设置某些变量，读取某些变量，从而转入一个新的状态。 同数据测试一样，状态测试运用等价分配技术选择状态和分支。因为选择不完全测试，所以要承担一定的风险，但是通过合理选择减少危险。 1. 建立状态转移图 使用：方框和箭头；圆圈（泡泡）和箭头。 应包含的项目： － 软件可能进入的每一种独立状态。 如果不能断定是否独立，先认为是；以后一旦发现不是，随时剔除。 － 从一种状态转入另一种状态所需的输入和条件。 状态变化和存在的原因，就是我们要寻找的对象。 － 进入或退出某种状态时的设置条件及输出结果。 包括显示的菜单和按钮、设置的标志位、产生的打印输出、执行的运算等等。 由于是黑盒测试，因而只需从用户的角度建立状态图即可。 2. 减少要测试的状态及转换的数量 测试每一种路线的组合，走遍所有分支是不可能的事情。大量的可能性也需要减少到可以操作的测试案例集合。方法有以下5种： － 每种状态至少访问一次。 无论用什么方法，每种状态都必须测试。 － 测试看起来最常见最普遍的状态转换 － 测试状态之间最不常用的分支。 这些分支是最容易被产品设计者和程序员忽视的。 － 测试所有错误状态机器返回值。 错误是否得到正确的处理、错误提示信息是否正确、修复错误时是否正确恢复软件等 － 测试随机状态转换。 3. 进行具体的测试——定义测试案例 测试状态及其转换包括检查所有的状态变量——与进入和退出状态相关的静态条件、信息、值、功能等等。如：窗口外观、窗口尺寸定义（固定/上次使用时的尺寸）、显示的菜单、默认设定值、文档的名称等。状态无论是否可见，都必须进行状态确定。 状态变量也许不可见，但是很重要，一个常见的例子时文档涂改标志（以此判断退出时是否询问保存）。 失败状态测试 状态测试的失败测试的案例，主要是竞争条件、重复、压迫和重负。 1. 竞争条件和时序错乱 设计多任务操作系统不是很难，设计充分利用多任务能力的软件才是艰巨的任务。在真正的多任务环境中软件设计绝对不能想当然，必须处理随时被中断的情况，能够与其他任何软件在系统中同时运行，并且共享内存、磁盘、通信设备以及其他硬件资源。 这样的结果，就是导致竞争条件问题；软件未预料到的中断发生，时序就会发生错乱。 竞争条件测试难以设计，最好是首先仔细查看状态转换图中的每一个状态，以找出哪些外部影响会中断该状态。考虑要使用数据如果没有准备好，或者在用到时发生了变化，状态会怎样。数条弧线或者直线同时相连的情形如何。 一下是要面临竞争条件的典型情形： － 两个不同的程序同时保存或打开同一个文档。 － 共享同一台打印机、通信端口或者其他外围设备。 － 当软件处于读取或者修改状态时按键或者单击鼠标。 － 同时关闭或者启动软件的多个实例。 － 同时使用不同的程序方位一个共同数据库。 2. 重复、压迫和重负 这三个测试的目标是处理那些连程序员都没有想到的恶劣条件下产生的问题的能力。 － 重复测试 重复测试是不断执行同样的操作。最简单的是不停地启动和关闭程序，或者反复读写数据或者选择同一个操作。这种测试的主要目的是看内存是否不足。如果内存被分配进行某项操作，但操作完成时没有完全释放，就会产生一个常见的软件问题。 － 压迫测试 压迫测试是使软件在不够理想的条件下运行——内存小、磁盘空间少、CPU速度慢、调制解调器速率低等等。观察软件对外部资源的要求和依赖程度。压迫测试就是将支持降到最低限度，目的在于尽可能的限制软件的必要条件。 － 重负测试 重负测试和压迫测试相反。压迫测试是尽量限制软件，而重负测试是尽量提供条件任其发挥。让软件处理尽可能大的数据文件。最大限度的发掘软件的能力，让它不堪重负。比如：软件对打印机或通信端口进行操作，就把能连的都连上；服务器可以处理几千个模拟连接，就按他说的做。 不要忘了，时间也是一种重负测试。 重复、压迫和重负测试应联合使用，同时进行。 需要注意的是： 一，项目管理员和小组程序员可能不完全接受软件测试员这样打破软件的做法。但是软件测试员的任务就是确保软件在这样恶劣的条件下正常工作，否则就报告软件缺陷。如何以最佳方式报告软件缺陷，使其得到严肃对待和修复，也是一门学问。 二，无数次重复和上千次的连接对于手工操作是不可能的。因而需要借助自动化测试工具来实现。 其他黑盒测试方法 1. 像无经验的用户那样做 输入意想不到的数据；中途变卦而退回去执行其他操作；单击不应该单击的东西…… 2. 在已经找到软件缺陷的地方再找找 原因有二：一是软件缺陷的集中性。如果发现在不同的特性中找出了大量上边界条件软件缺陷，那么就应该对所有特性着重上边界条件。对某个存在的缺陷，应当投入一些案例来保证这个问题不是普遍存在的。二是程序员往往倾向于只修改报告出来的软件缺陷，不多也不少。比如报告启动－终止－再启动255次导致冲突，程序员可能只修复了这个问题。重新测试时，一定要重新执行同样的测试256次以上。 3. 凭借经验、直觉和预感 记录哪些技术有效，哪些不行。尝试不同的途径。如果认为有可疑之处，就要仔细探究。按照预感行事，直至证实这是错误为止。 经验是人们对错误行为的称谓。 |
来源：https://www.cnblogs.com/bukudekong/archive/2011/08/10/2134201.html