一位經驗豐富的測試經理告訴我，為什么她不把需求跟蹤到她的自動化測試用例中去。
她指出：大部分工具都允許需求鏈接到測試腳本，但是任何進行工業級的自動化的人都會把腳本做得可重用并把測試用例轉換成數據。理論上你也可以把需求標識到每一條數據記錄中，但是這樣會使跟蹤更改變得棘手，因為數據通常存儲為文本而需求標識存儲為數據庫的鍵。
此外，她注意到編寫得好的測試用例實際上就是有效的需求，因此沒有必要在其他地方復制相同的信息。她的測試用例都有字段描述測試的執行條件，她用這個字段來文檔化需求。實際上，她發現一個典型的需求管理系統允許在描述需求時存在太多的偏差，導致不明確和前后矛盾，然而，一個測試用例必須細化和足夠明確，以便被執行。
當然并不是每個人都知道需求，但是每個人都會有缺陷。那么與缺陷跟蹤系統做個接口如何？畢竟，一個全面的自動化測試套件應該發現需要被捕獲和解決的問題。但是，同樣的，并不是那么的簡單。
我們有一個顧客要求我們的自動化測試框架與他的顧客缺陷管理系統整合，我們花費了大量的成本和精力來做。當我們的下一個版本出來的時候，我聯系他，以便驗證針對他的接口的修改是否正確，但是出乎我的意料，他竟然說他沒有再用它。當然，我想知道為什么。
他說有3個原因。首先，當一個自動化測試失敗時，有很多可能的原因：測試環境可能未正確地配置；測試數據可能未同步；測試腳本本身可能有一些問題；或者軟件有一些問題。只有1/4的機會是真正的軟件缺陷。作為一個慣例，他的測試人員會檢查測試日志的錯誤，然后做出診斷 – 通常包括手工的重新執行測試 – 來揭露問題的原因。
這意味著他們需要把那些非軟件的問題篩選出來。這個過程是極其耗費時間的，因為他們運行冗長的測試套件，而測試數據問題可能引起上百個錯誤。即便是軟件的問題，它也可能引起多個錯誤，因此會創建多個重復的問題報告。這些缺陷會使他們的缺陷庫極度地膨脹，影響缺陷的關閉率，因此影響用于預計發布日期用的典型的S曲線報告。
另外，等到他們需要做出缺陷的分析和結論時，他們要提供的信息和分析報告要比測試日志能提供的多很多。他們仍然需要從缺陷管理系統中抽取問題信息并添加額外的信息，因此并沒有節省時間。
最后，他說，在自動化測試中，出現失敗的腳本或步驟未必就是問題的真正根源。往往問題的真正起因發生在比測試的錯誤日志記錄更早的之前，因此與測試日志的信息沒有非常密切的關系�？傊�，他覺得整合是麻煩多于帶來的價值。
因此，我的任務是找出這些問題是個別的還是規律，或者是否有其他途徑來使整合更加高效…或者沒有。你的發現是什么呢？
文章來源于領測軟件測試網 http://www.kjueaiud.com/
