在測試代碼中硬編碼測試數據

　　在前面的文章數據驅動測試里，講到了將測試數據以及表現測試步驟的代碼分開的技術。從測試的角度來看，固然希望能夠覆蓋的測試場景越多越好，但是在設計和編寫自動化測試代碼的時候，卻又可以事先設計好一些固定的測試數據簡化自動化測試代碼的編寫工作。

　　之所以要這樣做(按照編程的術語講是硬編碼)，是因為按照等價類劃分，固定的測試數據一般都已經被其他測試用例覆蓋了。請考慮下面這個例子，假設你要測試一個博客網站(例如博客園)的文章評論功能，例如測試禁用一篇文章的評論功能，或者是測試文章作者刪除評論的功能。按照正常的流程，肯定是需要先編碼發布一篇文章，然后再編碼指定的評論功能測試用例。這樣的流程有以下幾個缺點：

　　1. 需要冗余的編碼，因為每個評論測試用例的代碼都要包含發布文章的步驟，在編程里面，我們都是極力推薦，什么只要代碼在不同的地方重復兩次，就要考慮是否將它封裝成一個函數之類的理念。這種包含冗余編碼的方式是我們在測試過程中極力要避免地，否則，程序員可能哪天心情很好，重構一下代碼，破壞了一些網頁的HTML結構—但是從用戶的角度來看又沒有任何區別;這種代碼重構，作為測試人員只能跟著程序員的代碼重構，修改測試代碼，那個時候，你當然會希望改的地方越少越好啦。

　　對于這個缺點，可能有人要說，在前面的文章“網站測試自動化系統—基于Selenium和VSTT”，創建博客的測試步驟不是已經被有效地封裝成一個函數了嗎，為什么還會說有冗余?這是因為在自動化測試過程中， 測試人員會定期(一些高規格的軟件開發團隊要求每天)將所以編寫完畢的測試代碼批量執行一遍，這就涉及到對于任何測試用例編碼都非常重要的兩個原則：

　　1) 一個測試用例可以獨自執行成功，就是說如果是單獨執行這一個測試用例的話，這個測試用例是可以執行成功的—否則就是產品編碼的失誤(Bug)。舉個例子，你正要編碼測試一個管理博客文章的功能，這個功能通常來說都是登錄用戶才可以使用的。然而，也許你剛剛編碼完畢一個登錄方面的測試用例，而且用例執行完畢的時候，沒有執行注銷操作。這個時候你不能想當然地以為下一個測試用例一定就是你現在正在編碼的文章管理的測試用例。

　　因為測試人員既保留有將多個測試用例任意排列執行的權力，也可以選擇單獨執行這一個測試用例—比如程序員剛剛重構了文章管理功能的代碼，為了節省測試時間，測試人員可能會選擇只執行文章管理方面的測試用例。所以不要將自己的命運寄托在別人手里。即除了整個團隊都公認的前提以外，不要相信任何前提。

　　2) 測試用例可以在任意排列的用例序列中執行通過，因此測試代碼應該盡量保護測試環境。舉個例子，你設計了一個管理用戶權限的測試用例，一般來說這種功能只有管理員才有權限操作的。然而，也許另一個粗心大意的測試工程師編碼了一個測試刪除用戶的用例，恰好將管理員刪除了，而你的用例正好在他的用例之后執行……己所不欲，勿施于人，既然你不希望碰到這種情況，那么在編碼自己的測試用例之前也應該避免類似的事情發生。

　　回過頭來再舉評論管理測試用例的設計，于是你的幾個測試代碼可能看起來像下面這樣：

原文轉自：http://www.anti-gravitydesign.com