测试发展趋势(转)

   我在某软件工程积累很多的大公司从事过一段时间early testing工作的探索，因此有几个月时间经常和公司的产品架构师混在一起工作，全程参与了需求和设计工作。从而积累了很多软件设计，软件开发工程领域的认知，也对软件开发工程的发展历史和规律有了更多了解。（early testing就是没写代码前的测试怎么做？测试人员如何尽可能去发现需求，架构，设计中的缺陷或不足）

   原来软件开发也经历了：没有章法单兵作战，凭感觉开发的1.0时代——>接着有了开发流程的2.0时代——>接着又发现流程的每个环节如何做好，还需要一些更具体的指导（方法论）和帮助（技术工具）， 于是有了软件开发3.0时代，各种IDE开发工具，各种编程规范，各种编程技巧——>进入九十年代后软件领域有了更多的开发框架（比一般的API库集成度更高）如J2EE，.net，这些框架不是API代码或函数的简单拼凑，而是重用了前辈或领域专家们的设计经验，系统性的构建起来，是对前人设计技术和思想的继承重用，从而既提升了开发效率也提升了质量。唯一坏处多增加了一些学习成本（不光学基本语言，还要学习前人定下了的设计规则）。

一直以来测试行业的难题，如何评审用例，如何评审测试设计？在自动化测试运动结束后，这个问题最终还是被测试经理们提出落到我头上去解决，原来那些评审单个用例文字编写规范的东西早已不被一线测试经理们认可，必须要有所突破否则整个组织的测试用例质量无法提升，绝大部分的测试执行和测试资源都将在地基不牢的地方浪费，质量提升就等同皇帝新装。 当时我另开辟渠道，想了解软件开发如何评审设计的？后来看了一个公司软件开发专家的内部ppt，他在几年前也在解决软件设计如何评审的问题？最终我暂时找到了一个可用答案——设计约束、设计模板、设计回溯 三板斧。 原来现在很流行的J2EE，.net的框架不仅仅是加快开发速度，还提供了设计模板，通过设计约束来保障了基本的设计质量。从而我认为测试设计领域也应该有自己的设计约束和设计模板，测试分析设计人员可以按设计约束和设计模板来填空，测试技术主管或管理主管可以用设计约束和设计模板通过设计回溯的方法评审测试用例。 需要特别强调的是：测试设计模板，不是传统意义上单个用例的结构或文字描述规范的规定。而是测试用例是通过什么严谨系统的大脑处理流程而来的。为此，我从2010年底到2011年初整理开发了《软件可靠性测试分析设计框架》，《压力测试分析设计框架》《长时间测试分析设计框架》来辅助不同项目组改进现有这些领域的专项测试用例，改善了用例不再完全凭个人经验和感觉编写的问题，给测试经理接下来测试用例评审的武器。