軟件測試的新模型(5)

　　另外，所執行的測試本身也是一種有用的信息的資源。好的測試人員會仔細閱讀bug報告，因為這些報告講授了系統所存在的薄弱之處。特別地，這些報告還暗示了一些正式的架構設計所沒有提供的架構上的策略。執行測試的行為應該產生一些新的測試想法。如果模型沒有考慮到這些，那么它就是一個落后的模型。

　　因此，測試模型應該包含反饋的循環，讓測試設計可以考慮到，在運行測試時還可以繼續發現到更多的測試內容。

　　在我們的工作中，真正的復雜性來自于所有計劃的執行都處于一個不確定的、容易忽略的環境里。代碼并不是唯一在不斷變化的東西。而計劃日程也在改變。新的功能擴充會帶來新的里程碑。某些功能會從當前版本中去除。在開發過程中，所有人--市場人員、開發人員和測試人員，都會逐漸對諸如“產品究竟提供什么”這樣的問題有越來越清晰的了解。在這些情形下，我們怎么能說測試計劃的第一個版本會是完全正確的呢?

　　因此，模型應該要求測試計劃人制定明確的規定，對已交接的交接內容，新的交接，以及交接內容的變更進行負責。

　　總結

　　V模型有以下致命的缺陷，其它模型實際上也與此相似：

　　1. 忽略了這樣的事實情況，即軟件開發是由一系列的交接所組成，每一次交接內容都改變了前一次交接的行為。

　　2. 依賴于開發文檔的存在，及文檔的精確性、完整性，并且沒有對時間進行限制。

　　3. 認定一種測試的設計是依據某一個單獨的文檔，而不包括根據其前后階段的文檔的修改而作相應修改。

　　4. 認定這些依賴于某個單獨文檔的測試一定要在一起執行。

　　我大致描述了一個替代模型，但還不夠精細。它考慮到了代碼的交接和里程碑。對測試成本控制作了以下明確描述：

　　測試設計的目標是定義好可能發現bug的測試輸入，而測試執行的目標是以各種方式加入這些數據，并檢驗結果，由此來降低整個生命周期的成本。

　　我們的模型假設軟件產品總是不完美的，開發過程中有很多變更，而且對產品的測試也是一個不斷學習的過程。

　　過去，我很少考慮到模型。表面上我一直還在用V模型。雖然我按此制訂計劃，但我總是還要花費很多額外的精力和時間來考慮模型中沒有提到的方面。換言之，模型造成了一些阻礙，因此我有必要對此進行研究。

　　對一個新的模型來說，對模型所提出的要求必須非常明確，這就象業務需求對產品開發非常重要一樣。我希望自己對本文中所提倡的模型的要求的描述能夠和V模型中的描述一樣精確，并具有同樣的指導意義。

　　理想的測試模型應該包括下列要求：

　　1. 使測試對項目中的每一次代碼交接有所反應。

　　2. 要求測試計劃人制定明確的規定，對已交接的交接內容，新的交接，以及交接內容的變更進行負責。

　　3. 在測試設計中，除了使用項目文檔外，還應明確鼓勵使用其它各種信息，這些信息有不同來源。

　　4. 事實上項目文檔總是不到位，而且經常延遲提交，測試的效果也因此常常被降低。但我們還是要盡量避免測試受到項目文檔的制約。

　　5. 允許根據多種來源提供的綜合信息來設計一些獨立的測試。

　　6. 讓測試被重新設計，以新的信息形式進行表現。

　　7. 包含反饋的循環，讓測試設計可以考慮到，在運行測試時還可以繼續發現到更多的測試內容。

　　8. 讓測試人員認識到，避免測試的延遲可以節省成本。

　　9. 在組件被組裝到程序中去之前對組件的執行進行測試。

　　感謝

　　是James Bach最早讓我認識到，在測試計劃中應考慮到交接。Noel

　　Nyman和Johanna Rothman在一份草案中提供了一些有幫助的評論。Kamesh Pemmaraju和Carol Stollmeyer使我終于沒有放棄對原理的辯解和闡述，不僅是在細節方面，也在實際生活中，以及每一個實際項目中。他們給了我很大的促進，使我去反復地思考問題。

原文轉自：http://www.uml.org.cn/Test/test47.htm