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.2google的保守与创新
Google在微模型建立方面应该积攒了丰富的经验。(从目前流出的资料,我的猜测)。目前海量数据的大部分分析都是基于不同微模型的。但是我们同时发现,公开的paper与成果非常少。只能在技术大会与相关介绍中抓到几个精髓。目前看到的有一篇关于分析问题与答案系统的微模型比较经典(是不是联想到百度知道了? 呵呵,这里的问答系统指广义的搜索需求。)
作者:sevensky615