自动化测试——何为自动化测试，为何自动化测试

Posted 2022-11-24 不是Z君

概述

我们主要就接口功能自动化测试从两个方面做一些交流，一是何为自动化测试 ，二是为何自动化测试，同时包含关于下面三个问题自己的一些认识:

明确自动化测试开展原由
明确自动化测试开展方式
明确自动化测试开展评估
关于自动化基础的认知:

常见的错误认知

使用自动化完全替代手工测试。
使用自动化测试发现更多的新BUG。
应该形成怎样的认知

自动化测试的目的不单纯是为了减少或者替代手工测试，而是为了测试人员能够做更多更有意义的测试（也包含手工测试）。
自动化测试是用来验证以前能够正常工作的功能是否依旧可以正常工作。

为何自动化测试

不是为了自动化而自动化，而是为了实现一套解决方案来解决问题从而开展某种自动化 ，肯定是解决某些测试过程中的问题而引入自动化测试。

利与弊

既然选择自动化解决某些问题，首先要清楚自动化测试其本身的利弊。

利
1.关于成本

机器资源成本代替人力成本，一定程度解决了重复性的测试执行成本问题。
2.关于效率

提高测试执行效率，缩短测试周期，一定程度解决了测试周期随版本迭代次数的增加(功能点增加)而增长的问题。
3.关于测试覆盖

通过自动化测试工具的录制回放及数据驱动来测试功能，可以提高测试覆盖率，一定程度解决了回归测试中测试覆盖率低的问题。
4.关于发现问题

自动化测试具有较好的一致性和可重复性， 一定程度解决了手工反复执行过程中的一致性的问题。
5.关于流程

自动化测试工具作为一种角色引入到整个测试流程中，提高测试执行流畅性。

弊

1.关于人员

额外要求测试人员具备定测试开发能力，引入了对测试人员能力要求较高的问题。
2.关于成本

自动化测试开发成本因选择自动化框架(或工具)而异，但都具有较高的开发成本，引入了开发成本的问题。
3.关于维护

随着版本迭代和功能变更，引入了自动化代码的开发维护的问题。
4.关于发现问题

受其本身的局限性(大多应用在回归测试、稳定版本场景中)， 自动化测试发现问题较少。

我们在认识自动化优点的时候,是否思考过其弊端带来的影响,我们是否能够应对，如何应对?

工欲善其事必先利其器

通过上述，我们不难发现，自动化测试是一把双刃剑。 所以关于自动化是否开展，我们需要从以下几个方面进行考虑：

做与不做

IT行业甚至其它行业的产品都是能够做到自动化的，所以是否自动化不是能与不能的问题，而是是否存在合适的时间或阶段以及合适方式去做的问题，实施自动化测试之前需要对产品开发过程进行分析，通常需要同时满足以下条件：

软件需求变动不频繁(超过10%的变动是频繁变动，当然10%不是一个定值)
项目周期足够长
自动化测试用例可重复使用
通常适合于软件测试自动化开展的场景如下：

回归测试，重复单一的测试操作造成了不必要的浪费
上文中也提到肯定是解决某些测试过程中的问题而引入自动化测试，如果是为了自动化而自动化，无疑它将是失败的。

飞机与大炮

框架、工具的选择是我们确认开展自动化后首先面临的问题。之前网上有个梗，泡面煮着吃是没有灵魂的，当然这是一种调侃。自动化测试开展一定要结合被测系统的特点进行选择，不顾被测系统（系统框架）特性、场景而盲目选择自动化测试框架(或工具)， 它是没有灵魂的，自动化失败概率会相对高很多。

下面我们先简单的介绍一下自动化开展的几种自动化测试驱动框架。

首先我们需要明白自动化测试框架更倾向于一种设计思想 ，这种思想指导工具的使用或者自研开发，并且不是只能使用仅仅一种框架，结合被测系统本身特性一般是选择多种测试框架的组合，来满足测试和设计需求(开发、维护角度)。

录制回放测试框架

录制回放测试框架所采用的原理是通过录制应用程序产生的线性脚本进行回放从而达到自动化测试的目的。

优点：对测试人员测试开发能力要求最低，通过录制就可以得到所需脚本。
缺点：一般不具有逻辑判断的能力 ，可维护性差 ，效率低。
适应场景：不推荐，传统的UI自动化测试逐步弱化。关于U自动化，一定要清楚 被测系统是否满足开展自动化的条件，在被测系统变动频繁的项目中，开展UI自动化无疑是挖了一个很大的坑，其后期维护工作足以让大心疲惫，被迫放弃自动化测试。
测试库构架框架(The Test Library Architecture Framework )

测试库构架框架的核心思想可以概括为系统功能操作和业务逻辑的解耦。将所有的针对测试系统支持的功能操作封装在测试库中，测试脚本调用测试库的同时传递外部的测试数据，测试库的编写由自动化测试发工程编写(可以不懂业务)，负责控件的变更和维护， 测试脚本的编写可由对业务比较掌握的自动化测试开发工程编写，负责业务逻辑、测试数据的变更和维护。

优点：被测试系统无论是哪层发生变化(代码层或业务层等)，只需要相应的人员进行变更维护即可。
缺点：变更引起的维护工作同时附加在自动化测试开发工程师与业务测试人员身上，维护代码建级大。
适应场景：基于各种自动化开展方式(基于工具如Jemet或不基于工具的自研研发+持续集成)一般都会应用该框架。
数据驱动的自动化测试框架( The Data-Driven Testing Framework )

数据驱动的核心思想可以概括为数据(测试数据、配置数据)与代码解耦。该种框架的原理是采用了数据驱动脚本进行测试，数据驱动脚本是将数据输入存储在独立的数据文件中，脚本只存代码，运行时脚本的输入直接从文件中读取，如此相同的脚本(代码模版)可以运行于不同的测试用例中，实现了代码与数据的分离。

优点：对于业务人员由面向代码的开发转换为面向配置的设计(参数组合设计)， 降低了开发难度与开发成本，同时提高了测试用例的易扩展性，可以快速扩展相似测试，实现了自动化代码不随用例的增长而增
缺点：测试脚本的维护由自动化测试开发工程师负责，要求懂自动化编程和业务逻辑，初始测试脚本设计成本较大，具有一定局限性 (针对相同的测试内容并具有相同的测试逻辑).
适用场景：更适应于测试内容测试逻相重复度高，被测对象对测试用例易扩展性、可复用性要求较高的场景。
关键字或表驱动的自动化测试框架(The Keyword-Driven or Table-Driven Testing Framework )

关键字驱动是对数据驱动的逻相扩展，它的核心思想可以概括为数据代码流程(逻辑)解耦，同时完成了代码与测试描述(针对被测对象的测试描述)的映射。该框架的原理是基于数据驱动的基础上，完成了对被测对象的拆分、抽象、 封装使之映射成个个“关键词” (测试描述)，编写测试用例时，仅需要对关键词进行组合 ，即可完成不同场景的测试用例开发。

优点:对于业务手工测试人员，由面向代码或配置的开发转化为面向自然语言(测试描述)的开发，最大程度的降低了开发难度与维护成本，同时提高了测试用例的易扩展性、易组织性，实现了自动化代码不随用例的增长而增多。

缺点:对测试人员的测试开发能力以及业务了解程度要求很高。

适用场景:被测对象包含复杂业务流程(逻辑)，当然复杂的能做简单的更ok。

何为自动化测试

关于自动化的认识

自动化测试是把以人为驱动的测试行为转化为机器执行代码的一种过程。

通常，在设计测试用例并完成评审之后 ，由测试人 员根据测试用例一步步执行侧试，得到实际结果与期盟结果的比较。

在此过程中，为了降低人力、时间或硬件资源的投入，提高测试执行效率，便引入了自动化测试的概念。

自动化开展的流程

自动化测试不仅仅是工具使用、代码开发，这一切都是围绕保障产品质量服务，自动化测试和手工一样其核心是测试分析与设计，自动化测试本身开展的好于环取决与是否选择合适的方式并且进行了充分的测试分析和覆盖。

测试分析与测试用例设计

关于如何进行测试分析、测试设计因为介绍篇幅过多，后续会开专项交流，此处不做说明，记得关注哦。

自动化测试预研

两个明确：

明确被测系统背景 (被测系统处于的开发或测试阶段、 需求变动情况、项目周期等)
明确自动化测试目标(具体哪些模块、自动化转换率、效率提升等)
测试框架选择

仅仅从实现上讲，很多种自动化测试框架(或工具)都可以开展自动化，或者说任意一种也不是很勉强， 所以在自动化框架(或工具)的选择上，不是人为核心的(我会什么， 或有哪种框架比较好掌握)，而是以被测对象为本来选择自动化框架(或工具)。

两个场景：

场景一:多维度的查询功能，类似于某宝商品的筛选查询。
场景二:较为复杂的业务流程，类似于某逐级审批流程系统。
思考:关于这两种场景，我们如何选择自动化测试框架(或工具) ?

场景一特点:类似于某宝WEB端， 不同关键词(衣服、足球)的多维度(品牌、发货地)组合查询，查询逻辑单一、复用性强。推荐使用:测试库架构框架+数据驱动框架。
场景二特点:类似于审批申请流程，包含复杂的业务逻辑和多用户角色。推荐使用:测试库构架框架+数据驱动框架(配置解耦）+关键词驱动框架
测试用例开发

两个注意

规范性和契合性：开发规范性以及开发过程一定要与其自动化测试框架思想相契合，比加选择测试库构架框架，那么在用倒编写的时候，发现还有需要进行封装的功能操作时，需要在测试库中开发，在用例中调用，而不是随手在用例中进行开发。
开发成本和维护成本：开发设计一定要考虑开发成本和维护成本问题，开发成本决定效率，维护成本决定这个自动化能否长明有效的运行下去，同时注意关于成本问题的解决思路是在对被则对象进行有效覆盖的前提下，通过框架设计和优化方案来降低成本，而不是靠少做一些做的粗一些来降低成本。
比如选择测试库构架框架，实现上述场景一查询业务的自动化时:

我们如果"关键词（鞋子) +品牌(耐克)“写一条自动化用例，“关键词（鞋子) +品牌(耐克)+发货地（南京）”又写了一条自动化用例，这种方式是否有需要优化的地方?

结合业务特点，我们在测试库构架框架的基础上再采用数据驱动框架，将其单的查询逻辑与测试数据分离，这样我们再开发其他用例时，只需要在数据文件中增加测试数据(输入、对应期望)，避免了重复开发带来的开发、维护成本。

测试用例执行

一般使用Jenkins进行持续集成。

测试用例结果反馈

两个要求:

结果信息指向清晰：具体是由于什么原因导致的失败
结果信息表述清晰：具体是失败的原因
测试用例维护

一个警場

警惕当用例维护成本随着用例数量的增多而增大时， 需要及时优化用例设计框架， 避免用例维护成本过大，导致用例废弃或放弃维护。
思考:如何评价我们自动化测试开展的如何？
下面这几个维度，大家看看该如何选择呢？（多项选择题哦）

关于自动化测试动机

我们在什么背展下提出的自动化测试需求?

项目周期较长，老功能趋于稳定，项目人力紧张、需要做更多的事情，需要降低对重复测试的投入?
其它团队在做自动化，我们也跟风搞一决。
关于自动化测试目的

我们以什么目的来开展自动化测试?希望达到的目的是什么，这是在自动化预研阶段需要明确。

提高测试效率，降低重复投入，能够抽出时间做更多的事情。
做自动化的目的就是做完自动化。
关于自动化本身

选择的自动化测试框架(或工具)是否与被测系统相契合，是否评估开发成本、维护成本，以及提供的解决方案？

结合业务特性场景，选择适当的时机以及合适的方式开展自动化
在进行自动化开发之前，进行充分测试分析、设计，保证适当的测试覆盖(测试点测试结果)。
其他团队在使用XX工具，我们也可以学着用一下，把我们团队的自动化做起来。
造一两条测试数据覆盖一个接口就行 ，期望结果挑着验证一下。
关于自动化测试效果

是否达到了我们既定目标。
是否做了更多有价值的事情，如利用自动化节省的时间我们对核心业务做了更多深层分析，挖掘出些问题等等。动起来，不需要人力去做子。
这家伙维护起来真差，维护不子，算了手动测试吧。

共勉:【可能给予你助力的教程】

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。

关注我的微信公众号【程序媛木子】免费获取~