Shadow'S Site

心之所愿，无所不至！

0%

Robot-Framework测试用例编写规范

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 2.2k 阅读时长 ≈ 2 分钟

命名

测试套件的命名

Robotframework 的套件名称是直接从文件/目录的名字转换来的。文件的后缀名被去掉了而且下划线会被转换成空格，如果你的用到的单词都是小写的，那么开头字母会被转换成大写的。
比如 login_test.txt 会被转换成 Login Test, DHCP_and_DNS 会被转换成 DHCP and DNS。

测试用例的命名

表达你需要做什么。

关键词命名

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

生成和分解的命名

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

结构

测试套件的结构

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

测试用例的结构

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

用例

工作流程的测试用例

1.1 通常来说有以下这些部分：

◦前置条件（可选，通常在生成部分）
◦动作 （对被测系统执行一些动作）
◦验证 （必须有一个验证的部分！）
◦清理 （可选，通常在分解部分，以保证用例已经执行完毕）

1.2 关键词是用来描述这个用例做了什么。

◦用清晰的关键词名称和合适的抽象层次。
◦应该包含足够的信息使得手动执行可以启动。
◦应该从来不需要文档或者沟通来告诉你这个用例在做什么。

1.3 不同的用例可以有不同的抽象层次。

◦详细的功能测试是更精确的。
◦端到端的测试可以是一个很高的抽象层次。
◦一个测试用例应该只使用一种抽象层次。

1.4 不同的风格

◦对于底层的详细测试和集成测试用例来讲应该是更关注技术细节。
◦「可执行定义」来扮演需求。
◦使用领域中的语言（术语？）。
◦所有人（包括顾客和产品负责人）都应该可以看明白。

1.5 不复杂的逻辑

◦不用 for 循环或者 if/else 判断结构。
◦小心给变量赋值。
◦测试用例不应该看起来像脚本一样难读。

1.6 最多10步，越少越好。

数据驱动的测试用例

2.1 每个测试用例有一个高层次的关键词。

•不同的参数创建不同的测试。
•关键词通常包含了与同一个用例文件中工作流程测试用例中描述的流程类似的流程。

2.2 推荐使用测试模板功能。

•不需要多次地去重复关键词。
•在一个用例里去测试更容易去测试多种变化。

2.3 如果可能，推荐在列头部命名。
2.4 如果真的需要很多测试用例，考虑把他们做成依赖于外部的模型。

用户自定义关键词

  1. 应该容易让人理解
    ◦和工作流程测试用例一样的标准。

  2. 不同的抽象层次。

  3. 可以包含一些编程逻辑（for 循环，if 判断这些）
    ◦特别对于底层的的关键词。
    ◦复杂的逻辑应该放在库里而不是用户定义的关键词里。

变量

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

变量的命名

1.1 清楚，但是不要太长。
1.2 可以在变量表格里用注释来说明。
1.3 对每个使用场景保持一致：

•小写的本地变量只在当前的用例或者关键词中可用。
•全局变量或者套件，用例级别的变量需要大写。
•空格或者下划线都可以用来分割变量中的词。

1.4 推荐在变量表格中也把设置成动态的变量也列出来。

•用Set Global/Suite/Test variable关键词来命名变量。
•变量的初始值应该可以解释真实的值应该是什么。

传递和返回值

2.1 通常的方式是通过关键词来返回值，把他们赋给变量，然后传递给其他关键词的参数。

•清楚易懂地遵循这个方法。
•看起来像是编程。

2.2 备选方案是使用Set Test Variable关键词

•不需要在测试用例层面上有什么编程风格。
•要遵循起来比较复杂，很难重用关键词。
•避免以下这种测试用例层级。

避免使用sleeping

3.1 Sleeping 是非常脆弱的。
3.2 平均来说，安全的边界值会使得 Sleeping 很长时间。
3.3 用包含了一定的动作触发的关键词来替代 Sleeping

•等待需要有一个超时的值。
•关键词可以用 Wait Until… 来开头
•可能的话用内置的关键词 Wait Until Keyword Succeeds来包装其他关键词。

3.4 有时候 Sleeping 是一种最简单的解决方式

•请总是小心使用，不要在经常用到的自定义关键词或者其他关键词中用 Sleeping。

3.5 在 Debugging 的时候 Sleeping 用来暂停测试执行还是很有用的。

•虽然 DialogsLibrary 通常更适合用来干这个。

作者：抽屉(chouti)
链接：https://zhuanlan.zhihu.com/p/19565445
来源：知乎