第二篇 文化背后
2.1 IBM的敏捷史
2.1.1 大象也会跳舞--敏捷的老面孔
IBM是个非常有意思的公司，从硬件到软件再到咨询、服务业。完成了几次成功的华丽转身。每次几乎都能给你意外惊喜。了解的人都知道大象跳舞的历史。而这种反思文化的实质是在追求高效。也就是我们目前不断提及的敏捷内容的核心。
敏捷不是什么新鲜玩意，几乎每个组织与个人都曾经经历过。
一个公司需要反思自己的市场定位，一个部门需要反思自己的公司定位，一个工程师则需要反思自己的角色定位。
总结：那么QA的角色是什么？价值在哪里？我们如何避免组织结构与技术上的边缘化？
2.1.2 七年之痒--技术的未来还是产品的未来
七年之痒，借指一下IBM对基于模型测试七年研究的一路风雨。
先展示一下IBM标准，也是目前通用的基于模型测试的系统架构。
再展示一下IBM的对模型测试的几个阶段的研究与尝试。
基于模型测试本身，IBM实现了比较成熟的技术（如基于UML的状态/数据流模型），获得了很大的收益。但是几度弃用已开发的产品。有两点总结值得思考：
1、 技术人员自己定义技术，发展技术。（实则在指责技术研究为了技术而技术，脱离产品本身）
2、 技术上的高耦合性。（IBM的基于模型测试从模型制定，到分析，到自动执行。集成度非常之高。造成了产品的不通用性， 因此单个案例成功多，复用性少。）
总结：技术应该基于产品才有生命力，产品分析的高耦合性与技术实现的低耦合性。
2.2 Micosoft的聪明（spec explorer）
2.2.1 技术的大众化
spec explorer是微软基于模型测试研究的商业产品。模型实现过程基本概括如下：
这套技术本质上与IBM一样，基于相同的模型标准在做。但是微软很聪明，实现了几个跨越：
第一、对传统软件对象进行了高度抽象。状态机的描述不仅完美而且被扩大。
状态机进行代码设计。（注意，模型驱动设计的雏形，联想到什么？测试驱动设计？没那么轻松！!?）
第二、在理论上与实践中解决了模型测试产生的case爆炸问题。（正交技术的运用。这个不是简单的去重，做了非常多的算法优化。）
第三、实现了产品的高耦合性（作为软件服务存在），与技术的低耦合性（分析与执行的较低联系）
总结：这个案例还是值得借鉴的,通用的思路,每一步都进行最彻底完善的解决。
2.2.2 产品理念的商业化
微软对spec的包装与宣传是成功的。现在提及基于模型的测试，大家最先想到的总是spec。这种技术影响力的方式值得我们思考。如何展现百度质量部门自己的技术影响力，形成我们测试人员自己的技术沉淀。这个应该是伴随整个公司与产品发展形成的，或者我们也可以称之为底蕴的东西。
2.3 google的创新与实用主义
2.3.1 google的实用主义
IBM曾经因为技术高耦合而弃用一些已开发好的模型工具。原因是复用性不够。这点google采取了截然相反的思路。Google开发的是基于微模型的思路。每一个模型只为解决一个互联网问题（小吗？不小，因为处理数据量的庞大，这个模型本身需考虑的已足够复杂）。
微模型（个人定义，可能存在不妥的地方.不知google自己怎么叫）的分析方式
总结：这个对比是最值得我们深思的，传统意义上的软件测试，模型测试是基于事件触发跳转的（界面操作系统的核心）。因此天生是完美的有限状态机模型。对于互联网产品来说，核心基于数据处理，这种状态机模型已经不能覆盖。因此业界有数据流模型，流程图模型等等。目前我们采取的组件化测试的核心仍然是基于流程模型的。但是设计之初，我们不希望对分析方法作严格限定，可以对不同组件采取不同分析方法。即不同微模型的不同分析。这个后续可以根据需求裁定。
2.3.２google的保守与创新
Google在微模型建立方面应该积攒了丰富的经验。（从目前流出的资料，我的猜测）。目前海量数据的大部分分析都是基于不同微模型的。但是我们同时发现，公开的paper与成果非常少。只能在技术大会与相关介绍中抓到几个精髓。目前看到的有一篇关于分析问题与答案系统的微模型比较经典（是不是联想到百度知道了？ 呵呵，这里的问答系统指广义的搜索需求。）
作者：sevensky615
本文转自百度技术51CTO博客，原文链接：http://blog.51cto.com/baidutech/743713
，如需转载请自行联系原作者
