一个关于自动化框架的故事丨中国DevOps社区

嗨，米妮

嗨，米奇，你好吗?

我很好，怎么了?

你知道什么是自动化框架吗?

我知道

你能教一下我吗? 我明天要在课堂上讲解自动化框架。

可以，米妮，我要赶这趟火车了。晚上去你那讲讲。

不，我跟你一起去，这样你可以在火车上给我讲讲自动化框架。

这里太棒了！

是的，我喜欢乘火车旅行。

我们可以开始吗？

可以，米妮，告诉我如果你去火车站你都看到了什么?

首先有一个问讯处，我们可以在那里得到有关火车的所有信息，有一个售票柜台，还有一个上下火车的月台。

很好，你在站台上还看到了什么？

有候车室和座位安排，有卖零食、报纸、杂志的小贩等。

很好，所有必要的或者任何有助于我们坐上火车的事物可以在一个叫做火车站的地方得到。

是的。

同样地，自动化框架就像一个平台，在那里，可以通过适当的编排，组织和有效的方式，将所有必要的东西用来创建和运行自动化脚本。

所有的函数库，工具，软件，报告系统等，关于需求和使用的信息，都组装在自动化框架中。

因此自动化框架有助于创建和运行自动化。

是的，并且可以管理，更新，添加脚本等。它还包含测试结果和报告机制。

我开始理解这个了。

所以它就像自动化测试的工具箱，是可移植的。你可以把它应用到任何系统，并开始应用自动化。

好的。

或者我们可以说测试自动化框架是一个提供环境来创建、运行和报告测试自动化结果的系统。

这个很容易理解。我们现在可以深入一点吗？

可以。在那之前，你想来点茶和点心吗？

是的，我正需要。

好的，米妮，这些是自动化框架的一般组件：

Test Scripts（测试脚本）
Object（对象）
Repository（存储库）
LibrariesModules（函数库模块）
Utilities（公用工具模块）
Reusable elements（可复用元素）
Logging（日志模块）

Reporting（报告模块）
Command Line Tools（命令行工具）

好，这就是一个标准的测试自动化框架的样子？

这些是测试自动化框架的通用组件。根据我们所测试的应用程序或平台的类型，可能会有一些变化和定制。

比如什么？

例如，如果你正在做API的自动化测试，你可能需要request(请求)和response(响应)结构，而这在Web浏览器测试中是不需要的。

哦，我明白了。

也有不同类型的框架，如：

Data-Driven（数据驱动的）
Keyword Driven（关键词驱动的）
Hybrid（混合模式的）
Modular（模块化的）
BDD（行为驱动开发）

哦，所以这些都有不同的结构。

基本元素是一样的，这些不同类型的框架在实现上有所不同。改天我会告诉你这些事情的。

好的，米奇。

你还有其他问题吗?

这些都很好，但是为什么我们需要这些框架呢？

这是个好问题。我们为什么需要站台？

因为这样上火车很容易且方便。我们在一个地方就有所有需要的东西。

没错，现在假设你在一个地方有服务台，在另一个遥远的地方有售票台，其他东西也分散了，会怎么样? 

那就一团糟了。

是的，类似站台，框架在一个统一的地方，使用适当定义的结构，提供了自动化所需的一切。

我明白了。

这也有助于实现下列这些：

易维护性

更容易和有效的添加和更新

可重用性

速度

可靠性

可移植性

我理解了，米奇。

太棒了，我也到站了。我要在这里下车了。你可以乘下一班火车回家。

不，我在这儿等着，晚上一起回去。

好的，这是我的午餐，吃点东西吧。

好的，米奇，你是我最好的朋友。

我永远在你身边。