自動化測試整合的問題

自動化測試整合的問題

陳能技2007-12-30

原文：inte***ce or interfere?-the issue of integration

（linda hayes

）跟蹤需求到自動化測試用例，看起來是很自然而非常需要的，但是坦白說我從來沒有看到這發生，並且對其感到困惑。我一直認為這是因為需求被掩蓋了或者是過於高層次，以致不支援可跟蹤性。雖然那可能在某些情況下是真的，但是並不完全是真的。

一位經驗豐富的測試經理告訴我，為什麼她不把需求跟蹤到她的自動化測試用例中去。

她指出：大部分工具都允許需求鏈結到測試指令碼，但是任何進行工業級的自動化的人都會把指令碼做得可重用並把測試用例轉換成資料。理論上你也可以把需求標識到每一條資料記錄中，但是這樣會使跟蹤更改變得棘手，因為資料通常儲存為文字而需求標識儲存為資料庫的鍵。

此外，她注意到編寫得好的測試用例實際上就是有效的需求，因此沒有必要在其他地方複製相同的資訊。她的測試用例都有字段描述測試的執行條件，她用這個欄位來文件化需求。實際上，她發現乙個典型的需求管理系統允許在描述需求時存在太多的偏差，導致不明確和前後矛盾，然而，乙個測試用例必須細化和足夠明確，以便被執行。

當然並不是每個人都知道需求，但是每個人都會有缺陷。那麼與缺陷跟蹤系統做個介面如何？畢竟，乙個全面的自動化測試套件應該發現需要**獲和解決的問題。但是，同樣的，並不是那麼的簡單。

我們有乙個顧客要求我們的自動化測試框架與他的顧客缺陷管理系統整合，我們花費了大量的成本和精力來做。當我們的下乙個版本出來的時候，我聯絡他，以便驗證針對他的介面的修改是否正確，但是出乎我的意料，他竟然說他沒有再用它。當然，我想知道為什麼。

他說有3

個原因。首先，當乙個自動化測試失敗時，有很多可能的原因：測試環境可能未正確地配置；測試資料可能未同步；測試指令碼本身可能有一些問題；或者軟體有一些問題。只有

1/4的機會是真正的軟體缺陷。作為乙個慣例，他的測試人員會檢查測試日誌的錯誤，然後做出診斷

– 通常包括手工的重新執行測試

– 來揭露問題的原因。

這意味著他們需要把那些非軟體的問題篩選出來。這個過程是極其耗費時間的，因為他們執行冗長的測試套件，而測試資料問題可能引起上百個錯誤。即便是軟體的問題，它也可能引起多個錯誤，因此會建立多個重複的問題報告。這些缺陷會使他們的缺陷庫極度地膨脹，影響缺陷的關閉率，因此影響用於預計發布日期用的典型的

s曲線報告。

另外，等到他們需要做出缺陷的分析和結論時，他們要提供的資訊和分析報告要比測試日誌能提供的多很多。他們仍然需要從缺陷管理系統中抽取問題資訊並新增額外的資訊，因此並沒有節省時間。

最後，他說，在自動化測試中，出現失敗的指令碼或步驟未必就是問題的真正根源。往往問題的真正起因發生在比測試的錯誤日誌記錄更早的之前，因此與測試日誌的資訊沒有非常密切的關係。總之，他覺得整合是麻煩多於帶來的價值。

因此，我的任務是找出這些問題是個別的還是規律，或者是否有其他途徑來使整合更加高效

…或者沒有。你的發現是什麼呢？