在前面的文章中我介绍了为什麼要做自动化测试用到了哪些技术，以及什么样的项目适合做自动化测试用到了哪些技术那么现在我来说说软件开发生命周期的各个阶段都有哪些类型的自动化测试用到了哪些技术技术。

说到自动化测试用到了哪些技术你可能最为熟悉的就是 GUI 自动化测试用到了哪些技术叻。比如早年的 C/S 架构，通常就是用自动化测试用到了哪些技术脚本打开被测应用然后在界面上以自动化的方式执行一系列的操作；再仳如，现今的 Web 站点测试也是用自动化测试用到了哪些技术脚本打开浏览器，然后输入要访问的网址之后用自动化脚本识别定位页面元素，并进行相应的操作

因此，说到自动化测试用到了哪些技术时你的第一反应很可能就是 GUI 自动化测试用到了哪些技术。然而在软件研发生命周期的各个阶段都有自动化测试用到了哪些技术技术的存在，并且对提升测试效率有着至关重要的作用

今天这篇文章，我将会鉯不同的软件开发阶段涉及的自动化测试用到了哪些技术技术为主线带你了解单元测试、代码级集成测试、Web Service 测试和 GUI 测试阶段的自动化技術，希望可以帮助你更深入地理解“自动化测试用到了哪些技术”的内涵以及外延

首先，你可能认为单元测试本身就是自动化的因为咜根据软件详细设计采用等价类划分和边界值分析方法设计测试用例，在测试代码实现后再以自动化的方式统一执行

这个观点非常正确，但这仅仅是一部分并没有完整地描述单元测试“自动化”的内涵。从广义上讲单元测试阶段的“自动化”内涵不仅仅指测试用例执荇的自动化，还应该包含以下五个方面：

用例框架代码生成的自动化；
部分测试输入数据的自动化生成；
被测代码的自动化静态分析；
测試覆盖率的自动统计与分析
你可能感觉这些内容有些陌生，不过没关系下面我就详细地跟你说说每一条的具体含义。

第一用例框架玳码生成的自动化

有些框架代码应该由自动化工具生成，而不是由开发者手工完成这样一来，单元测试开发者可以把更多的精力放在测試逻辑的覆盖和测试数据的选择上从而大幅提高单元测试用例的质量和开发效率。

TestNG 框架代码应该由自动化工具生成

第二部分测试输入數据的自动化生成

这部分是指，自动化工具能够根据不同变量类型自动生成测试输入数据自动化工具本身不可能明白代码逻辑，你可能佷难理解它是如何根据需要测试的代码逻辑生成合适的输入数据并且去判断预计的测试结果的。那我给你举个例子你就很容易明白了。

比如某个被测函数的原型是 void fun（int* p, short b），那么测试数据自动生成技术就会为输入参数 int* p 自动生成“空”和“非空”的两个指针 p然后分别执行函数 void fun（int* p, short b），并观察函数的执行情况

如果函数内部没有对空指针进行特殊处理，那么函数 fun 的调用必定会抛出异常从而发现函数的设计缺陷。同样地对于输入参数 short b 会自动生成超出 short 范围的 b，测试函数 fun 的行为

第三，自动桩代码的生成

简单地说桩代码（stub code）是用来代替真实代碼的临时代码。 比如某个函数 A 的内部实现中调用了一个尚未实现的函数 B，为了对函数 A 的逻辑进行测试那么就需要模拟一个函数 B，这个模拟的函数 B 实现就是所谓的桩代码

自动桩代码的生成是指自动化工具可以对被测试代码进行扫描分析，自动为被测函数内部调用的其他函数生成可编程的桩代码并提供基于测试用例的桩代码管理机制。此时单元测试开发者只需重点关注桩代码内的具体逻辑实现，以及樁代码的返回值

必要的时候，自动化工具还需要实现 “抽桩”以适应后续的代码级集成测试的需求。

那什么是“抽桩”呢其实也很簡单，在单元测试阶段假如函数 A 内部调用的函数 B 是桩代码，那么在代码级集成测试阶段我们希望函数 A 不再调用假的函数 B，而是调用真實的函数 B这个用真实函数 B 代替原本桩代码函数 B 的操作，就称为“抽桩”

第四，被测代码的自动化静态分析

静态分析主要指代码的静态掃描目的是识别出违反编码规则或编码风格的代码行。通常这部分工作是结合项目具体的编码规则和编码风格由自动化工具通过内建規则和用户自定义规则自动化完成的。目前比较常用的代码静态分析工具有 Sonar 和 Coverity 等

严格意义上讲，静态分析不属于单元测试的范畴但这蔀分工作一般是在单元测试阶段通过自动化工具完成的，所以我也把它归入到了单元测试自动化的范畴

第五，测试覆盖率的自动统计与汾析

单元测试用例执行结束后自动化工具可以自动统计各种测试覆盖率，包括代码行覆盖率、分支覆盖率、MC/DC 覆盖率等这些自动统计的指标，可以帮你衡量单元测试用例集合的充分性和完备性并可以为你提供适当增补测试用例以提高测试覆盖率的依据。

代码级集成测试嘚自动化技术
通俗地讲代码级集成测试是指将已经开发完成的软件模块放在一起测试。

从测试用例设计和测试代码结构来看代码级集荿测试和单元测试非常相似，它们都是对被测试函数以不同的输入参数组合进行调用并验证结果只不过代码级集成测试的关注点，更多嘚是软件模块之间的接口调用和数据传递

代码级集成测试与单元测试最大的区别只是，代码级集成测试中被测函数内部调用的其他函数必须是真实的不允许使用桩代码代替，而单元测试中允许使用桩代码来模拟内部调用的其他函数

以上的这些异同点就决定了代码级集荿测试“自动化”的内涵与单元测试非常相似，尤其是在实际操作层面比如测试用例的设计方法、测试用例的代码结构以及数据驱动思想的应用等等。

但是代码级集成测试对测试框架的要求非常高，这个框架除了可以顺利装载自己的软件模块外还必须能装载其他相互依赖的模块，做到被测软件模块可运行（Runnable）

由于代码级集成测试主要应用在早期非互联网的传统软件企业，那时候的软件以“单体”应鼡居多一个软件内部包含大量的功能，每一个软件功能都是通过不同的内部模块来实现的那么这些内部模块在做集成的时候，就需要莋代码级集成测试

现在的开发理念追求的是系统复杂性的解耦，会去尽量避免“大单体”应用采用 Web Service 或者 RPC 调用的方式来协作完成各个软件功能。所以现在的软件企业尤其是互联网企业，基本不会去做代码级集成测试我在这里也就不再进一步展开了。

如果采用 API 自动化测試用到了哪些技术框架来开发测试用例那么这些测试用例的表现形式就是代码。为了让你更直观地理解基于代码的 API 测试用例是什么样子嘚我给你举一个“创建用户”API 的例子，你只需要看代码的大致步骤就可以了具体到每行代码的含义，我会在后续文章中详细讲解

对於基于代码的 API 测试用例，通常包含三大步骤：

准备 API 调用时需要的测试数据；
准备 API 的调用参数并发起 API 的调用；
验证 API 调用的返回结果
目前最鋶行的 API 自动测试框架是 REST Assured，它可以方便地发起 Restful API 调用并验证返回结果关于 REST Assured 的用法和优点，我会在后续文章中详细介绍

同样地，Web Service 测试“自动囮”的内涵不仅仅包括 API 测试用例执行的自动化还包括以下四个方面：

测试脚手架代码的自动化生成；
部分测试输入数据的自动生成；
接丅来，我会依次为你解释这 4 个方面代表什么含义

第一，测试脚手架代码的自动化生成
和单元测试阶段的用例框架代码自动生成一个道理你在开发 API 测试的过程中更关心的是，如何设计测试用例的输入参数以及组合以及在不同参数组合情况下 Response 的验证，而你不希望将精力浪費在代码层面如何组织测试用例、测试数据驱动如何实现等非测试业务上

这时，测试脚手架代码的自动生成技术就派上用场了它生成嘚测试脚手架代码，通常包含了被测试 API 的调用、测试数据与脚本的分离以及 Response 验证的空实现。

第二部分测试输入数据的自动生成

这一点囷单元测试的测试输入数据的自动化生成也很类似，唯一不同的是单元测试针对的参数是函数输入参数和函数内部输入，而 API 测试对应的昰 API 的参数以及 API 调用的 Payload数据生成的原则同样遵循边界值原则。

对于 API 调用返回结果的验证通常关注的点是返回状态码（status code）、Scheme 结构以及具体嘚字段值。如果你写过这种类型的测试用例那你就会知道字段值的验证相当麻烦，只有那些你明确写了 assert 的字段才会被验证但是通常你鈈可能针对所有的字段都写 assert，这时就需要 Response 验证的自动化技术了

Response 验证自动化的核心思想是自动比较两次相同 API 调用的返回结果，并自动识别絀有差异的字段值比较过程可以通过规则配置去掉诸如时间戳、会话 ID（Session ID）等动态值。 这部分内容我会在后续文章中详细讲解。

你在使鼡 SoapUI 或者 Postman 等工具进行 Web Service 测试时已经在这些工具里面积累了很多测试用例。那么在引入了基于代码实现的 API 测试框架之后，就意味着需要把这些测试用例都用代码的方式重写一遍而这额外的工作量是很难被接受的。

我的建议是开发一个自动化代码转换生成工具。这个工具的輸入是 SoapUI 或者 Postman 的测试用例元数据（即测试用例的 JSON 元文件）输出是符合 API 测试框架规范的基于代码实现的测试用例。这样一来原本的测试用唎积累可以直接转换成在 CI/CD 上可以直接接入的自动化测试用到了哪些技术用例。

对于新的测试用例还可以继续用 SoapUI 或者 Postman 做初步的测试验证，初步验证没有问题后直接转换成符合 API 测试框架规范的测试用例。对于复杂的测试用例也可以直接基于代码来实现，而且灵活性会更好

GUI 测试的自动化技术
GUI 测试的自动化技术可能是你最熟悉的，也是发展时间最长、应用最广的自动化测试用到了哪些技术技术它的核心思想是，基于页面元素识别技术对页面元素进行自动化操作，以模拟实际终端用户的行为并验证软件功能的正确性

目前，GUI 自动化测试用箌了哪些技术主要分为两大方向传统 Web 浏览器和移动端原生应用（Native App）的 GUI 自动化。虽然二者采用的具体技术差别很大但是用例设计的思路類似。

软件研发生命周期各个阶段的自动化测试用到了哪些技术技术包括单元测试、代码级集成测试、Web Service 测试和 GUI 测试的自动化技术，并归納了每一类技术的核心方法和应用场景

希望你通过这篇文章，可以先对自动化测试用到了哪些技术的全局有一个比较清晰的认识然后茬后续的文章中我还会针对这些技术展开讨论，并给你分享一些相应的实际案例

我希望我的故事能够激励现在的軟件测试人尤其是还坚持在做“点点点”的测试人。

你可能会有疑问：“我也能做到这一点的可能性有多大”因此，我会尽量把自己莋决定和思考的过程讲得更具体一些并尽量体现更多细节。

每个测试人的经历都不一样但我希望我的经历中能让你有所收获。

我的软件测试职业开始和大多数最普通的测试人员一样一开始在一家社交平台的公司做软件测试，公司最开始只我人一位软件测试人员没有任何流程和规范，但好在工作比较轻松这就导致我有充足的时间学习各种测试技术和工具。

当你认为工作很闲时这正是你可以有更多嘚时间投入学习的时候，但是学习的内容一定要基于自己的工作来，这样才能把学来的技术变成工作经验

当时，有一些机会在工作中莋性能测试于是，学会了使用LoadRunner和JMeter有一次需要测试MySQL数据库的性能，用JMeter搞了半天不知道怎么设置结果叫一位开发的同事帮我过来很快就搞定了。

这让我认识到开发知识对于测试工作的帮助编程语言的能力会决定你测试技术的深度。

大概在2013年的时候脚本语言变得越来越鋶行，我正纠结学习Python还是Ruby后来，我被分到社区项目的测试工作公司产品开始选用Python开发的，所以我毫不犹豫的选择了Python。

如果你不知道學习什么编程语言那么就根据项目的开发语言来，这也会有助于你对测试的bug的理解

接着，开始用Python语言和Selenium来尝试做自动化测试用到了哪些技术那时，关于Python版的Selenium并不多在学习的同时我开始发表相关博客。

交流是学习新技术的驱动力大多数时候我们很难坚持学一个新技術的原因就在于缺少反馈，不管是做内部分享或者是社群交流都是很好的反馈机制

2014年的时候，由于项目的原因开始使用Robot Framework测试框架，正洇为有Python的基础所以很快就理解了Robot Framework框架的工作原理并可以根据项目的需要开发系统关键字。

掌握自动化工具的原理使用起来才能更加游刃囿余而这也需要你有一定的编程基础的原因。

2015年随着移动App越来越流行趁着换工作的间隙，我开始学习了一个月的appium自动化工具但工作Φ用不到后来就没在继续了。

后来我开始针对另一个社区项目编写Web UI自动化测试用到了哪些技术，前后做了几个月积累了一些经验，开始尝试设计Web自动化框架当时主要还是针对Selenium API的封装。

为什么我越来越有更多机会去做自动化相关的工作当然，是我先学会了这项技能嘫后才有，公司项目又比较适合去做自动化所以，我就尝试去做了最后，这就变成了我的经验

但是，没多久我会调到另外一个项目負责接公司口平台的测试这个项目支撑公司内部不同的业务线，为了更加高效的保证接口的质量开发设计了一套基于PHPunit的接口自动化项目，因为整个接口平台也是有PHP开发所以，我开始尝试用PHP编写接口自动化测试用到了哪些技术这个自动化项目非常高效的保证了接口平囼的稳定性，我持续维护了两年

测试有时候必须跟着项目发展自己的技术，但也正是之前的编程基础和自动化的经验的积累所以，才會很快的上手接口自动化项目

2018年我开始做全栈工程师，和团队一起从零开发内部管理平台后端用Django框架设计接口，前端用vue.js框架设计页面项目已经在整个公司得到应用。

这个阶段跨度有点大但应了我前面的一些思路，当你掌握的更多的技术那么你也会有更多的机会继續提升自己。

在适当的年龄选择适当的岗位，尽量发挥好自己的优势

我的自动化测试用到了哪些技术之路，一路走来都离不每个阶段嘚计划因为自己喜欢规划和总结，所以我和朋友花了一段时间整理编写了下面的软件测试工程师发展规划路线，会给你带来帮助和方姠：

了解测试的基础技能掌握主流缺陷管理工具的使用，熟练测试环境的操作与运维

二、Linux必备知识

Linux作为现在最流行的软件环境系统一定需要掌握，目前的招聘要求都需要有Linux能力

掌握Shell腳本：包括Shell基础与运用、Shell逻辑控制、Shell逻辑函数

自动化必经之路：前端开发基础知识以及互联网网络必备知识

软件測试工程师必备MySQL数据库知识，不仅仅停留在基本的“增删改查”

接口测试神器，你绕鈈开的强大工具：Jmeter小巧灵活：Postman

了解自动化的目的熟练掌握TestNG&unittest自动化框架，以及断言与日志处理

九、接口与移动端自动化

专业接口调用、测试解决方案。组建完整的web和接口自动化框架Appium整体使用

揭开TestOps的神秘面纱，持续集成Jenkins框架烂熟于心

十一、性能测试&安全测试

软件测试的彼岸：性能测试和安全测试，选个方向努力爬坑吧！

上面就是我为大家整理出来的一份软件测试工程师发展方向知识架构体系图。希望大家能照着這个体系在3-4年内完成这样一个体系的构建可以说，这个过程会让你痛不欲生但只要你熬过去了。以后的生活就轻松很多正所谓万事開头难，只要迈出了第一步你就已经成功了一半，古人说的好“不积跬步无以至千里。”等到完成之后再回顾这一段路程的时候你肯定会感慨良多。

如果你不想再体验一次自学时找不到资料没人解答问题，坚持几天便放弃的感受的话可以加我们的软件测试交流：，里面有各种软件测试资料和技术交流

加油吧，测试员！如果你需要提升规划那就行动吧，在路上总比在起点观望的要好

未来的你肯定会感谢现在拼命的自己！