針對代碼移交的測試

　很多時候人們把代碼移交給其他人，并且說：“希望你能接受和喜歡它?！边@不僅發生在將整個項目放在一張光盤中交給客戶的時候，也發生在項目內部。 例如，一個小組對另一個小組說：“我們已經完成了為COMM庫加入對XML的支持。源代碼現在已經放在master庫中，可執行庫則已經加入到集成與創建的環境中。XARG小組的工作已經沒有什么阻礙了，隨時去取吧?！?

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

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

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

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

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

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

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

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

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

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

　　

　　圖1 添加在開發計劃之上的測試計劃

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　

　　圖2 測試中對開發文檔的利用

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

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

　　

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

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

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

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

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

　　另外，所執行的測試本身也是一種有用的信息的資源。好的測試人員會仔細閱讀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使我終于沒有放棄對原理的辯解和闡述，不僅是在細節方面，也在實際生活中，以及每一個實際項目中。他們給了我很大的促進，使我去反復地思考問題。

　　參考

　　[Boehm88]

　　Barry W. Boehm, “A Spiral Model of Software Development and Enhancement,” IEEE Computer, 1988年5月

　　[IEEE98]

　　"IEEE Standard for Software Test Documentation," IEEE標準829-1998, 電子和電氣工程師學會, 1998

　　[Marick98]

　　Brian Marick, “When Should a Test be Automated?” 國際質量周刊,1998年5月(ftp://ftp.rstcorp.com/pub/papers/automate.pdf)

原文轉自：http://www.anti-gravitydesign.com