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

\u003cp\u003eNadya Denisenko说，移动开发中的测试自动化应该由Scrum团队完成；不要建立单独的测试自动化团队。她建议遵守移动测试的测试金字塔，并从一开始就让测试人员参与进来。测试人员是面向质量的开发人员，他们可以指导和帮助其他开发人员交付高质量的软件；手工测试将在未来消失。\u003c/p\u003e\n\u003cp\u003e移动开发是厂商锁定的。Denisenko说，市场上有两大厂商决定操作系统、应用程序、开发和测试的走向。此外，大多数公司都在寻找能够在两个平台上开发自动化测试的测试自动化独角兽。Denisenko说，这意味着手机领域的自动化工程师至少应该了解Kotlin、Swift、Java和Objective-C，以及iOS和Android的工作原理，他们预期自动化工程师有能力手动测试这款应用，但事实并非如此。\u003c/p\u003e\n\u003cp\u003eDenisenko表示，移动应用程序以开发速度快著称，在大多数情况下，QA都是在产品上市很长一段时间后才开始参与。她说，在一个习惯了长时间没有测试人员的团队中建立测试流程会带来大量的挑战。她建议慢慢来：首先，与开发人员一起构建一个测试自动化框架，将引入sprint的特性自动化，并实现一个回归场景。\u003c/p\u003e\n\u003cp\u003eDenisenko说，与web或后端项目相比，移动项目非常小；对于Scrum团队能够或者应该处理的任务来说，单独的自动化测试团队是没有意义的。\u003c/p\u003e\n\u003cp\u003eDenisenko提到测试人员的角色是指导和帮助开发人员交付高质量的软件。她说：“我坚信测试人员是面向质量的开发人员，手工测试在未来将消失或改变。”\u003c/p\u003e\n\u003cp\u003eDenisenko说，越来越多的公司希望开发人员可以负责开发可测试的代码和测试。她从一个人工测试人员成长为测试自动化工程师，相信测试人员的角色正在转变为软件开发测试或代码质量评估教练。\u003c/p\u003e\n\u003cp\u003eInfoQ正在报道\u003ca href=\"https://europeantestingconference.eu/\"\u003e2019年的欧洲测试大会\u003c/a\u003e，有幸采访了\u003ca href=\"https://www.linkedin.com/in/nadyadenisenko/\"\u003eNadya Denisenko\u003c/a\u003e，与她谈论了在移动测试自动化中失败的方法以及如何避免失败。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eInfoQ：你在演讲中说过，单独的自动化团队是在浪费钱。你能详细解释一下原因吗?\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eNadya Denisenko：\u003c/strong\u003e一个主要原因是测试的设计。在决定测试覆盖率时，我们中的大多数人使用70%的单元测试、20%的集成测试和10%的E2E自动化测试的测试金字塔。在移动世界中，违反测试金字塔的做法很常见，结果要么是测试沙漏型，要么是测试冰淇淋甜筒型。在大多数情况下，拥有一个独立的自动化团队意味着这样一个团队的主要关注点是自动化E2E测试，因此根据测试设计来分配资源更有意义。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eInfoQ：测试金字塔比沙漏型或者冰淇淋型更合适?\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eDenisenko\u003c/strong\u003e：是的。测试金字塔可以更好地控制应用程序中发生的事情，并节省调试问题的时间。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eInfoQ：为什么移动测试人员会违反测试金字塔?\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eDenisenko：\u003c/strong\u003e根据具体情况，有以下几个原因：\u003c/p\u003e\n\u003cp\u003e银弹。管理人员和一些开发人员(特别是后端开发人员)认为，通过使用E2E UI测试，可以在所有真实环境中运行。此外，他们认为这些测试将涵盖API测试、后端和客户端集成测试的缺失，这是错误的。由于平台的限制，有太多东西无法在移动设备上测试。举一个简单的例子，比如深度链接外部应用程序推送通知。人们也容易忘记，在后端和应用程序UI之间有太多的层，所有这些层都可能出错，而且据我所知，没有哪个框架能够提供关于问题确切位置的详细信息：第三方、后端、网络、应用程序的网络实现、UI，所有你能说得出的都做不到。结果，项目最终只留下些不可维护的测试和令人失望的测试自动化。\u003c/p\u003e\n\u003cp\u003e时机。新的移动项目总是以MVP的身份开始，然后发展壮大。它总是在不考虑应用程序的可测试性的情况下开始，这意味着该应用程序在设计时没有考虑过单元和E2E UI测试之外的测试。当开发人员发现需要进行深入测试时，得进行成本高昂的变更，于是团队只能选择忽略。\u003c/p\u003e\n\u003cp\u003e专业知识。有时这只是一个专业知识的问题。集成测试是移动测试中的一个新浪潮，并不是每个开发人员都有足够的知识理解什么是集成测试，以及如何进行集成测试。有些人甚至没有学习的欲望。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eInfoQ：在自动化移动测试方面，你学到了什么?\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eDenisenko：\u003c/strong\u003e我学到了：\u003c/p\u003e\n\u003cp\u003e在加入一个没有自动化的项目时，千万不要试图玩赶进度的游戏。\u003c/p\u003e\n\u003cp\u003e在开发测试自动化框架时，尽可能使用供应商的测试框架。开源解决方案往往会在OS新版本发布六个月后才发布对最新OS版本的支持(这意味着在此之前任何自动化测试都不能在最新的OS上工作)，而且它们往往还会停止更新。\u003c/p\u003e\n\u003cp\u003e不要试图调整为其他项目开发的测试。最终陷于不断的测试集成，在整个Sprint中修复测试，而不是专注于开发和维护我自己的测试。\u003c/p\u003e\n\u003cp\u003e使用自己擅长的语言。开发人员很懒，他们永远不会仅仅为了测试目的而学习Ruby或Python。\u003c/p\u003e\n\u003cp\u003e质量是一个共同的责任，每个团队成员都应该为它做出贡献。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eInfoQ：苹果和谷歌提供了哪些测试指南，我们应该如何使用它们\u003c/strong\u003e?\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eDenisenko：\u003c/strong\u003e测试指南是：\u003c/p\u003e\n\u003cp\u003e谷歌建议进行不同层次的测试：单元测试、集成(组件间的集成)、UI测试、功能UI测试、E2E测试。谷歌试图培养一代知道如何在不同级别上测试代码的开发人员，最好是使用测试自动化。他们已经编写了很多关于这方面的教程，Google的测试社区非常活跃。\u003c/p\u003e\n\u003cp\u003e然而，苹果鼓励开发者开发单元测试和E2E测试。他们建议开发人员在实际用户使用应用程序时实现自动化，并在E2E测试中实现自动化。\u003c/p\u003e\n\u003cp\u003e在我看来，供应商不应该影响开发人员和测试人员，让他们决定哪种策略更好。通过增加规则和设置限制，它们实际上减少了创造出新的、更好的和创新的东西的可能性。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e查看英文原文：\u003ca href=\"https://www.infoq.com/news/2019/02/no-failing-mobile-test-automate\"\u003eHow to Avoid Failing at Mobile Test Automation\u003c/a\u003e\u003c/p\u003e\n