18、移动应用测试与持续部署：策略、挑战与实践-优快云博客

本文链接：https://blog.youkuaiyun.com/css33/article/details/150684359

移动应用测试与持续部署：策略、挑战与实践

1. 移动设备测试平台分析

Visual Studio App Center在设备测试方面有其独特的特点。它缺少一些用户友好的功能，如机器人测试器和通过Web控制台进行简单测试执行。相反，它专注于与App Center命令行界面（CLI）的命令行集成。通过App Center CLI，你可以使用Appium、Calabash、Espresso或XamarainUITest轻松启动自动化测试，并且与CI/CD工具的集成也很直接。

总体而言，Visual Studio App Center在设备覆盖方面表现出色，明确聚焦于企业移动设备测试。但对于独立开发者或小型团队来说，它不太容易上手，前期成本较高，不过在业务扩展时会有不错的表现。

2. 设备测试策略规划

在选择设备测试方式时，有自建设备实验室和利用云基础设施两种选择，它们各有优劣。

2.1 云服务的优势

低启动成本 ：云服务计划通常为开发者提供有限数量的免费设备测试，并根据设备使用情况定价。这是开始探索手动和自动化设备测试最简单、成本最低的方式。
设备选择丰富 ：云测试提供商服务大量客户，拥有大量当前和旧款手机库存，可精确针对用户可能使用的设备类型、配置进行测试。
快速扩展 ：应用开发注重快速推广和扩展。云服务允许根据应用规模和受欢迎程度扩大测试规模，而无需前期投入大量基础设施成本。
减少资本支出 ：构建大型设备实验室需要高额前期资本支出。使用云基础设施按需付费可延迟成本支出，提高资本效率。
全球访问 ：随着远程和分布式团队成为常态，云服务设计上允许团队成员无论身在何处都能轻松访问。

2.2 自建设备实验室的优势

大规模时成本降低 ：大规模运营和维护设备实验室的总体拥有成本，在设备使用寿命内远低于云服务提供商的每月总成本。对于大型移动企业，这能节省大量成本。
快速且可预测的周期时间 ：控制设备农场可确保测试并行运行，并在可预测的时间内完成，实现快速响应的构建。云服务提供商设备可用性有限，热门配置可能需要排队等待，限制快速迭代能力。
无会话限制 ：设备云服务通常对测试会话设置硬编码限制，以防止因测试或设备故障导致测试挂起。随着测试套件复杂性增加，30分钟的硬限制可能成为完成复杂用户流程测试的障碍。
法规要求 ：在金融和国防等受监管行业，安全要求可能限制或禁止在企业防火墙外部署应用和执行测试。这类企业需要自建设备实验室。
物联网设备集成 ：如果需要将移动设备与物联网设备和传感器集成，云服务提供商通常不会直接提供这种配置。自建设备实验室可以更好地匹配实际场景。

以下是云服务和自建设备实验室优势对比表格：
| 对比项 | 云服务 | 自建设备实验室 |
| ---- | ---- | ---- |
| 启动成本 | 低 | 高 |
| 设备选择 | 丰富 | 有限 |
| 扩展速度 | 快 | 慢 |
| 资本支出 | 低 | 高 |
| 全球访问 | 方便 | 受限 |
| 大规模成本 | 高 | 低 |
| 周期时间 | 不可控 | 可控 |
| 会话限制 | 有 | 无 |
| 法规适应性 | 差 | 好 |
| 物联网集成 | 差 | 好 |

下面是选择设备测试方式的mermaid流程图：

graph LR
    A[开始] --> B{是否预算有限}
    B -- 是 --> C[选择云服务]
    B -- 否 --> D{是否需要快速迭代}
    D -- 是 --> E{是否有法规要求}
    E -- 是 --> F[自建设备实验室]
    E -- 否 --> G{是否需要物联网集成}
    G -- 是 --> F
    G -- 否 --> C
    D -- 否 --> H{是否大规模测试}
    H -- 是 --> F
    H -- 否 --> C

3. 持续部署的重要性

连续更新已不再是软件开发的可选部分，而是任何重大项目的必要组成部分。规划持续更新交付与项目的功能需求同样重要，并且需要高度自动化才能可靠执行。

过去，软件发布节奏较慢，仅接收关键更新，更新安装通常是手动且容易出错的过程，涉及脚本调整、数据迁移和大量停机时间。但在过去十年中，情况发生了巨大变化。

3.1 用户对持续更新的期望

终端用户对新功能发布节奏的期望在过去十年发生了巨大转变。这一变化源于消费设备和持续更新应用的影响，这种期望也延伸到其他软件平台，包括企业软件。如果强迫用户等待长时间的发布周期或进行昂贵的迁移以使用新功能，会导致用户不满，使企业处于竞争劣势。

以消费行业为例，手机行业的发展体现了这一变化。早期诺基亚主导2G手机市场，但软件更新能力较差。直到2007年iPhone推出，采用软件优先的设计理念，实现了固件和操作系统的更新，后来还支持空中下载更新。如今，手机软件更新无缝且自动化，消费者甚至不知道自己使用的操作系统或应用版本。这种持续更新模式已成为各类消费设备的标准，如智能电视、家庭助手和新型自更新路由器。汽车行业中，特斯拉通过每两周一次的更新推动行业发展，用户无需前往服务中心进行召回或关键软件更新。

3.2 安全漏洞的风险

软件漏洞对科技行业构成的风险类似于石油泄漏对环境的影响。随着软件系统日益复杂，对开源软件和第三方库的依赖增加，几乎不可能审计和保证系统无安全漏洞。

组织应对安全漏洞通常需要三个步骤：
1. 识别：组织必须意识到安全问题的存在，并判断攻击者是否正在或可能利用该漏洞。
2. 修复：开发团队需要提出软件修复方案来修补问题。
3. 部署：将修复软件部署到受影响的大量终端用户或目标设备上。

以泰勒能源石油泄漏事件为例，识别问题用了6年，修复用了8年，部署解决方案用了5个月。软件漏洞的处理虽然理论上应该更容易，但实际案例表明，它们同样具有破坏性和经济成本。

以下是几个软件安全漏洞案例分析表格：
| 案例 | 识别时间 | 修复情况 | 部署时间 | 影响 |
| ---- | ---- | ---- | ---- | ---- |
| UK医院勒索软件攻击 | 1年 | 现有补丁 | 多年 | 约19000个预约取消，损失约1900万英镑产出，7300万英镑IT恢复成本 |
| Equifax安全漏洞 | 5个月 | 现有补丁 | 1天 | 14300万消费者个人信用信息泄露，花费14亿美元清理，13.8亿美元解决消费者索赔 |

下面是处理安全漏洞步骤的mermaid流程图：

graph LR
    A[发现安全问题] --> B[识别漏洞]
    B --> C[开发修复方案]
    C --> D[部署修复软件]
    D --> E[完成修复]

移动应用测试与持续部署：策略、挑战与实践

4. 具体安全漏洞案例分析

4.1 UK医院勒索软件攻击

2017年，一场全球性的网络攻击爆发，黑客利用“永恒之蓝”漏洞，对运行Windows Server Message Block（SMB）服务的计算机进行加密，并索要比特币“赎金”以恢复数据。英国国民健康服务（NHS）医院系统受到严重影响，多达70,000台设备，包括计算机、MRI扫描仪、血液储存冰箱和其他关键系统都被病毒感染。此次攻击导致约19,000个预约取消，在攻击后的几周内，估计损失了约1900万英镑的产出，并花费了约7300万英镑用于恢复系统和数据。

从漏洞缓解步骤来看：
- 识别：在事件发生前一年，漏洞和可用补丁就已存在，但直到攻击发生，NHS才发现该漏洞。
- 修复：由于修复只需使用现有的补丁来升级或修补系统，所以在漏洞被识别时，修复方案就已可用。
- 部署：尽管关键系统很快恢复上线，但受影响的系统数量众多，NHS花了数年时间才完全升级和修补受影响的系统，期间还经历了多次安全审计失败。

4.2 Equifax安全漏洞

2017年3月至7月期间，黑客利用Equifax系统中的安全漏洞，无限制地访问其内部系统，并提取了约1.43亿美国消费者的个人信用信息。此次安全漏洞对Equifax的品牌和声誉造成了无法估量的损害，该公司花费了14亿美元用于清理工作，并额外支出13.8亿美元解决消费者索赔。

导致此次漏洞的原因主要有两个：一是Apache Struts中未修补的安全漏洞，使黑客能够访问Equifax的争议门户；二是过期的公钥证书，阻碍了其内部对加密流量的检查系统。

从漏洞缓解步骤来看：
- 识别：最初的安全漏洞于3月10日出现，但直到7月29日Equifax修复其流量监控系统时，才意识到数据泄露问题，此时距离攻击开始已近5个月。
- 修复：Apache Struts的安全漏洞（CVE - 2017 - 5638）于3月10日公布，而修复补丁在3月6日就已发布。
- 部署：在发现漏洞的第二天（7月30日），Equifax就对漏洞进行了修补。

4.3 广泛的芯片组漏洞

即使在应用程序和操作系统层面保持对安全漏洞的关注，芯片组和硬件层面的漏洞仍然可能影响系统安全。最近最广泛的例子是谷歌安全研究人员发现的“熔断”（Meltdown）和“幽灵”（Spectre）漏洞。

这两个漏洞利用了硬件平台中推测执行和缓存交互的底层漏洞，能够访问本应受保护的数据。“熔断”漏洞使恶意程序可以访问机器上本不应访问的数据，包括具有管理权限的进程数据，但相对容易在操作系统层面进行修补。而“幽灵”漏洞则需要特定的攻击信息，更难利用，但也更难修补，新的基于该漏洞的攻击仍在不断被发现。

以下是不同安全漏洞案例对比表格：
| 案例名称 | 漏洞类型 | 影响范围 | 识别时间 | 修复情况 | 部署时间 |
| ---- | ---- | ---- | ---- | ---- | ---- |
| UK医院勒索软件攻击 | 操作系统漏洞 | 医院关键系统 | 1年 | 现有补丁 | 多年 |
| Equifax安全漏洞 | 应用程序漏洞 | 消费者个人信用信息 | 5个月 | 现有补丁 | 1天 |
| 芯片组漏洞（熔断、幽灵） | 硬件漏洞 | 云工作负载、移动设备等 | 及时发现 | 操作系统和硬件修复 | 持续推进 |

下面是不同类型漏洞处理流程的mermaid流程图：

graph LR
    A[发现问题] --> B{漏洞类型}
    B -- 操作系统漏洞 --> C[识别操作系统漏洞]
    C --> D[获取现有补丁]
    D --> E[部署补丁]
    B -- 应用程序漏洞 --> F[识别应用程序漏洞]
    F --> G[开发或获取修复方案]
    G --> H[部署修复]
    B -- 硬件漏洞 --> I[识别硬件漏洞]
    I --> J[评估修复方式]
    J -- 操作系统修复 --> K[更新操作系统]
    J -- 硬件修复 --> L[更换或升级硬件]