第四篇 方向评估
4.1 组件化测试的过程改进方向
4.1.1 过程改进
组件化测试本身基于敏捷的思路，发挥测试人员的全程参与能力以及对产品的控制力度。将会结合目前已经形成的测试过程不断完善。实现测试驱动设计，测试驱动开发的过程。我们最应该落实的首要是：rd应该提供什么。我们应该如何做。这个应该在整个敏捷过程中不断明确与打通。
4.1.2 意识转变
从功能、代码的测试意识向加强产品设计、开发、评估的意识转变。测试的范畴应该更多的纳入产品设计的内容与产品评估的内容。这个是一件很困难的事情，但这部分应该尝试。
4.1.3 技术积累
从整个产品团队角色，应该尽量避免qa的角色边缘化，从整个技术发展角度，测试应该形成自己的技术文化与思路。
4.2 组件化测试的技术方向
4.2.1 建模技术方向
建模过程梳理，目前对应的主要是流程模型的建立。
建模几个关键标准：（具体技术标准参见wiki文档）
1、 不同粒度的流程与功能在不同级别进行划分
2、 相同功能属于同一层次结构
3、 粒度细的流程模型应该对应于具体的功能，对于low level的流程模型，测试方法应该是固定的。(自动化方案也是固定明确的)
其中3是核心。
4.2.2 自动化的方向（意外的惊喜？）技术的低耦合性
1、 不同粒度的流程与功能在不同级别进行划分
2、 相同功能属于同一层次结构
3、 粒度细的流程模型应该对应于具体的功能，对于low level的流程模型，测试方法应该是固定的。(自动化方案也是固定明确的)
其中3是核心。
4.2.2 自动化的方向（意外的惊喜？）技术的低耦合性
标准模型的组件化实例：
A、 对应于目前的组件化测试平台—主要解决建模与模型分析的方法。
B、 对应于一套自动化框架（从产品特点来看，应该是基于数据驱动）
C、 数据，过程工具的整合维护。
从调研分析可以看到，技术的高耦性会必然带来失败。因此，组件化发展时将尽量采取技术低耦合的方式进行。上述三个框图内容彼此应该是可拆解与组合的。
由于模型建立时基于功能类聚的准则。因此，对于细粒度的模型来说，对应于非常具体的功能，也就是对应于同样的操作序列，同样的测试方法，同样的验证过程。不同的只是数据而已。数据驱动的良好嫁接。
是意外还是必然？ 从基于模型测试的本身来说，必然会出现这种逻辑，模型是根据当前组件特点建立的，方法上必然具有天生的一致性。这也是模型驱动测试开发的关键。
B、 对应于一套自动化框架（从产品特点来看，应该是基于数据驱动）
C、 数据，过程工具的整合维护。
从调研分析可以看到，技术的高耦性会必然带来失败。因此，组件化发展时将尽量采取技术低耦合的方式进行。上述三个框图内容彼此应该是可拆解与组合的。
由于模型建立时基于功能类聚的准则。因此，对于细粒度的模型来说，对应于非常具体的功能，也就是对应于同样的操作序列，同样的测试方法，同样的验证过程。不同的只是数据而已。数据驱动的良好嫁接。
是意外还是必然？ 从基于模型测试的本身来说，必然会出现这种逻辑，模型是根据当前组件特点建立的，方法上必然具有天生的一致性。这也是模型驱动测试开发的关键。
4.3 组件化测试的风险评估
4.3.1 质量风险
基于模型分析的方法覆盖率已被证明比手工测试创建更加彻底。（注意，这里的模型包括状态图，流程图，UML图的形式。 IBM用的较多的是UML图）
从目前组件化测试的实际结果来看，覆盖率的提升也在40%左右。
但是有一点前提依赖: 需要经验丰富的测试人员或者产品工程师进行建模。人的能力挑战是一大风险。
4.3.2 技术风险
目前模型测试技术研究方面是不算太成熟的，对于数据分析，产品评估方面的方法没有十分适合的技术，这个存在未知风险。摸索的结果可能完全错误。这一点我们希望能尽量参考业界研究，包括建模方法，分析方法。避免弯路。
同时，对于以前的测试模式，方法工具，人员能力都提出挑战。这个有较高代价,困难重重. 而模型测试本身又需要一定的学习成本。这一块得挑战不言而喻。
前途美好，道路曲折。
4.3.3 组织风险
过程改进可能面临的排斥，主要是敏捷思想带来的排斥。
4.3.4 规模失控风险
规模失控包括模型失控与case失控。
1、 case失控。包含两个方面。Case爆炸与无效case。这个对于状态图来说非常明显。微软spec是个解决方案，但是如何与我们的产品结合是个难题。对于流程图模型来说，经过人工分析抽象后，case爆炸不会存在。无效case不会出现。这种担心小很多。
2、 模型失控。主要是模型的复杂度与数量。 这个要注意一个前提，模型测试之初是为了解决复杂大型系统的测试而诞生的。因此模型的建立必须是简单，明了。高度抽象的。这个依赖于测试人员建模过程的分析与把握。
4.4 组件化测试的收益分析（具体参见wiki总结）
4.4.1 质量方面
基于模型分析的方法覆盖率已被证明比手工测试创建更加彻底。（注意，这里的模型包括状态图，流程图，UML图的形式。 IBM用的较多的是UML图）
以目前受益分析来看，覆盖率比以前提升在40%左右。
4.4.2 效率方面
以敏捷的思路来做，项目周期缩短是必然的。
后续主要是在组件分析与组件自动化方面获得较大效率提升。
4.4.3 敏捷过程的完全实施与优化
1、前期介入（建模）
2、测试驱动设计，开发（基于模型驱动）
3、迭代开发
4、维护的极低成本（模型可以更好的应对需求设计变动带来的修改代价）
4.4.4 产品设计与产品评估的尝试（产品价值）
1、 产品设计bug在试行与实际运行的几个项目中都有出现，2-4个不等。本身数量不大，但是意义很大，出现了就是好的。在锻炼大家的这种意识。
2、 产品评估尝试。如何进行产品评估，google在微模型的架构下进行驱动开发，rd与测试人员的产品设计与评估方面的区分被弱化。而这一块目前我们并没有尝试。
4.4.5 技术/流程导向性
1. 技术导向性希望能形成一定的测试方法沉淀。
2. 流程导向性希望能促进测试人员的产品全过程参与能力。
作者：
sevensky615
本文转自百度技术51CTO博客，原文链接：http://blog.51cto.com/baidutech/743229
，如需转载请自行联系原作者
