从0到1 —— 自动化测试成功起步

前言

本文分享一个小规模测试团队从0到1探索自动化测试实践的过程，主要从项目背景、测试方法、框架选择、实现路径、遇到的问题及解决方法、价值、经验等方面进行介绍，希望对有自动化测试需求的团队有所帮助。

先说成果

2020年我们前后用了六个月左右时间，泰康云CSDG测试团队三位伙伴在日常测试工作之余，从零开始掌握了python+selenium技能，完成了17个菜单下136个测试用例的编写，经过不断优化脚本和测试数据，脚本通过率可以达到80%以上，使原本需要花费两人天时间的回归验证工作压缩到3个小时内完成（自动化测试加未通过的用例手动验证）。

实现自动化测试之前，因为回归测试太耗费时间和人力，上线之前基本没有做过完整的回归测试，只对主要功能进行简单检查。实现自动化测试之后，每次上线之前都可以对原有功能进行回归，上线更安心。

团队不大，挑战不小

我们是个小测试团队，六位测试伙伴负责四个产品的测试任务，深度参与产品研发全过程：参与产品需求讨论，测试用例设计，测试计划制定，测试执行，上线验证工作。每个产品开发团队十人左右，测试人员一到两人，开发采用敏捷管理模式，开发系统为WEB系统，两到三周一个迭代。

目前各个产品都在新功能开发阶段，开发节奏紧张，人力投入有限，导致开发完成时间离功能上线的deadline越来越逼近，严重压缩了测试时间。宝贵的测试时间只能用来完成新功能验证，原有功能的回归测试越来越力不从心。因各系统具有很大的差异性，并且各个项目上线节奏不同步，测试人员无法在项目间共享，无法增加人力，只能寄希望于自动化测试来解决回归测试的需求。

在本次自动化测试实践之前，我们是个纯手工测试团队，几乎没有自动化测试经验。本次自动化测试实践是一次从零开始的探索实践过程。我们针对其中一个投入人力最多、回归测试压力最大的项目进行，参与的测试人员四人，其中三人主要完成测试框架和测试用例脚本开发任务，一人参与了流水线配置和测试环境配置工作，均在不影响日常测试工作的情况下进行。

测试方法选择

目前功能测试角度的自动化测试往往采用接口自动化测试和UI自动化测试两种方式，UI界面一般变动比较频繁，每次界面变动都可能引起测试脚本修改，因此维护测试脚本的工作量比较大，所以目前业内比较推崇接口自动化测试，但是实际选取哪种自动化测试方式还得取决于业务实际情况。

我们首先也尝试了接口自动化测试，尝试过使用JAVA+TestNG编写测试脚本，尝试过Jemter生成接口测试用例。但是实践证明，对于有大量界面功能的系统，接口测试无法对系统进行有效的回归，有超过50%的问题是前端问题，或前端对接口的不恰当调用引起的问题，所以完全采用接口自动化测试无法满足我们系统日常回归测试的需求，我们采用了UI自动化测试。

实现路径

自动化测试一般采用如下工具来实现：

• 采购商业化测试平台，功能完善，界面友好，成本较高；
• 自研测试平台，满足公司或项目个性化需求；
• 采用开源工具，接口测试使用的较多；
• 基于开源框架编写测试脚本/代码，灵活性强，工作量较大，对测试能力有一定要求；
• 使用工具录屏，生成测试脚本，操作简单，缺乏灵活性，维护成本很大。

对于测试投入有限的小团队，采购商业测试软件和自研测试平台都不现实；录屏工具看似容易，但稳定性非常差，难以持续维护。因此我们采用基于开源框架编写测试脚本的方式来实现。考虑到我们是一个年轻的纯手动测试团队，团队成员测试经验有限，缺少编程语言基础，在这种情况下，我们选择python+selenium这种应用广泛的脚本语言和主流测试组件，降低学习成本，激发学习热情。

我们首先划分了测试工具的功能模块，设计每个模块的具体功能。采用HTMLTestRunner管理测试用例执行和测试报告生成。

HTMLTestRunner实际上是采用的python unittest进行用例执行管理的，方便灵活，如果对测试报告有特殊要求，可以对HTMLTestRunner的测试报告部分进行修改和编辑。使用python unittest的断言来判断测试用例执行结果。我们基于python logging模块进行了log功能封装，根据每个测试用例生成测试报告，对测试服务启动、运行过程等公共代码执行也能生成log文件进行记录，便于问题定位。测试环境地址、浏览器类型等通过配置文件定义，增强灵活性。测试数据通过excel文件进行管理，可以灵活修改，也为后续数据驱动测试提供可能。编写了邮件通知功能，测试结束后，对测试报告和测试log进行打包发送，可以根据配置选择发送或者不发送，可以配置邮件接收人。测试框架的主要模块以及模块间关系如下图所示。

测试脚本完成后就可以随时随地执行，但是最重要的是能在新版本上线前执行。我们之前只有一套测试环境，测试脚本编写好后，发现执行自动化测试的时间和手动测试的时间有冲突，自动化测试和手动测试同时在一套测试环境上执行会产生干扰，影响测试效果。于是我们搭建了一套自动化测试环境，专门用于进行自动化测试。在一个完整迭代周期里，我们执行的各种测试工作如下图所示。

那么，对于一个零自动化测试基础的团队，如何进行上文介绍的框架的搭建和脚本的编写呢？我们通过自学和内部培训的方式来获得技能。先熟悉python语言，然后由有代码经验的测试工程师进行测试框架的设计、模块划分，主要代码的编写。Python语言学习掌握较好的伙伴可参与编写公共部分代码。然后由有经验的工程师选取几个稳定的页面（很少修改的页面）编写测试脚本demo。使用编写好的框架和测试脚本进行内部培训，测试人员按照测试脚本demo的结构和流程编写脚本并调试。之后团队一起对新编写的脚本进行review。经过几轮编写脚本和review之后，团队成员基本掌握了在本框架下编写测试用例的能力。

测试代码管理

在本项目实践中，没有专门的自动化测试岗位，参与测试的测试工程师都需要编写自己负责的模块的测试脚本。随着学习和实践经验的积累，测试脚本中的公共代码部分也在优化，那么这就需要对测试脚本进行代码管理。我们把测试项目放在gitlab上管理，并且制定了分支管理策略。

我们将devops分支作为执行测试的分支，个人修改代码后提交到远程个人分支，再merge到devops分支。当脚本稳定后，将devops分支merge到master分支，可以考虑打标签进行备份。

测试流水线

我们申请了专门的虚拟机来运行测试脚本，在TDS平台（基于jenkins的Taikang Deveops Service平台）建立测试项目流水线，通过TDS平台一键发起测试，测试结束后系统自动发送邮件将测试报告发送给相关测试和开发人员。

测试脚本项目和一般的开发项目有所不同，TDS中现有流水线模板不满足我们的需求，所以本流水线采用自定义jenkins的方式构建测试执行流水线。

Python是一种脚本语言，不需要编译直接可以运行。为了便于查看代码，便于出现问题后调试，我们通过自定义jenkinsfile，从gitlab直接下载代码上传到测试服务器，然后执行测试脚本的入口程序。测试脚本的执行时长因实际情况而不同，如果执行时间较短，可以让流水线执行起脚本后等待测试结束脚本退出，根据脚本的退出状态判断脚本执行情况，在流水线上显示脚本执行结果。如果测试脚本执行的时间较长，也可以让流水线执行起测试脚本后就结束本次流水线操作。

问题及解决

在开发测试脚本过程中，首先遇到的问题是，前端代码编写时很多元素没有定义id或者name，只能通过xpath进行定位。这样的话前端只要一点轻微的调整，xpath就可能发生改变，导致脚本稳定性很差，给脚本维护带来难度。我们通过和前端开发人员沟通约定，给大部分前端元素都设置id或者name，这样测试脚本里就可以通过id或name来定位元素，脚本的稳定性有了很大提升。对于必须用xpath定位的元素，通过学习xpath语法，优化xpath写法，从而在一定程度上提高了脚本可读性和稳定性。另外，对测试脚本进行适当改造，基于PageObject（页面对象）编写脚本，使测试脚本更易于维护。通过上述手段，测试脚本不断优化，脚本稳定性有了很大提高。

展望

虽然我们的UI自动化测试框架已经在团队内落地使用，解决了实际问题，但是不得不承认它使用起来不够简单，对使用者有一定的门槛。接下来我们会对该测试框架进行以下优化：

• 对测试配置部分进行优化，增强通用性。
• 将元素和操作进一步封装，从而让测试用例编写更简单。
• 将测试框架从单机模式改造成web服务，增加可视性，方便协作。
• 分级测试用例，制定不同级别的用例集，和被测系统的流水线结合，部署后执行测试。

UI自动化测试是针对界面功能进行操作和结果检查，不太适合对业务链条比较长的操作进行测试。下一步我们将业务链条比较长的测试点和复杂流程，用接口自动化测试覆盖这些场景，最终通过手动测试+主要菜单的UI自动化测试+复杂业务场景的接口自动化测试来实现功能测试的立体覆盖。

经验分享

本次自动化测试实践，我们有几个小经验想和大家分享：

1.对于小团队，初次进行自动化测试，建议充分利用优秀的开源项目，不追求重复造轮子，而是将好用的轮子组装成好用的战车，在最短的时间里追求尽量大的投入产出比，解决实际问题。

2.要选择合适的测试方式，否则可能投入很大的工作量但是解决不了实际问题。

3.从零开始实践，需要有一定经验的人进行测试设计，或者有人先行学习获得一定的自动化能力，指引方向，然后组织其他成员一起实践，效果往往更好。

4.要注意测试用例的有效性，明确用例的设计原则，注意断言的合理性，有效的用例才可能测试出问题。

本工作受到组内测试伙伴的极大支持，小伙伴们表现出了极大的学习热情和能力。做有价值的事情，一起学习成长，往往会有事半功倍的效果。也要感谢开发小伙伴们的支持和配合，代码更规范，测试才能更容易。

以上是泰康云测试团队自动化测试实践的一点经验，希望对人力投入有限，但是迭代频繁、前端界面功能复杂、项目有回归测试需求的团队有所参考。
感谢！

最后： 可以在公众号：伤心的辣条 ！ 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！喜欢软件测试的小伙伴们，可以加入我们的测试技术交流扣扣群：914172719（里面有各种软件测试资源和技术讨论）

---

好文推荐

转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！

面试经：一线城市搬砖！又面软件测试岗，5000就知足了…

面试官：工作三年，还来面初级测试？恐怕你的软件测试工程师的头衔要加双引号…

什么样的人适合从事软件测试工作？

那个准点下班的人，比我先升职了…

测试岗反复跳槽，跳着跳着就跳没了…