回顾
上一篇我们得到了一个简单的设计草稿. 接下来的工作就是根据这个map寻找我们的拼图了!
避免重复的造轮子
先不要急着开始写代码, 这是最愚蠢的工作方式. 我们先看看有哪些东西我们可以使用:
- PyUnit 这个是python的单元测试工具, 可以通过命令行在terminal下驱动, 我们可以替换它自身的runner和Logger部分.
类似于pyunit这样的单元测试工具其实还有很多, 而且都具有一定的扩展性. 如果考虑到使用简便, 不妨就可以使用python的单元测试工具PyUnit. 如果考虑到使用范围更广, 行为驱动测试的话, 那么下面的工具应该
- Cucumber. Ruby语言编写的行为驱动工具, 能够写出来类似下图的用例:
测试引擎
看了上面的介绍, 是不是突然觉得, 我们是不是什么都可以不做了? 恩...确实可以这样认为, 但是, 这个只是我们运行测试的引擎, 还有一些工作需要我们来继续做的.
下面是一个测试运行的大致流程:
准备测试环境 -> 测试集准备 -> 测试集运行 -> 测试运行 -> 测试集运行结束 -> 测试环境清理
我们的测试引擎就是要保证这个流程能够顺利进行. 现有的工具已经能够包含上面的环节, 但是几乎每个环节都有需要定制的地方, 包括但不限于: 检测测试机器信息, 准备测试数据, 以特定的命令运行测试, 捕获结果, 自定义信息处理的过程等等.
更重要的是, 既然是自动化测试, 那就要充分发挥程序的优点: 可以反复的运行不同的数据集合, 达到反复测试的目的. 说的更为直观一些就是下面的公式:
测试用例 = 场景(脚本) + 数据
我们用不同的数据就可以结合场景(脚本)组合成很多很多的用例了, 对不? 这种测试思路, 也就是我们常常听到的数据驱动测试(DDT), 是不是很好懂?
所以, 在我们定制测试引擎的时候, 请一定不要忘记灵活配置. 有没有更为直观的方式来组织我们的测试呢? 都是一个一个脚本, 看着多难受? 有比如, 我想要像前文提到的Cucumber那样直接描述行为的测试用例(行为驱动测试BDD)该怎么办?
这里我们介绍一个好伙伴: Robotframework
Robotframework不单单提供了从关键词映射到脚本(Java或者Python编写)的引擎, 还提供了各种自定义和监控测试过程的方法, 可以让我们按照意愿去定义测试的运行过程.
小结
到目前为止, 我们了解了一个自动化测试引擎的基本功能. 如果觉的这一篇比较繁杂, 大可以了解并使用�一下Robotframework, 这个绝好的测试引擎会让我们的工作事半功倍.