【iOS】TestFlight 发布包测试

Posted 2023-04-12

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了【iOS】TestFlight 发布包测试相关的知识，希望对你有一定的参考价值。

参考技术A 现阶段大部分公司在测试和回归期间都是习惯使用测试包，等测试回归没问题了，才打正式发布包发布，由于测试包和发布包在打包时间点和打包过程上存在差异，所以特别容易出现发布包和回归测试的测试包不一致的情况。使用自动化打包，如果打包脚本出现问题，更容易出现这种情况。

所幸的是，苹果在ios8之后推出了TestFlight，使我们在提交前可以安装发布包进行测试，所以我们可以把测试周期拆分

使用 TestFlight 进行内部测试时，啥是好的 iOS 应用版本控制策略？

【中文标题】使用 TestFlight 进行内部测试时，啥是好的 iOS 应用版本控制策略？【英文标题】：What is a good iOS app versioning strategy when using TestFlight for internal testing?使用 TestFlight 进行内部测试时，什么是好的 iOS 应用版本控制策略？ 【发布时间】：2016-01-13 07:13:22 【问题描述】：

我有一个 iOS 应用程序，它使用 semantic versioning 标记已发布的构建。我还使用 Apple 的 TestFlight 将内部构建推送给团队进行测试/QA。

推送内部构建需要将构建上传到 iTunes Connect。 iTunes Connect 的测试版本和发布版本之间没有区别，iTunes Connect 不允许覆盖以前上传的版本。所以每次我想推送一个新的内部测试版本时，我都必须提高版本号（嗯，补丁（X.X.X）号）。

这很好用，除了对我们的用户来说，我们的版本号看起来在更新之间跳了很多。例如，如果这是我们的构建历史：

v1.0.0 v1.0.1（测试中发现错误） v1.0.2 v1.1.0（测试中发现错误） v1.1.1（测试中发现错误） v1.1.2

...那么用户只会看到粗体发布，而我们的发布历史看起来很奇怪：

v1.0.0 v1.0.2 v1.1.2

我认为避免这种情况的一个好方法是使用 beta 版本，例如 v1.1.0-beta 用于测试版本，但 iTunes Connect 拒绝任何不是 X.X.X 的版本字符串。

有没有办法继续使用 TestFlight 进行内部测试/QA 并避免向用户显示填补空白的版本历史记录？

【问题讨论】：

Xcode 有两个不同的地方放置版本号和内部版本号，那么为什么不保持版本号不变并编辑内部版本号呢？ 【参考方案1】：

我在构建版本中使用内部第 4 号，我相信 iTunes 仍然接受这一点。例如它可能是版本 1.0.0，但构建可能是 1.0.0.87，表示要测试的第 87 个内部构建。在 App 中显示时，您可以选择去掉最后一个数字，但人们通常不会在意。

我发现这在大多数地方都很容易理解和接受。

与版本号相比，内部版本号没有得到足够的信任。

【讨论】：

效果很好！何时增加版本号必须和何时增加内部版本号必须之间的区别是我一直在努力解决的问题。感谢您的澄清！拥有 4 个组件是否合法？根据 Apple 的说法，“版本号和内部版本号最多可以包含三个以句点分隔的组件。” （来源：developer.apple.com/library/archive/technotes/tn2420/…）。您可以拥有它们并查询它们，但它们不会显示在 App Store 上，但这使得它们非常适合附加内部版本号。对于 iOS 应用程序的内部版本号不必跨版本唯一。因此，对于任何特定版本，构建号只能是 1、2、3...，下次版本递增时从 1 重新开始（Apple 将其称为版本发布序列）。这在 2021 年仍然有效。任何关于 Android 与 iOS 应用程序保持同步的建议。在 Android 中，内部版本号必须是连续的单个数字。【参考方案2】：