探索式測試：測試自動化實例分析

　　Harry Robinson是微軟公司的首席測試工程師(Principle Software Development Engineer in Test)，工作于必應(Bing)團隊。他在國際會議CAST 2010和PNSQC 2010做了兩次關于測試自動化的主題報告，都很有啟發性。本文從中摘錄了若干測試自動化實例。希望通過對它們的分析，能夠獲得一些可借鑒的經驗。

　　為避免誤會，在此重申：本文的素材來自Harry Robinson的主題報告，其內容皆來自他在必應的測試工作。我所做的工作是翻譯和評論，并為此過程中的所有錯誤負責。

　　案例1：蓋特伍德奶奶(Grandma Gatewood)

　　下面這張截圖來自于Harry的一張幻燈片，右側的老者就是著名的蓋特伍德奶奶(Grandma Gatewood)。她曾經在67、72、75歲時，三次獨自徒步走完阿帕拉契小徑(Appalachian Trail)。阿帕拉契小徑是美國著名的野外徒步路線，穿越14個州，全長3200公里。蓋特伍德是首位獨自徒步走完阿帕拉契小徑的女性，耗時僅三個月。

　　蓋特伍德是“超輕徒步先驅 ”(ultra-light hiking pioneer)。維基百科有如下描述：

　　1955年，67歲的蓋特伍德徒步前往阿帕拉契小徑，她穿著Keds運動鞋，她把一塊軍用毛毯、一件雨衣、一塊塑料浴簾裝在自家縫制的背包里，然后單肩背包徒步，由此她成了超輕背包的先驅。

　　1970年，時年83歲，她在弗吉尼亞州奧克頓訪問阿帕拉契旅行用品商店時，有人詢問她對于當時輕量背包裝備的看法，她建議：“制作一個雨衣，一個單肩背包，再買雙結實的Keds網球鞋。在當地雜貨店買好維也納香腸……其他吃的你可以在路邊找到……”

　　現在，你也許感到疑惑：蓋特伍德與測試自動化到底有什么關系?那么，請考慮下面這個問題

　　如果蓋特伍德選擇圖片左側男子所用的背包，她能夠在67歲之后徒步走遍美國大陸地區所有的州嗎?

　　答案顯然是不能。如果選擇圖片左側的雙肩包，蓋特伍德恐怕堅持不了一個星期就要倒下。這是一件顯而易見的事情：你所選擇的工具不應成為你的負擔。然而，我見過一些測試團隊，他們使用重量級的流程、框架、基礎設施，被自己的選擇所拖累，雖然天天抱怨，卻不思變更。

　　蓋特伍德的單肩包提示我們自問：

　　測試自動化的投入產出比如何?是那些投入最多的測試在創造最多的價值嗎?

　　我們遵循了“要事第一”(First Thing First)的原則嗎?我們的主要精力是投入在最有價值的事情上嗎?

　　現有的流程、框架、基礎設施中，有哪些部分不是必須的?能用更輕量的方法替代嗎?

　　程序員有時在潛意識中認為自己是無所不能的超人，但是我們真的強過蓋特伍德嗎?她經歷過兩次世界大戰，見證過改變世界的經濟危機，養育過11個子女(這是多么強大的管理經驗)，在67歲時開始新的冒險，獲得成功后又邁向新的目標。不要以為超輕背包是一個虛弱老嫗的無奈選擇，它是一個睿智老者多年人生體驗的沉淀。她知道什么是必須的(雨衣、背包、Keds網球鞋、維也納香腸)，什么可以稍后處理、隨機應變(“其他吃的你可以在路邊找到”)。她知道用超輕背包，她可以走得更遠，遠得令所有人敬佩。

　　如果看完本文，你只能記得一點，請不要忘記蓋特伍德奶奶的單肩包。

　　案例2：測試自動建議(AutoSuggest)

　　對于搜索用戶，自動建議(AutoSuggest)是一項貼心的設計。但是對于測試工程師，這不是一項容易測試的功能。

　　手工探索式測試無法保證測試抽樣可以覆蓋用戶輸入。與必應搜索龐大的用戶輸入相比，手工測試的覆蓋率接近于零。傳統的等價類劃分等測試抽樣方法，對于如此海量的、無規則的輸入，也無可奈何。

　　傳統的自動化測試遇到的困難是無法構建測試Oracle。自動建議的核心實現是基于海量數據的人工智能算法。算法的輸出受到多個因素的影響，如當前用戶的查詢、近期的相似查詢、自動拼寫更正、關鍵詞過濾(如去除色情內容)等。對于特定的輸入，很難構造自動建議的“預期結果”。

　　面對困難，Harry的測試思路是構造啟發式測試Oracle(Heuristic Test Oracles)。所謂啟發式Oracle，就是使用規則對測試結果進行一致性檢查。開始時，Harry的規則非常簡單：

　　自動建議的結果應該以輸入字符串為作為綴。

　　Autosuggestions should have the input string as their prefix.

　　Harry編寫了一個簡單的測試程序。它從必應的服務端日志中獲得真實用戶的查詢，調用自動建議的Web Service API，以獲得這些查詢的自動建議結果，最后利用上述規則對結果進行檢查。

　　很快，測試程序發現了不滿足規則的案例。當輸入是“nestb”，自動建議返回“bestbuy.com”(百思買，財富500強消費電子零售商)。這是自動建議的拼寫更正(Spelling Correction)功能，它將用戶的“疑似錯誤輸入”，糾正為一個最可能的結果。該行為是可接受的。于是，Harry將規則修正為：

　　自動建議的結果應該以輸入字符串的合理近似作為前綴。

　　Autosuggestions should have a reasonable approximation of the input string as their prefix.

　　雖然不知道Harry的具體做法，我能想到若干“合理近似”的判定方法。

　　將單詞看作向量，計算向量之間的距離。距離小于指定閾值的單詞對，可以認為相互“近似”。

　　查詢Office Word的拼寫更正字典，獲得指定單詞的所有拼寫更正建議。這些建議可以視為單詞的“合理近似”。

　　調用必應的搜索API，獲得搜索結果。搜索結果中的高亮關鍵詞可以視作查詢的“合理近似”。

　　Harry利用修正后的規則又發現了一些違規的案例。如輸入“dond”，自動建議返回“nbc.com”。也許這符合某些文化上的約定，但值得進一步調查。再例如，輸入“federal trust bank”，自動建議返回“floridalottery.com”。這個建議應該是錯誤的，需要開發者去調查哪里出了問題。在這個過程中，啟發式Oracle更像一個過濾器，它處理海量的數據，過濾出需要測試者人工審查的潛在錯誤案例。

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