關鍵詞：
軟件測試 過程實踐 測試用例 RUP
RUP(Rational Unified Process ，Ratinaol 統一過程)是rational公司提出的一套軟件開發過程，目前最新的版本是2003。RUP的最大特點就是它提供了一套完整的軟件開發過程框架，任何人或組織都可以根據自己的需要來對這個過程進行裁剪，并根據自身需要進行調整后使其成為個性化的過程。讀者可以參考網絡上流傳的《RUP2000中文版》。
(Rational以及 Rational Unified Process 均系 Rational Software Corporation 在美國和其他國家的商標或注冊商標。)
有句老話說：萬事開頭難。說的是在做事情的時候，通常都是一開始覺得非常困難，但是只要上了道，入了門，就會越來越容易、越來越順了。寫文章也是如此。不過筆者這里說的開頭難并不是不會寫文章，而是專指不會寫文章的開頭部分。過去看到過的很多小說，無論是言情的或者武俠的，都會拿很長的篇幅出來作為“引子”，或者叫“楔子”，用來交待一些同小說相關的信息。而一部小說是否能夠吸引讀者，這部分內容也起了很大的作用。不過，筆者作為一個技術工作者，寫的大多數都是技術文章，一般來說文章的內容、結構都是一早就想明白的，唯獨這個開頭，實在不知如何寫起。不過想想也罷，既然不擅長這個，那就努力把內容寫的詳細、易懂一些，盡量讓讀者不會有上當的感覺吧。
軟件測試作為一個獨立的職位或者說行業，并不是軟件業的新生事物，但的確是隨著最近兩年一些新的思想注入國內軟件行業(比如敏捷開發過程、測試驅動開發等)，才得以紅火起來的——這一點，從相關書籍的出版和銷售就可以看得出來，從事軟件測試工作的人也漸漸多了起來。但是也因為是剛剛起步，同時國內大多數軟件公司都還處在中小型開發團隊甚至作坊式開發的層次，不可能提供太多的測試職位，想找到一些高水平并且富有經驗的測試人員更是難上加難。這最終也就導致了國內大多數測試從業者都處在“初級階段”這樣一個結果。
筆者長期活躍在國內的幾個比較知名的測試論壇，發現大家希望討論的問題主要可以分為兩種：一種是對于一些測試工作具體操作方法的提問，一種是對于測試工具使用的提問�？傮w看來，更多的問題集中在了后者。這似乎已經成為了國內軟件業的通病，無論是開發還是測試，總希望可以通過某個工具或者語言來一勞永逸的實現某個理想。如果真的希望工具可以改變一切，那么這種愿望總是會落空的。而前者，大多是因為進入了一些剛剛開始重視軟件測試的中小型軟件公司，而公司的開發團隊中負責軟件測試的可能只有一兩個對軟件測試一知半解的新手，當公司需要開展某些方面的測試工作時，缺少這部分相關經驗的朋友變選擇了通過網絡求助。
測試工具的應用，的確可以提高工作效率，而對于測試工具方面的提問，本來也是無可厚非的，但是在筆者的實踐中，如果希望提高一個團隊的工作效率和改善工作效果，關注于過程和方法要遠遠好于關注工具。測試工具的學習、引入和使用，本身就是一個需要消耗大量資源的過程，而且對于工具的選擇和引入工具時機的選擇也是非常關鍵的，如果負責這項工作的并不是一位在軟件行業沉浸多年，有著豐富測試經驗并熟知開發過程的資深人士，那么開發團隊將為此承擔巨大的風險。即使成功的引入了測試工具，工具本身可以帶來的效率的提高也不是在短期內可以體現的。
在這里，筆者希望剛剛或者正在準備組建測試團隊的軟件公司在考慮測試流程的搭建和測試工具引入時，不要給剛剛進入測試行業的朋友太多壓力，因為這兩項工作都不僅僅同軟件測試本身相關，同時也會涉及到項目管理、開發過程方面的內容。輕易的做出一個決定只會對將來在團隊中測試工作的開展帶來不利的影響。
在這篇文章中，筆者不打算對測試工具方面的問題提出任何建議，而將對網絡上大家關注的測試過程和測試方法方面給出一些具有實際參考價值的經驗。
測試工作應該什么時候開始?
測試用例是不是一定要寫?如果寫，應該詳細到什么程度才會比較好用又容易維護?
文章來源于領測軟件測試網 http://www.kjueaiud.com/
