在新浪微博上大家常討論和抱怨，中國測試所處的環境多么初級和落后。我也常參與討論，無奈微博140字的限制，表達有限，還導致一些誤解。其實下面的內容，我在2011年2月就整理最原始的思路，今天周末正好拿出來與大家分享，聽聽大家的意見和批判：
我在某軟件工程積累很多的大公司從事過一段時間early testing工作的探索，因此有幾個月時間經常和公司的產品架構師混在一起工作，全程參與了需求和設計工作。從而積累了很多軟件設計，軟件開發工程領域的認知，也對軟件開發工程的發展歷史和規律有了更多了解。（early testing就是沒寫代碼前的測試怎么做？測試人員如何盡可能去發現需求，架構，設計中的缺陷或不足）
原來軟件開發也經歷了：沒有章法單兵作戰，憑感覺開發的1.0時代——>接著有了開發流程的2.0時代——>接著又發現流程的每個環節如何做好，還需要一些更具體的指導（方法論）和幫助（技術工具）， 于是有了軟件開發3.0時代，各種IDE開發工具，各種編程規范，各種編程技巧——>進入九十年代后軟件領域有了更多的開發框架（比一般的API庫集成度更高）如J2EE，.net，這些框架不是API代碼或函數的簡單拼湊，而是重用了前輩或領域專家們的設計經驗，系統性的構建起來，是對前人設計技術和思想的繼承重用，從而既提升了開發效率也提升了質量。唯一壞處多增加了一些學習成本（不光學基本語言，還要學習前人定下了的設計規則）。
一直以來測試行業的難題，如何評審用例，如何評審測試設計？在自動化測試運動結束后，這個問題最終還是被測試經理們提出落到我頭上去解決，原來那些評審單個用例文字編寫規范的東西早已不被一線測試經理們認可，必須要有所突破否則整個組織的測試用例質量無法提升，絕大部分的測試執行和測試資源都將在地基不牢的地方浪費，質量提升就等同皇帝新裝。 當時我另開辟渠道，想了解軟件開發如何評審設計的？后來看了一個公司軟件開發專家的內部ppt，他在幾年前也在解決軟件設計如何評審的問題？最終我暫時找到了一個可用答案——設計約束、設計模板、設計回溯 三板斧。 原來現在很流行的J2EE，.net的框架不僅僅是加快開發速度，還提供了設計模板，通過設計約束來保障了基本的設計質量。從而我認為測試設計領域也應該有自己的設計約束和設計模板，測試分析設計人員可以按設計約束和設計模板來填空，測試技術主管或管理主管可以用設計約束和設計模板通過設計回溯的方法評審測試用例。 需要特別強調的是：測試設計模板，不是傳統意義上單個用例的結構或文字描述規范的規定。而是測試用例是通過什么嚴謹系統的大腦處理流程而來的。為此，我從2010年底到2011年初整理開發了《軟件可靠性測試分析設計框架》，《壓力測試分析設計框架》《長時間測試分析設計框架》來輔助不同項目組改進現有這些領域的專項測試用例，改善了用例不再完全憑個人經驗和感覺編寫的問題，給測試經理接下來測試用例評審的武器。
最后再總結整理下軟件開發的發展趨勢：
1.0時代混亂；2.0時代流程化；3、方法和技術；4設計框架。
測試行業的發展和軟件開發發展趨勢也會一致：
1.0時代無流程 （我入行前） 某公司1998年前
2.0有測試流程 （我剛入行） 某公司1998年-2003年
3.0時代大量測試方法和技術 （我2010年前） 某公司2003至今，特別是08年至今有了大量突飛猛進的突破，正在大面積普及的路上
4.0時代有測試設計框架（設計和經驗復用） （我2010年至今，先走一步探索啦）
通過讀史明鑒，找到事物發展的規律后，我有信心并相信，中國測試業界相比開發只是晚1個時代，未來10年內中國多數公司的測試也會進步到3.0和4.0時代。某公司走過的歷史，也必將是國內才起步后來者們未來走的路以及趨勢。
各位tester看到未來的發展方向了嗎？