1.统一对象处理

  2. 定位的逻辑封装（Xpath、Jquery的统一处理）

  3. 封装辅助性方法（日志、截图、报告等）

  4. 统一的错误处理，应对不同错误类型

  5. 动态对象的动态定位与关联性定位

  6. 数据的统一来源处理，抽象层

问题：数据驱动的维护性代价，是否仍然很庞大

解析：1-2-3-∞，与需求的匹配度问题，Cucumber基础框架无法解决

解析：多个不同地址、不同版本，脚本无法复用的原因

框架构建的整体思路：第二部，所有转化为数据流

  1. 句柄匹配不同对象，封装为统一的方法，降低认知学习时间

  2. 操作流在后端转化为数据流，让脚本复用

  3. 让验证结果变为多重验证的正则模式，让验证结果正则化

  4. 统一到数据流，定义各种数据源

问题：仍然是多个用例匹配一个需求，现在降低了操作与验证的维护下代价，但跟不上需求的迭代

框架构建的整体思路：第三部，需求规则矩阵

  1. 认知到1-2-3-∞，TDD绑定为“3“，BDD绑定为”∞“

  2. 如何考虑让BDD的前端用例自我生成

  3. 介绍需求规则矩阵：自动通过规则生成用例（独家）

  4. 后端实现的统一化处理：应对通用规则和业务范围规则的定义（独家）

  5. 测试的思维匹配到需求的跟踪，应对变化

问题：仅仅解决单个模块内的维护下代价，和需求跟踪的问题，场景间仍存在问题

框架构建的整体思路：第四部，拓扑映射的测试端自动生成（Cucumber本身无关，与自动化整体有关）

  1. 解决测试数据在多个交易间流转准备的难题

  2. 思路的转化：学习PACT的考虑，与数据库外键的关联性，来自动发现数据在多个组件/系统之家的流转（拓扑关系）

  3. 消灭场景：构建拓扑自我映射，自动找寻前置与后置关系

  4. 如何落地在框架或平台中

问题：解决了场景间的问题，没有解决数据前置准备的问题

框架构建的整体思路：第五部，数据缓存机制的生成

  1. 构建中央缓存数据库

  2. 拓扑和数据统计的结合，发现前置多少次被调用

  3. 选取交易进行前置批跑，自动构建数据

  4.   Docker的使用，等到前置数据批次稳定后

问题：与开发端、需求端的集成问题

  1. 与需求的映射，与研发代码的对应关系，如何绑定

  2. 与Git，Jenkins之间如何调用

问题：与运维端，如何适应并集成到DevOps中

  1. 工具的调研：Puppet、Chef、Ansiable

  2. 流水线运行到测试时，调用工具进行自动部署构建，触发分级测试

  3. 分级测试的进行与策略

BDD+Cucmber   适应场景，与其他模式的比较

TDD、BDD、SBE和ATDD的关系

适合ATDD的条件

     测试自动化

     敏捷开发

ATDD规范性

各种模型的适应场景与要求

     1国外的业务发展模式与国内的区别

     2 BDD的适应场景，团队与人员要求

     3 TDD的适应场景，团队与人员要求

     4 ATDD的适应场景，团队与人员要求

     5 关键字的适应场景，团队与人员要求

     6 敏捷测试的适应性与发展限制

     7 分级测试的提出与互联网应对

其他工具的参考介绍

     1 框架原理与解决的问题

     2 Selenide介绍+C21

     3 Pickle、Capybara、Factory girl、Spork、Guard spork、webkit

     4 Mock工具介绍

     5 胶水层思考（如Calabash）