接口测试代码规范

发表于 | 分类于 | 次

1.1 style check

python的代码风格应该遵循 pep8，目前在push代码后由 gitlab-ci 进行检查，检查是通过 flake8 执行。其中我们修改的规则有：

  • 行宽限制，规定最大长度为120

目前automatic style check中没有enable，但是需要遵循，未来可能通过插件形式加入自动检查规则的包括 import顺序，应该遵循以下顺序，并且在每一个类别之间以一个空行分割：

  • standard library
  • third party library
  • local application / library specific import

tfws/libs 下引入的library与pep8风格差别较大，其中最大的区别是采用2空格缩进，修改后注意检查

1.2 命名规范

  • class 名首字母大写，使用CamelCase(PascalCase)方式命名
  • 文件名、模块名、函数名、变量名全部小写，采用下划线分割（snakecase）
  • 模块的 private 成员用单下划线 开头
  • 全局以及Class Constants采用大写，下划线分割，如 CLASS_CONSTANTS

1.3 注释规范

注释样例

  • 所有的public class都应该有docstring注释， doccstring使用三个双引号开始(“””)docstring应该写明该类的主要作用 在Args段写明构造函数参数（init函数的docstring在此时可以省略 在Attrbutes段列出该类的所有public attributes
  • 所有的public function以及methods都应该有doctring docstring的目标是让其他用户明确该函数的作用，以及可以在不阅读具体代码的情况下可以使用这个函数。 应当包含Args字段，以及Return（或者yield）字段 （Optional）列出该函数可能抛出的异常
  • 块注释应该缩进到与该代码块相同的级别

1.4 其他规范

  • 5行以上的代码块不允许出现重复
  • 使用assertpy.assert_that，assertpy.assert_warn断言时，需要在第二个参数description描述清楚失败的原因
    eg. 对于检查http response的内容时，建议直接把response赋值给description，assertpy.assert_that(rsp.rtn, rsp).is_equal_to(0)
  • 禁止代码里语义不明的数字，需要替换成带有语义的常量，比如一些响应错误码
  • 测试用例函数下方请按以下顺序写出完整的测试用例描述
    • u”””
    • @Title: 简要描述该用例主要测试点，函数名需和该描述一致
    • @Author: Weitai.Lin 写上自己的域账号，最后一个更新该用例的人需要更新Author为自己
    • @Description: 描述完整用例经过，step by step
      • step 1:
      • step 2:
      • …
    • @Checkpoint: 描述测试用例的检查点，即用例通过的标准
      • 1.xxx
      • 2.yyy
    • “””
  • 所有的测试用例函数上面都需要用pytest.mark标识这个用例满足的规则，以满足不同时间的测试需求，分类由业务团队自己定义
    • eg. 有些用例跑起来非常耗时，且相关模块平时不怎么动，可以每周跑一次，有些用例则需要每天都跑，有些冒烟用例需要每次提交代码都测试, 则可以定义以下几种mark
      pytest.mark.daily
      pytest.mark.weekly
      pytest.mark.smoke
      运行时加上-m smoke时就只会跑smoke标识的用例
    • 可以根据feature加一些feature的mark，比如pytest.mark.retrieval
    • 可以根据用例的优先级来定义一组
    • ……
  • 变量的命名需和业务术语一致，像jiansuo，bukong这种变量命名是不被允许的
  • 单词的缩写需要能完整表明语义
  • 提交代码前需要保证pytest –collect-only不报错
  • 同一个feature的测试用例应该放在相同的目录下
  • 保证测试代码是幂等的