設計你的自動化測試用例

　　深入探究數據測試之二：設計你的自動化測試用例

　　如果已經讀了上一篇文章《深入探究數據測試之一：數據測試概論》，相信大家已經對數據測試有了更加詳細的理解，也有可能找到了現實測試中的具體例子。

　　我們第一步要做的事情，是封裝你的無關操作。而這一步的基礎，就是設計自動化測試用例。

　　什么是無關操作?無關操作是和期望操作正好相反的一個概念。

　　測試人員的期望操作，就是要寫在自動化測試用例里面的代碼的最理想狀況。所以無關操作就是你不想寫在自動化測試用例里面的代碼。拿下面這個測試來舉例：

　　第一個例子：假設我們要測試一個hive腳本：(如果你熟悉hive，那么你應該可以看出我代碼所指的事情，如果你沒有用過hive，那么就把hive看成是一種sql語言就好了)

　　//下面一段是期望操作

　　$input = "zhangsan|28|8000\n";//準備輸入數據，第一行

　　$input.= "lisi|30|10000\n"; //準備輸入數據，第二行

　　$input.= "wangwu|40|20000\n"; //準備輸入數據，第三行

　　//下面一段是無關操作

　　file_put_contents('/tmp/staff.table', $input); //將輸入的數據寫入到文件

　　exec('hadoop fs -mkdir /table_path/staff/'); //在hadoop上建立目標文件的目錄路徑

　　exec('hive -e "create external table stuff(name string, age bigint, salary bigint) partitioned by (dp string) location \'/table_path/staff/dp=etao\';"'); //建立hive的建表語句

　　exec('hadoop fs -put /tmp/staff.table/table_path/staff/dp=etao/part-000'); //將我們的數據文件放到hdfs上

　　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