软件测试中的抽象级别系列之一-黑盒和白盒

几天前，我在微博上发布了STB-010（软件测试公益课程）注册通知. 讲座的题目是“软件测试黑盒技术和应用程序状态转换测试方法”，立即引起了一些讨论.

例如，朱少民老师指出: “人们喜欢将软件测试分为白盒方法和黑盒方法. 尽管已经建立了方法论，但对SUT的看法却完全不同. 有不同的应用场景，但是这种划分越来越不合适，例如等价类的分类，边界值分析等被归类为黑盒方法，并且可以*透明地*应用于代码测试，例如参数传递. ，内部变量等. 进行测试，是时候重新检查测试方法系统了. ”

我个人同意以上观点. 但是细微差别可以探索.

例如，“将等价类，边界值分析等分类为黑盒测试技术”和“它们在代码测试中是完全透明的”. 我不认为两者是不一致的！ “黑匣子”是一种将问题视为黑匣子的想法，忽略其内部实现的细节，并从外部考虑其行为. 换句话说，我们现在正在以更高的抽象水平看待这个问题.

这个黑匣子可能很大，例如整个被测系统；它也可能很小，例如对应一个功能. 因此，我们可以将各种黑盒测试技术应用于整个系统级别，也可以将其应用于代码级别. 实际上，“等价类划分和边界值分析”只是一些测试技术. 如何使用这些测试技术完全取决于上下文. “上下文驱动测试学校”也提倡这种观点.

许仍然认为“只要对代码进行测试，就必须引用白盒测试”. 首先让我们看一下白盒测试的一些定义.

ISTQB将白盒测试定义为“基于对组件或系统内部结构的分析而进行的测试”. 该定义认为软件测试黑盒白盒，无论是在单元测试阶段还是在系统测试阶段，只要重点放在被测试对象的内部即可. 该结构被归类为白盒测试. 例如，关心一段代码的各种测试覆盖范围（分支覆盖范围，条件覆盖范围等）属于白盒测试类别，我相信大多数人都可以理解. 但是其他情况可能不那么容易理解. 例如，在GUI测试中，测试人员检查菜单是否被正确调用（主菜单和每个层的子菜单的嵌套调用），并且不关心每个菜单的正确内容. 无论是否发生性行为，这都是白盒测试.

我个人认为，了解这种方式的白盒测试有些牵强. 菜单的调用结构是否正确，可以将其视为系统功能测试的一部分. 此时，系统也已作为黑匣子进行了测试. 如果测试人员读取分析代码以确定此菜单调用的特定实现是否正确，则可以将其分类为白盒测试. 当然，不管黑匣子和白匣子，它只是一个概念. 重要的是要弄清楚什么时候进行什么类型的测试以及应该完成什么具体的测试活动.

回到上一个问题，“只要您在代码级别进行测试，就必须引用白盒测试”？答案是否定的. 原因有两个: 如果您通过阅读代码了解SUT，那么代码只是一种学习手段，就像有时您需要阅读文档以了解被测系统一样，阅读后自然可以进行黑盒测试代码;对于任何一个功能或类，如果将其用作黑盒，并且在考虑其实现的主要功能时，使用等效类或边界值测试技术对其进行分析，那么我们自然会在进行黑盒测试.

可以看出，进行黑盒测试还是白盒测试与您是否阅读代码没有直接关系. 如果黑盒测试是将要测试的对象视为黑盒，那么白盒测试就是打开黑盒并深入测试过程的细节. 当然，由于代码包含许多实现细节，因此在基于代码进行测试时，通常会想到比基于纯需求文档的测试更多的测试点. 有人称其为黑盒和白盒之间的所谓的. 灰盒测试.

“黑盒子”和“白盒子”的抽象级别

由于“黑盒”和“白盒”属于不同的抽象级别，并且抽象分为多个层次，因此当我们讨论测试是黑盒还是白盒时，我们不能没有特定的测试，因为所谓的“黑匣子”和“白匣子”是相对的. 这就像当我们讨论“集成测试”时一样，这种“集成测试”不是“集成测试”，系统中有许多单元，模块，子系统，系统以及其他级别的接口. 讨论的两个方面必须首先阐明在什么级别上讨论了“集成测试”问题，以便讨论的结果有意义.

“黑盒子”和“白盒子”属于不同的抽象级别. 测试人员应该更关注黑盒测试，白盒测试还是两者都应给予足够的重视？

朱老师的另一篇文章: “当系统很复杂时，有必要简化问题，减少内部干扰，将系统作为一个整体（黑匣子），并了解系统的边界，接口和环境. 只有在这个时候（宏观级别（顶级），黑匣子方法才有意义. 但是，在我们无法理解系统，无法理解系统/业务结构的时代可以过去，我们应该能够彻底理解代码，数据软件测试之前的业务，业务及其结构，控制流程等是有效且充分的. ”

如果本文中的“我们”是指“测试团队”，我深表赞同. 每个测试人员是否也想吃黑盒和白盒，可以根据特定的测试环境（产品和项目的复杂程度，人员技能水平等）来确定，这属于测试项目的特定测试策略. 但是，这并不能阻止每个测试人员都将黑盒和白盒测试技术作为目标和方向.

您为什么说“黑盒和白盒测试同时完成，软件测试有效且足够？”

有一段代码可以输出0到99之间的100位数字:

　int x;
　　for(x=0; x<100; x++);
　　cout<<x;

结果，程序员很粗心，加了分号，导致实际输出只有100. 这种错误是相对常见的. 如果向我们提供了这小段代码，我们可以通过使用代码审查轻松找到此错误. 但是现在想象一下，将这段代码放入具有数百万行甚至更多行代码的系统中，并通过代码审查来发现此bug等于在大海捞针！

此外，添加多余的分号不会违反任何语法规则，并且编译器只会认为这是一个循环语句，其循环主体为空，并且不会出现错误提示.

您可能会说这很简单. 通过黑盒测试方法可以轻松找到是否运行基本功能. 但是谁能保证黑盒测试可以覆盖所有错误？毕竟，测试是无止境的，永远无法执行软件测试黑盒白盒，而遗漏的测试是不可避免的.

可以看出，单独使用白盒方法或黑盒方法并不是绝对可保的，并且由于它们的观点不同和抽象水平不同，黑盒测试和白盒中可以发现的缺陷和发现的类型测试是不同的. 缺陷的难度，发现缺陷的成本以及测试人员的技能要求是不同的. 可以有效地将两者结合使用，并相互补充，以使测试效果最佳.

结论

不必太在意“黑盒测试”和“白盒测试”的具体定义，它们只是一些有助于我们进行实际测试工作的概念（您甚至可以拥有自己的一组定义） ，一组术语）；

“黑盒子”和“白盒子”代表测试人员思考问题的方法. “黑匣子”将测试对象视为黑匣子，并考虑其总体性能； “白盒”对待每个黑盒. 打开并浏览其中的详细信息.

通常来说，“黑盒测试”和“白盒测试”属于不同的抽象级别. 黑盒更笼统，白盒更具体；

“黑盒”和“白盒”的抽象级别是相对的，系统可能具有多个抽象级别；

“黑盒测试”与“白盒测试”相结合，相辅相成，更加充分.

请参阅作者的GitHub页面以获取最新内容:

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-261280-1.html