軟件測試的新模型(3)

　　因此，模型必須允許利用不同來源的綜合信息進行個別的測試設計。另外，模型還應該允許在新的信息來源出現后重新進行測試的設計。

　　一個不同的模型

　　讓我們來看本文的第二項內容，一個不同的模型。

　　很多時候人們把代碼移交給其他人，并且說：“希望你能接受和喜歡它。”這不僅發生在將整個項目放在一張光盤中交給客戶的時候，也發生在項目內部。

　　例如，一個小組對另一個小組說：“我們已經完成了為COMM庫加入了對XML的支持。源代碼現在已經放在master庫中，可執行庫則已經加入到集成與創建的環境中。XARG小組的工作已經沒有什么阻礙了，隨時去取吧。”

　　某個程序員檢查了bug的修改并且發出郵件：“我已經修改了Bug列表中的那個Bug，很抱歉!”至此，早先受該問題影響的其它代碼就可以繼續處理了。

　　在這些情況下，人們要把代碼移交給其它人，其中有可能會存在一些影響。測試人員需要干預這個過程。在移交之前，測試人員應執行這些代碼，發現其中的 bug(影響)，并且提出問題：“你確實要提交這些嗎?”由此，移交的內容可能會被延期，直到bug被修復好。

　　盡管你還要做其它的各種測試，這項測試仍然是很基本的測試工作。如果你沒有做這樣的測試，就不能算是合格的測試人員。

　　我們的測試模型必須包含這一重要的現實需要：針對代碼移交的測試。由此，測試模型應提示進行針對每一次代碼移交的測試。

　　就讓我以支持XML的COMM庫作為例子。這里存在著一個小組把代碼移交給XARG小組以進行項目的余下部分。那么誰會遭受影響?

　　要將這些支持XML的代碼直接進行使用的XARG小組可能會立即受到影響;

　　這可能會在稍后影響到市場人員，他們要在一個行業展示會議上為“合作伙伴發行”版本提供產品演示和宣傳，而XML支持是影響他們銷售的重要部分;

　　還有，它可能損害采納我們的產品的合作伙伴。

　　現在我們可以提出一些有趣的關于測試計劃的問題了。最簡單的可以做的事情是，在移交的時候立即執行XML支持的完整測試。(“完整”的含義是，為此設計盡可能多的測試)但也許一些XML特性并不是XARG小組所需要的，因此可以把它們放在合作伙伴版本封版(下圖中的“Partner Release”)的測試中去。這意味著可以把一些XML相關測試放到稍后的移交過程中去?；蛘呋谄渌碛?，例如在近階段有其它的測試任務要執行。而 XARG小組則要因XML中的bug修復而延遲一小段時間。

　　我們的測試計劃所表示的進度可以通過在開發的時間線上進行注解的方式來表現，如下圖所示：

　　(圖9：添加在開發計劃之上的測試計劃)

　　我們應嚴格地圍繞在XML支持的功能交接的時段里進行測試。測試設計和測試支持工作要早于測試執行。而另外的XML測試則要延遲到基于整個項目范圍的“代碼完成”(圖中的“Code Complete”里程碑)，或者要等到全部的子系統被集中在一起，而且整個產品為了行業會議而在經過穩定化處理后創建了版本(圖中的“Partner Release”里程碑)。

　　顯然，有兩項內容沒有包含在代碼完成里程碑中：

　　還有大量其它的測試工作(包括設計、工具選用)。這些工作可能因為COMM以外的子系統的交接而延期。

　　而且，還有用于完成里程碑中所規定的某些風險的測試，例如，可能還有一組用于運行市場人員的演示Demo腳本的測試，包括她可能在無意中引起的偏離。其目的是要避免這樣的情況，即當她站在1000人的觀眾面前時，她還僅僅是第一次以某種特定的順序來輸入數據。

　　一些首次交接時進行的XML測試需要在代碼完成里程碑上再次執行。

　　我的觀點是，測試計劃是由很多困難的決定所組成，這些決定包括人員組織安排、機器資源配置、測試設計的時間定位、測試支持代碼的數量、哪些測試要做自動化，等等。這些決定應根據單獨的交接中的內容信息來作出。如果僅有一次交接，那么你可以更順利一些。測試計劃還應繼續考慮以下問題：

　　1. 風險分析，誰會因此受到損害，以什么方式?

　　2. 選定一種測試途徑來定位特定的風險。

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