我并不是經(jīng)常能看到好的文檔。需求文檔常常象是市場銷售用的系統(tǒng)特性列表。規(guī)格說明書有時(shí)就象是在代碼完成后提交的用戶手冊文件。而設(shè)計(jì)文檔經(jīng)常不存在。
好了，通過針對交接所引起的變化的集中討論，我已把測試過程和軟件開發(fā)過程相對地分離開了。如果文檔中關(guān)于“XML支持功能加入到COMM”的描述很薄弱的話，我會盡自己所知來進(jìn)行盡可能好的測試設(shè)計(jì)。然后，假如在項(xiàng)目后期，XML相關(guān)的用戶文檔出來了，我就可以對后來再次提交的交接增加相關(guān)的測試。假如市場需求改變了，她們經(jīng)常會這么做，我還會在此后增加或者去除一些測試。所有這一切看起來是這樣的：
這樣，雖然項(xiàng)目文檔總是不到位，而且經(jīng)常延遲提交，測試的效果也因此常常被降低，我們還是要避免測試受到項(xiàng)目文檔的制約。
頭腦靈活的測試人員并不過于相信文檔。畢竟，總是人在犯錯誤。那么，難道不是人在寫這些文檔嗎？
由于“正式的”文檔是很薄弱的，測試模型必須明確地鼓勵在測試過程中使用項(xiàng)目文檔之外的各種不同信息來源。
測試人員必須和程序員、用戶、市場人員、技術(shù)作者以及任何的可能為實(shí)現(xiàn)更好測試提供線索的人進(jìn)行交流。測試人員還應(yīng)該努力把自己沉浸在某些技術(shù)所構(gòu)建的氛圍中。例如，我希望測試人員在做XML測試工作時(shí)常去訪問W3組織的XML地址（http://www.w3.org/XML/）以及其它XML站點(diǎn)、郵件列表，甚至包括比較特別的 如Dave Winer的DaveNet/腳本新聞（http://www.scripting.com/）。這些資源并不是所謂的“輔助通道”，而是可以被列入計(jì)劃和進(jìn)度日程的資源。
另外，所執(zhí)行的測試本身也是一種有用的信息的資源。好的測試人員會仔細(xì)閱讀bug報(bào)告，因?yàn)檫@些報(bào)告講授了系統(tǒng)所存在的薄弱之處。特別地，這些報(bào)告還暗示了一些正式的架構(gòu)設(shè)計(jì)所沒有提供的架構(gòu)上的策略。執(zhí)行測試的行為應(yīng)該產(chǎn)生一些新的測試想法。如果模型沒有考慮到這些，那么它就是一個(gè)落后的模型。
因此，測試模型應(yīng)該包含反饋的循環(huán)，讓測試設(shè)計(jì)可以考慮到，在運(yùn)行測試時(shí)還可以繼續(xù)發(fā)現(xiàn)到更多的測試內(nèi)容。
在我們的工作中，真正的復(fù)雜性來自于所有計(jì)劃的執(zhí)行都處于一個(gè)不確定的、容易忽略的環(huán)境里。代碼并不是唯一在不斷變化的東西。而計(jì)劃日程也在改變。新的功能擴(kuò)充會帶來新的里程碑。某些功能會從當(dāng)前版本中去除。在開發(fā)過程中，所有人——市場人員、開發(fā)人員和測試人員，都會逐漸對諸如“產(chǎn)品究竟提供什么”這樣的問題有越來越清晰的了解。在這些情形下，我們怎么能說測試計(jì)劃的第一個(gè)版本會是完全正確的呢？
因此，模型應(yīng)該要求測試計(jì)劃人制定明確的規(guī)定，對已交接的交接內(nèi)容，新的交接，以及交接內(nèi)容的變更進(jìn)行負(fù)責(zé)。
V模型有以下致命的缺陷，其它模型實(shí)際上也與此相似：
1. 忽略了這樣的事實(shí)情況，即軟件開發(fā)是由一系列的交接所組成，每一次交接內(nèi)容都改變了前一次交接的行為。
2. 依賴于開發(fā)文檔的存在，及文檔的精確性、完整性，并且沒有對時(shí)間進(jìn)行限制。
3. 認(rèn)定一種測試的設(shè)計(jì)是依據(jù)某一個(gè)單獨(dú)的文檔，而不包括根據(jù)其前后階段的文檔的修改而作相應(yīng)修改。
4. 認(rèn)定這些依賴于某個(gè)單獨(dú)文檔的測試一定要在一起執(zhí)行。
我大致描述了一個(gè)替代模型，但還不夠精細(xì)。它考慮到了代碼的交接和里程碑。對測試成本控制作了以下明確描述：
測試設(shè)計(jì)的目標(biāo)是定義好可能發(fā)現(xiàn)bug的測試輸入，而測試執(zhí)行的目標(biāo)是以各種方式加入這些數(shù)據(jù)，并檢驗(yàn)結(jié)果，由此來降低整個(gè)生命周期的成本。
我們的模型假設(shè)軟件產(chǎn)品總是不完美的，開發(fā)過程中有很多變更，而且對產(chǎn)品的測試也是一個(gè)不斷學(xué)習(xí)的過程。
過去，我很少考慮到模型。表面上我一直還在用V模型。雖然我按此制訂計(jì)劃，但我總是還要花費(fèi)很多額外的精力和時(shí)間來考慮模型中沒有提到的方面。換言之，模型造成了一些阻礙，因此我有必要對此進(jìn)行研究。
對一個(gè)新的模型來說，對模型所提出的要求必須非常明確，這就象業(yè)務(wù)需求對產(chǎn)品開發(fā)非常重要一樣。我希望自己對本文中所提倡的模型的要求的描述能夠和V模型中的描述一樣精確，并具有同樣的指導(dǎo)意義。
理想的測試模型應(yīng)該包括下列要求：
1. 使測試對項(xiàng)目中的每一次代碼交接有所反應(yīng)。
2. 要求測試計(jì)劃人制定明確的規(guī)定，對已交接的交接內(nèi)容，新的交接，以及交接內(nèi)容的變更進(jìn)行負(fù)責(zé)。
3. 在測試設(shè)計(jì)中，除了使用項(xiàng)目文檔外，還應(yīng)明確鼓勵使用其它各種信息，這些信息有不同來源。
4. 事實(shí)上項(xiàng)目文檔總是不到位，而且經(jīng)常延遲提交，測試的效果也因此常常被降低。但我們還是要盡量避免測試受到項(xiàng)目文檔的制約。
5. 允許根據(jù)多種來源提供的綜合信息來設(shè)計(jì)一些獨(dú)立的測試。
6. 讓測試被重新設(shè)計(jì)，以新的信息形式進(jìn)行表現(xiàn)。
7. 包含反饋的循環(huán)，讓測試設(shè)計(jì)可以考慮到，在運(yùn)行測試時(shí)還可以繼續(xù)發(fā)現(xiàn)到更多的測試內(nèi)容。
8. 讓測試人員認(rèn)識到，避免測試的延遲可以節(jié)省成本。
9. 在組件被組裝到程序中去之前對組件的執(zhí)行進(jìn)行測試。
感謝
是James Bach最早讓我認(rèn)識到，在測試計(jì)劃中應(yīng)考慮到交接。Noel
Nyman和Johanna Rothman在一份草案中提供了一些有幫助的評論。Kamesh Pemmaraju和Carol Stollmeyer使我終于沒有放棄對原理的辯解和闡述，不僅是在細(xì)節(jié)方面，也在實(shí)際生活中，以及每一個(gè)實(shí)際項(xiàng)目中。他們給了我很大的促進(jìn)，使我去反復(fù)地思考問題。
參考
[Boehm88]
Barry W. Boehm, “A Spiral Model of Software Development and Enhancement,” IEEE Computer, 1988年5月
[IEEE98]
"IEEE Standard for Software Test Documentation," IEEE標(biāo)準(zhǔn)829-1998, 電子和電氣工程師學(xué)會, 1998
[Marick98]
Brian Marick, “When Should a Test be Automated?” 國際質(zhì)量周刊,1998年5月（ftp://ftp.rstcorp.com/pub/papers/automate.pdf）
