Python自动化框架代码规范

1 规范目的及适用范围

1.1 规范目的

1. 对于一个成熟的测试框架，80%的花费在于维护，为了降低维护维护成本，有必要制定编码规范
2. 编写测试用例的人员，可以很容易读懂测试框架的内容，使得手动测试人员也可以轻松的编写自动化测试用例，达到全民编程的目的
3. 好的编码约定可使源代码严谨、可读性强且意义清楚，与其它语言约定相一致，并且尽可能的直观

1.2 适用范围

1. 本规范以Python为开发语言的规范
2. 适用于NetBrain NG8.0自动化框架和自动化测试用例
3. 适用人员：Automation QA 和各个功能模块的Owner

2 具体Python编码规范规则

2.1 简明概述

2.1.1 编码

如无特殊情况, 文件一律使用UTF-8编码
如无特殊情况, 文件头部必须加入#-*-coding:utf-8-*-标识

2.1.2 代码格式

2.1.2.1 缩进

统一使用 4 个空格进行缩进

2.1.2.2 行宽

每行代码尽量不超过 80 个字符(在特殊情况下可以略微超过 80 ，但最长不得超过 120)

理由：

这在查看 side-by-side 的 diff 时很有帮助
方便在控制台下查看代码
太长可能是设计有缺陷

2.1.2.3 引号

简单说，自然语言使用双引号，机器标示使用单引号，因此 代码里 多数应该使用 单引号

自然语言 使用双引号 “…….”
例如错误信息；很多情况还是 unicode，使用u”你好世界”
机器标识 使用单引号 ‘……’
例如 dict 里的 key
正则表达式 使用原生的双引号 r”…”
文档字符串 (docstring) 使用三个双引号 “””……”””

2.1.2.4 空行

模块级函数和类定义之间空两行；
类成员函数之间空一行；

class A:

    def __init__(self):
        pass

    def hello(self):
        pass


def main():
    pass

可以使用多个空行分隔多组相关的函数
函数中可以使用空行分隔出逻辑相关的代码

2.1.2.5 编码

文件使用 UTF-8 编码
文件头部加入#--conding:utf-8--标识

2.1.3 import 语句

• import 语句应该分行书写

# 正确的写法
import os
import sys

# 不推荐的写法
import sys,os

# 正确的写法
from subprocess import Popen, PIPE

• import语句应该使用 absolute import

# 正确的写法
from foo.bar import Bar

# 不推荐的写法
from ..bar import Bar

• import语句应该放在文件头部，置于模块说明及docstring之后，于全局变量之前；
• import语句应该按照顺序排列，每组之间用一个空行分隔

import os
import sys

import msgpack
import zmq

import foo

• 导入其他模块的类定义时，可以使用相对导入

from myclass import MyClass

• 如果发生命名冲突，则可使用命名空间

import bar
import foo.bar

bar.Bar()
foo.bar.Bar()

• 导入总应该放在文件顶部, 位于模块注释和文档字符串之后, 模块全局变量和常量之前. 导入应该按照从最通用到最不通用的顺序分组:

• • 标准库导入
• • 第三方库导入
• • 应用程序指定导入

每种分组中, 应该根据每个模块的完整包路径按字典序排序, 忽略大小写.

import foo
from foo import bar
from foo.bar import baz
from foo.bar import Quux
from Foob import ar

2.1.4 空格

• 在二元运算符两边各空一格[=,-,+=,==,>,in,is not, and]:

# 正确的写法
i = i + 1
submitted += 1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)

# 不推荐的写法
i=i+1
submitted +=1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)

• 函数的参数列表中，,之后要有空格

# 正确的写法
def complex(real, imag):
    pass

# 不推荐的写法
def complex(real,imag):
    pass

• 函数的参数列表中，默认值等号两边不要添加空格

# 正确的写法
def complex(real, imag=0.0):
    pass

# 不推荐的写法
def complex(real, imag = 0.0):
    pass

• 左括号之后，右括号之前不要加多余的空格

# 正确的写法
spam(ham[1], {eggs: 2})

# 不推荐的写法
spam( ham[1], { eggs : 2 } )

• 字典对象的左括号之前不要多余的空格

# 正确的写法
dict['key'] = list[index]

# 不推荐的写法
dict ['key'] = list [index]

• 不要为对齐赋值语句而使用的额外空格

# 正确的写法
x = 1
y = 2
long_variable = 3

# 不推荐的写法
x             = 1
y             = 2
long_variable = 3

2.1.5 换行

Python 支持括号内的换行。这时有两种情况。

第二行缩进到括号的起始处

foo = long_function_name(var_one, var_two,
                         var_three, var_four)

第二行缩进 4 个空格，适用于起始括号就换行的情形

def long_function_name(
    var_one, var_two, var_three, var_four):
    print(var_one)

使用反斜杠\换行，二元运算符+ .等应出现在行末；长字符串也可以用此法换行

session.query(MyTable).\
        filter_by(id=1).\
        one()

print 'Hello, '\
      '%s %s!' %\
      ('Harry', 'Potter')

禁止复合语句，即一行中包含多个语句：

# 正确的写法
do_first()
do_second()
do_third()

# 不推荐的写法
do_first();do_second();do_third();

if/for/while一定要换行：

# 正确的写法
if foo == 'blah':
    do_blah_thing()

# 不推荐的写法
if foo == 'blah': do_blash_thing()

2.1.6 docstring

docstring的规范中最其本的两点：

所有的公共模块、函数、类、方法，都应该写 docstring 。私有方法不一定需要，但应该在 def 后提供一个块注释来说明。
docstring 的结束”””应该独占一行，除非此 docstring 只有一行。

"""Return a foobar Optional plotz says to frobnicate the bizbaz first. """

"""Oneline docstring"""

2.2 注释

2.2.1 注释

2.2.1.1 块注释

模块开始必须以以下形式书写模块注释，主要包括：（粗体字为必需部分，其余为可选部分）

文件名称(File Name)： 此文件的名称
功能描述(Description)： 此模块的功能描述与大概流程说明
作者(Author)： 此模块的编程人员
日期(Create Date)： 此模块的创建日期
参考文档(Reference)(可选)： 此模块所对应的分析文档，设计文檔。
引用(import) (可选)： 开发的系统中引用其它系统的DLL、对象等。
修改记录(Revision History)： 此模块的变更记录，如有变更需要有修改人员的名字、修改日期及修改理由。

2.2.1.2 行注释

1. 至少使用两个空格和语句分开，注意不要使用无意义的注释
2. 使用#region、#endregion块注释内容，方便收缩代码，每个部分很清晰

2.2.1.3 建议

在代码的关键部分(或比较复杂的地方), 能写注释的要尽量写注释

比较重要的注释段, 使用多个等号隔开, 可以更加醒目, 突出重要性

app = create_app(name, options)


# =====================================
# 请勿在此处添加 get post等app路由行为 !!!
# =====================================


if __name__ == '__main__':
    app.run()

2、文档注释（Docstring）
作为文档的Docstring一般出现在模块头部、函数和类的头部，这样在python中可以通过对象的doc对象获取文档.
编辑器和IDE也可以根据Docstring给出自动提示.

• 文档注释以 “”” 开头和结尾, 首行不换行, 如有多行, 末行必需换行, 以下是Google的docstring风格示例

• 不要在文档注释复制函数定义原型, 而是具体描述其具体内容, 解释具体参数和返回值等

• 对函数参数、返回值等的说明采用numpy标准, 如下所示

• 文档注释不限于中英文, 但不要中英文混用

• 文档注释不是越长越好, 通常一两句话能把情况说清楚即可

• 模块、公有类、公有方法, 能写文档注释的, 应该尽量写文档注释

2.3 命名规范

1、模块
模块尽量使用小写命名，首字母保持小写，尽量不要用下划线(除非多个单词，且数量不多的情况)

# 正确的模块名
import decoder
import html_parser

# 不推荐的模块名
import Decoder

2、类名

类名使用驼峰(CamelCase)命名风格，首字母大写，私有类可用一个下划线开头

class Farm():
    pass

class AnimalFarm(Farm):
    pass

class _PrivateFarm(Farm):
    pass

将相关的类和顶级函数放在同一个模块里. 不像Java, 没必要限制一个类一个模块.

3、函数
函数名一律小写，如有多个单词，用下划线隔开

def run():
    pass

def run_with_env():
    pass
私有函数在函数前加一个下划线_
class Person():

    def _private_func():
        pass

4、变量名

变量名尽量小写, 如有多个单词，用下划线隔开

if __name__ == '__main__':
    count = 0
    school_name = ''

常量采用全大写，如有多个单词，使用下划线隔开

MAX_CLIENT = 100
MAX_CONNECTION = 1000
CONNECTION_TIMEOUT = 600

5、常量

常量使用以下划线分隔的大写命名

MAX_OVERFLOW = 100

Class FooBar:

    def foo_bar(self, print_):
        print(print_)

6 Python之父Guido推荐的规范

4 错误处理
不要”捕捉了异常却什么也不做”。如果隐藏了一个异常，你将永远不知道异常到底发生了没有。

发生异常时，给出友好的消息给用户，但要精确记录错误的所有可能细节，包括发生的时间，和相关方法，类名等。
只捕捉特定的异常，而不是一般的异常。

正确做法：

try:
    print("try...")
    r = 10/0
    print('result', r)
except ZeroDivisionError as e:
    print("except:", e)
finally:
    print("finally...")
    print("END")

5 资源释放
所有外部资源都必须显示释放，例如：数据库连接对象、IO对象等

6 测试用例书写规范
测试用例应该包括以下几个代码块：（粗体字为必需部分，其余为可选部分）

• 测试用例编号（ID），优先级。

前提条件： 测试需要的前提条件。
测试步骤： 请尽量和测试用例的步骤对应。
从页面获取数据： 从页面抓取需要的数据实例化到相应的Data Module。
从数据库获取数据： 从MongoDB获取相应的数据源，并且实例化到Data Module。
页面数据和数据库数据对比：页面数据和数据库数据对比，两个Data Module执行Comparison操作。
输出测试结果： 把测试结果输出到本地Log，同时Population 到 Postgres数据库，用于Web Portal进行结果展示。
资源释放和清理： 测试环境恢复，测试数据的清除等

7 其他规范
Config文件的提交要求，添加appSettings或者connectionStrings允许修改，因本地运行或调试产生的配置文件修改不要上传。
代码重构等大批量修改代码操作需要至少两个人Review之后才能check In，避免不必要的rollback。