f2c网站建设,全国互联网安全管理服务平台官网,缩短链接的网站,网络营销策划书5000字一、软件测试基本分类
一般地#xff0c;我们将软件测试活动分为以下几类#xff1a;黑盒测试、白盒测试、静态测试、动态测试、手动测试、自动测试等等。
黑盒测试
黑盒测试又叫功能测试、数据驱动测试或给予需求规格说明书的功能测试。这种测试注重于测试软件的功能性需…一、软件测试基本分类
一般地我们将软件测试活动分为以下几类黑盒测试、白盒测试、静态测试、动态测试、手动测试、自动测试等等。
黑盒测试
黑盒测试又叫功能测试、数据驱动测试或给予需求规格说明书的功能测试。这种测试注重于测试软件的功能性需求。
采用这种测试方法测试工程师把测试对象看作一个黑盒子不需要考虑程序内部的逻辑结构和特性只需要依据程序的需求规格说明书检查程序的功能是否符合它的功能说明。黑盒测试能更好更真实的从用户角度来考察被测系统的功能性需求实现情况。在软件测试的各个阶段如单元测试、集成测试、系统测试及确认测试等阶段都发挥着重要作用。尤其在系统测试和确认测试中其作用是其他测试方法无法取代的。
白盒测试
白盒测试又称结构测试、逻辑驱动测试或基于程序代码内部结构的测试。此时需要深入考察程序代码的内部结构、逻辑设计等等。白盒测试需要测试工程师具备很深的软件开发工地精通相应的开发语言一般的软件测试工程师难以胜任该工作。
静态测试
静态测试顾名思义就是静态的、不执行被测对象程序代码而寻找缺陷的过程。通俗地讲静态测试就是用眼睛看阅读程序代码文档资料等与需求规格说明书中的需求进行比较找出程序代码中设计的不合理以及文档资料中的错误。
在进行代码的静态测试时可以采用一些代码走查的工具如 QA C、C Test等。
动态测试
动态测试即为实际的执行被测对象的程序代码输入事先设计好的测试用例检查程序代码运行的结果与测试用例中设计的预期结果之间是否差异判定实际结果与预期结果是否一致从而检验程序的正确性、可靠性和有效性并分析系统运行效率和健壮性等性能状况。
动态测试由四部分组成设计测试用例、执行测试用例、分析比较输出结果、输出测试报告。
动态测试结合使用白盒测试和黑盒测试。
二、测试方法
对于白盒测试常用的测试方法有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖等等。黑盒测试较为知名的测试方法有等价类划分、边界值分析、因果图分析、错误猜测等。本章将对这些测试方法进行一些简单的介绍。
1.白盒测试
白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构源代码 的程度。如完全的白盒测试是将程序中每条路径都执行到然而对一个带有循环的程序来说完全的路径测试并不切合实际。
图 2‑1被测试的小程序
1测试方法
如果完全从路径测试中跳出来看那么有价值的目标似乎就是将程序中的每条语句至少执行一次。遗憾的是这恰是合理的白盒测试中较弱的准则。图2‑1描述了这种思想。假设图2‑1 代表了一个将要进行测试的小程序其等价的代码段如下
Public void foo(int a, int b, int x)
{
if (a 1 b 0)
{
x x/ a;
}
if (a 2 || x 1)
{
X x 1;
}
}
通过编写单个的测试用例遍历程序路径 ace可以执行到每一条语句。也就是说通过在点 a 处设置 A2B0X3每条语句将被执行一次实际上X 可被赋任何值。
遗憾的是这个准则相当不足。举例来说也许第一个判断应是“或”而不是 “与” 。 如果这样 这个错误就会发现不到。另外 可能第二个判断应该写成 “X0” 这个错误也不会被发现。还有程序中存在一条 X 未发生改变的路径路径 abd如果这是个错误它也不会被发现。换句话说语句覆盖这条准则有很大的不足以至于它通常没有什么用处。
2判定分支覆盖
判定覆盖或分支覆盖是较强一些的逻辑覆盖准则。该准则要求必须编写足够的测试用例使得每一个判断都至少有一个为“真”和为“假”的输出结果。换句话说也就是每条分支路径都必须至少遍历一次。分支或判定语句的例子包括switchdo-while 和 if-else 语句。
判定覆盖通常可以满足语句覆盖。由于每条语句都是在要么从分支语句开始要么从程序入口点开始的某条子路径上如果每条分支路径都被执行到了那么每条语句也应该被执行到了。但是仍然有些例外情况
• 程序中不存在判断。
• 程序或子程序/方法有着多重入口点。只有从程序的特定入口点进入时某条特定的语句才能执行到。
我们的探讨仅针对有两个选择的判断或分支当程序中包含有多重选择的判断时判定/分支覆盖准则的定义就必须有所改变。典型的例子有包含select(case)语句的 Java 程序包含算术 三重选择 IF 语句、计算或算术 GOTO 语句的 FORTRAN 程序以及包含可选 GOTO 语句或 GO-TO-DEFENDING-ON 语句的 COBOL 程序。对于这些程序判定/分支覆盖准则将所有判断的每个可能结果都至少执行一次以及将程序或子程序的每个入口点都至少执行一次。
在图2‑1 中两个涵盖了路径 ace 和 abd或涵盖了路径 acd 和 abe 的测试用例就可以满足判定覆盖的要求。如果我们选择了后一种情况两个测试用例的输入是 A3B0X3 和 A2B1X1。
判定覆盖是一种比语句覆盖更强的准则但仍然相当不足。举例来说我们仅有 50%的可能性遍历到那条 X 未发生变化的路径也即 仅当我们选择前一种情况 。
如果第二个判断存在错误例如把 X1 写成了 X1那么前面例子中的两个测试用例都无法找出这个错误。
3条件覆盖
比判定覆盖更强一些的准则是条件覆盖。在条件覆盖情况下要编写足够的测试用例以确保将一个判断中的每个条件的所有可能的结果至少执行一次。因为就如同判定覆盖的情况一样这并不总是能让每条语句都执行到因此作为对这条准则的补充就是对程序或子程序。举例来说分支语句
DO K0 to 50 WHILE (JKQUEST)
包含两种情况K 是否小于或等干 50以及 JK 是否小于 QUEST? 因此需要针对K 50、 K 50 达到循环的最后一次迭代以及JKQUEST、 JKQUEST的情况设计测试用例。
图 2‑1 有四个条件A1、B0、A2 以及 X1。因此需要足够的测试用例使得在点 a 处出现 A2、A2、X1 及 X1 的情况。有足够数量的测试用例满足此准则用例及其遍历的路径如下所示
1A2B0X4 ace
2A1B1X1 adb
请注意尽管在本例中生成的测试用例数量是一样的但条件覆盖通常还是要比判定覆盖更强一些。因为条件覆盖可能但并不总是这样会使判断中的各个条件都取到两个结果“真”和“假” 而判定覆盖却做不到这一点。举例来说在相同的分支语句
DO K0 to 50 WHILE(JKQUEST)
中存在一个两重分支执行循环体或者跳过循环体 。如果使用的是判定覆盖测试将循环从 K 0 执行到 K 51 即可满足该准则但从未考虑到 WHILE子句为假的情况。如果使用的是条件覆盖准则就需要设计一个测试用例为JKQUEST 产生一个为假的结果。
虽然条件覆盖准则乍看上去似乎满足判定覆盖准则但并不总是如此。如果正在测试判断条件 IF (AB)条件覆盖准则将要求编写两个测试用例A为真B为假A 为假B 为真。但是这并不能使 IF 语句中的 THEN 被执行到。对图2‑1 所示例子所进行的条件覆盖测试涵盖了全部判断结果但这仅仅是偶然情况。举例来说两个可选的测试用例
1 A2B0X3
2 A1B1X1
涵盖了全部的条件结果却仅涵盖了四个判断结果中的两个这两个测试用例都涵盖到了路径 abe因而不会执行第一个判断结果为真的路径以及第二个判断结果为假的路径 。
4判定/条件覆盖
显然解决上面左右为难局面的办法就是所谓的判定/条件覆盖准则。这种准则要求设计出充足的测试用例。将一个判断中的每个条件的所有可能的结果至少执行一次将每个判断的每个条件的所有可能的结果至少执行一次将每个判断的所有可能的结果至少执行一次将每个入口点都至少调用一次。
判定/条件覆盖准则的一个缺点是尽管看上去所有条件的所有结果似乎都执行到了但由于有些特定的条件会屏蔽掉其他的条件常常并不能全部都执行到。请参见图2‑2来观察此种情况。图2‑2 中的流程图描述的是编译器将图2‑1中的程序编译生成机器代码的过程。源程序中的多重条件判断被分解成单个的判断和分支因为大多数的机器都没有能执行多重条件判断的单独指令。那么更为完全的测试覆盖似乎是将每个基本判断的全部可能的结果都执行到而前两个判定覆盖的测试用例都做不到这点它们未能执行到判断 I 中的结果为 “假”的分支 以及判断 K 中结果为“真”的分支。
图 2‑2 图 2‑1中程序的机器码
如图2‑2所示其中的原因是“与”和“或”表达式中某些条件的结果可能会屏蔽掉或阻碍其他条件的判断。举例来说如果“与”表达式中有个条件为“假”那么就无须计算该表达式中的后续条件。 同样 如果 “或”表达式中有个条件为 “真” 那么后续条件也无须计算。因此条件覆盖或判定/条件覆盖谁都不一定会发现逻辑表达式中的错误。
5多重条件覆盖
所谓的多重条件覆盖准则能够部分解决这个问题。该准则要求编写足够多的测试用例将每个判定中的所有可能的条件结果的组合以及所有的入口点都至少执行一次。举例来说考虑下面的伪代码程序
NOTFOUNDTRUE;
DO I1 TO TABSIZE WHILE (NOTFOUND); /*SEARCHTABLE*/
……searching logic……;
END
要测试四种情况
1. ITABSIZE并且 NOTFOUND 为真
2. ITABSIZE并且 NOTFOUND 为假在到达表格尾部前查询指定条目
3. ITABSIZE并且 NOTFOUND 为真查询了整个表格未找到指定条目
4. ITABSIZE并且 NOTFOUND 为假指定条目位于表格的最后位置 。
很容易发现满足多重条件覆盖准则的测试用例集同样满足判定覆盖准则、条件覆盖准则以及判定/条件覆盖准则。
再次回到图2‑1中测试用例必须覆盖以下 8 种组合
1. A 1 B 0
2. A 1 B ! 0
3. A 1B 0
4. A 1, B ! 0
5. A 2 X 1
6. A 2 X 1
7. A ! 2 X 1
8. A ! 2 X 1
注意第 5 至8 组合表示了第二个 if 语句的值。由于 X可能在该 if 语句之前发生了改变因此这个 if 语所需的值必需对程序逻辑进行回溯以找到相对应的输入值要测试的这 8 种组合并不一定意味着需要设计出 8 个测试用例。实际上用 4 个测试用例就可以覆盖它们。下面是这些测试用例的输入以及它们覆盖的组合
A3B0X4 覆盖组合 15
A2B1X1 覆盖组合 26
A1B0X2 覆盖组合 37
A1B1X1 覆盖组合 48
图 2‑1的程序存在 4 条不同的路径需要 4 个测试用例这样的情况纯属巧合。事实上这 4 个用例也没有覆盖到每条路径路径 acd 就被遗漏掉了。
举例来说对于如下所示的判断语句尽管它只包舍两条路径仍可能需要 8个测试用例
if (xy length(z)0 FLAG)
{
j1
}
Else
{
i1;
}
在存在循环的情况下多重条件覆盖准则所需要的测试用例的数量通常会远远小于其路径的数量。
总的来说对于包含每个判断只存在一种条件的程序最简单的测试准则就是设计出足够数量的测试用例实现1将每个判断的所有结果都至少执行一次2将所有的程序入口都至少调用一次以确保全部的语句都至少执行一次。而对于包含多重条件判断的程序最简单的测试准则是设计出足够数量的测试用例将每个判断的所有可能的条件结果的组合以及所有的入口点都至少执行一次加入“可能”二字是因为有些组合情况难以生成。
6路径覆盖
在以上测试用例中我们发现漏掉了路径acd。路径覆盖则要求覆盖程序所有可能的路径路径覆盖需要对所有可能的路径进行测试包括循环、条件组合、分支选择等。那么需要设计大量、复杂的测试用例使得工作量呈指数级增长。而在有些情况下一些执行路径是不可能被执行的。
从这个简单的例子可以看出要想充分测试一个程序是很困难的。同时测试条件越强测试的代价越高。测试时应分主次在测试代价和测试充分性之间做出平衡。
2.黑盒测试 1等价划分
一个好的测试用例描述为具有相当高的可能性发现某个错误来此外对程序的穷举输入测试是无法实现的。因此当测试某个程序时我们就被限制在从所有可能的输入中努力找出某个小的子集。理所当然我们要找的子集必须是正确的并且是可能发现最多错误的子集。确定这个子集的一种方法就是要意识到一个精心挑选的测试用例还应具备另外两个特性
1. 严格控制测试用例的增加减少为达到“合理测试”的某些既定目标而必须设计的其他测试用例的数量。
2. 它覆盖了大部分其他可能的测试用例。也就是说它会告诉我们使用或不使用这个特定的输入集合哪些错误会被发现哪些会被遗漏掉。
虽然这两个特性看起来很相似但描述的却是截然不同的两种思想。第一个特性意味着每个测试用例都必须体现尽可能多的不同的输入情况以使最大限度地减少测试所需的全部用例的数量。而第二个特性意味着应该尽量将程序输入范围进行划分将其划分为有限数量的等价类这样就可以合理地假设但是显然不能绝对肯定测试每个等价类的代表性数据等同于测试该类的其他任何数据。也就是说如果等价类的某个测试用例发现了某个错误该等价类的其他用例也应该能发现同样的错误。相反如果测试用例没能发现错误那么我们可以预计该等价类中的其他测试用例不会出现在其他等价类中因为等价类是相互交迭的。
这两种思想形成了称为等价划分的黑盒测试方法。第二种思想可以用来设计一个“令人感兴趣的”输入条件集合以供测试而第一个思想可以随后用来设计涵盖这些状态的一个最小测试用例集。
使用等价划分方法设计测试用例主要有两个步骤1确定等价类 2生成测试用例。
表2‑1等价类列举表 输入条件 有效等价类 无效等价类
1确定等价类
确定等价类是选取每一个输入条件通常是规格说明中的一个句子或短语并将其划分为两个或更多的组。可以使用表2‑1中的表格来进行划分。注意我们确定了两类等价类有效等价类代表对程序的有效输入而无效等价类代表的则是其他任何可能的输入条件即不正确的输入值。这样我们遵循了测试原则即要注意无效和未预料到的输入情况。
在给定了输入或外部条件之后确定等价类大体上是一个启发式的过程。下面给出了一些指导原则
1. 如果输入条件规定了一个取值范围例如“数量可以是从1到999”)那么就应确定出一个有效等价类 1数量999 ) 以及两个无效等价类 数量1数量999 。 输入条件 有效等价类 无效等价类 取值范围 1数量999 数量1数量999
2. 如果输入条件规定了取值的个数例如“汽车可登记一至六名车主”)那么就应确定出一个有效等价类和两个无效等价类没有车主或车主多于六个。 输入条件 有效等价类 无效等价类 取值个数 1至六名车主 没有车主车主多于六个
3. 如果输入条件规定了一个输入值的集合而且有理由认为程序会对每个值进行不同处理例如“交通工具的类型必须是公共汽车、卡车、出租车、火车或摩托车” 那么就应为每个输入值确定一个有效等价类和一个无效等价类例如“拖车” 。 输入条件 有效等价类 无效等价类 输入值集合 公共汽车卡车出租车火车摩托车 拖车
4. 如果存在输入条件规定了“必须是”的情况例如“标识符的第一个字符必须是字母”,那么就应确定一个有效等价类首字符是字母和一个无效等价类首字符不是字母 。 输入条件 有效等价类 无效等价类 第一个字符 首字符是字母 首字符不是字母
如果有任何理由可以认为程序并未等同地处理等价类中的元素那么应该将这个等价类再划分为小一些的等价类。
2生成测试用例
第二步是使用等价类来生成测试用例我们以上述第一个例子来说明其过程如下
1. 为每个等价类设置一个不同的编号。
2. 编写新的测试用例尽可能多地覆盖那些尚未被涵盖的有效等价类直到所有的有效等价类都被测试用例所覆盖包含进去。
3. 编写新的用例覆盖一个且仅一个尚未被覆盖的无效等价类直到所有的无效等价类都被测试用例所覆盖。
用单个测试用例覆盖无效等价类是因为某些特定的输入错误检查可能会屏蔽或取代其他输入错误检查。举例来说如果规格说明规定了“请输入书籍类型硬皮、软皮或活页及数量l999 )”代表两个错误输入书籍类型错误数量错误的测试用例“XYZ 0”很可能不会执行对数量的检查因为程序也许会提示“XYZ 是未知的书籍类型”就不检查输入的其余部分了。
这里将上述的第4个例子进行一下扩展然后进行示范说明如何用等价类划分的思想来设计测试用例
规定标识符的第一个字符必须是字母标识符只能使用字母、数字和下划线。
第一步划分等价类为每一个等价类编号。 输入条件 有效等价类 无效等价类 第一个字符 首字符是字母1 首字符不是字母2 字符限制 仅使用字母、数字和下划线3 使用了其他字符4
第二步设计测试用例覆盖所有有效等价类用尽可能少的用例覆盖最多的有效等价类。
测试用例Test_1 覆盖13
第三步设计测试用例覆盖所有无效等价类。每新增一个测试用例只覆盖一个无效等价类。
测试用例123test 覆盖2
测试用例Test# 覆盖4 边界值分析
经验证明考虑了边界条件的测试用例与其他没有考虑边界条件的测试用例相比具有更高的测试回报率。所谓边界条件是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。边界值分析方法与等价划分方法存在两方面的不同
1. 与从等价类中挑选出任意一个元素作为代表不同边界值分析需要选择一个或多个元素以便等价类的每个边界都经过一次测试。
比如要求输入职工年龄规定输入为18 – 45。根据等价类划分思想一个有效等价类18 年龄 45 两个无效等价类年龄18 和 年龄45。这样选取 10 30 50即可满足覆盖。但是等价类的思想没有从边界值方面来分析问题从边界值角度分析我们就会再添加17、18、19 、44、45、46这样的边界值。
2. 与仅仅关注输入条件输入空间不同还需要考虑从结果空间输出等价类设计测试用例。
比如ATM机取款手续费为取款额%1最低2元最高50元。从输出等价类来考虑边界值就要设计用例来测试手续费会不会低于2元会不会高于50元。
很难提供一份如何进行边界值分析的“详细说明’因为这种方法需要一定程度的创造性以及对问题采取一定程度的特殊处理办法因此就像测试的许多其他方面一样这更多的是项智力工作并非其他的什么。
因果图
边界值分析和等价划分的一个弱点是未对输入条件的组合进行分析。边界值测试不一定能检查出此类错误。
对输入组合进行测试并不是简单的事情因为即使对输入条件进行了等价划分这些组合的数量也是个天文数字。如果在选择输入条件的子集时没有采用一个系统的方法很可能选择出一个任意的输入条件子集 这样会使测试没有什么成效。
因果图有助于用一个系统的方法选择出高效的测试用例集。它还有一个额外的好处就是可以指出规格说明的不完整性和不明确之处。
这里不对因果图这种方法进行详细介绍有兴趣的同事可以查阅《软件测试的艺术》相关章节。
错误猜测
常常可以看到这种情况有些人似乎天生就是测试的能手。这些人没有用到任何特殊的方法比如对因果图进行边界值分析却似乎有着发现错误的诀窍。
对此的一个解释是这些人更多是在下意识中实践着一种称为错误猜测的测试用例设计技术。接到具体的程序之后他们利用直觉和经验猜测出错的可能类型然后编写测试用例来暴露这些错误。
由于错误猜测主要是一项依赖于直觉的非正规的过程因此很难描述出这种方法的规程。其基本思想是列举出可能犯的错误或错误易发情况的清单然后依据清单来编写测试用例。例如程序的输入中出现 0 这个值就是一种错误易发情况。因此可以编写测试用例检查特定的输入值中有 0或特定的输出值被强制为 0 的情况。同样 在出现输入或输出的数量不定的地方 如某个被搜索列表的条目数量。数量为“没有”和“一个” 例如空列表仅包含一个条目的列表也是错误易发情况。另一个思想是在阅读规格说明时联系程序员可能做的假设来确定测试用例即规格说明中的一些内容会被忽略要么是由于偶然因素要么是程序员认为其显而易见。
最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走 这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你
