1.2 自动化并不等同于白盒测试

网上有不少介绍白盒测试，分享白盒测试工具的文章。阅读之后会发现，那些并不是白盒测试范畴的内容，只是某种黑盒测试的自动化工具用到了一些编程技术罢了。当大量这类文章充斥着我们的视野，不少测试同行会心生疑惑：自动化就是白盒测试吗？

让我们先通过维基百科上的介绍来梳理一下“黑盒测试”与“白盒测试”的概念。

“黑盒测试，软件测试的主要方法之一，也可以称为功能测试、数据驱动测试或基于规格说明的测试。测试者不了解程序的内部情况，不需具备应用程序的代码、内部结构和编程语言的专门知识，只知道程序的输入、输出和系统的功能，这是从用户的角度针对软件界面、功能及外部结构进行测试，而不考虑程序内部逻辑结构。测试案例是依应用系统应该实现的功能，照规范、规格或要求等设计的。测试者选择有效输入和无效输入来验证是否正确地输出。此测试方法适用于大部分的软件测试，如集成测试（integration testing）和系统测试（system testing）。”

“白盒测试（white-box testing）又称透明盒测试（glass box testing）、结构测试（structural testing）、逻辑驱动测试或基于程序本身的测试等，软件测试的主要方法之一。测试应用程序的内部结构或运作，而不是测试应用程序的功能（即黑盒测试）。在进行白盒测试时，以编程语言的角度来设计测试案例。测试者输入数据，验证数据流在程序中的流动路径，并确定适当的输出，类似测试电路中的节点。测试者了解待测试程序的内部结构、算法等信息，这是从程序设计者的角度对程序进行的测试。”

通过上述内容可以看出，自动化测试与白盒测试没有必然联系，它们是不同维度的概念。是否是白盒测试，要看在设计测试用例、准备测试数据的过程中，是否考虑了待测程序的代码实现逻辑。如果仅凭待测程序的输入输出进行测试，不关心程序的实现细节，那就是黑盒测试，与你选择了哪种自动化测试工具，使用了哪种框架进行测试一点关系也没有。

举个例子，不少购物应用在最后结算时都会根据当前优惠活动对订单自动减价。这是一个很常见的功能，买了100元钱，活动优惠了20元，最后付款80元。对于这种金额计算的测试，你或许不用了解开发程序的实现细节，脑子里就已经浮现出N个测试用例了。整数金额、浮点型金额、正常值、等价类、边界值、优惠金额比订单金额大、正交表、并发测试，你的想法越来越多。按照这种思路整理出多个测试场景，把不同的输入值和期望结果整理为测试用例。为了提高下一个版本的测试效率，你写了脚本，不再需要通过手动配置应用的后台金额来进行测试，你的脚本也对期望结果做了充足的验证。于是，测试脚本把你从手动执行的烦琐工作中解脱出来，之后的回归测试还因此发现了几个Bugs。

当你看着测试脚本，满怀成就感，嘴角微微上扬的时候，你应该意识到，这只是做了黑盒测试自动化。无论你的测试脚本写得多优雅，此时的待测程序对你而言，还是一个黑盒子，测试的出发点并没有考虑“盒子”的内部结构。

你不满足现有的测试用例，开始研究开发代码，试图了解中间数据的存储、计算方式。发现页面上显示的金额是浮点型，单位是“元”，数据库中存储了整型，单位是“分”。Python代码大概是这样的：

    #original_price页面上显示的原订单金额
    #discount数据库中存储可优惠的金额
    original_price_db =original_price*100
    final_price = original_price_db - discount
    print(final_price)

是不是很简单？但如果你有浮点型数据的处理经验，你会看出其中的猫腻。

让我们针对上述逻辑整理出两个用例，做一个小实验，如表1-1所示。

表1-1 两个用例说明

再把上述代码写到test.py文件中，观察脚本执行的结果。如图1-1所示，当金额为69.10元时，若订单金额全免，则最终订单价格不是零。正确做法应该如图1-2所示。

图1-1 错误的计算语句

图1-2 正确的计算语句

这个例子或许不太恰当，合格的开发人员不会犯这种低级错误。但笔者想强调的是，你要意识到测试数据不充分，开始针对代码逻辑设计测试用例。在这一过程中，你的测试方法和策略都是围绕着待测程序的内部逻辑展开的，所以你做的是白盒测试。

请不要把测试自动化与白盒测试等同起来，它们既不是对等也不是对立的关系。