可讀性： 很多情況下，在測試人員開(kāi)始測試項目之前，公司已經(jīng)有了一套測試腳本，并且已經(jīng)存在很多年了。我們可以稱(chēng)之為 “ 聰明的橡樹(shù) ”(wise oak tree)[Bach 1996] 。大家很依賴(lài)它，但是并不知道它是什么。由于 “ 聰明的橡樹(shù) ” 類(lèi)型的測試腳本缺乏可讀性，在具體應用中，那些腳本常常沒(méi)有多大的實(shí)用價(jià)值，越來(lái)越讓人迷惑。因此，測試人員很難確定他們實(shí)際在測試什么，反而會(huì )導致測試人員對自身的測試能力有過(guò)高的估計。測試人員能夠檢視測試腳本，并且理解測試腳本究竟測試了什么，這是很關(guān)鍵的。好的文檔是解決問(wèn)題的手段之一，對測試腳本全面分析是另外一個(gè)手段。由上面兩種方法可以引申出其它的相關(guān)方法，我曾經(jīng)在一個(gè)項目中使用過(guò)引申之后的方法。在測試腳本中插樁，把所有執行的產(chǎn)品相關(guān)的命令記錄到日志里。這樣，當分析日志確定執行了哪些產(chǎn)品命令，命令采用了何種參數配置時(shí)，可以提供一個(gè)非常好的測試記錄，里面記錄了自動(dòng)化測試執行了什么，沒(méi)有執行什么。如果測試腳本可讀性不好，很容易變得過(guò)分依賴(lài)并沒(méi)有完全理解的測試腳本，很容易認為測試腳本實(shí)際上做的工作比你想象中的還要多。測試套的可讀性提高后，可以更容易的開(kāi)展同行評審活動(dòng)。
可維護性： 在工作中，我曾經(jīng)使用過(guò)一個(gè)測試套，它把所有的程序輸出保存到文件中。然后，通過(guò)對比輸出文件內容和一個(gè)已有的輸出文件內容的差別，可以稱(chēng)已有的輸出文件為 “ 標準文件 ” ( “gold file” )。在回歸測試中，用這個(gè)方法查找 BUG 是不是明智之舉。這種方法太過(guò)于敏感了，它會(huì )產(chǎn)生很多錯誤的警告。隨著(zhù)時(shí)間的推移，軟件開(kāi)發(fā)人員會(huì )根據需要修改產(chǎn)品的很多輸出信息，這會(huì )導致很多自動(dòng)化測試失敗。很明顯，為了保證自動(dòng)化測試的順利進(jìn)行，應該在對 “ 標準文件 ” 仔細分析的基礎上，根據開(kāi)發(fā)人員修改的產(chǎn)品輸出信息對之做相應的修改。比較好的可維護性方法是，每次只檢查選定的產(chǎn)品的某些特定輸出，而不是對比所有的結果輸出。產(chǎn)品的接口變動(dòng)也會(huì )導致原來(lái)的測試無(wú)法執行或者執行失敗。對于 GUI 測試，這是一個(gè)更大的挑戰。研究由于產(chǎn)品接口變化引起的相關(guān)測試修改，并研究使測試修改量最小的方法，測試中采用庫是解決問(wèn)題的方法。當產(chǎn)品發(fā)生變化的時(shí)候，只需要修改相關(guān)的庫，保證測試與產(chǎn)品的變動(dòng)同步修改即可。
完整性： 當自動(dòng)化測試執行后，報告測試執行通過(guò)，可以斷定這是真的嗎?這就是我稱(chēng)之為測試套的完整性。在前面的故事中，當沒(méi)有對自動(dòng)化測試完整性給予應有的關(guān)注的時(shí)候，發(fā)生了富有喜劇性的情況。我們應該在多大程度上相信自動(dòng)化化測試執行結果?自動(dòng)化測試執行中的誤報告警是很大的問(wèn)題。測試人員特別討厭由于測試腳本自身的問(wèn)題或者是測試環(huán)境的問(wèn)題導致測試執行失敗，但是，對于自動(dòng)化測試誤報告警的情況，大家往往無(wú)能為力。你期望自己設計的測試對 BUG 很敏感、有效，當測試發(fā)現異常的時(shí)候，能夠報告測試執行失敗。有的測試框架支持對特殊測試結果的分類(lèi)方法，分類(lèi)包括 PASS ， FAIL 和第三種測試結果 NOTRUN 或者 UNRESOLVED 。無(wú)論你怎么稱(chēng)呼第三種測試結果，它很好的說(shuō)明了由于某些測試失敗導致其他測試用例無(wú)法執行而并非執行失敗的情況。得到正確的測試結果是自動(dòng)化測試完整性定義的一部分，另一部分是能夠確認執行成功的測試確確實(shí)實(shí)已經(jīng)執行過(guò)了。我曾經(jīng)在一個(gè)測試隊列中發(fā)現一個(gè) BUG ，這個(gè) BUG 引起測試隊列中部分測試用例被跳過(guò)，沒(méi)有執行。當測試隊列運行完畢后，沒(méi)有上報任何錯誤，我不得不通過(guò)走讀代碼的方式發(fā)現了這個(gè) BUG 。如果，我沒(méi)有關(guān)注到這個(gè) BUG ，那么可能在認識到自動(dòng)化測試已經(jīng)出現問(wèn)題之前，還在長(cháng)時(shí)間運行部分測試用例。
獨立性： 采用自動(dòng)化方法不可能達到和手工測試同樣的效果。當寫(xiě)手工測試執行的規程時(shí)候，通常假定測試執行將會(huì )由一個(gè)有頭腦、善于思考、具有觀(guān)察力的測試人員完成的。如果采用自動(dòng)化，測試執行是由一臺不會(huì )說(shuō)話(huà)的計算機完成的，你必須告訴計算機什么樣的情況下測試執行是失敗的，并且需要告訴計算機如何恢復測試場(chǎng)景才能保證測試套可以順利執行。自動(dòng)化測試可以作為測試套的一部分或者作為獨立的測試執行。測試都需要建立自己所需要的測試執行環(huán)境，因此，保證測試執行的獨立性是唯一的好方法。手工回歸測試通常都相關(guān)的指導文檔，以便一個(gè)接著(zhù)一個(gè)有序地完成測試執行，每個(gè)測試執行可以利用前一個(gè)測試執行創(chuàng )建的對象或數據記錄。手工測試人員可以清楚地把握整個(gè)測試過(guò)程。在自動(dòng)化測試中采用上述方法是經(jīng)常犯的錯誤，這個(gè)錯誤源于 “ 多米諾骨牌 ” 測試套，當一個(gè)測試執行失敗，會(huì )導致后續一系列測試失敗。更糟糕的是，所有的測試關(guān)聯(lián)緊密，無(wú)法獨立的運行。并且，這使得在自動(dòng)化測試中分析合法的執行失敗結果也困難重重。當出現這種情況后，人們首先開(kāi)始懷疑自動(dòng)化測試的價(jià)值。自動(dòng)化測試的獨立性要求在自動(dòng)化測試中增加重復和冗余設計。具有獨立性的測試對發(fā)現的缺陷的分析有很好的支持。以這種方式設計自動(dòng)化測試好像是一種低效率的方式，不過(guò)，重要的是在不犧牲測試的可靠性的前提下保證測試的獨立性，如果測試可以在無(wú)需人看守情況下運行，那么測試的執行效率就不是大問(wèn)題了。
可重復性： 自動(dòng)化測試有時(shí)能夠發(fā)現問(wèn)題，有時(shí)候又無(wú)法發(fā)現問(wèn)題，對這種情況實(shí)在沒(méi)有什么好的的處理辦法。因此，需要保證每次測試執行的時(shí)候，測試是以同樣的方式工作。這意味著(zhù)不要采用隨機數據，在通用語(yǔ)言庫中構造的隨機數據經(jīng)常隱藏初始化過(guò)程，使用這些數據會(huì )導致測試每次都以不同的方式執行，這樣，對測試執行的失敗結果分析是很讓人沮喪的。這里有兩個(gè)使用隨機數據發(fā)生器的的方法可以避免上述情況。一種方法是使用常量初始化隨機數據發(fā)生器。如果你打算生成不同種類(lèi)的測試，需要在可預測，并且可控制的情況下建立不同類(lèi)型的隨機數據發(fā)生器。另外一個(gè)辦法是提前在文件中或數據庫中建立生成隨機測試數據，然后在測試過(guò)程中使用這些數據。這樣做看起來(lái)似乎很好，但是我卻曾經(jīng)看到過(guò)太多違反規則的做法。下面我來(lái)解釋到底看到了什么。當手動(dòng)執行測試的時(shí)候，往往匆匆忙忙整理文件名和測試數據記錄。當對這些測試采用自動(dòng)化測試方法，該做哪些工作呢?辦法之一是，可以為測試中使用的數據記錄給固定的命名。如果這些數據記錄在測試完成后還要繼續使用，那么就需要制定命名規則，避免在不同的測試中命名沖突，采用命名規則是一種很好的方法。然而，我曾經(jīng)看到有些測試只是隨機的命名數據記錄，很不幸，事實(shí)證明采用這種隨機命名的方式不可避免的導致命名沖突，并且影響測試的可重復性。很顯然，自動(dòng)化工程師低估了命名沖突的可能性。下面的情況我遇到過(guò)兩次，測試數據記錄的名字中包含四個(gè)隨機產(chǎn)生的數字，經(jīng)過(guò)簡(jiǎn)單的推算如果我們采用這種命名方式的時(shí)候，如果測試使用了 46 條記錄，會(huì )存在 10% 沖突的可能性，如果使用 118 條記錄，沖突的幾率會(huì )達到 50% 。我認為測試當中使用這種隨機命名是出于偷懶的想法 —— 避免再次測試之前寫(xiě)代碼清除老的數據記錄，這樣引入了問(wèn)題，損害了測試的可靠性和測試的完整性。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
