介绍
　　这篇文档将会是一篇在「高层面」的怎么用 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