动态黑盒测试 不深入代码细节的软件测试方法。常被称为行为测试,因为测试的是软件在使用过程中的实际行为。 首先,从产品说明书获知测试对象的软件的输入和应该得到的输出。 测试基本方法:通过测试 vs 失败测试 失败测试:纯粹为了破坏软件而设计和执行的测试案例,也称为迫使出错测试。蓄意攻击软件的薄弱环节。 选择测试案例:等价分配 等价分配:是指分步骤地把过多(无限)的测试案例减小到同样有效的小范围的过程。也称等价划分。 等价分配技术提供了一个选择哪些数值、舍弃哪些数值的系统方法。 等价类别或者等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试案例。在寻找等价区间时,想办法把软件的相似输入、输出、操作分成组。这些组就是等价区间。 数据测试 软件由数据(包括键盘输入、鼠标单击、磁盘文件、打印输出等等)和程序(可执行的流程、转换、逻辑和运算)两个最基本的要素组成。 对数据进行软件测试,就是在检查用户输入的信息、返回结果以及中间计算结果是否正确。主要根据下列原则来进行等价分配,以合理减少测试案例:边界条件、次边界条件和无效数据。 1. 边界条件测试 程序在处理大量中间数值时都是对的,但是可能在边界处出现错误。比如数组的[0]元素的处理。想要在Basic中定义一个10个元素的数组,如果使用 Dim data(10) As Integer ,则定义的是一个11个元素的数组,在赋初值时再使用 For i =1 to 10 ...来赋值,就会产生权限,因为程序忘记了处理i=0的0号元素。 数据类型:数值、字符、位置、数量、速度、地址、尺寸等,都会包含确定的边界。 根据边界来选择等价分配中包含的数据。然而,仅仅测试边界线上的数据点往往不够充分。提出边界条件时,一定要测试临近边界的合法数据,即测试最后一个可能合法的数据,以及刚超过边界的非法数据。以下例子说明一下如何考虑所有可能的边界:
-------------------------------------------------------------------------------- --------------------------------------------------------------------------------
--------------------------------------------------------------------------------
上面所讲的是普通的边界条件,在产品说明书中有定义,或者在软件的过程中确定。但有些边界在软件内部,最终用户几乎看不到,但是软件测试仍有必要检查,这样的边界条件成为次边界条件或者内部边界条件。寻找这样的边界条件,不要求软件测试员成为程序员或者具有阅读源代码的能力,但是确实要求大体了解软件的工作方式。2的乘方和ASCII表是这样的两个例子: -------------------------------------------------------------------------------- 位bit 双位doublebit 字节Byte 字word 千K 兆M 亿 万亿
在建立等价区间的时候,要考虑是否需要包含2的乘方边界条件。例如:软件接受1~1000范围内的数字,那么合法区间除了1和1000,也许还有2和999之外,还应该有临近2的乘方次边界:14,15,16以及254,255和256。
ASCII码表并不是结构良好的连续表。数字0~9对应48~57;斜杠字符(/)在0的前面,冒号(在9的后面;大写字母A~Z对应65~90;小写字母对应97~122。这些情况都代表次边界条件。 --------------------------------------------------------------------------------
3. 默认值测试(默认、空白、空值、零值和无) 好的软件会处理这种情况,常用的方法:一是将输入内容默认为合法边界内的最小值,或者合法区间内某个合理值;二是返回错误提示信息。
4. 破坏测试(非法、错误、不正确和垃圾数据) 数据测试的这一类型是失败测试的对象。这类测试没有实际规则,只是设法破坏软件。不按软件的要求行事,发挥创造力吧!
状态测试 状态测试是通过不同的状态验证程序的逻辑流程。软件测试员必须测试软件的状态及其转换。软件状态是指软件当前所处的情况或者模式。软件通过代码进入某一个流程分支,触发一些数据位,设置某些变量,读取某些变量,从而转入一个新的状态。 同数据测试一样,状态测试运用等价分配技术选择状态和分支。因为选择不完全测试,所以要承担一定的风险,但是通过合理选择减少危险。 1. 建立状态转移图 2. 减少要测试的状态及转换的数量 3. 进行具体的测试——定义测试案例 测试状态及其转换包括检查所有的状态变量——与进入和退出状态相关的静态条件、信息、值、功能等等。如:窗口外观、窗口尺寸定义(固定/上次使用时的尺寸)、显示的菜单、默认设定值、文档的名称等。状态无论是否可见,都必须进行状态确定。 状态变量也许不可见,但是很重要,一个常见的例子时文档涂改标志(以此判断退出时是否询问保存)。 失败状态测试 状态测试的失败测试的案例,主要是竞争条件、重复、压迫和重负。 1. 竞争条件和时序错乱 设计多任务操作系统不是很难,设计充分利用多任务能力的软件才是艰巨的任务。在真正的多任务环境中软件设计绝对不能想当然,必须处理随时被中断的情况,能够与其他任何软件在系统中同时运行,并且共享内存、磁盘、通信设备以及其他硬件资源。 一下是要面临竞争条件的典型情形: 2. 重复、压迫和重负 这三个测试的目标是处理那些连程序员都没有想到的恶劣条件下产生的问题的能力。 - 重复测试 重复测试是不断执行同样的操作。最简单的是不停地启动和关闭程序,或者反复读写数据或者选择同一个操作。这种测试的主要目的是看内存是否不足。如果内存被分配进行某项操作,但操作完成时没有完全释放,就会产生一个常见的软件问题。 - 压迫测试 压迫测试是使软件在不够理想的条件下运行——内存小、磁盘空间少、CPU速度慢、调制解调器速率低等等。观察软件对外部资源的要求和依赖程度。压迫测试就是将支持降到最低限度,目的在于尽可能的限制软件的必要条件。 - 重负测试 重负测试和压迫测试相反。压迫测试是尽量限制软件,而重负测试是尽量提供条件任其发挥。让软件处理尽可能大的数据文件。最大限度的发掘软件的能力,让它不堪重负。比如:软件对打印机或通信端口进行操作,就把能连的都连上;服务器可以处理几千个模拟连接,就按他说的做。 重复、压迫和重负测试应联合使用,同时进行。 需要注意的是: 其他黑盒测试方法 1. 像无经验的用户那样做 输入意想不到的数据;中途变卦而退回去执行其他操作;单击不应该单击的东西…… 2. 在已经找到软件缺陷的地方再找找 原因有二:一是软件缺陷的集中性。如果发现在不同的特性中找出了大量上边界条件软件缺陷,那么就应该对所有特性着重上边界条件。对某个存在的缺陷,应当投入一些案例来保证这个问题不是普遍存在的。二是程序员往往倾向于只修改报告出来的软件缺陷,不多也不少。比如报告启动-终止-再启动255次导致冲突,程序员可能只修复了这个问题。重新测试时,一定要重新执行同样的测试256次以上。 3. 凭借经验、直觉和预感 记录哪些技术有效,哪些不行。尝试不同的途径。如果认为有可疑之处,就要仔细探究。按照预感行事,直至证实这是错误为止。 |
|