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

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

2017-11-16 1021

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介：

第一篇殊途同归

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 更短的时间更完美的产品
产品最终服务于用户。从纯商业角度看，追求收益是最终目标。具体的技术表现就是更短的时间，更完美的产品。因此无论敏捷还是模型驱动测试在这一点上应该是高度一致的。