如何从零开始搭建一个无线自动化测试框架(二)

回顾

上一篇我们得到了一个简单的设计草稿. 接下来的工作就是根据这个map寻找我们的拼图了!

避免重复的造轮子

先不要急着开始写代码, 这是最愚蠢的工作方式. 我们先看看有哪些东西我们可以使用:

• PyUnit 这个是python的单元测试工具, 可以通过命令行在terminal下驱动, 我们可以替换它自身的runner和Logger部分.

类似于pyunit这样的单元测试工具其实还有很多, 而且都具有一定的扩展性. 如果考虑到使用简便, 不妨就可以使用python的单元测试工具PyUnit. 如果考虑到使用范围更广, 行为驱动测试的话, 那么下面的工具应该

• Cucumber. Ruby语言编写的行为驱动工具, 能够写出来类似下图的用例:
  

测试引擎

看了上面的介绍, 是不是突然觉得, 我们是不是什么都可以不做了? 恩...确实可以这样认为, 但是, 这个只是我们运行测试的引擎, 还有一些工作需要我们来继续做的.

下面是一个测试运行的大致流程:

准备测试环境  -> 测试集准备 -> 测试集运行 -> 测试运行 -> 测试集运行结束 -> 测试环境清理

我们的测试引擎就是要保证这个流程能够顺利进行. 现有的工具已经能够包含上面的环节, 但是几乎每个环节都有需要定制的地方, 包括但不限于: 检测测试机器信息, 准备测试数据, 以特定的命令运行测试, 捕获结果, 自定义信息处理的过程等等.

更重要的是, 既然是自动化测试, 那就要充分发挥程序的优点: 可以反复的运行不同的数据集合, 达到反复测试的目的. 说的更为直观一些就是下面的公式:

测试用例 = 场景(脚本) + 数据

我们用不同的数据就可以结合场景(脚本)组合成很多很多的用例了, 对不? 这种测试思路, 也就是我们常常听到的数据驱动测试(DDT), 是不是很好懂?

所以, 在我们定制测试引擎的时候, 请一定不要忘记灵活配置. 有没有更为直观的方式来组织我们的测试呢? 都是一个一个脚本, 看着多难受? 有比如, 我想要像前文提到的Cucumber那样直接描述行为的测试用例(行为驱动测试BDD)该怎么办?

这里我们介绍一个好伙伴: Robotframework

Robotframework不单单提供了从关键词映射到脚本(Java或者Python编写)的引擎, 还提供了各种自定义和监控测试过程的方法, 可以让我们按照意愿去定义测试的运行过程.

小结

到目前为止, 我们了解了一个自动化测试引擎的基本功能. 如果觉的这一篇比较繁杂, 大可以了解并使用�一下Robotframework, 这个绝好的测试引擎会让我们的工作事半功倍.