在新浪微博上大家常讨论和抱怨，中国测试所处的环境多么初级和落后。我也常参与讨论，无奈微博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看到未来的发展方向了吗？