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 正確的計算語句

這個例子或許不太恰當，合格的開發人員不會犯這種低級錯誤。但筆者想強調的是，你要意識到測試數據不充分，開始針對代碼邏輯設計測試用例。在這一過程中，你的測試方法和策略都是圍繞著待測程序的內部邏輯展開的，所以你做的是白盒測試。

請不要把測試自動化與白盒測試等同起來，它們既不是對等也不是對立的關系。