命名
测试套件命名
1.套件名称应该尽可能描述清楚。
2.套件名称会从文件名或目录名自动创建：
· 文件名的扩展名不会出现在套件名称中；
· 下划线会被转成空格；
· 如果套件名称都是小写字母，那么名称会自动转成首字母大写。
3.名称可以相对长一点，但是过长的话在文件系统中不方便。
4.如果需要的话，顶级套件的名称可以在命令行使用--name选项进行重写。
举例：
1.在文件系统中看到的是login_tests.robot，在RIDE中看到的是Login Tests
2.IP_v4_and_v6在RIDE中看到的是IP v4 and v6
测试用例命名
1.测试用例和测试套件名称描述应该相似。
2.如果套件包含了多个相似的测试，并且套件命名良好的话，那么测试名称可以短一点。
3.测试用例名称就是你在测试用例文件中指定的名称，不会有任何的转换。
比如，如果我们在一个和非法登录相关的invalid_login.robot文件中有很多测试，那么下面这些测试用例名称都是可以的：
*** Test Cases *** Empty Password Empty Username Empty Username And Password Invalid Username Invalid Password Invalid Username And Password |
下面的名称就有点长了：
Login With Empty Password Should Fail Login With Empty Username Should Fail Login With Empty Username And Password Should Fail Login With Invalid Username Should Fail Login With Invalid Password Should Fail Login With Invalid Username And Invalid Password Should Fail |
关键字命名
1.关键字名称描述应该清晰。
2.应该解释该关键字做什么而不是怎么做。
3.不同的抽象级别（比如，Input Text 和 Administrator logs into system）。
4.至于应该是每个单词首字母大写还是应该只有名称的首字母大写没有明确的规范。
· 每个单词的首字母大写通常用于关键字名称很短的情况，比如Input Text;
· 如果关键字的命名像一个句子，那么一般将该关键字的首字母大写。比如Administrator logs into system。这些关键字通常也具有更高的级别。
好的关键字命名：
*** Keywords *** Login With Valid Credentials |
不好的关键字命名:
*** Keywords *** Input Valid Username And Valid Password And Click Login Button |
setup和teardown的命名
1.尽量使用描述做什么的名称。可能使用一个已存在的关键词。
2.如果setup和teardown包含了不相干的步骤，那么可以接受更抽象的名称：
· 将关键字名称逐个列出来会产生重复和维护问题(比如Login to system, add user, activate alarms and check balance)
· 使用一些通用的名字通常来说更好一些（比如Initialize system）。
3.如果已存在实现了更低级别步骤的关键字，那么建议使用内置的Run Keywords。
*如果setup或teardown只需要一次的话，那么使用最好，这样不会重复。
4.使用测试的每个人务必要明白该setup或teardown做了什么。
好的命名：
*** Settings *** Suite Setup Initialize System |
好的命名2（如果只使用一次）：
*** Settings *** Suite Setup Run Keywords ... Login To System AND ... Add User AND ... Activate Alarms AND ... Check Balance |
不好的命名：
*** Settings *** Suite Setup Login To System, Add User, Activate Alarms And Check Balance |
文档
测试套件文档
1.通常，最好是将所有的文档添加到测试用例文件中。
2.应该包含背景信息，比如为什么创建测试，执行环境需要注意的地方等等。
3.不要重复测试套件名称，如果真的不需要，那就最好不要有文档。
4.不要包含太多的详细信息和测试用例。
· 测试用例本身应该是理解起来清晰的。
· 重复信息浪费时间和精力，还会造成维护问题。
5.文档可以包含更多信息的链接。
6.如果需要以键值对形式的文档信息，可以考虑使用测试套件元数据metadata，比如Version:1.0。
7.顶级套件的文档和元数据可以分别使用--doc 和 --metadata选项从命令行进行设置。
好的文档：
*** Settings *** Documentation Tests to verify that account withdrawals succeed and ... fail correctly depending from users account balance ... and account type dependent rules. ... See http://internal.example.com/docs/abs.pdf Metadata Version 0.1 |
不好的文档（特别当套件名称像account_withdrawal.robot时）:
*** Settings *** Documentation Tests Account Withdrawal. |
测试用例文档
1.测试用例通常不需要文档。
· 父套件的名字和可能的文档以及测试用例本身的名字应该给出足够的背景信息。
· 测试用例的结构应该尽可能地清晰，不需要文档或其它注释。
2.Tags标签通常比文档更灵活，并提供了更多的功能，比如statistics【统计】、include/exclude等等。
3.有时测试文档是有用的，适当地使用很关键。
好的文档：
*** Test Cases *** Valid Login [Tags] Iteration-3 Smoke Open Login Page Input Username ${VALID USERNAME} Input Password ${VALID PASSWORD} Submit Credentials Welcome Page Should Be Open |
不好的文档：
*** Test Cases *** Valid Login [Documentation] Opens a browser to login url, inputs valid username ... and password and checks that the welcome page is open. ... This is a smoke test. Created in iteration 3. Open Browser ${URL} ${BROWSER} Input Text field1 ${UN11} Input Text field2 ${PW11} Click Button button_12 Title Should Be Welcome Page |
用户关键字文档
1.如果关键字很简单的话就不需要文档了，此时应该具备好的关键字和参数名以及清晰的结构。
2.重要的用法是给参数和返回值加文档。
3.在资源文件中，使用 Libdoc生成的文档可以在编辑器（RIDE）中完成关键字输入之后，按下Ctrl键看到注释。
测试套件结构
1.套件中的测试应该是相关的，公用的setup和teardown通常是一个很好的说明。
2.一个文件中不应该有太多的测试用例（最大10个），除非是数据驱动的测试。
3.测试应是独立的，使用setup/teardown初始化。
4.有时，测试间的依赖是无法避免的。
· 比如，分别初始化所有的测试可能花费太多时间。
· 绝对不要有太长的测试依赖链。
· 使用内置的变量${PREV TEST STATUS}验证前一个测试的状态。
测试用例结构
1.测试用例应该容易理解。
2.一个测试用例应该测试一个东西，可以很小（一个功能的一部分），也可以很大（端到端）。
3.选择合适的抽象级别：
· 使用抽象级别要一致
· 在测试用例的级别不要包含不必要的详细信息
4.两种测试用例：工作流测试和数据驱动测试。
工作流测试
1.通常有以下阶段：
· 前置条件（可选，通常在setup中）
· 操作（对系统做一些操作）
· 验证（对结果进行验证，必须要有）
· 清理工作（可选，总是在teardown中完成）
2.关键字描述测试做了什么
· 使用明确的关键字名称和合适的抽象级别
· 应该包含足够的信息以手动运行。
· 不需要文档或注释来解释测试做了什么。
3.不同的测试可以有不同的测试级别
· 细节功能的测试可以更精确。
· 端到端的测试可以是非常高的级别。
· 一个测试应该只包含一个测试级别。
4.不同的风格：
· 对于低级别细节的更技术性的测试和集成测试。
· 将“可执行的说明书”作为需求。
· 使用领域语言。
· 每个人（包括客户和产品拥有者）应该总可以理解。
5.测试用例级别没有复杂的逻辑。
· 没有循环或if/else
· 小心使用变量赋值
· 测试用例不应该看起来像脚本
6.最大10个步骤，最好更少。
下面是使用了“正常的”关键字驱动的样式：
*** Test Cases *** Valid Login Open Browser To Login Page Input Username demo Input Password mode Submit Credentials Welcome Page Should Be Open |
下面是使用了更高级的"gherkin"样式：
*** Test Cases *** Valid Login Given browser is opened to login page When user "demo" logs in with password "mode" Then welcome page should be open |
数据驱动测试
1.每个测试应该有一个高级的关键字
· 不同的参数创建不同的测试
· 一个测试可以运行相同的关键字多次来验证相关变化的结果
2.如果该关键字是以用户关键字实现的，那么它一般包含了和工作流测试相似的工作流。
· 如果在其它地方不需要该关键字，那么在和测试相同的文件中创建该关键字是个好主意。
3.推荐使用数据驱动测试
· 不需要重复写该关键字多次
· 在一个测试中方很容易测试多种变化。
4.如果可能的话，推荐给列命名标题头。
5.如果真的需要大量的测试，可以考虑基于一个外部模型生成。
样例：
*** Settings *** Test Template Login with invalid credentials should fail *** Test Cases *** USERNAME PASSWORD Invalid Username invalid ${VALID PASSWORD} Invalid Password ${VALID USERNAME} invalid Invalid Both invalid invalid Empty Username ${EMPTY} ${VALID PASSWORD} Empty Password ${VALID USERNAME} ${EMPTY} Empty Both ${EMPTY} ${EMPTY} *** Keywords *** Login with invalid credentials should fail [Arguments] ${username} ${password} Input Username ${username} Input Password ${password} Submit Credentials Error Page Should Be Open |
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
