軟件測試自動化

　　談到自動化測試方面的誤區，不少文章傾向于從人性、管理、職業規劃等方面進行探討。我這次專門從計劃、設計、實現、維護等技術角度總結一下。

　　自動化的最終目標是什么?

　　很多人以為是像工業革命一樣消滅手工勞動者，在這里等于手工測試人員。但是測試存在一個目前來看還算正確的、其他行業不多見的悖論：任何時候，你都不能準 確知道還有多少bug，就像警察不能準確知道還有多少賊一樣。所以自動化的最終目標——目前來說——是解放盡量多的人手去進行更多的測試，除非有一種手段 能像《少數派報告》里面的預言少女一樣預知所有的bug。因為永遠有bug，有未知的bug，所以目前不存在能覆蓋所有bug的手段，這意味著總需要人的 參與?，F代化手段只是減少了而不是杜絕對人員的需求。所以如果認為自動化工作一做完就沒活干，那你就大錯特錯了。正認為這些人閑下來，他們有空發現更難發 現的bug。這本來沒什么大不了的，但是擱在計劃階段如果過分樂觀，牛皮吹得太大的話，到后面就不容易圓回去了。因為按上面分析，自動化測試總有些地方是 力有不逮的，如果這些地方沒有安排好人手時間，只要在這些地方出大問題，那你就玩完了。

　　能否/怎樣自動驗證?

　　這個問題每次復審測試計劃的時候我都會問，針對每一個提出要實施自動化的地方。每個人、每個工具談論自動化的時候都在說如何真實模擬用戶使用產品的情況， 這很好，絕對需要關心。不過我得問一句：測試的最后結果是什么?如果你回答“各種使用產品的場景已經運行過“就嘎然而止的話，你就漏掉了一大塊：最起碼還 得加上“產品能工作/不能工作“!所以模擬用戶使用產品的各種情況，只是解決上述問題的第一部分;如何得出測試通過/不通過的最終結論，才是解決問題第二 部分的基礎部分，還有詳細缺陷描述、上下文數據收集等沒做到呢!

　　所以讓機器像人一樣使用產品，并沒有解決全部問題，剩下的事情還有多少，這是需要視情況而定的。如果只是解決了第一個問題就認為萬事大吉，那簡直就是在賭運氣——有些時候自動驗證是小菜一碟，但很多時候不是。

　　令事情惡化的是，自動驗證了產品的一些指標，并不能反映產品的真實質量。有時驗證過的指標通過了，其實其他地方暴露了問題卻沒有檢查：比如說界面說沒有查 詢結果，這是期望的，實際上查詢請求根本沒有發過去，不去檢查底下做了什么的話是發現不了這種bug的;有時驗證過的指標不通過，其實只是個小問題，大問 題需要通過別的指標暴露出來的：比如說返回結果跟預期的不一致，實際上該有的都有，只是沒有排好順序而已，但是被標記成重要的測試用例沒有通過，把開發人員搞個雞飛狗跳。

　　這個話題深入下去，那就涉及到白箱測試策略、邏輯推演、嗅探和代碼注入以及布景偽造(environment mockup)等領域，但我想強調的只是，如果考慮自動化測試，自動驗證絕對不是可忽略的問題。

　　整合現有還是自力更生?

　　這個話題用于辯論賽是最好不過的，它符合“沒有定論“這個要求 。所以我只談一下使用每種手段時的一些不正確的假設。

　　“現有的工具多少經過測試，質量比自己做的更有保證“。先不在“是不是更有保證”這個話題上鉆牛角尖，我們先關注幾個問題：整個測試方案里面哪些部分是關 鍵，質量不好會導致致命后果的?這些部分有專人保證質量嗎?出事的時候反應時間和修復效果如何?如果這些問題的答案是“我充分了解”或者“沒問題”，那我 也同意這個觀點(我敢打賭，回答“不清楚”或者“很不妙”的人已經跑去重新考慮整個測試方案了)。

　　“整合現有的工具省時間和人力”。類似的幾個問題：你能在這些工具中自由地調試產品的缺陷嗎?整合方案能適應產品的演變嗎?幾個月后呢?幾個版本后呢?有需要變動的話代價多少?(嘩啦啦又跑掉一大隊人了)

　　“自力更生好控制”。投入產出比如何?引用的技術可靠嗎?如果你是開發者(之一)，別人都覺得好控制嗎?誰來測試你的自力更生成果?

　　“有些事情必須得自力更生“。剪裁現有工具難度如何?時間允許嗎?

　　其實，縱觀所有提出的問題，我想強調的一點是，自動化測試的開發跟產品開發一樣，也是需要規劃和管理的，回答這些問題也是自動化測試項目管理的一部分。

原文轉自：http://www.uml.org.cn/Test/200708291.asp