如何對數據進行測試？

　　前兩天在阿里技術嘉年華上分享了一個有關《報表類型的數據測試》的話題，發現很多人的遇到了我之前測試時候遇到的問題，我相信我們之前走過的彎路，以及最后的解決方案和經驗，就可以幫助大家構建出更好的數據測試用例。

　　所以我決定寫一系列關于數據測試的文章，幫助大家避免我們曾經遇到過的問題，建立起強壯的自動化測試用例。

　　這系列文章不是：

　　1. 我們不針對敏捷測試，不專門講持續集成等戰略上的概念，戰略上講，這些東西很重要，但是依然要落在每一個強壯和易維護的自動化測試用例上。

　　2. 我們不推薦框架，更多的講思想和做法。因為我們在開始做這些工作之前，并沒有在市面上找到合適的解決我們問題的框架，所以我們只能從頭開始。好處是可以從很基本的方面理解我們的思想，壞處是沒有現成可用的工具。不過不用擔心，我們非常樂意把自己的框架開源出來，但是要整理一下。

　　3. 我們不講UI的測試，因為我們的數據測試會更加專注于數據，如果你要測試UI上的數據，那么請先學習UI自動化測試框架，把這些數據獲取好。

　　這系列文章會：

　　1. 用我們實際中的例子對數據測試進行系統的講解。如果你可以從我的例子中找到平時工作的影子，那么你一定會有所收獲。

　　2. 文章中不僅僅會涉及數據測試方面的內容，為了講明白我為什么這么設計框架，我可能還會提及其他自動化測試方面的東西，略嫌啰嗦請海涵。

　　那么言歸正傳，什么是數據測試呢?

　　數據測試不是一種測試方法，而是一種針對特定的被測對象所采取的一系列方法，提高這些被測對象測試效率的方法。

　　我定義我們的被測對象是：一切以數據計算和變化為過程的，可以以只對數據進行對比來測試的系統。

　　我和你一樣討厭晦澀的定義，我以幾個例子來解釋：

　　1. 我們團隊的最著名產品：量子恒道店鋪統計，整體來說，因為有很多UI方面的測試，這些測試很多地方不能單靠數據來驗證，所以整體來說量子店鋪統計不是數據測試的被測對象;但是我們拆開來看，量子恒道的所有后臺計算，都是數據測試的被測對象，因為他們從數據開始，經過計算，生成的都是數據。

　　2. 一個負責在網絡集群之間傳遞消息的消息中間件，不是數據測試的被測對象。他們雖然輸入是數據，輸出依然是數據，也可能進行了數據的計算，但是測試重點在于網絡的可用和穩定，數據測試不是我們的測試重點，所以不是。

　　3. Hadoop, hive, storm等平臺本身不是我們的被測試對象，但是基于這些平臺寫的應用，全部可以是數據測試的被測試對象。

　　4. 某網站的OpenAPI，可以是數據測試對象，因為用戶都是從http請求請求數據，經過數據庫，然后通過http響應返回相應的數據。

　　5. 一個MVC架構的網站，除掉V之后的部分是嗎?大部分情況，是的，但是如果這個網站的M和C層組成的是一套完整的增刪改查業務體系的話，我并不推薦數據測試的方法，原因見文章：《用白盒的思想黑盒的測試》

　　6. 某銀行的數據庫搬遷服務，是數據測試對象。

　　總之一句話，當測試人員的關注點在于數據是否正確，而不是其他流程、UI、性能等地方的時候，那么你就需要數據測試了。

　　不知道你有沒有找到自己工作中的數據被測對象呢?

　　如果已經讀了上一篇文章《深入探究數據測試之一：數據測試概論》，相信大家已經對數據測試有了更加詳細的理解，也有可能找到了現實測試中的具體例子。

　　我們第一步要做的事情，是封裝你的無關操作。而這一步的基礎，就是設計自動化測試用例。

　　什么是無關操作?無關操作是和期望操作正好相反的一個概念。

　　測試人員的期望操作，就是要寫在自動化測試用例里面的代碼的最理想狀況。所以無關操作就是你不想寫在自動化測試用例里面的代碼。拿下面這個測試來舉例：

　　第一個例子：假設我們要測試一個hive腳本：(如果你熟悉hive，那么你應該可以看出我代碼所指的事情，如果你沒有用過hive，那么就把hive看成是一種sql語言就好了)

　　讀了上一篇文章《深入探究數據測試之二：設計你的自動化測試用例》，相信你已經對自己未來的自動化測試用例代碼有所了解。這篇文章，我們就來談談在一淘，我們如何封裝這些無關操作。這里就要講講我們為封裝操作專門開發的框架SmartTest。

　　首先要知道，代碼不可能無故減少，只能是被封裝了而已。也就是說，上一篇的第一個例子中間所做的所有的事情，一樣都不能少，而是僅僅被搬到其他地方而已。

　　那么搬到什么地方了呢?我們這里提出一個概念，叫做測試應用。測試應用就是把所有的測試的過程和被測試對象的建模行為封裝好的一個類。這個類將所有的測試過程全部納入到每一個類函數中，而把動態的信息暴露出來，允許用戶設置。

　　如上一篇博文的第二個例子，underTest就是一個測試應用。也許你會說，原來就是把之前的代碼全部搬入到underTest的go函數中啊，這簡單。但是如果是僅僅的這么搬家，那么這個封裝就太無聊了。

　　做搬家之前，我們將會對整個測試過程進行階段劃分：

　　如上圖，我們可以看出，我們使用測試應用，定義了一個自動化測試用例的運行的三個階段：setup, run和teardown。每一個階段又劃分了若干步驟：

　　Setup的cleanEvironment步驟：負責清理環境，確保這個測試用例可以正確執行。好的習慣是每一次測試用例運行完畢之后清理一次，但是卻不能保證如果測試用例運行失敗或者中途退出導致沒有進行環境清理，而且很多情況會需要現場環境進行錯誤排查，所以我們將清理環境放在了每個測試用例之前。

　　Setup的generateConfig步驟，被測試對象總有多多少少的config配置，這一步就是將這些配置設置成為測試用例需要的配置，然后放置在合適的地方。

　　Setup的generateData步驟，這一步是至關重要的步驟，因為我們是數據測試，這個階段需要將需要的數據生成出來，放在合適的位置，等待被測試程序取用。我們后面的章節會對這一個階段做的事情進行更加全面的講解。

　　Setup的StartRefService步驟，將本次測試的依賴服務啟動起來，可能是mysql，可能是httpd，看被測試系統的應用場景。

原文轉自：http://www.anti-gravitydesign.com