如何對數據進行測試？(3)

　　exec('hive -e "alter table staff add if not exists partition ( dp=etao ) location \’/table_path/staff/dp=etao\’");//調用alter table為我們的表增加一個分區，地址是剛剛上傳的文件(hive的專有特性)

　　exec('underTestShell.sh'); //執行被測試腳本

　　exec('hadoop fs -cat /tmp/result.table/table_path/result/dp=etao/part-000 > /tmp/result.tmp'); //將結果表的結果下載下來

　　$result = file_get_contents('/tmp/result.tmp); //結果表讀取到內存中

　　//下面一段是期望操作

　　assert::equal($result, "38000");

　　?>

　　上面的測試代碼是我們最開始很可能寫出來的代碼，這樣的代碼面向過程，每一步都清楚的指明了他要干什么，非常直觀，因為他就是我們簡單的命令行命令的疊加。我相信交給別的測試人員，雖然看起來頭大，但是當他了解一個hive的測試過程之后，就容易理解這樣的代碼了。

　　但是這個測試用例會在后期的維護中給測試人員帶來巨大的麻煩，原因就在于，這個測試用例的無關操作太多，甚至多過了測試人員真正關心的數據準備的代碼。(無關操作還是期望操作，我已經在注釋中給出)這么做的壞處很多，最主要的就是以下三點：

　　1. 測試人員無法集中注意力在自己應該集中注意力的數據準備上，導致效率下降，這里效率下降的原因不僅僅是花時間關注無需關注的事情上，而且在不同的任務之間來回切換注意力，也會耗費大量的時間。

　　2. 測試代碼過于冗余，導致代碼無法維護。設想一下，當你擁有3個這樣的測試用例的時候，如果你想修改一下其中hadoop地址的路徑，這樣的代碼就需要將這個變化進行3次，如果有300個這樣的測試用例呢?自動化測試用例的易維護性是在日常中點點滴滴進行的。

　　3. 不熟悉hive代碼的人同學，編寫這樣的測試用例幾乎無法獨自完成。比如說你有一個同伴，對數據類型的驗證和測試方法很有成就，但是對hive一竅不通，那么他需要一個人手幫他熟悉hive的流程。這導致測試人員在同是數據測試的情況下跨項目流動困難。

　　下面是我們期望的封裝過無關操作之后的測試用例：

　　//下面一段是期望操作

　　$input = "zhangsan|28|8000\n";

　　$input.= "lisi|30|10000\n";

　　$input.= "wangwu|40|20000\n";

　　$underTest = new underTest();

　　$result = $underTest->run();

　　//下面一段是期望操作

　　assert::equal($result['result'], "38000");

　　?>

　　從上面我們可以看出來，所有的測試的過程都被一個run函數所取代。如果這么做，測試人員可以將自己的注意力放在$input的編寫和$result的預期結果，也對開發的修改測試也可以方便的修改所有的東西。

　　這個概念也可以平移到其他自動化測試中去：

　　UI的自動化測試，測試人員主要關心的焦點在于業務邏輯是否跑通，而不是某一個頁面元素如何定位上，UI自動測試要盡量把頁面元素抽取出來，定義成面向對象的類，或者使用關鍵字驅動來開發。

　　單元測試的時候，主要需要關注的是當前開發代碼的運行狀況，所以會使用Mock將目前的模塊所依賴的其他模塊模擬出來。

　　這些都是封裝無關操作的例子。

　　回顧一下，這一個小節我主要想說的是，自動化測試不是簡單的把手動步驟寫入腳本這么簡單，而是一個和開發過程一樣需要設計的過程。所以首先要想明白的事情是，你未來的幾百個甚至上千個的自動化測試用例長什么樣子，如何可以讓這些用例最簡單，最可以自描述。

　　下一篇文章，我們將會講如何封裝這樣的無關操作。

　　另外，本章的自動化測試用例的設計，并不是我們認為的最完美的自動化測試用例的樣本，之后我們會有其他的更新。

原文轉自：http://www.kjueaiud.com