Robot framework测试脚本编写思考

基于Robot Framework框架使用经验，总结下测试脚本的设计思路。

这里所谓的设计思路，其实就是编写测试脚本时应该关注的点。在工作中，我有根据自己的经验，整理了针对实际工作内容的脚本编写规范，并逐步优化脚本编写规范以及测试脚本的模板。

个人以为，在编写测试脚本时，需要关注以下几点：规范性、简洁性、时效性、结构性、稳定性、可读性。

一、规范性

规范性有多重要呢？大家都遵循相同的规范，那么在看别人的脚本时，就容易找得着北。

• 脚本名称

  • 脚本命名要求能体现功能名称，也就是见名知意。如果团队需要维护多个测试组件的测试工程集，那么建议脚本命名规则：组件名称-功能名称；
  • 全部使用小写字母；
  • 使用英文描述，描述需简洁，禁止使用拼音和特殊字符；
  • 英文单词之间用"-"符合隔开。

• 用例名称

  • 名称格式为：序号-英文名称，如"01-Test point"；
  • 简洁明了，可体现case要测试什么；
  • 单词之间可使用英文空格隔开或者"-"隔开；
  • 名称不使用特殊字符，如@,/等；
  • 英文名称部分，首字母大写，其他均小写；

• 配置文件命名

  • 全部使用小写字母；
  • 使用阿拉伯数字+组件名称以表示用例的序号；
  • 每个用例对应一个配置文件，如果一个用例使用多个配置文件，则配置文件的命名格式采用划线后紧跟阿拉数字再紧跟下划线最后紧跟阿拉伯数字；

• 变量定义
  在脚本中多次(2次以上)使用的一些值，可定义为变量值，以简化脚本编写及后期维护的工作量。
  Robot Framework是不区分大小写的，但我们习惯将全局变量用大写，局部(临时)变量用小写；单词之间用空格隔开，不要使用特殊字符。

• 自定义关键字的命名
  脚本语句超过2句及以上并且在2个及以上地方被调用，建议自定义关键字实现。

  • 名称一律使用英文，要求简洁明了，可体现关键字实现的功能；
  • 单词之间使用英文空格隔开；
  • 名称不要使用特殊字符，如@，/等；
  • 名称英文部分首字母为大写，其他均小写；
  • 功能复杂，需要Documentation用描述；
  • 关键字要求具有通用性，功能相近尽量使用一个关键字实现；

• CaseTags
  case tags用于匹配不同序号的用例，方便对每个测试用例单独测试。
  标签固定格式为"_case+序号"，序号对应测试用例编号。

• Suite Documentation
  这是针对整个脚本的描述,位于脚本名称下的Settings下。可在此处添加功能名称、需求链接、版本号、研发人员、测试人员等信息。
  通常我还会把该测试脚本所覆盖的测试点，按照测试用例的顺序，在此处罗列，让脚本所覆盖的测试点一目了然。

• Case Documentation
  这是针对每个用例的描述，位于每个用例的Settings下。
  case documentation用于描述测试用例，包括用例标题、配置、步骤和预期结果。

• case独立性
  每个case之间不能有任何的依赖关系，需要保持各自测试的独立性，各自均可独立运行。

• 功能单一性
  尽量保持用例功能的单一性。所谓单一性并非一个case只能测试一个测试点，可包括几个有关联并且可连续的测试点，但不可随意穿插其他测试点。

二、简洁性

测试脚本应该保持精简。精是一种修炼，简是一种风格。如何保持简洁性？最基础的就是不要冗余。

• 不要有冗余的变量；
• 不要有冗余的自定义关键字；
• 不要有冗余的操作；
• 不要有冗余的注释注解；
• 配置文件中不要有除了配置模板以外的冗余配置；

三、时效性

脚本时效性的重要性，大家知道得不彻底。为什么说不彻底呢？因为工作过程中有发现挺多测试人员有个错误的观念：我一个suite/case多花一两秒、几秒或十几秒，有什么关系呢？
有什么关系呢？整个测试工程集有几千个case，每个case要是多花一秒，积少成多就是几千秒了。按照我们现有的case量，一次回归就得至少多花两小时。
对一个初级的脚本编写者来说，关注脚本时效性可以考虑以下几点：

• 谨慎使用sleep；
• 操作的必要性；
• 尽量请求小文件；
• 响应时间
• 系统时间
• 能在suite层一次操作的，不要在case层多次操作；(举个例子：我们工作过程中，使用lighttpd模拟源站。如果脚本中的所有用例都使用同一份lighttpd配置文件启动，那么我们一般把lighttpd的启停放在suite setup/teardown，而不是放在 case setup/teardown中多次启停。)

更进一步来说，脚本时效性和测试点、测试用例的组织，脱离不开关系。30个测试点组织成10个case和30个测试点组织成8个case，脚本的运行时效性是不一样的。时效性差多少，就和脚本运行的每个操作有关系了。

清楚地知道每个常用操作的运行耗时，能帮助我们写出时效性更强的脚本。如何知道每个操作的运行耗时呢？看脚本运行结束后生成的log.html即可。

四、结构性

清晰的脚本结构，包括用例集的初始化和结束(Suite setup/teardown)、用例的初始化和结束(Case setup/teardown)。

• Suite Setup
  执行测试脚本前进行环境初始化操作。如关闭会影响本脚本的应用程序，释放端口，源文件拷贝，配置准备等。
• Suite Teardown
  执行完测试脚本后恢复测试环境。如关闭脚本启用的应用程序，删除suite setup中拷贝的源文件和配置，删除脚本产生的临时文件，系统时间恢复等。
• Setup
  执行测试用例前先关闭某些程序，清除某些可能会影响用例正常执行的文件。
• Teardown
  用例执行后判断是否存在core文件。也可以像Case setup一样关闭某些应用程序和删除文件。但是操作不能和Case setup重复，避免浪费时间。

五、稳定性

稳定的脚本可以降低自动化维护成本。
常见的脚本稳定性的问题有：

• 程序启动失败
  程序要监听的端口被占用，导致启动失败。应当在Suite setup/Case setup中释放要监听的端口。

• tcpflow抓包失败

  • 一种是没抓到数据
    这种失败是因为tcpflow抓包命令后后台执行，但还没执行时，请求命令就已经结束，导致抓不到数据。
    解决这种问题，我一般在tcpflow抓包命令后台执行后，sleep 0.3s;
  • 另一种是抓到数据但读不到
    这种失败是抓包数据来不及写入临时文件导致从临时文件获取数据失败。
    解决这种问题，可以先把tcpflow命令结束掉(会被缓冲区的数据写入临时文件)再执行从临时文件获取数据的操作。

• 内部测试依赖外部资源
  原则上内部测试不用使用外部资源，必须在内网搭建环境。

• 路径问题
  由于自动化平台运行脚本并不是在脚本的当前路径下执行的，所以，脚本中的配置文件都要指定路径，特别是当前路径的情况下，要加${CURDIR}/,以免自动化平台运行时找不到指定的配置文件而导致脚本运行失败。

六、可读性

可读性好的脚本，可以降低他人学习和维护该脚本的成本。

良好的用例编写习惯可以让他人更容易看懂你的测试用例和测试脚本。Case Documentation中要有完整清晰准确的测试用例。

测试脚本中，也可以增加适当的注释使脚本更易于理解。
注释有Comment和"#"两种。前者注释的内容会体现在报告中，后者注释的内容不会显示在报告中。建议在脚本中使用Comment进行注释，并用"Comment step-n"把脚本步骤和用例步骤进行一一对应。

实际工作中，建议持续维护配置文件模板和测试脚本模板。模板既是对工作的优化固化，又可以降低脚本编写调试、学习维护的成本。