取名

测试套件名称

• 套件名字应该尽可能的使用描述性语言。
• 自动被创建的名字来自文件或文件夹名字。
  • 去掉后缀名。
  • 将下划线转换成空格。
  • 如果名字都是小写，单词应该大写。
  • 在文件系统中名称可以相对较长，但是过长的名字是不方便的。
  • 如果需要可以在命令行使用 --name 选项，来替换顶层的套件名称。
  • login_tests.robot -> Login Tests
  • IP_v4_and_v6 -> Ip v4 and v6

  测试案例命名

  • 测试名称应该和套件名称的描述一致。
  • 如果一个套件包含多个相同的测试，并且这个套件的命名是可取的，那么测试名称可以短小。
  • 恰当的名字应该是在你的测试案例文件中指定并且无需任何转换。

  例如，假设我们需要在 invalid_login.robot 中把 invalid login 和测试联系起来，下面都是OK的测试名称。

  1 2 3 4 5 6 7

  *** Test Cases *** Empty Password Empty Username Empty Username And Password Invalid Username Invalid Password Invalid Username And Password

  下面这些命名是有点长

  1 2 3 4 5 6 7

  *** Test Cases *** Login With Empty Password Should Fail Login With Empty Username Should Fail Login With Empty Username And Password Should Fail Login With Invalid Password Should Fail Login With Invalid Username Should Fail Login With Invalid UserName And Invalid Password Should Fail

  关键字名称

  • 此外，关键字命名应该具有描述性和清晰的。
  • 应该阐述关键字是做什么，而不是描述它该怎么做。
  • 非常不同的抽象等级(例如 Input Text 或者 Administrator logs into system )
  • 这些是不明确的（可选的）指导方案,一个关键字标题大写或者是第一个字母大写。
    • 标题大写经常被使用在关键字名称很短的时候（例如：Input Text)。
    • 通常关键字第一个字母大写是较好的运行方式，因为它就像一个句子。这些关键字往往也有更高的等级。(例如：Administrator logs into system)

    好的案例：

    1 2	*** Keywords *** Login With Valid Credentials

    差的案例：

    1	Input Valid Username And Valid Password And Click Login Button

    初始化(setup)和拆卸(teardown)关键字命名

    • 尽量使用描述它是做什么的名词。
      • 尽可能使用一个已经存在的关键字。
      • 如果一个 初始化 和 拆卸 包含不相关的步骤，多个抽象名词是可被接受的
        • 清单中名词的步骤是重复和维护问题。
        • 使用一些普通的名字是更好的。（例如： Initialize system ）
        • 如果关键字覆写了已经存在在更底层的步骤，一定要内置关键字 运行关键字 能够正常工作。
          • 如果 初始化 和 拆卸 场景只需要使用一次，就不要重复的使用。
          • 每个人使用这些 初始化 和 拆卸 应当都是明确的。

          好的案例：

          1 2	*** Settings *** Suite Setup Initialize System

          好的案例（如果只使用一次）：

          1 2 3 4 5

          Suite Setup Run Keywords ··· Login To System AND ··· Add User AND ··· Activate Alarms AND ··· Check Balance

          差的案例：

          1 2	*** Settings *** Suite Setup Login To System, Add User, Activate Alarms And Check Balance

          文档

          测试套件文档

          • 经常一个好的想法添加到测试案例文件的综合文档中。
          • 应当包含后台信息，为什么要创建测试，备注执行环境，等。
          • 不要只重复测试套件名称。
            • 如果真的不需要最好不添加文档。
            • 不要包含太多测试案例详情。
              • 测试应当足够清晰明了。
              • 重复的信息是浪费的还有维护问题。
              • 文档可以包含更多信息的链接。
              • 如果你需要文档信息相当于 键值对，可要考虑使用测试套件元数据。
              • 文档和元数据是顶层的套件，可以在命令行中各自使用 --doc 和 --metadata 选项。

              好的案例：

              1 2 3 4 5 6

              *** 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 ）:

              1 2	*** Settings *** Documentation Tests Account Withdrawal.

              测试案例文档

              • 通常测试不需要文档。
                • 父套件的文档和测试案例的名称，应当给予足够的后台信息。
                • 测试案例结构应当足够清晰在没有文档和注释的情况下。
                • 标签通常比文档更灵活的提供更多实用性（统计，包含/排除，等）。
                • 有时候测试文档是有用的，无需害怕使用它。

                好的案例：

                1 2 3 4 5 6 7 8

                *** 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

                差的案例：

                1 2 3 4 5 6 7 8 9 10

                *** 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 Broser ${URL} ${BROWSER} Input Text field1 ${NU11} Input Text field2 ${PW11} Click Button button_12 Titlt Should Be Welcome Page

                用户关键字文档

                • 如果关键字相对简单的话，文档不是必要的
                  • 好的关键字和参数名称和清晰的结构是足够的。
                  • 最重要的使用方式，文档参数和返回值。
                  • 在资源文件中展示，使用 Libdoc 生成关键字文档，以及编辑器 RIDE 能够展示它在一个关键字中或者其他地方。

                  测试套件结构

                  • 在一个条件里每个测试都应当是相关联的。
                    • 通常公共的 初始化 或 拆卸 是不错的提示物。
                    • 在一个文件里不能改包含太多的测试（最大10个），除非它是数据驱动测试。
                    • 测试应当都是独立的，初始化使用 setup/teardown 。
                    • 有时候依赖测试时不可避免的。
                      • 例如，套件能够分别的多次初始值对于所有测试。
                      • 从来没有长链式的依赖测试。
                      • 考虑使用这个 ${PREV TEST STATUS} 变量来验证前一个测试的状态。

                      测试案例结构

                      • 测试案例应当简单易懂。
                      • 一个测试案例只测试一件事情。
                        • 事情能够很小（单一的功能部分）或很大（端到端测试）。
                        • 选择合适的抽象等级。
                          • 始终使用抽象等级（单一层抽象原理）。
                          • 不要包含非必要的详情在测试案例层。
                          • 两种测试案例：
                            • 工作流测试
                            • 数据驱动测试

                            工作流测试

                            • 通常有如下几个阶段：
                              • 先决条件（可选择的，经常在 setup )
                              • 动作（对系统做什么一些事）
                              • 核实（验证结果，强制的）
                              • 清除（可选择，经常在 teardown 去确保它被执行）
                              • 关键字描述一个测试做什么。
                                • 使用清晰地关键字名称来适应抽象等级。
                                • 应当包含足够的信息对于手动测试。
                                • 应当绝不使用文档和评论来解释测试是做什么的。
                                • 不同的测试有不懂的抽象等级。
                                  • 测试一个功能详情需要更清晰。
                                  • 端到端测试可能在更高的等级。
                                  • 一个测试应该只使用一个抽象等级。
                                  • 不同的方式。
                                    • 更多的专业测试针对底层详情和整合测试。
                                    • 可执行的规格 行为是必须的。
                                    • 使用领域语言。
                                    • 每个人（用户或产品拥有者）都能明白。
                                    • 没有复杂的逻辑在测试案例层级。
                                      • 没有循环或者判断结构。
                                      • 小心的使用指定变量。
                                      • 测试案例不应该看起来像脚本。
                                      • 最大10个步骤，更少是可取的。

                                      下面例子使用 标准 关键字驱动方式：

                                      1 2 3 4 5 6 7

                                      *** Test Cases *** Valid Login Open Broser To Login Page Input Username demo Input Password mode Submit Credentials Welcome Page Should Be Open

                                      下面例子使用高等级的 gherkin 方式：

                                      1 2 3 4 5

                                      *** 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 6 7 8 9 10 11 12 13 14 15 16 17 18

                                            *** 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 Password ${VALID USERNAME} ${EMPTY} Empty Username ${EMPTY} ${VALID PASSWORD} 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

                                            上述例子的可执行版本，请查看这个 网页项目示例

                                            用户关键字

                                            • 应该简单易懂。
                                              • 和工作流测试一样的规则。
                                              • 不同的抽象等级。
                                              • 可以包含一些程序逻辑（循环，判断）。
                                                • 尤其是一些低阶关键字。
                                                • 复杂的逻辑宁愿在用户关键字里而不是软件库。
                                                • 包含长而复杂的值。
                                                • 可以在命令行使用 --variable 选项，来传递信息。
                                                • 传递信息和关键字。
                                                • 清晰的并且不长的名字。
                                                • 能够在变量表中使用注释给文档更多详情。
                                                • 始终的使用案例。
                                                  • 在一个明确的作用域里面局部变量使用小写。
                                                  • 其他的都使用大写。（全局的，套件，和测试级别）
                                                  • 空格和下划线可以用来分割一个单词。
                                                  • 推荐使用清单变量，动态的设置在变量表中。
                                                    • 设置典型的使用内嵌的关键字 设置套件变量
                                                    • 这个初始化值应当解释，在何时哪里这个真实的值被设置。

                                                    1 2 3 4 5 6 7 8 9 10 11 12

                                                    *** Settings *** Suite Setup Set Active User *** Variables *** # Default sytem address. Override when tested agains other instances. ${SERVER URL} http://www.baidu.com ${USER} Actual value set dynamically at suite setup *** Keywords *** Set Active User ${USER} = Get Current User ${SERVER URL} set Suite Variable ${USER}

                                                    传递和返回一个值

                                                    • 从关键字中常见的处理是返回一个值，分配它们给一个变量并且将它们作为一个参数传递给其他关键字。
                                                      • 清晰和易于理解的方法。
                                                      • 允许创建独立的关键字并且方便重新使用。
                                                      • 看起来像编程，因为在测试案例级别不是很好。
                                                      • 可供选择的方式是从存储信息的软件库中或者使用内置的 设置测试变量 关键字。
                                                        • 避免编程式在测试等级。
                                                        • 可以更复杂的理解和制造困难的能重复使用的关键字。

                                                        好的例子：
                                                        

                                                        1 2 3 4 5 6 7 8 9 10 11 12 13

                                                        *** Test Cases *** Withdraw From Account Withdraw From Account $50 Withdraw SHould Have Succeeded *** Keywords *** Withdraw From Account [Arguments] ${amount} ${STATUS} = Withdraw From User Account ${USER} ${amount} Set Test Variable ${STATUS} Withdraw Should Have Succeeded Should Be Equal ${STATUS} SUCCESS

                                                        不是很棒的例子：
                                                        

                                                        1 2 3 4 5 6 7 8 9 10 11 12 13 14

                                                        *** Test Cases *** Withdraw From Account ${status} = Withdraw From Account $50 Withdraw Should Have Succeeded ${status} *** Keywords *** Withdraw From Account [Arguments] ${amount} ${status} = Withdraw From User Account ${USER} ${amount} [Return] ${status} Withdraw Should Have Succeeded [Arguments] ${status} Should Be Equal ${stauts} SUCCESS

                                                        避免使用休眠

                                                        • 休眠时非常脆的方式针对同步测试。
                                                        • 平均的安全边界会造成很长的休眠。
                                                        • 当一个确切的行为发生时，使用关键字替代休眠。
                                                          • 关键字名称通常是以 Wait ... 开始。
                                                          • 应该有一个最大的等待时间。
                                                          • 可以使用内置的关键字 Wait Until Keyword Succeeds 来包裹在其他关键字。
                                                          • 有时候休眠也可以简单的解决方案。
                                                            • 请小心的使用。
                                                            • 不要在用户关键字中使用，可以在测试或者其他关键字使用。
                                                            • 在调试中停止执行是非常有用的。
                                                              • Dialogs library 是一个非常好的库。
                                                              缺失模块。
                                                              1、在博客根目录（注意不是yilia根目录）执行以下命令：
                                                              npm i hexo-generator-json-content --save
                                                              
                                                              2、在根目录_config.yml里添加配置： jsonContent: meta: false pages: false posts: title: true date: true path: true text: true raw: false content: false slug: false updated: false comments: false link: false permalink: false excerpt: false categories: false tags: true