1. 程式人生 > >從功能測試角度談大數據測試

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

一個數 場景 一個數據庫 步驟 什麽 運行 都是 ces 等價類

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

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

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

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

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

技術分享圖片

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