Robot Framework接口自动化脚本规范
人生苦短，务必性感。
结合实际项目，在敏捷模式下的自动化接口测试实践
使用Robot Framework做接口自动化，敏捷工具选用TFS
如丝般润滑。。。
目录
1、概述
为了规范自动化脚本的质量，写出更好的自动化脚本，特编写了此文档。
本文档分两部分，第一部分针忽略使用语言的特性，针对自动化脚本共性的问题对脚本规范进行了描述。Robot Framework是经过调研选用的自动化框架，本文第二部分针对RF做了具体的说明。
2、自动化脚本规范
本文档从下面几个方面对对自动化脚本的规范进行描述，脚本的模块化，脚本的正确性，脚本的忠实性，脚本的可读性，脚本的可维护性，脚本的独立性，脚本的执行效率。
2.1、脚本的模块化
脚本的模块化：自动化脚本需要有各功能区域的模块划分
自动化脚本至少需要包含如下模块，公共函数，功能模块，测试脚本集，测试脚本，参数变量。各模块可以以文件夹或文件的方式进行组织，各模块功能介绍如下
公共函数：细化又可以分为业务的公共函数和非业务的公共函数。业务的公共函数主要是针对待测试的产品提取的。他可以被各测试脚本，其他公共函数调用。非业务的公共函数主要是一些第三方的库和包，一般这些包和自动化框架结合在一起。
功能模块：根据产品功能对自动化脚本的整体结构进行功能模块的划分。
测试脚本：也就是自动化测试脚本。
测试脚本集： 自动化测试脚本集合，以某种关系将自动化测试脚本以一定的顺序组合在一起，形成有特定测试目的的集合。建议自动化测试脚本集可以根据产品的不同功能以文件夹或者文件的形式存放。
参数变量：自动化脚本执行过程中的配置参数和变量。比如待测试设备IP地址，产品错误码，Restful接口url等。参数变量又根据作用的范围分为全局的参数变量和局部的参数变量。
2.2、脚本的正确性
脚本的正确性：在没有产品bug的情况下，自动化脚本编写完成之后需要保证100%的通过。
脚本作者编写完成自动化脚本，需要以测试集为单位对测试集中的所有自动化脚本执行多次并检查每次结果是否是100%成功，建议至少执行三次以上。自动化脚本reviewer人员需要检查脚本的成功日志以确认自动化脚本可以成功执行。
2.3、脚本的忠实性
脚本的忠实性：自动化脚本需要忠实于脚本编写的依据（测试用例，接口文档等）。
当自动化脚本的来源是测试用例的时候，自动化脚本需要准确实现测试用例的前置条件，操作步骤以及检查点。测试脚本中需要添加对应的测试用例的信息（测试用例ID，测试用例内容），方便后续在自动化脚本执行过程中的定位分析。
当自动化脚本的来源是接口文档的时候，脚本作者需要分两步去做。第一步是将接口转化为测试该接口的测试用例。脚本作者需要分析这个接口需要测什么，需要怎么测，每一个参数遍历的时候取什么值，异常值怎么取。这一块可以结合各种测试用例设计的 方法，比如等价类，边界值，正交法等。第二步，脚本作者将设计完成的测试用例转化为自动化脚本，在这一过程中要保证自动化脚本和测试用例的一致性。
2.4、脚本的可读性
脚本的可读性：自动化脚本中应当有清晰的注释，合适的命名。
自动化脚本中各全局变量名，通用方法名，类的命名需要能够表达其代表的含义或者用途。
自动化脚本需要将测试步骤和检查点抽象封装成函数或者方法，而不是将实现代码全部写在一个测试脚本中。
自动化脚本需要有清晰的注释表明步骤和检查点，建议按照如下截图，通过注释将自动化代码分成多个步骤，每一个步骤有清晰的注释并与测试用例保持一致。
2.5、脚本的可维护性
脚本的可维护性：自动化脚本在编写过程中要充分考虑到脚本在后期执行，分析，维护的方便。
自动化脚本的测试数据和测试逻辑应该保证分离，测试数据由单独的文件去保存。脚本的代码只能去引用定义数据的变量名称，不能使用硬编码。
对于系统有具体含义的编码，脚本作者需要统一提取并组织存放在变量文件中。比如系统错误码，各枚举的编码等。
自动化脚本需要根据各产品的业务提取可以适用于产品多个模块的公共方法，公共方法需要放在脚本的公共方法的模块以供各模块使用。
自动化脚本的检查点需要清晰明了，如果检查点非常复杂，建议将检查点进行封装，并添加注释对检查点进行解释。
自动化脚本的检查点需要在失败的时候有足够的日志打印，这些日志打印不限于检查点的失败信息，需要包含其他对定位失败有用的信息，比如系统状态，数据库取值等。
自动化脚本的公共方法需要有明确的作用域，每一公共方法只能被作用域之内的代码所调用。比较常见的定义是全局作用域，局部作用域（功能模块）等，全局作用域内的方法可以被所有脚本调用，局部作用域的方法只能被他作用域之内的脚本调用。
2.6、脚本的独立性
脚本的独立性：自动化脚本需要保证脚本和脚本之间的独立性，脚本和环境之间的独立性。
自动化脚本和脚本之间不能有依赖关系，一个自动化脚本能否成功执行不能依赖于另外某一个脚本。脚本之间的共同预置条件需要提取出来放在测试集的setup里面，并在测试集的teardown中进行清除。测试集中的脚本执行不能有顺序的要求，任何单个脚本应该可以正确执行，在测试集中可以全部执行，也可以选择测试集中的部分脚本进行执行。
自动化脚本不能对测试环境做数据持久化，在自动化测试中可以对待测试产品做一个预置状态的定义，这些配置往往是产品进行基本业务测试的一个必须配置。这个预置状态需要经过预先设计并发布给脚本作者。
脚本在执行过程中任何改变预置测试环境的操作需要在脚本执行结束后恢复，恢复的操作需要放在测试脚本或者测试脚本集的teardown中。保证测试环境在脚本执行前和脚本执行后的状态是一样的。
2.7、脚本的执行效率
脚本的执行效率：测试脚本应该以最快的速度执行。
脚本在编写过程中，需要通过合理的构建测试集，将公共的操作提取到测试集的setup中，减少整个测试集的执行时间。
脚本中任何出现sleep的地方都需要进行解释，所有使用sleep的地方都需要检查是不是应该用循环检查去替换。如果一定要用sleep，一定要指明为什么要sleep这么长时间。如果某个操作一定是在多少秒之后进行验证，这个多少秒是一个检查点的时候，可以使用sleep。
测试脚本应该以最快的速度失败，脚本的检查点需要尽早执行。能在setup中做的检查就不应该在脚本中做检查。
3、Robot Framework脚本规范
3.1、文件和目录结构
本部分主要对自动化脚本的目录结构进行定义和描述，包含了各目录的组织，目录的命名，文件的组织，文件的命名，以及作用。
3.1.1、目录结构概览
3.1.2、顶层目录结构
说明:
1.顶层目录，建议名称为XXXX项目，如本例中是VCMS项目
2.顶层目录下分为
项目配置参数
通用关键字
测试模块
1.项目配置参数名称
项目配置参数-XXXX：全局的配置参数，主要是待测设备信息，数据库连接信息等全局信息，要求如果待测产品从一个环境重新安装到另外一个环境的时候，我们所需要修改的信息都全部包含在这个文件内。
2.通用关键字名称
通用关键字-XXXX：产品级别通用的关键字，我们定义如果某关键字会被一个以上的测试模块所引用，那就是产品级别通用的关键字
3.1.3、测试模块目录结构
说明:
1.每一个测试模块一个文件夹，模块下面可以有子模块，建议模块下面最多只包含一个子模块
2.测试模块名称建议为XXXX模块
3.测试模块目录配置模块标签，格式为@模块=模块名，此例为@模块=告警管理
4.子模块如果存在需要配备子模块的标签，格式为@子模块=子模块名，此例为@子模块=历史告警
3.1.4、具体测试模块目录结构
说明:
1、具体测试模块下分为
测试集
关键字
变量
1.测试集名称
测试集-(子模块名)：所有子模块的测试脚本需要放在该子模块下面
2.关键字名称
关键字-(子模块名)： 所有基于子模块的关键字都需要放在里面
3.变量名称
变量-(子模块名)： 针对此子模块测试用例提取出来的变量需要放在里面
3.2、自动化脚本和关键字
本部分针对自动化脚本文件和关键字中文件进行了具体规定
3.2.1、通用部分
1.自动化脚本和关键字的代码应该逻辑清晰，有足够的注释和打印，如下脚本就清晰的表面该自动化脚本由三个步骤分别为新建设备，产生告警，数据清空
2.代码中不能出现无理由的sleep，对于脚本中任何sleep必须加注释说明sleep的原因以及为什么sleep这么长时间
3.对于需要等待某段时间再检查的，需要使用循环等待。循环等待推荐使用keyword-- Wait Until Keyword Succeeds
4.代码中不能出现hardcode，脚本中的hardcode需要提取出来放在变量里面
3.2.2、自动化脚本测试
说明:
1.每个测试集下面可以有多个测试脚本，建议将预置条件相同的测试脚本放在一个测试集中，这样一个测试集里面的测试脚本就可以共享测试集的setup和teardown，可以节省时间和资源，也便于维护。
2.测试脚本需要增加如下标签，分别表示脚本作者，脚本对应的测试用例id，脚本的优先级，和脚本运行的阶段，具体含义见TAG部分
@author=0049002074
@id=TC-20170623-0009
@priority=P1
@runlevel=smoke
1.自动化脚本的代码不适合出现太多的判断分支和循环，可以考虑用关键字封装并在自动化脚本进行调用
2.自动化脚本的初始配置需要放在setup里面，并在脚本运行完之后需要在teardown中进行删除。可以根据脚本的具体情况考虑是放在测试集或者自动化脚本的setup和teardown里面
3.自动化脚本需要在Documentation里面增加对应的测试用例的内容，直接把自动化脚本对应的测试用例内容拷贝到自动化脚本的Documentation里面即可
3.2.3、通用关键字
1.通用关键字由专人维护，通用关键字的新需求以及更新需要经过此人审核
2.所有通用的关键字，必须要添加标签 @author=XXX,并且有文档注释，文档注释需要包含关键字的使用说明，包括参数说明，返回值说明。可以参考如下格式：
在文本模式下查看为下面格式
3.2.4、自动化脚本和关键字命名
关键字的命名建议使用动宾结构，如下所示
自动化脚本的名称建议与PLM中测试用例名称一致，当出现标点符号的时候一律换成英文符号“-”或者省略，也可以使用动宾结构。（测试用例名称并不做强性要求，但是一定要能够表达出测试用例的基本意思）。
3.2.5、自动化脚本和关键字引用关系
为了避免脚本和关键字交叉引用带来维护的困难，规定自动化脚本文件只能引用同目录的同层级的关键字和上层级别的关键字。具体见下图
自动化脚本文件1可以引用关键字文件2,4,5
关键字文件2可以引用关键文件4,5
关键字文件4不可以引用关键字文件3
自动化脚本文件1 不可以引用关键字文件3
关键字文件2不可以引用关键字文件3
自动化脚本文件不可以引用自动化脚本文件
关键字文件不可以引用自动化脚本文件
当出现了自动化脚本文件1需要引用关键字文件3的时候，说明被引用的关键字不适合放在关键字3中，应当把被引用的关键字往上层提取，在本示例中可以放在关键字文件5中，作为一个通用关键字。
当一个关键字可能被超过一个模块引用的时候，该关键字就是一个通用关键字，需要将其放在通用关键字文件中
3.3、参数变量文件
3.3.1、参数文件
1.项目配置参数文件中的参数由自动化测试负责人进行管理并发布给各项目，其中每一个参数必须要添加注释表明参数的用途。
2.参数的命名最好能体现出该参数的用途
3.3.2、变量文件
1.每一个变量需要添加注释表明变量的用途
2.变量的命名要能够体现该变量的用途
3.3.4、TAG
为了避免冲突，特规定如下格式的TAG保留，个人不能随便在脚本中设置如下TAG
保留TAG： @XYZ=ABC
@为英文字母状态下的@，XYZ和ABC可以为中文，也可以为字母，整个TAG中间没有空格。
目前具体的保留TAG如下图所示：
| 保留的TAG | 说明 | 是否必须添加 |
| @author=0049003066 | 表明脚本作者是谁，=后面接十位工号，方便脚本数目统计 | 是 |
| @id=TC-20170623-0009 | 表面自动化脚本和测试用例的对应关系，id后面的内容是自动化脚本对应的测试 | 是 |
| @bug=WR-20160527-0005 | 用于标识部分脚本由于产品bug失败，主要用于执行分析过程中快速定位问题 | 否 |
| @priority=P1 | 表明自动化脚本优先级，要求和PLM中测试用例保持一致，P1,P2,P3,P4分别对应PLM中的非常重要，重要，一般，次要。如果PLM中设置了优先级则自动化脚本必须设置 | 是 |
| @runlevel=smoke | 用于后期脚本分层执行，考虑脚本是在smoke中执行，还是在回归测试中执行，分别在=后面取值smoke和regression来表示。如果脚本需要在多个测试场景中覆盖，如：smoke 和 regression。 则需要给脚本如下形式的两个tag： | 是 |
| @模块=XXX | 脚本属于的模块名称，用于模块脚本选择，模块脚本统计 | 是 |
| @子模块=XXX | 脚本属于的子模块名称，如果存在子模块就必须写，如果没有子模块则不用写 | 否 |
扫一扫
725
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
