如何避免移动测试自动化失败

栏目: 编程工具 · 发布时间: 5年前

内容简介:Nadya Denisenko 说,移动开发中的测试自动化应该由 Scrum 团队完成;不要建立单独的测试自动化团队。她建议遵守移动测试的测试金字塔,并从一开始就让测试人员参与进来。测试人员是面向质量的开发人员,他们可以指导和帮助其他开发人员交付高质量的软件;手工测试将在未来消失。移动开发是厂商锁定的。Denisenko 说,市场上有两大厂商决定操作系统、应用程序、开发和测试的走向。此外,大多数公司都在寻找能够在两个平台上开发自动化测试的测试自动化独角兽。Denisenko 说,这意味着手机领域的自动化工程

Nadya Denisenko 说,移动开发中的测试自动化应该由 Scrum 团队完成;不要建立单独的测试自动化团队。她建议遵守移动测试的测试金字塔,并从一开始就让测试人员参与进来。测试人员是面向质量的开发人员,他们可以指导和帮助其他开发人员交付高质量的软件;手工测试将在未来消失。

移动开发是厂商锁定的。Denisenko 说,市场上有两大厂商决定操作系统、应用程序、开发和测试的走向。此外,大多数公司都在寻找能够在两个平台上开发自动化测试的测试自动化独角兽。Denisenko 说,这意味着手机领域的自动化工程师至少应该了解 Kotlin、Swift、 Java 和 Objective-C,以及 iOS 和 Android 的工作原理,他们预期自动化工程师有能力手动测试这款应用,但事实并非如此。

Denisenko 表示,移动应用程序以开发速度快著称,在大多数情况下,QA 都是在产品上市很长一段时间后才开始参与。她说,在一个习惯了长时间没有测试人员的团队中建立测试流程会带来大量的挑战。她建议慢慢来:首先,与开发人员一起构建一个测试自动化框架,将引入 sprint 的特性自动化,并实现一个回归场景。

Denisenko 说,与 web 或后端项目相比,移动项目非常小;对于 Scrum 团队能够或者应该处理的任务来说,单独的自动化测试团队是没有意义的。

Denisenko 提到测试人员的角色是指导和帮助开发人员交付高质量的软件。她说:“我坚信测试人员是面向质量的开发人员,手工测试在未来将消失或改变。”

Denisenko 说,越来越多的公司希望开发人员可以负责开发可测试的代码和测试。她从一个人工测试人员成长为测试自动化工程师,相信测试人员的角色正在转变为软件开发测试或代码质量评估教练。

InfoQ 正在报道 2019 年的欧洲测试大会 ,有幸采访了 Nadya Denisenko ,与她谈论了在移动测试自动化中失败的方法以及如何避免失败。

InfoQ:你在演讲中说过,单独的自动化团队是在浪费钱。你能详细解释一下原因吗?

Nadya Denisenko:一个主要原因是测试的设计。在决定测试覆盖率时,我们中的大多数人使用 70% 的单元测试、20% 的集成测试和 10% 的 E2E 自动化测试的测试金字塔。在移动世界中,违反测试金字塔的做法很常见,结果要么是测试沙漏型,要么是测试冰淇淋甜筒型。在大多数情况下,拥有一个独立的自动化团队意味着这样一个团队的主要关注点是自动化 E2E 测试,因此根据测试设计来分配资源更有意义。

InfoQ:测试金字塔比沙漏型或者冰淇淋型更合适?

Denisenko:是的。测试金字塔可以更好地控制应用程序中发生的事情,并节省调试问题的时间。

InfoQ:为什么移动测试人员会违反测试金字塔?

Denisenko:根据具体情况,有以下几个原因:

银弹。管理人员和一些开发人员 (特别是后端开发人员) 认为,通过使用 E2E UI 测试,可以在所有真实环境中运行。此外,他们认为这些测试将涵盖 API 测试、后端和客户端集成测试的缺失,这是错误的。由于平台的限制,有太多东西无法在移动设备上测试。举一个简单的例子,比如深度链接外部应用程序推送通知。人们也容易忘记,在后端和应用程序 UI 之间有太多的层,所有这些层都可能出错,而且据我所知,没有哪个框架能够提供关于问题确切位置的详细信息:第三方、后端、网络、应用程序的网络实现、UI,所有你能说得出的都做不到。结果,项目最终只留下些不可维护的测试和令人失望的测试自动化。

时机。新的移动项目总是以 MVP 的身份开始,然后发展壮大。它总是在不考虑应用程序的可测试性的情况下开始,这意味着该应用程序在设计时没有考虑过单元和 E2E UI 测试之外的测试。当开发人员发现需要进行深入测试时,得进行成本高昂的变更,于是团队只能选择忽略。

专业知识。有时这只是一个专业知识的问题。集成测试是移动测试中的一个新浪潮,并不是每个开发人员都有足够的知识理解什么是集成测试,以及如何进行集成测试。有些人甚至没有学习的欲望。

InfoQ:在自动化移动测试方面,你学到了什么?

Denisenko:我学到了:

在加入一个没有自动化的项目时,千万不要试图玩赶进度的游戏。

在开发测试自动化框架时,尽可能使用供应商的测试框架。开源解决方案往往会在 OS 新版本发布六个月后才发布对最新 OS 版本的支持 (这意味着在此之前任何自动化测试都不能在最新的 OS 上工作),而且它们往往还会停止更新。

不要试图调整为其他项目开发的测试。最终陷于不断的测试集成,在整个 Sprint 中修复测试,而不是专注于开发和维护我自己的测试。

使用自己擅长的语言。开发人员很懒,他们永远不会仅仅为了测试目的而学习 Ruby 或 Python。

质量是一个共同的责任,每个团队成员都应该为它做出贡献。

InfoQ:苹果和谷歌提供了哪些测试指南,我们应该如何使用它们?

Denisenko:测试指南是:

谷歌建议进行不同层次的测试:单元测试、集成 (组件间的集成)、UI 测试、功能 UI 测试、E2E 测试。谷歌试图培养一代知道如何在不同级别上测试代码的开发人员,最好是使用测试自动化。他们已经编写了很多关于这方面的教程,Google 的测试社区非常活跃。

然而,苹果鼓励开发者开发单元测试和 E2E 测试。他们建议开发人员在实际用户使用应用程序时实现自动化,并在 E2E 测试中实现自动化。

在我看来,供应商不应该影响开发人员和测试人员,让他们决定哪种策略更好。通过增加规则和设置限制,它们实际上减少了创造出新的、更好的和创新的东西的可能性。

查看英文原文: How to Avoid Failing at Mobile Test Automation


以上所述就是小编给大家介绍的《如何避免移动测试自动化失败》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

产品经理必懂的技术那点事儿

产品经理必懂的技术那点事儿

唐韧 / 电子工业出版社 / 2017-1 / 59

《产品经理必懂的技术那点事儿》以非技术背景产品经理了解技术为主题,将技术知识以简单并且易于理解的方式讲述出来,帮助非技术背景产品经理了解技术、学习技术,旨在帮助产品经理高效地与技术人员进行沟通与合作。 《产品经理必懂的技术那点事儿》的主要内容围绕产品经理需要了解的互联网基础技术知识展开,涉及客户端、服务器端、数据库及一些数据处理知识。同时,还就产品经理需具备的一些软实力,例如沟通能力和解决问......一起来看看 《产品经理必懂的技术那点事儿》 这本书的介绍吧!

URL 编码/解码
URL 编码/解码

URL 编码/解码

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器