那年頭，JAVA沒有什么Struts-Spring-Hibernate，有我也不會；Oracle會簡單寫點存儲過程、函數啥的；Linux會點基本操作命令；Weblogic會點簡單配置。當我連C/S和B/S有啥區別都不清楚的時候，我就正式開始參與項目編碼了。
項目周期短，工作量大。我估計了下，從開始到結束，大概有接近三個月的時間沒有一天休息，每天是8：30到9：30，忘說了，公司“法定”每周上六天班。有一次實在熬不住，下班就回宿舍了。第二天一上班，迎接我的就是狂風暴雨。這里奉勸下諸位應屆生，除非你真的天質過人、才華橫溢，或有相當的背景，否則就夾著尾巴乖乖做人。老鳥都沒走你憑啥走，沒事做？沒事也要在這傻坐著！
還有件事也是我一直刻骨銘心的。
走廊上碰見領導，領導問：“進度怎么樣？”
我：“還可以�！�
領導一邊往廁所走一邊問：“什么叫還？有什么問題？”
我跟著領導往廁所走：“沒有沒有�！�
領導站那噓噓：“年輕人要謙虛，多象老員工學習�！�
我在旁邊連連點頭：“一定一定�！�
領導抖了兩抖，收拾好后拍了拍我的肩：“好好干�！�
我臉上堆滿笑容：“明白明白�！�
這就是社會。
看著現在很多應屆生對身處的環境不滿，你們他媽的有什么不滿的。
項目結束后，很順利的，我漲工資了。
小記：做人要靠自己。
一直想通過故事把工作幾年對軟件行業，特別是軟件測試的種種個人想法匯總表達出來。
個人博客上一直斷斷續續在寫，但不連貫，只是些零散的思考。
這次是準備花功夫寫下。
前面主要是鋪墊，后面就準備融入軟件測試來敘述了。
在項目期間有幾件事要講。
第一個是我頭發剪了。項目期間，全國四十幾個省市的政府單位來參觀，活動做的很大。插一句，在這家公司說一百樣不好，但有一樣是公認的，那就是實實在在開闊了眼界，包括后來溫JB都來視察過。為避免影響市容，開大會的時候老總專門點名說那個誰發型要換下，但我沒聽。后來在機房調試的時候，另一個老總加兩位總監跑過來說這發型真不合適，沒辦法，只有剪了，本來還想留長點扎辮子的。
理發店就在宿舍隔壁，看著不起眼，剃完收了我60，MB。隔天到公司又引起轟動，魯迅變成瘌痢頭啦。
第二個是喝酒。我們一幫武漢過來的，包括后來又陸陸續續來的幾個，長發美女也來了，一起在宿舍樓下大排檔喝酒。結果其他人還好，長發美女和B喝多了。不知道受了啥刺激，兩人在樓下抱頭痛哭，我和S怎么攔都攔不住。左鄰右舍看著都以為是咱倆干了什么天怒人怨的事，最后還是S麻利，直接往肩膀上一扛，一人一個扛了上去。后來我和老婆說起這件事，她打死不承認，鄙視！
第三個，我不想做開發了�，F在回想起來，根源上應該是對編碼沒興趣。但做測試也要編碼啊，特別是我離開開發也沒有直接做測試，而是做了段時間DBA、 SA、SCM、售前，最后才轉到測試的。為什么不想做開發？這問題我也問了自己好久。最后才明白，不是不想做開發，而是單單對編碼沒興趣，并且沒興趣的原因是我不擅長，或者說我認為自己的天賦不在這上面。經過這幾年，也慢慢驗證了這一點，我更擅長的領域是需求分析、系統設計、項目管理，喜歡做前瞻性、預演性的工作，看來當年的決定沒錯。
許多人都曾經問我，為什么總能保持這種旺盛的精力，這種對工作的激情。無他，知之者不如好知者，好之者不如樂之者，如此而已。
就這樣，我一面忍氣吞聲的做項目，一面勾搭長發美女，一面準備轉崗。
小記：成功＝99％的努力＋1％的天份，也就是說沒有那1％的天份永遠成功不了，秀才永遠比不上天才。每個人或多或少都有屬于自己的天份，一定要正確找到自己的天份，很多時候往往和興趣是一致的。
再記：郭靖有天份嗎？有——“毅力”。這種天份無與倫比！
記憶中，大概是2002年底離開開發職位的。在沒轉測試前中間做過幾個不同的職位，但時間都不長。其中映象最深的是Oracle DBA，當時公司用的是Oracle 9i。要說我對數據庫了解有多深那是吹牛，但我對數據庫確實很敏感。
剛來的時候F買了本Oracle 9i管理員手冊，厚厚的一本，叫囂要一周內看完。我勸他，這又不是看小說，重點在于理解運用，他不聽。后來在某個項目設計數據庫的時候，會上他侃侃而談，實際操作卻一籌莫展，最后還是我做的，坐實了紙上談兵這四個字。這也是后來我轉DBA很順利的原因之一。過了幾年后，我再次兼任DBA，發覺當初的一點基礎還在。一方面是工作幾年一直都在和Oracle打交道；另一方面是除了測試外我對數據庫的興趣最濃。
廢話少說，總之期間兜兜轉轉一大圈，最后終于轉到軟件測試上了。也是我持之以恒，到今天也不離不棄的行業。具體轉入的時間真記不清了，只記得在后來差不多一年的時間里，我連升三級，當然工資也漲了三次。在我2003年底離開公司的時候，周圍同事說：“cx走了，公司沒人懂測試了�！边@句話是對我第一份工作最大的肯定。
在這不到一年的測試工作中，從對軟件測試一無所知，到測試部門主管，其中發生的事情太多太多，各位看官且聽我慢慢道來。
對了，還有件小事。2002年11月9日21點37分，我和長發美女確定關系了，開始了漫長的六年的馬拉松式愛情長跑。
小記：聞道有先后，術業有專攻，如是而已。
剛接觸軟件測試的人員一般都是由功能測試開始，很多人也認為是黑盒測試，也有稱之為數據驅動測試的。一般說的黑盒測試方法包括：等價類劃分、邊界值分析、因果圖、判定分析表、正交實驗設計等。其實這些方法在白盒測試中運用的也不少。
等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭示程序中的錯誤都是等效的。等價類劃分的辦法是把程序的輸入域劃分成若干具有相同特性的部分，然后從每個部分中選取少數代表性數據當作測試用例。
所謂邊界條件，是相對于輸入情形，輸出等價類直接在其邊緣上，稍高于其邊界和低于其邊界的這些狀態條件。邊值分析是對等價類劃分的有效補充。
因果圖著重分析輸入條件的各種組合，每種組合條件就是“因”，它必然有一個輸出的結果，這就是“果”。而在一些數據處理問題中，某些操作是否實施依賴多個邏輯條件的取值，即在這些邏輯條件取值的組合所構成的多種情況下，分別執行不同的操作。處理這類問題的一個非常有力的分析和表達工具是判定表。通常，因果圖和判定分析表是結合起來使用的。
正交實驗設計是從大量的實驗點中挑選出適量的、有代表性的點，應用依據伽羅瓦理論導出的“正交表”，合理地安排實驗的一種科學的實驗設計方法。它其實是組合測試里的一個分支，組合測試是什么后面再講。
除此之外，還有組合測試、基于模型測試、錯誤推測、測試場景分析、隨機測試、猴子測試等很多測試方法。其中場景分析是近幾年我常用的測試設計方法。組合測試、基于模型測試這兩種是各大高校、科研機構的重點研究對象，每年發布的論文有不少。題外話，我對這兩種方法不感冒。
很多測試新人一接觸測試就拼命看這些資料，其實最開始要了解測試思想。
首先，如果從標準論來看軟件測試，可以定義為軟件測試就是"驗證（Verification）"和"有效性確認（Validation）"活動構成的整體，即軟件測試 = V&V。"驗證"是檢驗軟件是否已正確地實現了產品規格書所定義的系統功能和特性。驗證過程提供證據表明軟件相關產品與所有生命周期活動的要求（如正確性、完整性、一致性、準確性等）相一致。相當于，以Spec為標準進行軟件測試活動，驗證軟件產品和Spec的一致性。"有效性確認"是確認所開發的軟件是否滿足用戶真正需求的活動。相當于，保持對軟件需求定義、設計的懷疑，一切從客戶出發，理解客戶的需求，發現需求定義和產品設計中的問題。這主要通過各種軟件評審活動來實現。
其次，業內有兩種截然相反的指導思想。一種認為要驗證軟件是"工作的"，以正向思維，針對軟件系統的所有功能點，逐個驗證其正確性。其代表人物是軟件測試領域的先驅Dr. Bill Hetzel （代表論著《The Complete Guide to Software Testing》)。另一種認為要證明軟件是"不工作的"，以反向思維方式，不斷思考開發人員理解的誤區、不良的習慣、程序代碼的邊界、無效數據的輸入以及系統的弱點，試圖破壞系統、摧毀系 統，目標就是發現系統中各種各樣的問題。其代表人物是G.J.Myers（經典著作《The Art of Software Testing》)。他給出了與測試相關的三個重要觀點：測試是為了證明程序有錯，而不是證明程序無錯誤；一個好的測試用例是在于它能發現至今未發現的錯誤；一個成功的測試是發現了至今未發現的錯誤的測試。這兩種都有很多的擁護者。在我所見過的測試活動中，采用第一種指導思想進行測試工作的多，特別是設計測試用例的時候。
當思想與基本方法了解的差不多了，是不是就可以開始做測試設計了？當然不行，還要熟悉業務。2004年在北京的時候和當時雅虎中國的技術總監交流，我說我一直想尋找一種方法可以跨行業開展工作，說白了不熟悉業務也能進行測試，回答是做夢。到現在2009年，我還是想尋找這么一種方法。這也是我認為測試理論、方法高于測試技術、手段的原因。
準備工作做好，可以嘗試做下測試設計了。我的做法是，拿到PRD，按照因果圖、判定分析表的規則進行業務、功能分析，然后針對每個功能進行等價類劃分、邊界值分析。恕我數學沒學好，正交試驗設計每次用到一半就進行不下去了。
當然，現在測試設計時采用的方法已經不同。更多的是使用路徑法劃分功能點，場景法設計業務流程。
業內還有個爭論，是否需要編寫詳盡的測試用例？我當時沒這些過多的想法，只知道熟能生巧。所以在自己學習及后來參與的前幾個項目中，畫了大量的圖（幾百幅是有的），寫了大量的測試用例（幾萬個是有的）。量變到質變這句話是有道理的。再后來一拿到PRD，腦海里就會自動拆分功能點，自動梳理業務流程。歷史總是驚人的重復發生，項目也一樣。當你做了上百個項目后，你會發現開展的測試活動大同小異。也許，此時只有大型（比如項目團隊人員規模在千人左右）、超大型、非常有特點的項目才能吸引你。
緊跟著做的幾個項目沒什么好說的，無非就是從測試需求分析開始，然后經過測試團隊組建、測試環境構建、測試計劃、測試設計、測試實施、測試結果收集與分析、測試總結等階段，最后項目結項。
測試流程、測試模型啥的后面再說。這里要先敘述下和Intel合作的一個測試項目，就是這個項目，給我打開了一扇嶄新的測試大門。
小記：我亦無他，唯手熟爾。
傳說中的Intel，一說起它不知道別人首先想到的是什么，我腦海里最先出現的是“嘣～嘣嘣嘣嘣”。
和Intel合作的是一個系統集成測試項目，這樣說可能很多人不明白，啥叫系統集成？去google。公司是家系統集成商，當時有個大項目要評估下硬件平臺、軟件平臺的支撐能力。硬件平臺選擇的是Intel的安騰系列，軟件平臺選擇的是Redhat AS 3、Oracle 9.2.0.2、Weblogic 6、Openldap，仿佛是這幾個版本。簡單講，就是在安騰服務器上運行這些軟件，檢測運行狀況、性能，其中Oracle主要驗證的是集群性能�，F在明白為什么要和Intel合作了吧。當時64位服務器剛出來，安騰老貴的，據說一臺上百萬。公司一口氣弄了三十多臺扔在機房里做實驗，結果被我們當成了板凳。細節不多說，大體上講有點類似于標準測試(benchmark)，但遠沒有那么復雜。
Intel上海實驗室的測試工程師只有6個人，據說就是這6個人負責中國大陸的所有測試工作。嘖嘖，真是敬仰之情猶如……后來才知道并不是這樣，中國大陸是只有6名，但美國總部有龐大的測試團隊提供支持。
參與這個項目的我方一共四人，Intel四人，基本上一對一。這里要特別提到一個人，當時的測試主管C。
C也是湖北的，和我一般高，濃眉大眼，家在農村，非常勤奮、質樸，來公司兩年了，此項目由他負責。之前他認識了個女孩，當老師的。他是落花有意，女孩卻流水無情，每天愁眉苦臉的想著該咋辦，后來不知咋地燒香燒到我這來了。
我給他出主意：“女人嘛，推倒了就是你的�！�
C撓撓腦袋：“咋推倒？”
我一臉藐視：“灌醉撒還用問！”
C恍然大悟：“是哦……咋灌醉？”
文章來源于領測軟件測試網 http://www.kjueaiud.com/
