3.2.6 标签
Robot Framework支持对测试用例设置标签，在运行时可以指定只运行有某一种或几种标签的测试用例。这是一种很智能的分类方法。例如，一个产品有成百上千个测试用例，全部运行一遍可能需要几小时甚至几天。如果每次提交代码后都运行所有的测试用例，将会使反馈周期相当漫长。这个时候可以把测试用例分类，并设置不同的标签。例如，对基本的测试用例设置smoke标签，对所有测试用例设置regression标签。这样每次提交代码时，可以指定只对拥有smoke标签的测试用例做冒烟测试。每天或发布新版本前对所有拥有regression标签的测试用例做回归测试。
不仅可以在某个具体的测试用例上设置标签，还可以在测试工程和测试套件中为所有测试用例都设置同一个标签。用Force Tags或Default Tags可以设置这种标签。
1．测试工程里的标签
在测试工程中，Force Tags用于为测试工程及其子目录下的所有测试用例设置同一个标签。如果要为所有测试用例设置一个regression标签，我们不必在每一个测试用例上都设置该标签，只需要在产品顶层目录的Force Tags里填上regression即可。
2．测试套件里的标签
在测试套件中，Force Tags用于使本测试套件里的所有测试用例拥有相同的标签，Default Tags用于使本测试套件里那些没有明确设置任何标签的测试用例拥有相同的标签。
3．测试用例里的标签
在测试用例中，[Tags]用于为某一个具体的测试用例设置标签。
下面是一个简单的示例。在测试套件里设置Force Tags为regression，设置Default Tags为smoke（见图3-26）。不管这个测试套件下的所有测试用例有没有设置自己的标签，都将强制为它们设置一个regression标签。如果没有设置任何标签，那么smoke标签也会默认加上，如图3-27所示。
图3-26 在测试套件里设置Force Tags和Default Tags
图3-27 3-2-1-Variable TestSuit下的测试用例将自动拥有测试套件里设置的标签
如果测试用例有自己的标签，那么smoke标签就不会加在这个测试用例上。比如，如果有一个测试用例需要花比较长的时间，不想让它在持续集成过程里运行冒烟测试，可以设置一个not_in_ci标签，如图3-28所示。
图3-28 在测试用例里设置not_in_ci标签
3.2.7 超时设置
部分测试用例在设计过程中可能考虑不周，使得它占用较长时间甚至永远运行不完。Robot Framework提供超时机制来强行终止现在运行的测试用例并将测试用例执行结果标记为fail。超时可以设置在测试套件里，也可以设置在测试用例里。测试套件里设置的超时时间（Test Timeout）不是指整个测试套件中全部测试用例执行完的最长时间，而是指本测试套件里每个测试用例的最长运行时间。在此时间之内，如果没有执行完，就会强行终止，并将结果标记为fail。如果超时时间同时在测试用例和测试套件里都设置了，那么以测试用例的设置为准。例如，测试用例里设置的超时时间是3min，但是该测试用例所在的测试套件里设置的超时时间为2min，即使测试用例的运行时间超过2min也不会马上终止，而是会继续运行或等到超时时间3min用完后才退出。
时间遵循3.2.3节讲述的格式，如5 minute、1 min 30 sec。
3.2.8 模板
前面提到数据驱动和关键字驱动，它们是两种不同风格的自动化方法测试。
·数据驱动：基于模块化的测试库，将数据与测试脚本分离。通过一系列测试数据可以覆盖不同的测试分支。一个驱动脚本可以执行多个相似测试，这样非常容易建立新测试。维护工作可以分离，测试人员负责数据，开发人员负责写测试库。
·关键字驱动：将数据与关键字结合起来描述如何使用数据执行测试。测试用例总体上用关键字来组织和驱动。这种方法具备数据驱动的优势，同时非编程人员也能建立新测试。所有测试由同一个框架执行，不需要不同的驱动脚本。
Robot Framework是关键字驱动的测试框架，从前面的章节中我们已经了解到了关键字的组织和编写方法，Robot Framework测试用例的设计就是关键字的设计和使用。
其实，Robot Framework支持数据驱动的测试用例设计。它是通过在测试套件或测试用例里定义测试模板来实现的。我们通过一个简单的例子来理解测试模板。
假如我们要对一个登录界面做测试，此界面上有两个文本框。一个是“用户名”，另一个是“密码”。此外，还有一个“登录”按钮。登录界面如图3-29所示。
图3-29 登录界面
要对这个登录界面做测试，用户名和密码有非常多的组合方式：
·正确用户名 + 正确密码；
·正确用户名 + 错误密码；
·不存在的用户名 + 合法密码；
·空用户名 + 合法密码；
·非法用户名 + 合法密码；
·合法用户名 + 非法密码；
·合法用户名 + 空密码。
如果用关键字驱动的方法编写测试用例，如下所示。
Invalid User Test Case input ${id_of_user} 非法用户名 input ${id_of_passwd} 正确密码 click button ${id_of_login} main page cannot be open Empty User Test Case input ${id_of_user} ${EMPTY} input ${id_of_passwd} 正确密码 click button ${id_of_login} main page cannot be open …… |
如果用数据驱动的方法编写测试用例，如下所示。
*** Test Cases *** Login UI Invalid Input Check Test Case [Template] Invalid Login Check 非法用户名 正确密码 ${EMPTY} 正确密码 合法用户名 错误密码 合法用户名 ${EMPTY} …… *** Keywords *** Invalid Login Check [Arguments] ${username} ${passwd} input ${id_of_user} ${username} input ${id_of_passwd} ${passwd} click button ${id_of_login} main page cannot be open |
在关键字驱动的测试用例设计中，每一个测试用例用于测试用户名和密码的一种组合，每个测试用例里都需要重复使用关键字input、click button等。
在数据驱动的测试用例设计中，我们抽象出一个关键字Invalid Login Check作为模板来验证非法登录的测试组合。各种不同的用户名和密码的组合不再需要重复写测试用例，而只需将用户名和密码像数据字典一样罗列在表格中，来覆盖不同的数据驱动测试场景。
Robot Framework的测试模板一般由一个关键字构成，可以将此关键字放到资源文件里。如果将测试模板放在测试套件文件里，那么这个测试套件里的所有测试用例只能按模板定义的格式罗列测试数据。由于一个测试套件由一个独立的文件构成，因此这个文件就是完全由数据构成的数据驱动测试文件。
版权声明：51Testing软件测试网获得人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
