如何用 Robotframework 来编写优秀的测试用例

• 这篇文档将会是一篇在「高层面」的怎么用 Robotframework 来编写优秀测试用例的原则。至于如何使用 Robotframework 来与您的待测试系统相作用这样的细节讨论是不包含在这篇文档中的。
• 最重要的一条原则就是保证测试用例对于（不？）熟悉这个领域的人来讲越简单越好。
• 关于这个主题的更多信息，你可以查看以下这些优秀的资源：
• Writing Maintainable Automated Acceptance Tests 作者：Dale H. Emery
• How to Structure a Scalable And Maintainable Acceptance Test Suite 作者：Andreas Ebbert-Karroum

命名

测试套件的命名

• 套件的名称应该尽可能地描述这个套件的用途。
• 名称可以相对长一些，但是如果超过40个字那也太长了一些。
• 记住 Robotframework 的套件名称是直接从文件/目录的名字转换来的。文件的后缀名被去掉了而且下划线会被转换成空格，如果你的用到的单词都是小写的，那么开头字母会被转换成大写的。比如 login_test.txt 会被转换成 Login Tests, DHCP_and_DNS 会被转换成 DHCP and DNS。

测试用例的命名

• 测试用例的名字应该与套件的名字描述相似。
• 如果一个套件里包含了好多个相似的测试用例，而且测试套件本身已经很好地命名了，那么用例的名称可以简短一些。
• 在测试用例文件中的名称应该恰好表达了你需要做什么。

关键词命名

• 同样的，关键词的名称也应该是清晰具体的。
• 应该可以表达这个关键词干了什么，而不是它如何去做。
• 关键词应该是非常不同的抽象层次（比如，「输入字符」或者「用户登录到系统」）。

生成和分解的命名

• 试着用名称来描述这个步骤完成了什么。
• 或许你可以用一个已经存在的关键词
• 如果生成或者分解包含了不相关的步骤，那么可以接受更抽象一点的名称。
• 在名称中列举步骤是一个重复化和维护的问题（比如：登入系统，添加用户，激活警报和检查平衡）。
• 或许需要用到一些通用一些的名称比如「初始化系统」
• 每个用到这几个测试用例的人都需要明白这几个生成或者分解动作是干什么的。

文档

测试套件的文档

• 通常把文档添加到包含测试用例的最底层套件中是一个不错的想法。
• 高层的套件不需要那么频繁地文档化。
• 文档应该包含必要的背景信息，比如为什么要创建这些测试用例，测试环境中需要注意的点等等。
• 文档内容不要只是简单地重复套件的名称。
• 如果不是真的有文档还不如不添加文档。
• 文档的内容不要包含关于测试用例的太详细的信息。
• 测试用例本身就应该足够清楚易懂了。
• 重复的信息是一种浪费，而且也不容易维护。
• 文档中可以添加一些详细内容的链接。
• 如果你需要在文档中添加一些比如（版本：1.0 或者 OS：Linux）这样的「名称-值」组的话，可以考虑使用测试套件 metadata

测试用例的文档

• 测试用例通常来说不需要文档。
• 套件名称和文档以及用例的名称已经提供了足够的背景信息。
• 测试用例的结构应该是不需要文档或者其他注释都足够清楚了的。
• Tag 通常比文档更灵活，还能提供更多的功能。
• 当测试用例的文档是有用的时候，也不要担心而不去添加哟。

用户自定义关键词文档

• 如果这个关键词非常简单明了的话，不需要文档。
• 好的名称和明确的结构就足以说明一切了。
• 用户自定义关键词文档的一个重要的用途是用来记录参数和返回值的信息。
• 在 RIDE(比如在关键词补全的地方)以及在资源文件中显示的文档是由 libdoc.py 生成的。

测试套件的结构

• 在套件中的用例应该是互相相关的。
• 如果测试用例拥有同样的生成或者分解部分，那么他们应该是属于一个套件的。
• 除非是数据驱动的，在一个套件中不要放10个以上的测试用例。
• 测试用例应该是独立的。
• 用生成和分解来初始化他们。
• 有时候如果测试用例之间无法避免地相关联
• 比如说，它可能是因为把所有的用例独立出来要化太多的时间在初始化上。
• 相关联的测试用例就那么几个（最多4到5个）
• 下一个用例是用来验证上一个用例的结果的。（用${PREV TEST STATUS} 这个变量）

测试用例的结构

• 测试用例应该是易懂的。
• 一个测试用例只测试一件事情。
• 当然，事情本身可大可小。
• 选择一个合适的抽象层面。
• 一致地使用抽象水平（单一水平的抽象原则）
• 只包含与测试相关的信息。
• 用例可以分为两种
• 工作流程的测试用例
• 数据驱动的测试用例

工作流程的测试用例

• 通常来说有以下这些部分：
• 前置条件（可选，通常在生成部分）
• 动作 （对被测系统执行一些动作）
• 验证 （必须有一个验证的部分！）
• 清理 （可选，通常在分解部分，以保证用例已经执行完毕）
• 关键词是用来描述这个用例做了什么。
• 用清晰的关键词名称和合适的抽象层次。
• 应该包含足够的信息使得手动执行可以启动。
• 应该从来不需要文档或者沟通来告诉你这个用例在做什么。
• 不同的用例可以有不同的抽象层次。
• 详细的功能测试是更精确的。
• 端到端的测试可以是一个很高的抽象层次。
• 一个测试用例应该只使用一种抽象层次。
• 不同的风格
• 对于底层的详细测试和集成测试用例来讲应该是更关注技术细节。
• 「可执行定义」来扮演需求。
• 使用领域中的语言（术语？）。
• 所有人（包括顾客和产品负责人）都应该可以看明白。
• 不复杂的逻辑
• 不用 for 循环或者 if/else 判断结构。
• 小心给变量赋值。
• 测试用例不应该看起来像脚本一样难读。
• 最多10步，越少越好。

数据驱动的测试用例

• 每个测试用例有一个高层次的关键词。
• 不同的参数创建不同的测试。
• 关键词通常包含了与同一个用例文件中工作流程测试用例中描述的流程类似的流程。
• 推荐使用测试模板功能。
• 不需要多次地去重复关键词。
• 在一个用例里去测试更容易去测试多种变化。
• 如果可能，推荐在列头部命名。
• 如果真的需要很多测试用例，考虑把他们做成依赖于外部的模型。

用户定义关键词

• 应该容易让人理解
• 和工作流程测试用例一样的标准。
• 不同的抽象层次。
• 可以包含一些编程逻辑（for 循环，if 判断这些）
• 特别对于底层的的关键词。
• 复杂的逻辑应该放在库里而不是用户定义的关键词里。

变量

• 封装常的或者复杂的值。
• 从命令行传递信息。
• 在关键词之间传递信息。

变量的命名

• 清楚，但是不要太长。
• 可以在变量表格里用注释来说明。
• 对每个使用场景保持一致：
• 小写的本地变量只在当前的用例或者关键词中可用。
• 全局变量或者套件，用例级别的变量需要大写。
• 空格或者下划线都可以用来分割变量中的词。
• 推荐在变量表格中也把设置成动态的变量也列出来。
• 用Set Global/Suite/Test variable关键词来命名变量。
• 变量的初始值应该可以解释真实的值应该是什么。

传递和返回值

• 通常的方式是通过关键词来返回值，把他们赋给变量，然后传递给其他关键词的参数。
• 清楚易懂地遵循这个方法。
• 看起来像是编程。
• 备选方案是使用Set Test Variable关键词
• 不需要在测试用例层面上有什么编程风格。
• 要遵循起来比较复杂，很难重用关键词。
• 避免以下这种测试用例层级。

避免使用sleeping

• Sleeping 是非常脆弱的。
• 平均来说，安全的边界值会使得 Sleeping 很长时间。
• 用包含了一定的动作触发的关键词来替代 Sleeping
• 等待需要有一个超时的值。
• 关键词可以用 Wait Until… 来开头
• 可能的话用内置的关键词Wait Until Keyword Succeeds来包装其他关键词。
• 有时候 Sleeping 是一种最简单的解决方式
• 请总是小心使用，不要在经常用到的自定义关键词或者其他关键词中用 Sleeping。
• 在 Debugging 的时候 Sleeping 用来暂停测试执行还是很有用的。
• 虽然 DialogsLibrary 通常更适合用来干这个。