從功能測試角度談大資料測試

標籤：輸入框   時代   自己   集合   tle   子集   舉例   oss   編寫   

大資料，已經成為了一個時代的代名詞，當今的互連網屬於大資料時代，大資料時代的到來，顛覆了以往對資料的慣性思考方式，要保證資料執行，軟體品質，測試品質，資料使用情境等，都需要重新變換一個新的角度，對軟體進行更全方面的思考。

 

 之前大資料很少有測試，開發會覺得：測試環境又沒有那麼多資料，你怎麼測？拋開大資料的資料量大的特點，究其根本，他也是為商務服務的，有一句話我非常贊同： 一切技術都是為商務服務，脫離業務的技術一文不值，這句話在大資料時代的今天，依然適用，並且會一直適用下去。測試的工作就是要保證資料的正確性，商務邏輯正確。大資料指令碼也有輸入、輸出，這有點類似與功能測試中的後台邏輯測試，沒有介面，一切都是後台伺服器處理的，測試人員必須要清楚整個處理流程，每個資料的流轉，每個步驟的輸入和輸出，才能判斷最後的輸出結果是否正確，對於大資料測試也是一樣，我們要清楚每個指令碼的功能，每個指令碼的輸入和輸出，整體資料流轉過程，來判斷大資料實現的功能是否正確。

 

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

 

 

  1、編寫測試案例

功能測試編寫測試案例的常用方法：等價類別、邊界值（這兩個方法估計做測試的都知道），同樣適用於大資料測試編寫用例，與通常意義上的功能測試不同的是，他的輸入不再是一個輸入框，而是一個資料庫欄位或者一個有特殊意義的資料集（包含多個資料）。

 

我們先回顧一下等價類別和邊界值兩種常用的功能測試設計用例的方法。首先劃分等價類別：是指某個輸入欄位的子集合。在該子集合中，各個輸入資料對於揭露程式中的錯誤都是等效的，併合理地假定：測試某等價類別的代表值就等於對這一類其它值的測試.因此,可以把全部輸入資料合理劃分為若干等價類別,在每一個等價類別中取一個資料作為測試的輸入條件,就可以用少量代表性的測試資料.取得較好的測試結果.邊界值是對等價類別的補充，其測試案例來自於每個等價類別用例的邊界。

 

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

 

拿我們之前測試的一個大資料指令碼舉例，指令碼的主要功能是統計某家店鋪某一天的訂單量，根據設定的每個商品不同的返利規則，計算店鋪每天的利潤。

 

首先輸入分析條件：

1、指定店鋪 

2、指定某一天

3、不同時間，不同的商品，不同的返點

商品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%

他的等價類別不再是一個輸入，而是一個條件，滿足這個條件的我們划到有效等價類別上，不滿足這個條件的，我們劃分到無效等價類別上，而在條件邊界上的資料則是我們的邊界值。

用例劃分結果：

 

其他編寫功能測試用例的方法，如情境分析法、分支覆蓋法，也同樣可以用在編寫大資料測試案例中，任何測試都不能脫離實際業務，單純的測試資料，或者單純的測試輸入，沒什麼意義，我們必須結合不同的情境，設計更全面、更有效率的測試案例。

 

2、準備測試資料

根據編寫的測試案例，準備不同類型的測試資料，這個也與功能測試一樣，測試資料不在數量的多少，而在於覆蓋的全面性，如果你準備了幾千條資料，但是資料類型都一樣，覆蓋的代碼分支也都是一條，那這些資料只有一條能稱之為有效測試資料，其他的全部是無效測試資料。

其中準備測試資料，可以有幾種方法：

1）自己寫sql單條插入  

2）使用預存程序 

3）從線上導匯出資料，直接匯入到測試環境。

同時要注意，準備測試資料時，盡量和實際資料保持一致，如時間的值，精確到時分秒還是只到年月日，還有金額保留幾位小數等。

 

3、執行測試指令碼，檢查測試結果

準備好測試資料後，就可以執行測試指令碼，指令碼可能是在hadoop平台上，也可能是在其他平台上，但這些都只是一個操作，類似我們學習一個工具怎麼使用，知道怎麼運行指令碼後，接下來的工作就又迴歸到測試上來，這時候測試人員要做的事情就是利用準備好的資料，執行指令碼，檢查預期結果和實際結果是否一致，判斷指令碼邏輯是否正確，這完全是我們功能測試的工作一模一樣。

 

所以，不管什麼類型的測試，其測試過程都是通用的，測試方法都是可借鑒的，我們儲備了足夠多的測試基礎和測試方法，就可以輕鬆應對各種不同的測試。

 

從功能測試角度談大資料測試