一种测试方向的探讨-基于模型测试调研引发的思考 – 1

http://qa.baidu.com/blog/?p=165

 

一种测试方向的探讨-基于模型测试调研引发的思考 – 1

第一篇 殊途同归

1.1 敏捷是一种态度

敏捷是目前组内尝试开发模式。结合实际操作，总结一下看法，敏捷更多的在提倡一种理念与态度，而非技术本身。
1.1.1 技术角度分析
从技术角度来讲，敏捷本身并未提供或定义具体的方法。敏捷更多的是在提倡一种更快更高效得开发模式，来缩短产品上线周期。如被经常提及的提前介入，迭代开发，更多沟通，测试驱动设计，测试驱动开发等等。
1.1.2 产品流程角度分析
从整个产品设计流程上来说，敏捷要求处于流程后期的参与者对于产品的参与度与贡献度更大。因为产品的末端参与者通常处于比较被动的角色，这种被动性是产品周期缩短的天然屏障。这势必对测试人员提出最大的挑战。如何主动前期介入，如何更有效的介入，如何成为推动产品周期的动力，如何驱动设计与开发。这个是敏捷测试的核心价值。
1.1.3 敏捷的误区
敏捷本身提倡更简单的流程，更高效的工作。但通常实践时经常出现2大误区：
1、很多事情不做就是敏捷了。敏捷的核心是化繁为简，不是直接删除。 （调研的过程中发现不少rd的意识是只写代码，别的不提供。Qa的意识是当前项目快速over，产品维护并不考虑。这个不仅给测试带来较大麻烦。对于产品的迭代开发来说更是一个噩梦。） 敏捷的过程需要整个产品团队保持远见，保持对持续集成，迭代开发的高度关注。不仅是为了现在更快，而是为了将来越来越快。
2、敏捷对于流程，技术，文档的要求变得更高（更简单与高效），而不是一部分人认为的降低。

1.2 模型驱动是一种过程+方法

模型驱动是伴随着整个软件对象的复杂性，规模型，不可控性，自动化迫切性，分布式等要求越来越高而诞生的。模型驱动核心是对产品对象建立模型，通过模型驱动设计，开发与测试。方法本身天然包含对整个产品开发过程的梳理与重构。
1.2.1 从过程角度分析
模型驱动希望在产品设计阶段，产品周期的所有参与人员进行模型制定。测试人员在项目启动时介入，进行产品bug（mrd bug），设计bug（架构bug，文档bug，思路bug）的发掘（这一点基于bug发现的越迟，代价将成指数级增长的原理。）。提倡更多的沟通，降低产品升级的影响，让迭代开发变得更高效。
1.2.2 从技术方法角度分析
模型驱动包含建立模型，分析模型，翻译模型，执行，结果对比等阶段。建立模型的思想是核心。业界比较成熟的建模方案包括（基于状态机，基于数据流，基于产品逻辑，基于马尔科夫模型等等。） 通常会提供建模到自动化执行的一系列解决方案。

总结:敏捷体现的是一种态度，基于模型测试是敏捷思想的方法实践，组件化测试只是模型测试的一个分支。

1.3巧合还是必然的一致?(组织与技术的双重挑战)
1.3.1 更短的时间更完美的产品
产品最终服务于用户。从纯商业角度看，追求收益是最终目标。具体的技术表现就是更短的时间，更完美的产品。因此无论敏捷还是模型驱动测试在这一点上应该是高度一致的。

图表 1敏捷思想=〉模型驱动=〉组件化测试
1.3.2敏捷与模型驱动对比分析