软件测试（黑盒/白盒测试/集成测试）

白盒测试

覆盖语句

该程序模块有四条不同的路径：

P1(a-c-e) P2(a-c-f) P3(a-b-e) P4(a-b-f)

基本逻辑判定条件有：

x>3, z5

判定M = x > 3 and z 5

一共有八种条件出现的情况：

(1) x > 3为真 (2) x == 3为假

(3) z

(5) x == 4为真 (6) x 4 为假

(7) y > 5 为真 (8) y == 5 为假

条件 / 判定覆盖

判定覆盖

条件组合覆盖

控制流图

绘图

控制流图的结构有：

分析一下这个图是如何得出来的：

• 首先我们画一下入口，对于基本的没有判断的语句（如第3，4行）可以写在一起替换掉入口，即(3,4)作为一个圈
• 走到第5行，遇到while判断条件，放下一个判断块
• 进入循环，走到第7行的 if 判断，有第8、10行这两种结果
• 结束当前循环体，走入第11行，然后回到第5行进行判断，如果跳出循环，就进入12 行
• 最后结束的出口块也需要画出

例子二

代码段为：

环路复杂度：

一共有9个点，11条边，所以环路复杂度为 11 – 9 + 2 = 4

黑盒测试

边界值分析法

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，其测试用例来自等价类的边界。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。下面介绍几种情况：

• 假设一个文本输入区域内允许输入 1 到 255 个字符，则，输入1个和255个字符作为有效等价类，然后，输入0个和256个字符作为无效等价类，这几个值都属于边界条件值
• 假设文本输入框要求输入5位数据值，则10000作为最小值，99999作为最大值，然后，输入9999和100000作为恰好超出边界的值

决策表法（判定表法）

决策表能够将各种复杂情况都列举出来，不会产生遗漏，因此，使用决策表设计出的测试用例是完整的测试用例集合，它们非常适合描述在不同条件集下采取许多行动组合的情况

决策表的组成

决策表通常由四部分组成：条件桩，动作桩，条件项，动作项

• 条件桩：列出问题的所有条件
• 动作桩：列出问题规定所采取的操作
• 条件项：针对条件桩给出的条件，列出所有可能情况下的真假值
• 动作项：列出在条件项的各种取值情况下应该采取的动作
• 规则：任何一个条件组合的特定取值即相应要执行的操作成为一条规则，决策表中一列就是一条规则

黑盒测试例题

接下来用一道例题来补充说明：

快递收费标准

快递按公斤计算超过1公斤按2公斤算，超过2公斤就按3公斤算以此类推。（每个产品的重量在产品的详情里面都有标注）

江浙沪首重10元续重1.5元，

北京，安徽，福建，广东，广西，贵州，海南，河北，河南，黑龙江，湖北，湖南，江西，辽宁，宁夏，山东，山西，陕西，四川，天津，云南，重庆首重18元续重15元，

甘肃，吉林，内蒙古，青海，西藏，新疆首重25元续重22元。

首重是指1公斤以内，续重是每增加一公斤

f(x,y)=

自下而上

从应用程序的最低或最里面的单位开始，逐渐向上移动。集成测试从最低模块开始，逐步向应用程序的上层模块发展。这种集成一直持续到所有模块都集成在一起，整个应用程序作为一个单元进行测试。

在这种情况下，模块B1C1，B1C2，B2C1，B2C2是经过单元测试的最低模块。模块B1和B2尚未开发。模块B1和B2的功能是调用模块B1C1，B1C2，B2C1，B2C2。由于B1和B2还没有开发，我们需要一些程序或“刺激器”来调用B1C1，B1C2和B2C1，B2C2模块。这些刺激计划称为驱动程序。

简单来说，**DRIVERS（驱动模块）**是虚拟程序，用于在调用函数不存在的情况下调用最低模块的函数。自底向上技术要求模块驱动程序将测试用例输入提供给被测模块的接口。

优点：

• 如果在程序的最低单元存在重大故障，则更容易检测到它，并且可以采取纠正措施
• 可以实施多个模块的并行测试，提高了测试效率
• 模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块

缺点：

• 在最后一个模块被集成和测试之前，主程序实际上不存在。因此，只会在最后检测到更高级别的设计缺陷
• 对驱动程序的需求让测试管理变得很复杂

举个例子，现在给出一个自底向上的集成测试示例：

现在测试D1对应的M2，以及D3对应的M4（因为D2对应的M1依赖的M2和M4模块还没有测试，所以此时不测试M1）

自上而下

该技术从最顶层的模块开始，以深度优先或者是广度优先，逐渐向较低的模块发展，向系统中增加模块。只有顶层模块是单独进行单元测试的。在此之后，下层模块逐个集成。重复该过程，直到所有模块都被集成和测试。

在我们的图中，测试从模块A开始，下层模块B1和B2逐个集成。现在，较低的模块B1和B2实际上不可用于集成。因此，为了测试最顶层的模块A，我们开发了“ STUBS（桩模块）”。

“Stubs”可以称为代码片段，它接受来自顶层模块的输入/请求并返回结果/响应。这样，尽管模块较低，但是不存在，我们能够测试顶层模块。

优点：

• 较早地验证了主要的控制和判断点，可以首先实现和验证一个完整的软件功能
• 在早期发现顶层的错误
• 早期的程序框架可以进?演?

缺点：

• 创建Stubs像真实模块一样复杂和耗时。在某些情况下，Stub模块可能会比受激模块更大
• 需要开发桩模块辅助测试。有些甚?需要多个桩模块辅助，加?了桩模块本来的错误影响

举个例子，现在给出一个程序模块化设计示意图：

以M1-M2-M5这条路径为例进行深度遍历，现在测试M2，构建S5，S6的stubs模块

4. 测试M6，没有后续模块

5. 测试M4，构建S7的stubs模块

广度优先

以广度优先进行测试：

这里就不步骤介绍了，整体来说，首先测试M1，然后构建S2，S3，S4的stubs模块；然后测试M2->构建，测试M3->构建，测试M4->构建…具体的思路和广度优先算法一样：

• 软件测试是验证软件产品特性是否满足用户的需求

• 软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性或能力，井确定其是否达到了预期结果

• 测试是不能穷尽的

• 测试就是为了发现缺陷，而不是证明程序无错误

• 一个成功的测试是发现了软件问题的测试，否则测试就没有价值。这就如同一个病人(因为是病人，假定确实有病)，到医院去做相应的检查，结果没有发现问题，那说明这次体检是失败的，浪费了病人的时间和金钱。以逆向思维方式引导人们证明软件是“不工作的”，会促进我们不断思考开发人员对需求理解的误区、不良的习惯、程序代码的边界、无效数据的输入等，找到系统的薄弱环节或识别出系统复杂的区域，目标就是发现系统中各种各样的问题

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！