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

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

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

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

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

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

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

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

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

大資料測試方法

相關推薦