個人認為測試技術的發展經歷了以下幾個階段：
一，
純手工測試階段
測試是從使用者角度出發，去使用產品以檢測是否符合預期的工作。所以最基本的測試技術也就是手工測試，根據需求文件，編寫相應的測試用例。然後根據具體的測試流程來做：
（1）需求評審。此時測試人員需要測試需求是否存在不合理的地方，從需求不把不符合使用者習慣的東西給檢測出來。
（2）編寫測試用例。如果需求評審沒有問題，就需要根據需求文件來編寫相應的測試用例。此時開發人員著手開發相應的**，與我們編寫測試用例同步。
（3）冒煙測試用例的提交。在我們編寫測試用例的時候，需要先編寫核心功能的冒煙測試用例。只有這些兒測試用例通過後，才能開始其他的測試，冒煙測試用例編寫完成後提交給開發人員，以方便他們提測之前自測。
（4）正常測試。在開發提交測試後，需要先驗證一下冒煙測試用例是否通過，然後再按照完整的測試用例一步步的測試，提bug，驗證bug。一輪一輪地測試，直到達到上線的標準。
（5）上線及驗證。一般需求達到上線的要求的時候，會上乙個**環境或是沙箱環境再驗證一下，沒有問題了就上線，而後要做線上回歸。
（6）專案總結。一般大型的專案上線完成後，要做乙個專案總結，總結專案中遇到的問題，積累測試方法和相關經驗。
二，
黑盒，白盒和灰盒測試階段
隨著技術的不斷發展，測試也在不斷地發展。此時的手工測試又被稱為黑盒測試，就是我們不管盒子裡有什麼東西，只要對外表現符合要求即可。白盒測試就是要通過走查**，採取一些兒如
**檢查法、靜態結構分析法、靜態質量度量法、
邏輯覆蓋
法等對被測試物件進行測試。灰盒測試就是要結合黑盒和白盒的測試方法，進行互動測試。
不過現在技術發展的比較快，高速迭代，頻繁上線，造成這類測試階段成為了歷史，使用的越來越少了。
（1）黑盒測試不符合要求。因為幾乎不存在只測試功能，發現問題就直接丟擲的測試人員，必須進行問題定位，黑盒測試就不合適了。而且只會黑盒測試的人員要求比較低，沒有門檻，所以競爭比較大，越來越多的測試人員不單純做黑盒測試。
（2）白盒測試跟不上時代。現在網際網路發展的太快了，為了搶占市場或是客戶，早上線一天比晚上一天影響非常大的。所以效率第一，現在根本就沒有單元測試，更不可能讓乙個**能力不太強的人去做白盒測試。而**能力強的人，就又不屑於做測試，人家都去做開發了；再加上出於安全的考慮，白盒測試已過時了。
（3）灰盒測試推進很難。同樣的原因，灰盒測試要求也比較高，通過前端表現的
bug,
來定位後端錯誤程式，本身就不太容易。加上這個程式不是你寫的，會非常耗時的。人員的匱乏，加上時間的允許。現在幾乎沒有測試人員在分什麼黑盒
，白盒和灰盒測試了。
三，
工具測試階段
測試行業的發展，讓不少公司看到了這是乙個大餅，所以有不少公司專門做測試工具的開發，進而想搶占這一市場。也就湧現出不少如
效能測試
:loadrunner jemter ab
，功能測試
：qtp
，bug
管理：qc bugziller
等知名的工具。
此時的測試人員就會努力學習各種測試工具，不過後來發現這些測試工具為了盈利，就會收費的。不少公司，尤其是創業公司完全拋棄了這些兒測試工具，而只有銀行或是國企使用這些兒收費的測試工具，而這樣的公司很難進去的。而測試工具的學習成本比較低，你出去面試的時候，如果說自己會什麼樣的測試工具，人家根本就不
care,
因為在大家看來，如果有需要，這些工具就可以直接拿來用的。會測試工具的使用，不算任何優勢，就像吃飯會用筷子似的；再者我們也不能保證工具完全好用，出現了問題，如果是測試工具的缺陷導致的，那就非常鬱悶了！
四，開源及自動化測試階段
於是就出現了webdriver+python+unittest+htmltestrunner
+jenkins
要開展自動化測試，雖然要求測試人員有一定的編碼能力，可是要求也不太高。需要對特定的語言的一些兒簡單的應用即可，而大部分測試用例的編寫使用的技術都是那幾種，所以上手還是比較快的。有專門的人指導的話，一兩周完全可以編寫自動化測試用例，自動化測試的優勢在前幾年比較明顯，最近兩年也在慢慢的暗然失色。現在還在沉迷於自動化測試的同學，需要注意一下了。
五，工具，平台和服務化階段
測試技術發展了這麼多年，有一定的技術積累了，當然高階測試開發工程師也成長起來了不少。於是大型的公司就開始開發針對自己業務的測試工具，測試平台，同時將自己特定的測試功能**服務化，以方便公司其他測試同事的使用。
58趕集等都有自己開發的平台。有成熟的也會開源給社會，以提高自己公司的技術形象，當然更多的出於安全考慮不會公開的。我們暫切不管工具，平台或是服務化的具體實現及其功能，這說明乙個趨勢，業界對測試人員的要求越來越高了。測試的產品是測試，測試的使用者也是測試，需要一批高技術人員為測試人員服務，以提高測試質量和效率。這就要求我們不僅會測試技術，還要會開發技術，運維，產品，互動等等，也就是全站工程師的趨勢，具體的技術就不一一羅列了。
此時那些只會一兩種語言，編寫簡單的測試用例，使用開源框架編寫自動化測試用例的同學，明顯感覺不太夠用了。需要全面提高自己，幾乎你公司裡面其他同學會的東西，都是你學習的物件，不要求你比他們精通，但是要求你必須了解，遇到問題的時候會通過相關的技術來解決。
六，測試架構及新技術拓展階段
再往上發展就是架構師，設計測試平台或是測試工具的架構，以便使我們的開發更加合理。同時，對新技術進行探索，給出新技術能否應用到我們的測試工作為，提公升測試效率及質量。
測試行業有兩極發展的趨勢，一方面的開發能力較強的高階測試工程師，他們負責開發高階的測試工具及平台，以方便普通的測試人員使用。而測試工具和平台要求使用簡單，不需要任何技術，如果達不到這個要求，則說明不夠成功。另一方面，普通測試人員，只要懂得簡單的測試方法，就可以工作，而且有複雜的測試工作的時候，高階的測試人員就會開發出相應的工具。普通測試人員屬於高消耗型的，公司不會提公升你的技術水平，只需要你花費大量的時間工作就行，一旦不符合公司的發展，就換一批。
七
總結
以上僅是我個人認為測試技術發展的各個階段，由於能力和眼界有限，可能存在不少不到之處，希望大家多多包涵。僅供參考吧，測試門坎比較低，但是真正發展起來，還是很有難度的。不要僅僅以自己對測試的認識來阻礙發展，未來評價測試人員的不是工作經驗，而是你在工作用學到了什麼？能為我們帶來什麼？
c 技術學習的幾個階段
c opp ood系列 層級一 語法 語意 c lippman2000 essential c essential c by stanley b.lippman addison wesley longman 2000,276 pages essential c 中文版 侯俊傑 譯，282頁 greg...
技術的看法
對於技術的看法，容易落入兩樣。一是覺得技術無所不能，技術創造一切，技術改變世界云云。另一是覺得技術是屁。技術什麼都不是。前一種人可能遭受某次打擊，或者遇到某些事情後，轉化為第二種人，第二種人，也會在吃了技術的虧後，考慮第一種人的看法。好像論語中也有這樣的對話 子貢 問 師與商也孰賢？子曰 師也過，商...
軟體測試分為幾個階段 各階段的測試策略和要求
和開發過程相對應，測試過程會依次經歷單元測試 整合測試 系統測試 驗收測試四個主要階段 單元測試測試策略 自頂向下的單元測試策略 比孤立單元測試的成本高很多，不是單元測試的乙個好的選擇。自底向上的單元測試策略 比較合理的單元測試策略，但測試週期較長。孤立單元測試策略 最好的單元測試策略。整合測試的測...