自动化测试脚本编写规范.docxVIP

自动化测试脚本编写规范

做了近八年自动化测试，带过五六个团队，我最常跟新人说的一句话是：“写自动化脚本不是炫技，而是用最朴素的方式，让三个月后的自己还能看懂，让接手的同事不用骂娘。”这句话背后，藏着所有测试人的痛点——当初信手拈来的脚本，半年后自己都理不清逻辑；团队协作时，张三的脚本用”a1”“b2”命名，李四的脚本满屏复制粘贴，最后整个项目的自动化用例成了”数字积木”，一跑就报错，一修就耗时。今天咱们就掰开了揉碎了，聊聊自动化测试脚本那些必须遵守的”规矩”。

一、为什么需要编写规范？先聊痛点再谈意义

我刚入行那会儿，跟着师傅做电商系统的自动化测试。师傅是技术大拿，写的脚本运行速度快、覆盖场景全，可他离职后我们接手时，差点集体崩溃：用例命名是”test_001”“test_002”，变量名是”x”“y”“z”，关键步骤没有注释，遇到弹出框直接用”time.sleep(5)“硬等。有次线上活动前做全链路验证，脚本跑到支付环节突然报错，我们对着”driver.find_element_by_id(‘a’)“找了三天，才发现”a”是三天前前端改的临时ID，正式环境早就改成”pay_btn”了。

这件事让我明白：自动化脚本不是一次性工具，而是需要长期维护的”测试资产”。据统计，优秀团队的自动化脚本维护成本能控制在初始开发成本的30%以内，而缺乏规范的团队，这个数字可能高达80%甚至更多。编写规范的意义，就是通过统一的”语言”降低沟通成本，用可预期的结构减少维护难度，最终让自动化测试真正成为提升效率的”利器”，而不是拖慢进度的”负担”。

二、从0到1：自动化测试脚本的核心规范维度

2.1命名规范：让代码自己”说话”

我带团队时做过一个实验：随机抽取10份脚本，隐去作者信息，让团队成员两两一组解读用例功能。结果发现，命名规范的脚本平均解读时间5分钟，不规范的脚本平均耗时20分钟，还有3份根本没人能完全理解。这就是命名规范的价值——好的命名本身就是最好的注释。

2.1.1脚本文件命名

脚本文件的命名要直接体现”业务模块+测试类型”。比如用户登录功能的接口测试脚本，建议命名为”user_login_api_test.py”；购物车功能的UI测试脚本，命名为”shopping_cart_ui_test.py”。避免使用”test1.py”“v2.0.py”这类模糊命名，因为当项目里有几十个脚本时，你根本记不清”test1”测的是登录还是支付。

2.1.2用例名称命名

用例名称要完整描述”操作对象+操作动作+预期结果”。比如测试用户输入错误密码的场景，好的命名是”test_user_login_with_incorrect_password_return_error_tip”，而不是”test_login_error”。曾经有个新人写了个用例叫”test_login”，后来我们发现里面同时测了正确密码、错误密码、空密码三种情况，导致用例失败时根本定位不到具体问题——这就是用例名称不精准的典型教训。

2.1.3变量与函数命名

变量名要体现”数据含义+数据类型”，比如”user_name_input”（用户名输入框）、“error_message_text”（错误提示文本）；函数名要体现”功能动作”，比如”get_token()“（获取令牌）、”check_order_status()“（检查订单状态）。我见过最离谱的变量名是”aa”，后来问作者才知道是”address_area_selector”（地址区域选择器）——多打几个字母，能让后续维护少掉很多头发。

2.2代码结构：像搭积木一样设计脚本

很多新人写脚本喜欢”一镜到底”：从打开浏览器到关闭浏览器，所有操作全挤在一个函数里。我曾经见过一个300多行的UI测试脚本，里面既有元素定位，又有数据构造，还有断言判断，修改任何一个步骤都得从头翻到尾。优秀的脚本结构应该是”分层清晰、职责单一”，就像盖房子要分地基、框架、装修，脚本也要分不同的功能层。

2.2.1基础层：封装通用操作

把所有跨用例的通用操作单独封装，比如UI测试中的”元素定位”函数、接口测试中的”发送请求”函数、数据库操作中的”查询表数据”函数。我在项目中会专门建一个”common”目录，里面放”ui_common.py”“api_common.py”“db_common.py”，团队成员需要点击按钮时，直接调用”click_element(driver,locator)“，而不是每次都写”driver.find_element(…).click()“。这样做的好处是：当元素定位方式从”id”改成”xpath”时，只需要修改基础层的一个函数，所有调用它的用例都会自动生效。

2.2.2业务层：串联业务流程

业务层负责把基础层