本文较长，译文分为成两篇，此文为上半部分。

       大多数用户几乎连一小时都不能离开他们的移动设备，或者更确切地说，是离不开移动设备上的应用程序。移动技术给我们生活的方方面面带来了新的转折。随着我们对移动性的看法发生变化，移动软件开发的标准也相应变化。2021年，一款成功的移动应用程序不仅仅是要运行丝滑，更需要拥有超凡脱俗的新功能来吸引用户。否则，您全新的应用程序很大风险会淹没在一大堆应用程序里。在这篇文章中，我们将逐步分解这个能够将一款应用程序从不完善变得强大的工具——移动应用测试。

本文目录

1 移动测 试的重要性
1.1 越早测试成本更低
1.2 第一印象很重要
1.3 最终 用户 ≠ 测试人员
2 移动测试的独特特性
2.1 更高的用户期望
2.2 物理测 试设备需求
2.3 操作系 统发布周期 频繁
3 iOS 和 安卓系统的独特功能
3.1 定制的系统
3.2 开放 式系统和封闭式系统
3.3 发布 周期 不同
3.4 升级的容忍度不 同
4 移动应用测 试的各阶段
4.1 原型测 试
4.2 MVP 测试
4.3 发布 和功能测试
4.4 发布 后的支持
5 移动应用测试 词汇表
5.1 测试分类
5.2 测试阶段
5.3 移动应用测 试类型
5.4 移动应用测 试方法
5.5 手动测试与 自动测试
6 组建测试 团队
6.1 QA 团队角色 和责任
6.2 内部团 队与外包团队
6.3 测试人 员薪水
6.4 QA和测 试预算
6.4.1 测试时长评估
6.4.2 预算 估算

6.5 怎么识别QA团队

6.6 找到了喜欢的移动测试公司，接下来呢？

7 最后的想法

1 测试的重要性

       需要考虑的数字：

• 77% 的用户表示，他们对自己安装的移动应用程序的性能表现表示担忧。

• 51% 的移动开发人员承认他们没有足够的时间进行全面的发布前测试。

• 移动应用中用户最关心的问题包括缺陷（58%）、崩溃（57%）和整体性能不佳（48%）。

• 如果应用程序启动时间过长，28%的美国人表示宁愿使用其他竞争对手的数字产品。

• 88%的美国人对网站和移动应用表现不好的公司品牌感到消极。

       软件测试是判断程序是否按要求工作（甚至是不是根本不起作用）的唯一方法。作为质量保证的主要部分，应用测试是一个多层次的过程，对版本发布非常重要。连续从事了20年的软件开发工作，我们不禁要强调测试对于任何解决方案（小的、大的、复杂的等等）的至关重要性、成本效益和战略影响。以下是我们将移动应用测试与开发、规划和技术支持等同起来的更多原因：

1.1 早期测试比最后时刻的修复成本更低

       从历史上可以知道许多程序员和/或产品负责人对软件测试粗心大意的例子。尽管并不是每个错误都值得成为头条新闻（比如2020年的谷歌大故障或亚马逊1英镑销售臭名昭著的案例），但所有的小缺陷累积起来会导致每年数万亿美元的经济损失。我们并不是要否认幸运的企业家的存在，而是想让您思考：如果绝对的市场领导者都因为技术错误从而遭受财务损失，那这样的错误会对小公司造成什么样的影响？

       软件错误是可以预防的，唯一可以防止错误的技术是质量保证和深入的软件测试。有专业执行的 QA，潜在的故障可以在投入实际运行的更早之前就被检测出来。QA的预算可以很容易地提前评估和规划，但是在版本发布后谁能识别出您需要投入多少来紧急修复产品中的某些问题呢？这个数字是不可预估的。考虑到错误本身的紧迫性和对财务收入的伤害，不要奢望能够轻松地避免这些损失。低估软件测试就意味着盲目地将您在产品中所有投资都押注在开发人员的技能和对细节的把控上。

1.2 您的应用没有出现错误的机会

       根据Quettra收集的数据，77%的人在安装应用程序后三天内就放弃了它。这一百分比在一个月内会增长到90%，并在90天内达到95%大关。这意味着移动应用程序有大约 72 小时的时间给用户留下深刻印象，并开始形成定期使用该应用程序的习惯。显然，如果应用程序不能按预期工作，用户不太可能花整整三天的时间来尝试它。坦率地说，如今人们在经历一次应用程序的崩溃之后，几乎不会再给这种有缺陷的应用程序一次机会。如果应用市场中存在数百万个其他选择，为什么还要费心呢？

       人们很快就对他们下载的应用程序失去了兴趣，这个可以有不同的原因。对许多人来说，最简单的方式似乎是因为推送通知。如果一个人安装了一个应用程序，却把它晾在那里，为什么不通过一两条无恶意的消息提醒他们程序的存在呢？如果推送通知不像今天这样被过度使用，那将是完全正确的。一个移动应用程序在不需要通过无数次的推送来烦扰用户的情况下，用户也能表现出真诚的意愿来经常使用它，那它才能被认为是成功的。如果从项目一开始就采用正确的移动应用测试服务，这是绝对可以达成的。

1.3 最终用户不是您的beta测试人员

       我们在移动软件开发中经常使用的另一种方式是直接发布数字产品的原型版本，而不是它的完整版本。这样做的人往往认为更快的上市时间比应用程序的性能表现更重要。毕竟，您始终都可以收到负面的反馈并再次发布更新，对吗？不幸的是，考虑到最初的负面体验，改进版的产品很可能在应用商店中不会再受到太多关注了。

       将您的名声放在基本操作就有问题的应用程序上，对您的品牌形象和长期声誉是非常冒险的。原型、MVP 版本和许多其他软件开发和移动应用程序测试技术可以保证您的安全，因此我们强烈建议将它们纳入您的项目规划。

2 移动应用测试的独有特性

       很多移动应用开发和测试团队都认为，把移动应用程序当作运行在小型设备上的同款（PC）软件是不准确的。实际上，移动应用程序测试服务与任何其他项目类型都有很大的不同。下面看我们如何看待移动软件测试的独特特性。

2.1 用户期望

       移动软件被称为“移动”软件是有原因的：这些应用程序预期在任何时间、任何地点都能工作。此外，易用性是移动软件的一个关键显著特性。对于开发人员、UI/UX 设计师和测试人员来说，用户与其移动设备不同的物理交互带来了很大变化。同时，数字体验个性化的全球趋势也提高了用户对所选择软件的期望。当软件的个性化遇到了易用性需求的时候，对项目测试团队的要求可能会失控。

       鉴于智能手机用户平均每 6 分钟就查看一次手机，并期望在 2 秒内就可以启动一款应用，我们可以自信地说，用户对移动软件的要求远远高于桌面和 Web 应用程序。下面是一个简短的提示列表，可以帮助应用软件的负责人评估潜在的用户预期：

• 在目标受众的研究上投入时间和精力;

• 在项目的每个阶段分析潜在的用户需求;

• 全面研究竞争对手，并尽早做到这一点（理想情况下，在开始规划应用程序之前就开始）;

• 明确您的应用将要为安装它的人解决什么问题;

• 如果您自己都没有动力去使用您的应用程序，就不要指望其他人会用；

• 优先考虑应用程序性能和易用性。

2.2 物理测试设备

       移动软件测试的最大痛点之一是碎片化，这个术语用来描述这种多种物理设备运行着不同操作系统的复杂情况。现在即使移动操作系统只有 iOS 和 Android，每个操作系统也仍然还有很多版本。再加上大量的智能手机和平板电脑，有旗舰机也有仍在使用中的老设备，您将遇到无数影响应用性能表现的组合。这对移动测试人员来说是一个挑战：他们必须定义最常用的设备型号和操作系统版本，并记录可能的组合情况，作为其测试策略的基础。显然，不可能测试到每一个组合，但是使用最普遍的组合作为您的指导是必要的。

      考虑到测试碎片化的复杂性，选择了全面移动 QA 测试的团队通常更喜欢手头上拥有真实的物理设备。仿真器可能很有用，但像UI/UX和安装之类的东西很难用它们进行全面评估。用户对应用程序的感知会因为屏幕大小、导航按钮（或手势）或者其他窗口小挂件的技术特性发生巨大变化。这是（桌面软件）只有屏幕分辨率的变化或者 PC 和笔记本电脑几英寸的差异无法相提并论的。我们的建议是，为您的移动应用QA团队提供所需物理设备及相应数量，并确保您的目标不仅仅是在最新的移动平台版本上。

或者，您始终可以外包给已经拥有各种物理设备的团队。

2.3 移动操作系统发布周期

      除了碎片化，您的 QA 团队还必须考虑移动操作系统的发布周期。移动硬件制造商在行业内面临着难以置信的竞争，这迫使他们尽可能频繁地向我们抛出创新的产品。传统上，市场领导者每年都会推出新的旗舰移动设备。许多公司同时发布新硬件配套的新软件。总之，这为整个移动软件行业在用户界面、屏幕比例、导航工具和 API 方面树立了新的标准。

      能够解释如此巨大变化的一个很好的例子是iPhone X和iOS 11的发布，它们带来新的安全区域输入参数、手势接口、革命性的显示形状（又名"刘海屏"）、画板尺寸、像素密度、新的排版等。本来看似不寻常甚至不被需要的东西已成为当前移动硬件的基础特性。如果计划开发移动数字产品，您必须同时兼顾最新的操作系统版本以及一些更老一点的版本，但注意不要让过时的平台过多分散你的注意力。

3 从测试的角度来看，iOS和Android有何不同？

       iOS 和安卓之间的纷争一直伴随着这些操作系统的发展。撇开技术上的比较不谈，无论建立在哪个平台上的数字产品，移动开发人员和测试人员必须提供完善的功能。正如我们已经知道的，这在很大程度上取决于软件测试。这些在 iOS 和安卓系统有什么不同吗？如果有，要怎么做呢？以下是将安卓和 iOS 软件测试区分开的核心因素列表。

3.1 定制化差异

      iOS完全由苹果公司发布，只在苹果品牌的移动硬件（iPhone、iPad等）上运行，没有任何定制。与iOS不同的是，Android关于可定制操作系统特性的政策要民主得多。选择 Android 作为其产品核心的硬件生产商可以创建自定义的用户界面，将 Android 移动架构的核心隐藏在他们的设计样式之下。基于 Android 最知名的定制用户界面包括三星的 One UI、华为的 EMUI 和小米的 MIUI。所有这些定制不仅在美学上不同，在性能和速度上都不一样。可以理解的是，当涉及到 Android 应用测试时，QA 团队除了需要关注不同设备和操作系统版本外，还必须花费额外的时间来检查不同定制用户界面上的性能表现和可用性。

3.2 开放系统和封闭系统差异

      在代码库的可访问性方面，两个操作系统也表现出巨大差异。iOS 是基于 XNU 内核的闭源系统。iOS 中流行的编程语言是Swift、C 、C++和Objective-C。苹果移动软件开发标准相当严格，确保应用程序遵守这些标准是 iOS 应用测试团队的主要职责之一。反过来，Android操作系统使用谷歌的开源码库，操作系统核心主要基于Linux，编程语言是C和C++。谷歌在软件开发和Android应用程序测试方面的政策一直相当开放，很受工程师欢迎。这并不意味着Android移动应用程序测试和开发标准较低，只是对Google Play贡献者肯定更宽容。在iOS移动测试中，应用程序更新很少能够第一次就通过苹果应用程序审查团队的批准。

3.3 部署周期

      由于苹果保持其移动操作系统严格的一致性，iOS应用程序的部署过程通常比Android快一点。这是因为苹果试图保持目前使用的所有iOS版本在优化和性能上都一致。将 iOS 应用构建版本上传到应用商店的准备阶段仍有很多步骤需要遵循，但对于任何 iOS 版本，这些步骤大致相同。对于 Google 的操作系统，或者更准确地说，对于未接收更新最新操作系统版本或者运行了定制UI的智能手机/平板电脑，Android 应用测试服务有更多工作要做。

3.4 升级容忍度（update tolerance）

       应用程序更新升级是移动软件开发和测试工作的重要组成部分。苹果的App Store更新审查和审批流程比Google Play市场要长得多。等待应用程序更新批准的过程可能很烦人，但这意味有专业人士来仔细审查更新。尽管 Android 用户接收应用程序更新的速度更快，但喜欢 iOS 的人不太喜欢因为更新版本测试不充分而目睹自己喜爱的应用运行崩溃。两个移动操作系统都需要软件测试人员在更新时给予额外的关注，但具体在 Play 市场，没有人会花费太多时间检查您的特定更新是否值得发布。

4 移动应用开发各阶段及其相关的测试技术

      需要考虑的数字：

• 移动设备88% 的时间都用在应用程序上。

• 预计到2023 年，移动应用将产生超过 9350亿美元的收入。

• Google Play目前有287万个移动应用程序可用，而苹果应用商店有大约196万个。

• 21% 的00后每天打开同一个应用程序 50 多次。

• 2020年，智能手机用户的手机上平均安装了40个应用程序。

• 全球98% 的应用收入来自免费应用程序。

• 亚马逊、Gmail 和 Facebook 是00后最重要的三个应用程序。

      显然，移动应用测试不能与软件开发分开讨论。但就在几年前，测试曾被视为项目中的一个独立阶段，其位置如下：

1. 研究与概念化

2. 项目规划

3. 设计

4. 开发

5. 测试

6. 部署

      这种"先开发，后测试"的瀑布方法，对许多IT团队来说是低效和浪费的。现在，它正逐渐被一种整体的敏捷软件质量保证方法所取代——这个概念认为，测试应该在实际编程的很早之前，在团队一启动项目时就开始。这样，该团队不仅可以检测功能不良的代码，还可以检测到影响整体应用的高级别错误，而不只是针对一个特定功能。按照这个概念，下面是移动应用开发过程的大致阶段，以及每个阶段的相应测试技术：

4.1 应用原型和概念测试

      不管经验和资历如何，光凭一个人的想法就想出来一个全新的数码产品是极其困难的。实际上，开发人员在开发新应用程序时，会采用各种技巧来降低潜在的失败风险。制作原型并对其进行测试是其中之一。

      基本上，原型是功能有限但能清晰展示未来产品外观和特性的早期示例或模型。原型测试使团队能够评估未来产品的可用性及其核心功能，并检验应用预期的整体概念。与现成的应用程序不同，数字原型背后没有较大的代码库，这意味着创建一个原型不会花很长时间。事实上，你可以很容易地在设计程序 Figma 或者 Invision上实现一个原型。我们强烈推荐原型测试技术，以便进行实用性验证和早期发现概念上的错误。

4.2 MVP 和关键特性测试

       MVP 是指最简化可实行产品，是一种软件开发方法，意味着新应用程序首次发布时仅具有核心功能，而不考虑所有辅助功能。在收集第一批 MVP 用户的反馈后，团队可以继续进一步开发。这样，您的应用程序可以更快地到达用户（或焦点小组）手上，而无需浪费时间或资源来充分打磨使其发挥全部潜力。

       与原型不同，MVP 应用程序具有实际代码库，以后可以用作最终版本的基础。在UI/UX设计方面，MVP 版本不太注重美学，但我们仍然认为这是一个测试计划用于全功能产品的整体风格和配色方案的好机会。通过MVP测试，QA分析员不仅在部署之前对简化版本进行测试，而且还对早期用户的反馈进行分析。

4.3 发布和功能测试

      发布之前和发布期间进行的软件测试是大多数人想象中的质量保障行为。尽管您已经看到QA不仅仅是部署阶段的功能测试，它仍然是一个基本的测试阶段。

     功能测试将产品的功能需求与实际开发的实现进行比较。它与许多其他测试类型一起使用，我们也在本文的稍后分解。简单地说，功能测试主要关注可访问性、主要特性、基本可用性和潜在错误以及解决这些错误的方法。

4.4 发布后的支持和回归测试

      不要以为你的应用程序一进入应用程序商店，你的工作就完成了。移动程序的定期更新与成功发布同样重要。但是，即使代码库稍有中断也可能导致严重的错误，甚至导致程序崩溃。这时回归测试成为关注的焦点。

      移动应用回归测试是一个检查新代码能否与旧程序兼容运行的过程。它旨在确保应用程序更新不会以任何方式影响其稳定性，而只会使其变得更好。与桌面测试相比，由于多种技术组合（应用架构-原生或跨平台、移动平台、其版本等），移动应用程序的回归可能更复杂。

{测试窝原创译文，译者：Apple}