軟件測試工具如何創新

　　本年度的測試工具Jolt大獎最近公布，社區專家Andrew Binstock認為測試工具多年來沒有任何創新，他在文章中說，對這些產品的實現質量感到非常高興，唯一的遺憾是它們大部分只支持Windows平臺。質量對于測試工具來說非常重要，特別是對于編譯器和調試器來說，因為通過測試工具引入的Bug會讓測試人員和開發人員搞不清楚到底是測試的產品出了問題還是測試工具本身出了問題，讓他感到失望的是，年復一年，測試工具沒有什么創新。它們總是把已有的概念實現并應用到新的平臺上。今年也是一樣，主題與移動領域和與計算領域有關。是的，這些平臺需要測試工具，但是也許開發者需要的測試功能不僅限于以下幾條：

　　代碼檢查

　　單元測試

　　界面測試

　　瀏覽器測試

　　負載和性能測試

　　Andrew列舉了一些他認為比較創新性的測試功能：

　　自動化黑盒測試

　　Fuzz測試

　　配置測試

　　安全測試

　　災難恢復測試

　　隱私測試(當你關閉應用時，應用把內存中的敏感數據刪除了嗎?目前很難測試這一點，也沒有相應的測試工具，只能編寫特定的腳本來運行)

　　他認為目前各種測試功能的支持方面最大的問題是缺乏自動化，“自動化”意味著錄制、回放。這意味著編寫腳本來測試不是自動化，測試工具應該從界面上來支持自動化，而不是要求測試人員在后臺編寫腳本。

　　Andrew舉了一個實際工作中的例子，在測試Web應用的時候，他希望能夠運行測試工具自動生成檢查安全問題的測試腳本，包括SQL注入、空字符串攻擊、CRLF攻擊、非常REST命令、cookie攻擊、多次登陸、緩存溢出等等。Andrew還希望在測試一個整型參數的函數時，測試工具能夠準備好何種邊界值，比如最大整型值、最小整型值、-1、0、1等等。如果參數是字符串類型，那么測試值應該包括null、空字符串、30000個字符長度的字符串、隨機字符串等等。如果應用讀取一個輸入文件，那么測試工具應該考慮到文件不存在、空文件、大小超過2G的文件、特殊名字的文件等等。如果是文本文件，那么測試工具是否考慮了外國字符的情況?

　　雖然測試情況可能有成百上千種，，但是目前的測試工具可能只考慮了幾種條件。Andrew希望測試工具能夠做到：

　　抓取異常情況

　　模擬異常輸入

　　通過良好的界面報告測試結果

　　這種理想情況可以大大減輕測試人員的腳本準備精力投入。

　　提到測試工具的錄制和回放功能，測試專家Lisa和Janet在“敏捷測試指南”一書中對該領域有過深入的探討：

　　我們已經提到過記錄/回放工具的一些缺點，但只要用對地方，他們還是有用的。你可以在下面這種情況下使用記錄/回放工具：或許遺留代碼擁有了一個使用該工具創建的自動化測試套件，團隊也擁有該工具的使用經驗，或是管理層出于某種原因想讓你使用該工具。你可以將記錄腳本作為起點，接下來將該腳本劃分為幾個模塊，使用恰當的參數替換掉硬編碼的數據，將模塊作為構建塊來組裝測試。即便你沒有太多編程經驗也不會影響到如何將腳本塊放到模塊中。比如說，登錄就是一個顯而易見的選擇。

　　Lisa舉了一個例子。Gerard Meszaros是一位敏捷教練，同時也是“xUnit Test Patterns”一書的作者，他描述了一種情況，其中最簡單的辦法就是使用記錄/回放。我們曾提到過記錄/回放工具的缺點，但如果設計代碼時就支持他們，那么他們也能成為最好的方法。有團隊曾求助Gerard將一個“高度重視安全”的應用由OS2遷移到Windows上。其業務主要關注于測量遷移系統所花費的時間以及團隊忽略掉重要bug的可能性。設計該系統的目的在于向用戶提供有效選擇而不會危及系統的安全性。他們考慮使用一個測試記錄工具來記錄舊系統上的測試并在新系統上回放，但并沒有適合于OS2和Windows的測試記錄工具能夠使用ASCII字符處理類Windows繪圖。在審查了系統架構后，Gerard認為編寫xUnit測試并不是一個有效的系統測試方式，因為很多業務邏輯都嵌入到了用戶界面邏輯當中了，重構代碼將其分隔開來風險又太高，也比較花時間。因此，我們提議在移植前為系統開發一個記錄/回放測試功能。

　　即便項目的其他部分是里程碑驅動的，Gerard也使用敏捷方式開發了內建的測試機制。每個界面至少需要一個新的回調，有時也需要幾個。 Gerard從使用最為頻繁的界面開始，增加必要的回調來記錄用戶的行為和系統對其的響應(保存到XML文件中)。他還增加了回調以回放該XML并觀察測試結果。一開始，Gerard主要將回調放在需要記錄的界面上并使用簡單但實際的測試進行回放。在所有人都相信這種方式可行后，他們根據界面所能提供的好處對其進行優先級的劃分。一個一個地實現了回調直到可以自動化重要的測試為止。還創建了一個XSLT樣式表，它可以適合于Fit的方式格式化XML，綠色單元格表示接受的測試而紅色單元格表示失敗的測試。與此同時，客戶確定需要測試用例的測試場景。由于已經完成了足夠的界面來記錄特殊的測試，客戶通過記錄與回放(仍舊在OS2上)測試進行“驗收”測試。當所有的回調就緒后，可以更進一步并開始從OS2到Windows移植代碼了，包括測試回調。在OS2上成功驗證完回放后，客戶會將XML測試文件遷移到Windows上并再一次針對移植版本的代碼運行?？蛻舭l現這么做很簡單并且可以在相對少的時間內記錄大量的測試。由于測試記錄了行為以及業務上的響應，因此他們很容易理解?？蛻粝矚g這種方式，它節省了大量的時間，同時對產品也更具信心了。“這不僅節省了大量的測試工作量，甚至還發現了遺留系統中隱藏很深的bug，這就是Gerard所說的黃金標準”。在Gerard的故事中，團隊一起將可測試性追加到并不適合測試的系統中。他們給予客戶一種手段，在一個平臺上捕獲測試場景并在兩個平臺上進行回放來驗證該移植是成功的。這是團隊方法的鮮明示例。在團隊協作進行測試自動化方法的探索中，有更多成功的機會。

原文轉自：http://www.infoq.com/cn/news/2013/06/better-testing-tools