脚本编写_脚本编写效率总结

一、目的

测试脚本作为测试与质量工作中非常重要的文档，实现及调试、移植到CI、维护等相关工作都需要投入很多时间，文章通过一些这方面思路的梳理和分享，期望能对过程效率有一些借鉴意义。

二、详细说明

• 从编写一份优秀的case说起

测试脚本的一般入口是测试用例，编写一份优秀的测试用例，可对测试脚本实现起到事半功倍的效果。

case设计可关注以下几个方面：

1.描述清晰，测试脚本关注信息（前提条件、操作步骤、断言三大块），case可有明确准确的相关描述，能明确指出测试方法、测试命令、断言详细信息，就不要用文字模糊描述

2.测试用例避免跳跃性思维，避免把无关逻辑、关联性弱的整合到一个case中

3.部分逻辑可整合为一个case，减少环境准备、数据重复准备成本等

4.case之间互不耦合

5.case考虑抽象为“数据驱动”步骤，脚本转换成本更低

6.……

• 有统一的环境管理方式

一般情况下本地调试脚本的环境和CI的测试不一致，甚至参与脚本编写的人较多，这种情况下会存在环境之间的差异性，导致脚本移植存在问题，固需要有一个环境统一管理方式，如部署手册、部署软件统一性、甚至Jenkins管理所有机器进行统一管理、docker镜像管理等。

做到环境一致、最新，可减少差异、缺失，确保移植可用性、测试精准性、脚本维护工作等。

• 有统一认知的规范

脚本是一种弱代码，有自己的生命周期，在服务软件长期存在且动态变化中，可能参与的人员众多、参与人员水平、参与人员角色、不同时期，如没有一个统一的规范，可能导致五花八门、维护难道高、排查效率低、稳定性差各种状况。

规范可从几个维度入口：

1. CI 要求规范，确保与CI契合
2. 低级错误规范，避免各种明显低级错误，提供脚本编写质量和效率；
3. 维护相关规范，降低维护和排查投入成本
4. 其他

• 有一个脚本模板

脚本一般都可以抽象形成一个模板，共大家直接拿来使用，类似需求、设计有个模板，可包含：

1. 规范要求信息，减少规范理解和学习成本；
2. 包含以下基本的依赖（如RF库、变量文件导入等），减少重新建档的成本和错误；
3. 包含脚本的基本框架，保证脚本编写架构一致性，减少后期理解和维护、排查成本；

• 及时抽象重复逻辑，活用关键字

及时抽象重复逻辑，形成关键字，供脚本编写使用，在团队中可以减少五花八门的逻辑（实际上可能是同一个逻辑或者相似的逻辑），可以提高编写效率。

对各种关键字可以梳理一些关键字示例，供团队查阅参考使用，减少理解成本、自创成本、维护成本。

• 了解IDE，善用使用技巧

有很多ide，有非常强大的插件，及快捷键之类的使用技巧，可以解决各种效率问题。

如RF框架，RIDE有一些常用快捷键，可实现快速查询关键字、搜索关键、创建工程/用例、自动补全关键字等，可以让效率有很大提示，参考文档：

robotframework常用的几个快捷键_爱敏的博客-CSDN博客​blog.csdn.net

。

如window同步linux脚本及远程执行，参考本专栏其他文章。

• 其他

等