⑴ RobotFramework 自动化框架环境搭建及使用
一、为什么要做自动化？
前提：主流程稳定，周期长，脚本可重复利用。
1.节省人力资源
2.提高效率
3.面试需要
二、什么是RobotFramework：
基于Python的关键字驱动的自动化框架。
1. 基于Python：就是由python语言开发的这个框架。
2.关键字驱动：关键字驱动测试又称为表格驱动测试，是自动化测试的一种方法，是数据测试的一种改进方法。关键字驱动主要包括测试步骤、测试步骤中的对象，测试对象执行的动作，测试对象需要的数据
3.自动化框架？：是应用于自动化测试，框架提供可重用的基础自动化测试平台，提供自动化测试执行和管理功能的组织架构。
三、pip的常用方法：
pip 是 Python 包管理工具，该工具提供了对Python 包的查找、下载、安装、卸载的功能。
以下在win10_x64 cmd中操作：
安装：pip install 包名
eg：pip install robotframework
安装指定版本：pip install 包名==版本号
eg：pip install robotframework==1.7.4.1
升级指定包：pip install --upgrade 包名
eg：pip install --upgrade robotframework
卸载：pip uninstall 包名
eg：pip uninstall robotframework
搜索安装包：pip search 包名
eg：pip search robotframework
查看当前电脑上已经安装的包：pip list
查看当前电脑上可以升级的包：pip list -o
四、rf的安装：
安装RF自动化框架：pip install robotframework
安装RF自动化框架IDE：pip install robotframework-ride
安装wxpython（ride依赖wxpython）：pip install wxpython
ps ：实际上新版本pip在安装ride时会自动安装所需依赖，也就是wxpython
版本信息：Win10 x64 + Python 3.7.7 + rf 3.1.2 + ride 1.7.4.1 + wxpython 4.0.7.post2
ps ：ride 1.x版本不支持Python 3.8及以上，ride 2.x（开发中）支持Python 3.8
rf日志中文乱码解决方法：修改文件 python安装目录下 Libsite-packagesrobotidecontrib estrunner estrunnerplugin.py 第 565 行，将 SYSTEM 改成 OUTPUT ，重启ride工具。
五、元素定位：
id ：以网络搜索输入框为例
在RF中写法： id=kw
name ：以网络搜索输入框为例
在RF中写法： name=wd
xpath ：Xml Path Language
1. 绝对路径：从html根部逐级（从上至下）查找
/html/body/p[1]/p[1]/p[3]/p/p/form/span[1]/input
在RF中写法：xpath=/html/body/p[1]/p[1]/p[3]/p/p/form/span[1]/input
2.相对路径：根据节点的上下文进行查找
eg：//p/form/span/input 这里是在html中找一个p，p里面包含一个form，form包含一个span，span包含一个input，找有这样一个四层的关系的input标签，要注意如果html中有多个符合这种层级关系的input，会默认选第一个，也就是说这种方式未必是完全准确的。
3. xpath相对定位我们还可以根据元素的属性来查找：
eg：//p/form/span[1]/input[@type] 这里是找符合这样一个层级关系并且有'type'这个属性的input标签
在RF中写法：xpath=//p/form/span[1]/input[@type]
eg：//p/form/span[1]/input[@type='submit'] 这里是找符合这样一个层级关系并且'type'这个属性的值为'submit'的input标签
在RF中写法：xpath=//p/form/span[1]/input[@type='submit']
eg：//p/form/span[1]/input[contains(@type,'sub')] 这里是找符合这样一个层级关系并且'type'这个属性的值包含'sub'的input标签
在RF中写法：xpath=//p/form/span[1]/input[contains(@type,'sub')]
以上是根据属性，如果是下面这样的a标签，我们还可以根据链接文字来进行定位
点我
eg：//a[contains(text(),'点我')] 这样就是找所有a标签并且文字为'点我'的元素了
在RF中写法：xpath=//a[contains(text(),'点我')]
小技巧：
在 Chrome-F12-Console 中根据Xpath寻找元素：使用 $x ("")，引号中填写xpath路径，如$x("/html/body/p[1]/p[1]/p[3]/p/p/form/span[1]/input")
css：
id： 以网络搜索输入框为例
在RF中写法： css=#kw
class： 以网络搜索输入框为例
在RF中写法： css=.s_ipt
css根据属性定位 ：
[id='kw'] 表示查找id值为'kw'的元素
[name^='w'] 表示查找name值为'k'开头的元素
[class$='ipt'] 表示查找class值为'ipt'结尾的元素
[autocomplete*='f'] 表示查找autocomplete值中包含'f'的元素
[id='kw'] [name^='w'] 表示查找id值为'kw'并且name值为'k'开头的元素
在RF中写法：css=[id='kw'] [name^='w']、css=[class$='ipt']、
css=[maxlength=饗']、css=[autocomplete='off']
ps：id和class也是属性，只是在css中针对id和class多了一种简单的写法，如上面的
css=#kw、css=.s_ipt
css根据标签定位：
input
表示查找当前页面所有input标签
在RF中写法：css=input
a,input
表示查找当前页面所有a标签和input标签
在RF中写法：css=a,input
span input
表示查找span标签下的所有input标签，哪怕是span下下级的input
在RF中写法：css=span input
span>input
表示查找父元素为span标签的所有input标签，注意和span input的区别
在RF中写法：css=span>input
span+input
表示查找紧挨在span元素后的第一个input元素
在RF中写法：css=span+input
span~input
表示查找紧挨在span元素后的所有input元素
在RF中写法：css=span~input
ps ：其实大家都知道，因为页面上只依靠标签定位的话重复的可能性太大了，所有我们可以采用 标签 + 属性 的方式来进行定位
例如 span>input[id='kw'][name^='w'] 意思是查找所有父标签为span的input标签，并且该标签中有属性id的值为kw且属性name的值为w开头
在RF中写法：css=span>input[id='kw'][name^='w']
小技巧：
在 Chrome-F12-Console 中根据css寻找单个元素：
使用 $ ("")，引号中填写css选择器，如$("span>input[id='kw'][name^='w']")
在 Chrome-F12-Console 中根据css寻找多个元素：
使用 $ ("")，引号中填写css选择器，如$("span>input[id='kw'][name^='w']")
⑵ 如何用 Robot Framework 来编写优秀的测试用例
我们使用符合RobotFramework规范的一种表格语法来编写测试用例。用例一般会是下面这个样子这样的表格存储到一个文件中，就是一组测试用例。RF支持多种格式，如HTML，TSV,纯文本等。它们长相大同小异，其实描述的都是一种内容。为了方便，推荐使用RIDE这个用例的编辑工具来编写测试用例，这些文本在RIDE环境下被打开长得是一个样子的。
⑶ robot framework 怎么调试脚本
需要的 我们使用符合Robot Framework规范的一种表格语法来编写测试用例。用例一般会是下面这个样子 这样的表格存储到一个文件中，就是一组测试用例。RF支持多种格式，如HTML，TSV,纯文本等。它们长相大同小异，其实描述的都是一种内容。
⑷ 如何用 Robotframework 来编写优秀的测试用例
命名测试套件的命名套件的名称应该尽可能地描述这个套件的用途。名称可以相对长一些，但是如果超过40个字那也太长了一些。记住Robotframework的套件名称是直接从文件/目录的名字转换来的。文件的后缀名被去掉了而且下划线会被转换成空格，如果你的用到的单词都是小写的，那么开头字母会被转换成大写的。比如login_test.txt会被转换成LoginTests,DHCP_and_DNS会被转换成DHCPandDNS。测试用例的命名测试用例的名字应该与套件的名字描述相似。如果一个套件里包含了好多个相似的测试用例，而且测试套件本身已经很好地命名了，那么用例的名称可以简短一些。在测试用例文件中的名称应该恰好表达了你需要做什么。关键词命名同样的，关键词的名称也应该是清晰具体的。应该可以表达这个关键词干了什么，而不是它如何去做。关键词应该是非常不同的抽象层次（比如，“输入字符”或者“用户登录到系统”）。生成和分解的命名试着用名称来描述这个步骤完成了什么。或许你可以用一个已经存在的关键词如果生成或者分解包含了不相关的步骤，那么可以接受更抽象一点的名称。在名称中列举步骤是一个重复化和维护的问题（比如：登入系统，添加用户，激活警报和检查平衡）。或许需要用到一些通用一些的名称比如“初始化系统”每个用到这几个测试用例的人都需要明白这几个生成或者分解动作是干什么的。文档测试套件的文档通常把文档添加到包含测试用例的最底层套件中是一个不错的想法。高层的套件不需要那么频繁地文档化。文档应该包含必要的背景信息，比如为什么要创建这些测试用例，测试环境中需要注意的点等等。文档内容不要只是简单地重复套件的名称。如果不是真的有文档还不如不添加文档。文档的内容不要包含关于测试用例的太详细的信息。测试用例本身就应该足够清楚易懂了。重复的信息是一种浪费，而且也不容易维护。文档中可以添加一些详细内容的链接。如果你需要在文档中添加一些比如（版本：1.0或者OS：Linux）这样的“名称-值”组的话，可以考虑使用测试套件metadata测试用例的文档测试用例通常来说不需要文档。套件名称和文档以及用例的名称已经提供了足够的背景信息。测试用例的结构应该是不需要文档或者其他注释都足够清楚了的。Tag通常比文档更灵活，还能提供的功能。当测试用例的文档是有用的时候，也不要担心而不去添加哟。用户自定义关键词文档如果这个关键词非常简单明了的话，不需要文档。好的名称和明确的结构就足以说明一切了。用户自定义关键词文档的一个重要的用途是用来记录参数和返回值的信息。在RIDE(比如在关键词补全的地方)以及在资源文件中显示的文档是由libdoc.py生成的。测试套件的结构在套件中的用例应该是互相相关的。如果测试用例拥有同样的生成或者分解部分，那么他们应该是属于一个套件的。除非是数据驱动的，在一个套件中不要放10个以上的测试用例。测试用例应该是独立的。用生成和分解来初始化他们。有时候如果测试用例之间无法避免地相关联比如说，它可能是因为把所有的用例独立出来要化太多的时间在初始化上。相关联的测试用例就那么几个（最多4到5个）下一个用例是用来验证上一个用例的结果的。（用${PREVTESTSTATUS}这个变量）测试用例的结构测试用例应该是易懂的。一个测试用例只测试一件事情。当然，事情本身可大可小。选择一个合适的抽象层面。一致地使用抽象水平（单一水平的抽象原则）只包含与测试相关的信息。用例可以分为两种工作流程的测试用例数据驱动的测试用例工作流程的测试用例通常来说有以下这些部分：前置条件（可选，通常在生成部分）动作（对被测系统执行一些动作）验证（必须有一个验证的部分！）清理（可选，通常在分解部分，以保证用例已经执行完毕）关键词是用来描述这个用例做了什么。用清晰的关键词名称和合适的抽象层次。应该包含足够的信息使得手动执行可以启动。应该从来不需要文档或者沟通来告诉你这个用例在做什么。不同的用例可以有不同的抽象层次。详细的功能测试是更精确的。端到端的测试可以是一个很高的抽象层次。一个测试用例应该只使用一种抽象层次。不同的风格对于底层的详细测试和集成测试用例来讲应该是更关注技术细节。“可执行定义”来扮演需求。使用领域中的语言（术语？）。所有人（包括顾客和产品负责人）都应该可以看明白。不复杂的逻辑不用for循环或者if/else判断结构。小心给变量赋值。测试用例不应该看起来像脚本一样难读。最多10步，越少越好。数据驱动的测试用例每个测试用例有一个高层次的关键词。不同的参数创建不同的测试。关键词通常包含了与同一个用例文件中工作流程测试用例中描述的流程类似的流程。推荐使用测试模板功能。不需要多次地去重复关键词。在一个用例里去测试更容易去测试多种变化。如果可能，推荐在列头部命名。如果真的需要很多测试用例，考虑把他们做成依赖于外部的模型。用户定义关键词应该容易让人理解和工作流程测试用例一样的标准。不同的抽象层次。可以包含一些编程逻辑（for循环，if判断这些）特别对于底层的的关键词。复杂的逻辑应该放在库里而不是用户定义的关键词里。变量封装常的或者复杂的值。从命令行传递信息。在关键词之间传递信息。变量的命名清楚，但是不要太长。可以在变量表格里用注释来说明。对每个使用场景保持一致：小写的本地变量只在当前的用例或者关键词中可用。全局变量或者套件，用例级别的变量需要大写。空格或者下划线都可以用来分割变量中的词。推荐在变量表格中也把设置成动态的变量也列出来。用SetGlobal/Suite/Testvariable关键词来命名变量。变量的初始值应该可以解释真实的值应该是什么。传递和返回值通常的方式是通过关键词来返回值，把他们赋给变量，然后传递给其他关键词的参数。清楚易懂地遵循这个方法。看起来像是编程。备选方案是使用SetTestVariable关键词不需要在测试用例层面上有什么编程风格。要遵循起来比较复杂，很难重用关键词。避免以下这种测试用例层级。避免使用sleepingSleeping是非常脆弱的。平均来说，安全的边界值会使得Sleeping很长时间。用包含了一定的动作触发的关键词来替代Sleeping等待需要有一个超时的值。关键词可以用WaitUntil…来开头可能的话用内置的关键词WaitUntilKeywordSucceeds来包装其他关键词。有时候Sleeping是一种最简单的解决方式请总是小心使用，不要在经常用到的自定义关键词或者其他关键词中用Sleeping。在Debugging的时候Sleeping用来暂停测试执行还是很有用的。虽然DialogsLibrary通常更适合用来干这个。
⑸ 如何使用RobotFramework编写好的测试用例
命名
测试套件的命名
套件的名称应该尽可能地描述这个套件的用途。
名称可以相对长一些，但是如果超过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 通常更适合用来干这个。
⑹ robot framework用自己写脚本么
需要的
我们使用符合Robot Framework规范的一种表格语法来编写测试用例。用例一般会是下面这个样子
这样的表格存储到一个文件中，就是一组测试用例。RF支持多种格式，如HTML，TSV,纯文本等。它们长相大同小异，其实描述的都是一种内容。为了方便，推荐使用RIDE这个用例的编辑工具来编写测试用例，这些文本在RIDE环境下被打开长得是一个样子的。
测试用例与文件的关系
一个文件被称作一个测试套件(Test suit)，期间可以包含多个测试用例。上图就是一个测试套件，里面包含2个测试用例，My Test 和AnotherTest。
Test suit也能嵌套，比如同一个目录下的多个Test suit组成一个更高层的Test Suit，这些更高层的Test suit可以组成，这种嵌套的层数可以无限多。这种嵌套的用例组织形式在实际应用中很常见。
测试用例文件的内部结构
一个Test Suit文件包含四段内容他们分别是：Setting，Variable，Testcase，Keyword
Setting部分主要的作用是：
引用测试类库文件(test Library)，引用资源文件(resource files)，引用变量文件(variable files)。
为测试套件或者测试用例定义元数据(metadata)
Variable部分的主要作用是：
定义测试用例中要使用的变量。
TestCase部分的主要作用是：
使用测试关键字来完成测试用例
Keword部分的主要作用是：
把现有关键字进行组合，生成更高一级的新关键字。
对测试用例文本解析的规则
如同各种编程语言一样，RF需要对它规定的这种表格语言进行解析，并用内部引擎把这些脚本语言解释成执行测试用例的具体操作。在解析过程中我们需要如下几点：
忽略字符：根据格式不同，忽略不符合格式的字符，规则很多，但是可以使用RIDE来规避，使用RIDE我们就可以不考虑这些。
转义符：RF使用 \ 作为转义符。举个例子：\${notvar} 代表字符串 ${notvar} 而不是一个变量
空格：RF会自动截断头尾的空格
多行用例
如果参数太多，需要换行，则需要在下一行的关键字处使用英文的省略号(...)表示参数属于同一个关键字。
Test Case
Action
Argument
Argument
Argument
Example [Documentation] Documentation for this test case.
... This can get quite long...
[Tags] t-1 t-2 t-3
... t-4 t-5
Do X one two three
... four five six
${var} = Get X 1 2
... 3 4 5
...
从上表中我们可以看到：[Tags]有5个参数，而Do X有6个参数。
⑺ 如何用 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 通常更适合用来干这个。