測試錯誤代碼

 

測試錯誤代碼

 

---James Whittaker原著《Testing Error Code》

---Kiki翻譯於2005/7/19

 

開發人員會編寫兩種代碼：功能代碼和錯誤代碼。這篇文章是關於瞭解在測試錯誤代碼時的空前的挑戰，我們將從一個開發人員的角度討論錯誤代碼開始。隨後我們將探索作爲測試人員一種最好的攻擊這一挑戰的方法。

 

開發人員會編寫兩種代碼。第一個是讓工作執行的代碼，我們稱這種代碼爲功能代碼因爲它提供了滿足用戶需求的功能性。第二種是爲了防止功能代碼由於不正確的輸入（或一些意外的環境狀況）而引起的失敗，我們稱它爲錯誤代碼是因爲它是處理錯誤的。對於許多的開發人員而言，這是出於需要而被強迫編寫的，並不是因爲它特別有趣。

同時編寫兩種類型的代碼是有問題的，是因爲在軟件開發人員的頭腦裏必須在兩種代碼之間做上下文的切換（context shift）。這種上下文的切換是值得懷疑的，因爲他們需要開發人員停止思考一種代碼並開始思考另一種代碼。

假設Johnny，一個我們假想的辛勤的開發人員，正在開發一個新的應用程序。Johnny通過編寫功能代碼開始工作，你甚至可能想的更遠，想使用一些象UML的技術以讓Johnny充分理解必須要編寫的各種各樣的用戶場景。這樣很好，實際上，象Johnny一樣的優秀的編程人員可以查找到大量的可以幫助他們編寫優秀的功能代碼的信息。有很多的書，指南，還有許多有用的出版物中的示例都可以幫助你。

但是，當Johnny意識要需要編寫錯誤代碼時會發生什麼事情呢？可能當他在編寫或指定一些他確定要做的代碼對象時，他說，這個輸入需要校驗邊界（bounds-checked）。Johnny會怎麼做呢？其中一個選擇是停止編寫功能代碼並且改爲編寫錯誤代碼。這需要在Johnny的開發員的腦子裏做一個上下文的切換。他必須停止思考用戶的場景和他正在實現的功能代碼，然後開始思考如何處理錯誤。由於處理錯誤可能會比較負責，這可能要花他一些時間。

現在，當Johnny返回到編寫功能代碼的任務裏，yes它們變得編寫任何不平凡的程序。你看到了問題：可憐的Johnny不得不忍受着兩種上下文切換以除了一個錯誤。設想以下在編寫一個（即使是一個小的）應用程序將有多少象這樣的上下文切換。
 另一個選擇是推後編寫錯誤代碼以避免上下文切換。假設Johnny記得在最後抽出時間來編寫錯誤代碼，他或許不得不發一些時間來回憶他以前試圖編寫一個處理器來處理的錯誤事件的本質。因此現在Johnny在沒有上下文利益的前提下編寫錯誤代碼。編寫錯誤代碼是有問題的不管你如何面對。因此對於象我一樣的人來說，發現錯誤。因此現在讓我們用測試的角度看看，我們要用什麼方法測試錯誤代碼呢？

強制錯誤信息出現是使錯誤代碼執行的最好方法。軟件應該正確地響應錯誤的輸入或者首先應該成功地防止輸入進入到軟件中。有把握瞭解的的唯一辦法是用一批錯誤的輸入測試應用程序。或許最重要的是瞭解應用程序如何響應不正確的輸入。我設法驗證以下三種不同的錯誤處理器的類型：
輸入過濾器（Input filters）：能夠用於預防錯誤的輸入進入所測試的軟件（software under test）。有效的過濾錯誤的輸入，例如，一個圖形用戶界面，只允許合法的輸入通過界面 
輸入校驗（Input checking）： 可以執行以確保軟件不會執行使用錯誤的輸入。最簡單的例子是每次輸入一個到系統中，開發人員插入一條IF語句以確保數據在處理之前輸入是合法的。換句話說，如果輸入是合法的，那麼就除了它，否則顯示一個錯誤信息。在這個優先的攻擊時，我們的目標是確保我們看見了所有這樣的錯誤信息。

異常處理器（Exception handlers）： 是一種最後才採用的方法，並且常用於在系統由於處理了錯誤輸入而導致的失敗之後清理錯誤。換句話說，錯誤的輸入允許進入稀土女冠，被處理後，系統出現了錯誤。異常處理器是一種常見的程序，在軟件失敗時被調用。它通常包括重新設置內部變量，關閉文件並且恢復軟件和用戶交互能力的代碼。一般來說，也會顯示一些錯誤信息。 
測試人員必須考慮所測試軟件可以接受的輸入並且集中在不正確數值上。在這裏的方法是輸入太打，太小，太長，太短的數值，這些數值是超出了可接受的範圍或是錯誤的數據類型的數值。這種方法可以發現的主要的缺陷是遺漏了錯誤的情況－開發人員不知道哪些輸入的數據是錯誤的或被忽略的個別情況。遺漏的情況通常導致軟件中止或崩潰。測試人員也應該查看錯誤信息放錯位置的情況。有時開發人員正確地獲得了錯誤信息，但是卻把它安排給了錯誤的輸入數值。因此，對於那個提交的輸入數值而言，這個錯誤信息就好像是胡說八道。 
最後，純粹惡作劇的數據是不能提供任何信息的錯誤消息。儘管這樣的信息不會引起對用戶直接的傷害，但是他們是草率的並且在用戶的頭腦裏投下了對軟件製造商的誠信的懷疑。“Error 5—Unknown Data” 對於一些開發人員來說可能看上去是一個好的主意，但是它將在用戶的頭腦裏產生挫敗，用戶不知道他們什麼地方做錯了。不管測試人員正在測試一個GUI面板中的輸入字段還是測試一個API調用中的參數，測試人員必須在執行這個攻擊時思考輸入的屬性。如下是一些常見的應該思考的屬性： 
輸入類型（Input type）: 輸入無效類型通常將產生一個錯誤信息。例如，如果“問題”的輸入類型是整數，那些嘗試輸入一個真實的數字或一個字符。 
輸入長度（Input length）: 對於字符（字母和數字）類型的輸入，輸入少量的很多的字符將引起錯誤信息。 
邊界值（Boundary values）：每一個數字數據類型有邊界值，並且有時這些數值代表着特殊的情況。例如，整數0就是正數和負數的邊界。