自动化横行的今天,手工测试员如何杀出一条血路?

简介: 该文讨论了自动化测试在软件行业中的地位和作用,指出自动化测试虽能快速测试和重复测试,但也存在脚本复杂、维护成本高、不适用于频繁变动的系统等问题。文章强调,手工测试并不会消亡,不是所有用例都需要自动化,自动化也不意味着无敌。选择稳定的功能和接口用例进行自动化是明智之举,而测试设计能力仍然是测试人员的核心竞争力。面对自动化趋势,测试人员应提高学习力,保持身体健康,并拓宽技术视野。

自动化测试是每个软件公司反复提及的,放眼望去,测试岗位的招聘要求里十有八九都会有一条“掌握自动化测试技巧”,甚至有的公司把用例自动化率(实现自动化的用例数/总用例数*100%)当作考核测试人员工作质量的指标之一。

那么,对此,想必大多测试人员会发出灵魂一问:难道手工测试就必须消亡了吗?自动化用例真的那么重要吗?是不是所有用例都需要实现自动化呢?自动化测试是不是就是所向披靡,无敌的呢?

在回答这几个问题之前,我们先来简单了解下自动化测试的特点。谈及自动化测试,就不得不把手工测试拉出来一较高下了,它们各自的定义就毋庸赘言了。

01 自动化测试的特点…

相较手工测试,自动化测试最大的优势就在于:

能够快速测试(快速检测代码变更引入的错误);

可以重复测试(反复执行成本低)。

但是,自动化测试也有自己的缺点:

如果软件系统体量比较大,那么自动化测试脚本也会比较复杂。自动化测试脚本的复杂度与系统的复杂程度是成正相关的;

如果软件系统迭代快、周期短、变动多,那么脚本维护将需要较大成本;

随着软件系统的不断迭代,功能的不断增加或细节的变更,会出现大量冗余的自动化测试脚本,这类冗余的脚本会直接影响测试脚本执行的效率;

自动化测试脚本的质量直接影响测试执行成功率(执行成功通过的次数/总的执行次数*100%)。只要是代码都会有故障,测试代码也不例外。低质量的自动化测试脚本有可能导致测试执行时的不稳定性(例如:反复失败);

对于测试人员而言,自动化测试,脚本准备时间(如自动化测试工具选取、脚本编写等)大于测试设计时间;

对于迭代较快的产品,需要测试人员快速地完成测试,在此种情况下,留给测试人员实现用例自动化的时间不会很多,自动化测试在新功能周期内往往很难快速实现;

对于业务量大、业务复杂的系统(如经济类系统,银行等),用例自动化率难以保证。且如前端GUI自动化测试,100%用例自动化率本身就是一个几乎难以实现的愿景。

说了那么多,到底是想证明个什么事儿呢?其实,上面的阐述无非是想问答几个问题:

手工测试会消亡吗?

个人觉得,答案肯定是不会。为什么呢?自动化测试有其优点,可以帮助测试人员快速完成回归测试。但其缺点也依然存在:测试代码冗余、测试代码维护成本大、部分产品的复杂功能难以自动化等等。

是不是所有自动化用例都需要实现自动化呢?

答案当然是否定的。理想很丰满,现实很骨感。且不说产品本身特点是否能满足完全自动化测试,从自动化成本(维护成本,时间成本,人力成本等)而言完全自动化就是值得思考的问题。再者,对于前端GUI自动化测试而言,完全自动化本身就很难。

自动化测试是不是所向披靡、无敌的?

答案当然也是否定的。毕竟自动化测试的根本目的主要在于快速地回归测试,在回归测试的过程中对于环境的需求、场景的设置都是具有限定性的,且自动化测试代码也会存在故障。如果切换场景进行自动化测试,不见得能百分百通过。

那么,再进一步想想,如果自动化测试很重要,但又不是百分百完美的,如果想要借助自动化的便利提升测试效率,那么应该针对怎样的用例实现自动化呢?自动化用例应该用在什么样的测试活动中呢?

02 选择需要实现自动化的用例…

其实在上述章节已经揭晓了如何选择需要实现自动化用例的部分原则。

选择执行结果稳定的用例实现自动化

试想如果一个用例执行结果不够问题,那么将手工测试步骤自动化有什么意义呢?这个时候需要的是去重新审视测试步骤是否准确或者代码是否有隐藏问题吧?!

选择功能稳定的用例实现自动化

试想如果一个模块或者一个功能频繁变更,那么用例实现自动化有什么意义呢?如果将此类用例实现自动化,反而会加重测试人员对自动化脚本的维护成本。

首先选择接口用例自动化

那是因为接口自动化学习成本低,几乎是每个测试人员接触自动化测试的第一步。而且接口是每个模块衔接之处,保障系统运行的重中之重。

如果要求前端GUI自动化

要慎重

前端GUI本身就是一个属于频繁变动的部分,如果实现自动化,对自动化脚本的维护就是一个不得不思考的问题。

也许你会说,我用录屏啊。录屏虽然学习成本低、操作简单,但是对于测试步骤的断言、测试结果的判定大多还需人工干预。

03 如何在自动化兴起下发展手工测试…

百分百自动化测试是每个测试人员的追求,每个公司的终极梦想,但这本身就意味着实现的困难和不可能。

自动化测试很重要,但手工测试仍然不可或缺。

测试人员担心自己会被各种不断进步的自动化测试工具替代的时候,可以想想如何在包围圈中拼杀出一条血路:我想,测试设计应该是一条可选之路。

好的测试设计能够节省测试成本(如测试资源的投入)、提高测试效率、提升测试结果稳定性。同样,优秀的测试设计能够指引测试人员挖掘一些深层故障,提高产品质量。

常有人说:测试是一门简单的工作,测试岗位可以被取消,不需要专职测试人员。但是如果不需要专职测试人员,让开发人员兼职测试工作,岂不是开发人员既当选手又当裁判?如何能够公正地评判。

再试想:如果开发人员能够知道自己代码中的故障,那为什么不在编写代码的时候就避免了呢?

04 测试员如何杀出一条血路…

说实话,我没什么远大的理想,无非就是想在测试这条道路上做大做强,当然为了我稳定的工作,我发自内心也确实想做点什么,总结下来无非就是以下几点:

1、提高核心竞争力

当然,无论你选择自动化还是手工作为自己的核心竞争力,学习是一定不能落下的,学习力强的软件测试员敢大胆地体验尝试新技术,所以他们的技术栈始终在保持不断地更新。

对于软件测试员而言,看文档其实是最快的学习方法,对于自己工作中常用到的技术,抽时间把官方文档都读一遍,其实没有你想象中的那么多,但你一定会有意想不到的收获,所有的核心竞争的前提都是需要不断学习来造就的,拥抱技术升级,才能使你一直不会被市场淘汰。

2、锻炼一个强健的体魄。

做了程序员之后我就很少运动了,新的计划就是一周至少要去健身房2-3次,不求练的跟泰森一样壮,只求能有一个强健的体魄,程序员猝死的新闻比比皆是,在职场杀出血路的前提条件当然是身体健康。锻炼身体是很必要的,为了预防猝死嘛,嘻嘻,开个玩笑。

3、学习更多的技术。 

我的学习效率实在是太低了,说到底就是因为懒,这也是我觉得自己最该改变的一点。目前计划是继续多学多看多实践。

相关文章
|
13天前
|
存储 设计模式 测试技术
怎么基于Pytest+Requests+Allure实现接口自动化测试?
该文介绍了一个基于Python的自动化测试框架,主要由pytest、requests和allure构成,采用关键字驱动模式。项目结构分为六层:工具层(api_keyword)封装了如get、post的请求;参数层(params)存储公共参数;用例层(case)包含测试用例;数据驱动层(data_driver)处理数据;数据层(data)提供数据;逻辑层(logic)实现用例逻辑。代码示例展示了如何使用allure装饰器增强测试报告,以及如何使用yaml文件进行数据驱动。
|
5天前
|
Java 测试技术 Python
《手把手教你》系列基础篇(八十)-java+ selenium自动化测试-框架设计基础-TestNG依赖测试-番外篇(详解教程)
【6月更文挑战第21天】本文介绍了TestNG中测试方法的依赖执行顺序。作者通过一个实际的自动化测试场景展示了如何设计测试用例:依次打开百度、搜索“selenium”、再搜索“selenium+java”。代码示例中,`@Test`注解的`dependsOnMethods`属性用于指定方法间的依赖,确保执行顺序。如果不设置依赖,TestNG会按方法名首字母排序执行。通过运行代码,验证了依赖关系的正确性。
26 4
|
6天前
|
Java 测试技术 Python
《手把手教你》系列基础篇(七十九)-java+ selenium自动化测试-框架设计基础-TestNG依赖测试-下篇(详解教程)
【6月更文挑战第20天】TestNG是一个Java测试框架,提供两种测试方法依赖机制:强依赖(所有前置方法成功后才运行)和弱依赖(即使前置方法失败,后置方法仍运行)。文中通过代码示例展示了这两种依赖如何实现,并解释了当依赖方法失败时,如何影响后续方法的执行。文章还包含了TestNG Suite的运行结果截图来辅助说明。
28 8
|
1天前
|
XML Java 测试技术
《手把手教你》系列基础篇(八十二)-java+ selenium自动化测试-框架设计基础-TestNG测试报告-上篇(详解教程)
【6月更文挑战第23天】TestNG 是一个用于自动化测试的 Java 框架,它自动生成测试报告,包括 HTML 和 XML 格式。报告可在 `test-output` 文件夹中找到。要创建测试用例,可创建一个实现了 `@Test` 注解的方法。通过 `testng.xml` 配置文件来组织和执行测试。默认报告包括测试结果、失败点和原因。用户还能实现 `ITestListener` 和 `IReporter` 接口来自定义报告和记录器。
18 2
|
7天前
|
Java 测试技术 Python
《手把手教你》系列基础篇(七十七)-java+ selenium自动化测试-框架设计基础-TestNG依赖测试- 上篇(详解教程)
【6月更文挑战第18天】TestNG是一个Java测试框架,它允许在测试方法间定义执行顺序和依赖关系。当不指定依赖时,TestNG默认按方法名首字母排序执行。`@Test`注解的`dependsOnMethods`属性用于指定方法依赖,如`test1`依赖`test4`,则实际执行顺序为`test4`、`test2`、`test3`、`test1`。如果依赖的方法失败,后续依赖的方法将被跳过。此外,`dependsOnGroups`属性通过组名指定依赖,方便管理多个相关测试方法。通过`groups`定义方法所属组,然后在其他方法中用`dependsOnGroups`引用这些组。
21 5
|
7天前
|
XML Web App开发 测试技术
《手把手教你》系列基础篇(七十八)-java+ selenium自动化测试-框架设计基础-TestNG依赖测试- 中篇(详解教程)
【6月更文挑战第19天】本文介绍了使用TestNG框架配置XML文件来管理测试用例的分组和依赖关系。
26 2
|
12天前
|
jenkins 测试技术 持续交付
30个接口自动化测试面试题,赶紧收藏
接口自动化测试是使用工具验证接口功能、性能和安全性的自动化过程。它能提升测试效率,减少人工工作量,及时发现问题。常见工具包括Postman、SoapUI和JMeter。测试涉及需求分析、测试计划、用例设计、脚本编写、执行、报告生成及问题跟踪。测试用例涵盖输入数据、预期结果等,脚本包含请求和响应细节。断言验证接口正确性,数据驱动测试使用多数据验证,性能测试检查响应时间等,安全测试关注认证和加密,Mock测试模拟数据,集成测试验证接口交互,回归测试确保修改未破坏原有功能,异常处理确保测试稳定性,并发和压力测试检查系统负载,持续集成通过工具如Jenkins保证软件质量。
|
15天前
|
IDE 测试技术 持续交付
Python作为一种简洁、易读且功能强大的编程语言,其自动化测试和单元测试框架的丰富性和易用性为开发者提供了极大的便利
【6月更文挑战第10天】本文探讨了Python自动化测试与单元测试框架在提升代码质量和效率中的作用。Selenium、Appium和pytest是常用的自动化测试框架,分别支持Web和移动应用的测试。unittest是Python的标准单元测试框架,提供断言方法和测试组织结构。通过制定测试计划、编写高质量测试用例、持续集成与测试、以及有效利用测试报告,开发者能提高代码质量和开发效率。
27 1
|
19天前
|
消息中间件 Kubernetes Kafka
AutoMQ 自动化持续测试平台技术内幕
Marathon 是一个针对流系统 AutoMQ 的自动化持续测试平台,旨在在模拟生产环境和各种故障场景中验证 SLA 的可靠性。设计原则包括易拓展、可观测和低成本。平台采用分布式架构,Controller 负责资源管理和任务编排,动态调整 Worker 数量和配置,而 Worker 是无状态的,用于生成负载和上报数据。系统基于 K8S,利用服务发现、事件总线和 Spot 实例降低成本并提高弹性。测试场景以代码形式描述,支持不同流量模型和断言,提供丰富的可观测性和告警功能。未来,Marathon 有望泛化为适用于各种分布式系统的测试平台。
22 0
AutoMQ 自动化持续测试平台技术内幕
|
22天前
|
Java 测试技术 Web App开发
《手把手教你》系列技巧篇(六十二)-java+ selenium自动化测试-RemoteWebDriver让你的代码与测试分离(远程测试)
【6月更文挑战第3天】本文介绍了在没有本地浏览器的情况下,如何使用RemoteWebDriver进行远程自动化测试。RemoteWebDriver分为客户端和服务端,客户端运行测试代码,服务端启动服务。服务端需要安装JDK、浏览器和对应的WebDriver,并启动selenium-server-standalone.jar。客户端通过URL连接到服务端,并指定预期的浏览器类型。这样,客户端的测试代码就能远程控制服务端的浏览器执行自动化测试。RemoteWebDriver的优点包括跨平台和浏览器测试、提高测试稳定性以及使测试环境和执行代码的机器分离。
30 3

热门文章

最新文章