目前做自动化测试开发领域分为两拨人。一拨在搞自动化的 SDK 比如 selenium、 appium 、robotium 还有像国内阿里的 macaca 。所谓自动化的 SDK 就是自动化测试的软件开发包，比如最有名的 selenium-webdriver 在国内都快把 QTP 干出翔了。这些 SDK 的开发者我是很钦佩的，正是有了它们我们可以很轻松的编写我们的自动化测试脚本。然后另一拨人就是开发各种自动化测试平台的人，我就是其实中一位（笑）。

做过或者正在做自动化的人可能对下面这张架构图不陌生：

大多数的自动化平台设计思路是这样的：
XXX 自动化平台 ，自动化测试分工模式，由测试工程师编写测试脚本，业务测试人员编写测试用力，测试执行人员 执行和收集测试结果（嗯，我们又创造了三个职位）。
分工模式人员要求更低，案例设计人员无需具备编码技能。（那开发测试脚本的人写好就可以开了？）
一键执行和产出测试报告。（先不说前面那些需要人工的准备工作，这个报告模版不适合我们啊能不能改改？）

然后还有比上面那些更 “强大” 的自动化平台（环境构建、持续集成、自动化测试 我样样都行 ）：

相比之下，jenkins 简直弱爆了有没有 ，jenkins 要实现这些还要下载各种插件，插件不适合还得自己造轮子。

然而当你使用这些平台实施自动化的时候，你的噩梦也开始了。。。

你：下星期 XX 流程要改造一下，页面上多了几个参数，我们需要改造一下平台的测试脚本。
测试开发：可以，不过你需要让案例开发人员将已有的案例全部案例都添加上这几个参数，不然没法兼容。
业务测试：

你：这次的这个项目数据库是 oracle，之前都是从 mysql 中自动取数据，可以改一下吗？
测试开发：这个不好弄啊，取数逻辑和案例耦合太严重了，要不让测试人员先手动填一下？
业务测试：

为什么在使用过程中会出现如此多的问题？我们从架构上来分析这个问题.
在使用各种平台的自动化测试流程中,你的代码脚本是被嵌入到了平台中的, 被嵌入的代码必须符合这个平台的规范,这就使得一些原本容易的事情变的复杂了.你想要获取测试数据,必须经过平台! 你想要定制测试报告,不好意思你先看懂平台代码再说...

测试的入口在平台而不是你的代码,一旦平台设计不满足你的需求时,那么你的自动化测试就会陷入被动.

而 OneBlock 的设计理念 是将平台作为一个工具来使用的,整个的流程是下面这样的:

(具体可以看这个帖子 OneBlock1.1 发布 支持批量执行)

测试的入口是测试脚本,OneBlock 平台被当成一个案例管理工具来使用,测试数据由 Excel 提供,结果由脚本直接输出.

基于这种设计概念,你可以任意的更换你的"零件",以达到你的需求 ,而这些都是可控的:

看到这里可能有人会说,那这个可控和 OneBlock 也没有直接关系啊,完全可以脱离 OneBlock 来做自动化啊.
是的,OneBlock 就是这么一个非主流的框架,他不绑架你的自动化设计,它只是一个案例管理工具, 我写它的目的也不是为了把大家的自动化绑死在我的框架上,而是为了分享 怎么样 搭建属于自己的自动化框架 .
自动化不应该被那些框架平台束缚,自动化的主要目的是为了高效的完成测试任务并提供测试报告,那些高大上的功能 (华丽的报告,一键解决方案) 我们也要,但是你不该强行加给我,你得让我有自由选择的能力.

结尾打个广告

后面 OneBlock 的功能性的扩展 我暂时不准备做了,后面我会把重心放在解读我原有的代码 (C#) 和用 python 重写 执行客户端上.

介于我并没有任何的 python 经验,所以希望各位 python 大神和友人能协助我完成这个任务.

OneBlock 测试开发 QQ 群: 588076977