軟件測試的新模型(4)

　　3. 對測試設計和執行的周期和成本進行估計。

　　4. 在項目進度上的特定位置，將計劃納入執行的行動：

　　A. 開始對測試進行設計…

　　B. … 同時設計和創建一些支持測試的代碼…

　　C. … 在全部測試完成以前就執行部分的測試，因為可能存在不只一次的交接，在每一次交接的測試規劃中，可能存在一些潛在的復雜的相互影響。工作安排不得不進行一些調整以達到相互間的平衡。測試支持代碼和工具需要在各項任務中得到共享。你還必須考慮到在什么程度上讓那些為早先的交接所設計的測試在以后重新執行，等等。

　　這看起來很復雜?？瓷先ニ坪跤刑嗟膬热菪枰?，而且太多的內容可能被忽略。也許你認為我是在要求你要對每一次交接來執行IEEE 829 [IEEE98]中關于測試計劃的要求，然后把它們合并為一份貫穿整個項目的針對交接進行測試的測試計劃。

　　是，也不是。思考問題總是要占用時間的。太多的計劃可能會減少結果的產出。在有些時候，你需要做的是停止計劃并開始行動。例如，你無法思考并描述每一個bug修復，盡管bug修復也是一種交接。

　　但是bug修復是實際工作中現實存在的問題?？傮w項目計劃中應該包含bug修復。需要強調的是，你應該有一個默認的bug修改處理的標準過程，該過程應包括運行于每一個提交的bug修復的驗證過程。你還需要努力地去思考問題。很多時候，各項驗證是被放在一起同時進行并完成的。

　　比較現實地來說，一個模型應該允許一些機械式行為，例如，“不管是哪一個X類型的交接，都要執行下列操作”。同時我們鼓勵對特定的交接執行剛剛夠的檢查，對于風險越小的交接，就越可以采用機械式的測試行為。

　　一個明確考慮到基本的測試現實的模型肯定會比忽略這些現實或者把你的工作復雜性完全抽象化的模型做得更好。文檔則是另一個例子。

　　我還沒有提到需求及規格說明書，或者設計文檔。某個交接中產生的一系列變化會引起很多爭議。這些文檔所扮演的角色是什么呢?它們常常是這么被使用的：

　　(圖10：測試中對開發文檔的利用)

　　文檔可以指導你在一個交接變化時如何作出反應。如果你有一份很好的需求文檔，它可能是產品所解決的問題的描述，盡管也許不是很直接。它可以幫助你對風險進行分析。一份好的規格說明應對系統的行為進行描述。這將幫助你把測試方法轉化為具體的測試。一份好的架構設計則可以幫助你理解變化可能引起的幾種不同的情況：系統的其它部分會受到怎樣的影響?什么測試需要再次進行?

　　我并不是經常能看到好的文檔。需求文檔常常象是市場銷售用的系統特性列表。規格說明書有時就象是在代碼完成后提交的用戶手冊文件。而設計文檔經常不存在。

　　好了，通過針對交接所引起的變化的集中討論，我已把測試過程和軟件開發過程相對地分離開了。如果文檔中關于“XML支持功能加入到COMM”的描述很薄弱的話，我會盡自己所知來進行盡可能好的測試設計。然后，假如在項目后期，XML相關的用戶文檔出來了，我就可以對后來再次提交的交接增加相關的測試。假如市場需求改變了，她們經常會這么做，我還會在此后增加或者去除一些測試。所有這一切看起來是這樣的：

　　(圖11--在文檔不完整的條件下進行測試，并在后期補充測試)

　　這樣，雖然項目文檔總是不到位，而且經常延遲提交，測試的效果也因此常常被降低，我們還是要避免測試受到項目文檔的制約。

　　頭腦靈活的測試人員并不過于相信文檔。畢竟，總是人在犯錯誤。那么，難道不是人在寫這些文檔嗎?

　　由于“正式的”文檔是很薄弱的，測試模型必須明確地鼓勵在測試過程中使用項目文檔之外的各種不同信息來源。

　　測試人員必須和程序員、用戶、市場人員、技術作者以及任何的可能為實現更好測試提供線索的人進行交流。測試人員還應該努力把自己沉浸在某些技術所構建的氛圍中。例如，我希望測試人員在做XML測試工作時常去訪問W3組織的XML地址(http://www.w3.org/XML/)以及其它XML站點、郵件列表，甚至包括比較特別的 如Dave Winer的DaveNet/腳本新聞(http://www.scripting.com/)。這些資源并不是所謂的“輔助通道”，而是可以被列入計劃和進度日程的資源。

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