github地址：https://github.com/robotframework/HowToWriteGoodTestCases/blob/master/HowToWriteGoodTestCases.rst，这个文档是官方描述如何写好用例的，主要内容包括：命名规范、文档使用、用例结构组织等。
1.命名
1.1 测试用例集命名
- 通常一个robot文件为一个测试用例集，如：
test_login.robot，那么它的测试用例集名称就是Test Login. - 所以，测试用例集的命名符合以下3个规则：
1.会去掉扩展名
robot.
2.会把下划线转换为空格.
3.会将每个单词的首字母大写.
- 测试用例集的命名长度是没有限制的，但是测试用例集是以文件形式存在于操作系统的文件系统中，当测试用例集的命名超过操作系统支持的最大长度或字符不满足操作系统要求，是会出现问题的。
1.2 测试用例命名
- 测试用例命名时，需要结合测试用例集的命名，使测试用例集名称+测试用例名称能够充分描述一个用例的功能。
- 因此，在命名时，需要注意，名称不要冗余，见示例图：
测试用例命名
1.3 关键字命名
- 关键字命名应该是清晰的描述性语言，用于解释关键字的作用，而不是怎样用。
- 示例见图片：
image.png
1.4 setup and teardown命名
- 采用已有的关键字进行命名操作
- 当有多个步骤，用AND连接
- 当这个用例集的setup和teardown只需要运行一次时，需要加上关键字
Run Keywords
image.png
2.文档
2.1 测试集文档
- 对测试集添加文档说明，有助于明确测试用例集的功能及背景信息
- 测试集的文档信息中，应该包括：创建原因、执行环境信息等，为了能更好的了解背景信息，也可以添加链接
- 当不需要测试集的文档描述时，可以不必添加
- 测试集的描述应该简洁清晰，不需要添加详细的测试用例信息
image.png
2.2 测试用例文档
- 测试用例通常不需要文档说明
- 测试用例的功能由用例名称和用例集的描述进行体现，因此用例名称需要简洁贴切
- 如果需要对用例进行描述，可以添加
[Tags]对用例进行一个简要说明 - 最后，测试用例文档描述并非不可用哦，需要用
Documentation才能清楚描述的话，还是可以采用的
image.png
2.3 关键字文档
- 关键字通常不需要进行文档描述
- 使用简洁明确的关键字信息就可以了
3.测试集结构
- 一个测试集中的测试用例应该有相关性，比如：能够用同一组setup/teardown
- 除数据驱动类的用例外，一个测试集中的用例最好不要超过10个
- 测试集中的用例应该保持独立性，用例之间不要关联，如：用例2需要用到用例1成功才能执行，不能存在这类关联性
- 但有时，用例之间的关联性是不能避免的，这时应该如何处理呢？
1.情况1：当用例2需要用到用例1的结果，但如果将用例1放入setup的执行步骤中，会导致所有用例的初始化时间过长，可以考虑关联；
2.但是不要使用例关联的链过长，如：用例4关联用例3、用例3关联用例2、用例2关联用例1，这类过长的关联链很容易出现问题，在规划用例时，需要采用一些手段进行用例的合理规划；
3.当用例关联时，需要用到上一个用例的结果，可以采用内置关键字${PREV TEST STATUS}进行验证。
4.测试用例结构
- 测试用例应该简洁明了，易于理解和阅读
- 一个测试用例应该验证一个功能点或一个测试点
- 设置合适的用例级别，如用于：冒烟测试或全量测试
- 用例通常分为2种类型：工作流程用例和数据驱动用例
4.1 流程用例
- 流程用例通常包含以下几个要素：前置条件、执行步骤、断言验证、环境恢复
image.png
- 用例是由关键字进行描述的，关键字清晰明确，不需要文档或注释去描述用例实现的功能是什么
- 不同的用例应该有不同的测试级别，一个用例只能有一个测试级别，通常E2E（指一个完整功能点）的用例拥有较高级别
- 测试用例的风格：
1.更多的低级别的详细信息的技术测试和集成测试；
2.将“可执行规范”作为需求文档；
3.使用领域特定语言；
4.用例易于理解，客户或产品经理等都能看懂用例描述的功能。 - 测试用例中没有复杂的逻辑，如：条件判断和循环、变量的赋值使用合理、用例看起来不应该像脚本。
- 每个用例的步骤不要超过10个，最好少于10个；
- 工作流测试的用例示例，如图：
image.png
4.2 数据驱动用例
- 每个用例中，都有一个高级别的关键字：
1.不同的参数需要创建不同的用例；
2.一个测试用例中，可以采用多组参数来运行同一个关键字多次，去验证多个相关的变化。 - 如果关键字是以用户关键字实现的，那它通常在工作流用例中有一个相似的流程：除非在其他地方需要，否则最好将它与使用它的测试创建在同一个文件中。
- 数据驱动用例推荐使用测试模板，这样可以减少关键字重复，更易于在同一用例中使用多组变量数据；
- 由于使用的参数通常不止一个，建议在用例的标头对使用的参数进行命名，这样更易于阅读，如图所示：
- 如果一个用例需要使用大量的测试数据，建议将数据保存在一个外部文件中，读取后进行参数化操作
- 数据驱动示例如图：
image.png
5.用户关键字
- 关键字应该易于理解，不需要文档或注释去描述用例实现的功能是什么
- 关键字具备不同的抽象级别
- 关键字中允许有程序逻辑，如：循环和判断
- 但是复杂的逻辑最好放在Library中，通过关键字去调用，不要在用户关键字中去实现复杂逻辑
6.变量
- 变量用于封装过长或者过于复杂的值
- 在命令行中进行参数传递时，可以采用
--variable选项 - 在关键字之间传递信息
6.1 变量命名规则
- 短小清晰
- 在变量表中可以使用文档或注释对变量进行说明
- 变量的使用说明：
1.以小写的单词作为局部变量的命名；
2.以大写的单词作为全局变量的命名；
3.单词之间可以使用空格或下划线进行分割； - 建立在变量列表中，设置动态的变量，如：列表、字典格式的变量
- 设置动态变量通常使用内置关键字： Set Suite Variable
-
定义变量时，同时需要进行初始化操作
image.png
6.2 传递和返回值
- 常见方法是，将关键字返回的值传递给变量，再将变量以参数形式传递给其他关键字：
1.传递过程应该明确且易于遵循；
2.创建独立的关键字，使关键字易于复用；
3.在测试用例级别上使用领域性语言，使用例看起来不像程序； - 为了避免用例像程序语言风格，以及破坏关键字的复用性，可以将需要传递值的功能写入Library或者使用内置关键字 Set Test Variable进行存储。
image.png
7.避免使用sleeping
- 使用sleeping，极易造成同步测试的不稳定；
- 通常，安全边界会导致过长的睡眠时间；
- 因此，我们可以使用内置关键字代替sleep：Wait Until Keyword Succeeds
- 但是有时，对于逻辑功能实现，使用sleep也是一个有效的解决方案，所以要善于使用，但是不要用于调用频繁的用户关键字中。
总结
- 通过阅读How to write good test cases，了解了使用RobotFramework编写用例的规则
- 遵循规则编写用例，才能写出更易于阅读、理解和稳定的用例
