從功能測試角度談大數據測試

大數據，已經成爲了一個時代的代名詞，當今的互聯網屬於大數據時代，大數據時代的到來，顛覆了以往對數據的慣性思考方式，要保證數據執行，軟件質量，測試質量，數據使用場景等，都須要從新變換一個新的角度，對軟件進行更全方面的思考。

 以前大數據不多有測試，開發會以爲：測試環境又沒有那麼多數據，你怎麼測？拋開大數據的數據量大的特色，究其根本，他也是爲業務服務的，有一句話我很是贊同： 一切技術都是爲業務服務，脫離業務的技術一文不值，這句話在大數據時代的今天，依然適用，而且會一直適用下去。測試的工做就是要保證數據的正確性，業務邏輯正確。大數據腳本也有輸入、輸出，這有點相似與功能測試中的後臺邏輯測試，沒有界面，一切都是後臺服務器處理的，測試人員必需要清楚整個處理流程，每一個數據的流轉，每一個步驟的輸入和輸出，才能判斷最後的輸出結果是否正確，對於大數據測試也是同樣，咱們要清楚每一個腳本的功能，每一個腳本的輸入和輸出，總體數據流轉過程，來判斷大數據實現的功能是否正確。

一個數據腳本或者一段數據計算邏輯，在大數據下運行正確的前提，必須是其功能是正確的，這也是咱們測試人員首先要保證的，今天我想從功能測試的角度，討論大數據的功能測試要怎麼作，用例怎麼設計，才能覆蓋面更廣，更好的保證其正確性。

  一、編寫測試用例

功能測試編寫測試用例的經常使用方法：等價類、邊界值（這兩個方法估計作測試的都知道），一樣適用於大數據測試編寫用例，與一般意義上的功能測試不一樣的是，他的輸入再也不是一個輸入框，而是一個數據庫字段或者一個有特殊意義的數據集（包含多個數據）。

咱們先回顧一下等價類和邊界值兩種經常使用的功能測試設計用例的方法。首先劃分等價類：是指某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露程序中的錯誤都是等效的，併合理地假定：測試某等價類的表明值就等於對這一類其它值的測試.所以,能夠把所有輸入數據合理劃分爲若干等價類,在每個等價類中取一個數據做爲測試的輸入條件,就能夠用少許表明性的測試數據.取得較好的測試結果.邊界值是對等價類的補充，其測試用例來自於每一個等價類用例的邊界。

那麼這兩種方法如何用在大數據測試用例的編寫上呢？

拿咱們以前測試的一個大數據腳本舉例，腳本的主要功能是統計某家店鋪某一天的訂單量，根據設置的每一個商品不一樣的返利規則，計算店鋪天天的利潤。

首先輸入分析條件：

一、指定店鋪 

二、指定某一天

三、不一樣時間，不一樣的商品，不一樣的返點

商品1：2016.12.6  13:00:00------2016.12.6  15:00:00 返利爲5%

商品2：2016.12.7  00:00:00------2016.12.7  23:59:59  返利爲15%

全部商品，除指定時間外， 返利均爲1%

他的等價類再也不是一個輸入，而是一個條件，知足這個條件的咱們劃到有效等價類上，不知足這個條件的，咱們劃分到無效等價類上，而在條件邊界上的數據則是咱們的邊界值。

用例劃分結果：

 

其餘編寫功能測試用例的方法，如場景分析法、分支覆蓋法，也一樣能夠用在編寫大數據測試用例中，任何測試都不能脫離實際業務，單純的測試數據，或者單純的測試輸入，沒什麼意義，咱們必須結合不一樣的場景，設計更全面、更有效率的測試用例。

二、準備測試數據

根據編寫的測試用例，準備不一樣類型的測試數據，這個也與功能測試同樣，測試數據不在數量的多少，而在於覆蓋的全面性，若是你準備了幾千條數據，可是數據類型都同樣，覆蓋的代碼分支也都是一條，那這些數據只有一條能稱之爲有效測試數據，其餘的所有是無效測試數據。

其中準備測試數據，能夠有幾種方法：

1）本身寫sql單條插入  

2）使用存儲過程 

3）從線上導導出數據，直接導入到測試環境。

同時要注意，準備測試數據時，儘可能和實際數據保持一致，如時間的值，精確到時分秒仍是隻到年月日，還有金額保留幾位小數等。

三、執行測試腳本，檢查測試結果

準備好測試數據後，就能夠執行測試腳本，腳本多是在hadoop平臺上，也多是在其餘平臺上，但這些都只是一個操做，相似咱們學習一個工具怎麼使用，知道怎麼運行腳本後，接下來的工做就又迴歸到測試上來，這時候測試人員要作的事情就是利用準備好的數據，執行腳本，檢查預期結果和實際結果是否一致，判斷腳本邏輯是否正確，這徹底是咱們功能測試的工做如出一轍。

因此，無論什麼類型的測試，其測試過程都是通用的，測試方法都是可借鑑的，咱們儲備了足夠多的測試基礎和測試方法，就能夠輕鬆應對各類不一樣的測試。