Release checklist 版本清单

Sure, all your tests pass, but how can you make sure your app functions properly? Most large projects have a solution called a release checklist, and here I want to share mine with you.
当然，您的所有测试都通过了，但您如何确保您的应用程序正常运行呢？大多数大型项目都有一个称为发布清单 的解决方案，在这里我想与您分享我的解决方案。

Checklists vs tests  清单与测试

Every great project is backed by a whole lot of software tests – unit tests mostly, but also integration tests and sometimes also UI tests.
每个伟大的项目都由大量的软件测试提供支持——主要是单元测试，但也包括集成测试，有时还有 UI 测试。

But would you be happy to ship an app update just on the basis of those tests passing? Probably not – you want to actually see the app launch, and make sure its features are actually working.
但是，您是否愿意仅在这些测试通过的情况下发布应用程序更新？可能不是 – 您希望实际看到应用程序启动，并确保其功能确实正常工作。

Sometimes that might be simple, and launching the app and trying out its key features is such a common form of test that it has its own name: “smoke test.” Sometimes you’re more thorough, going through quite a few screens to make sure everything is in order.
有时这可能很简单，启动应用程序并试用其主要功能是一种非常常见的测试形式，以至于它有自己的名称：“冒烟测试”。有时你会更彻底，通过相当多的屏幕来确保一切正常。

But once you move beyond small, personal apps into anything that makes any sort of money, trying out the app becomes much more formalized, often with a dedicated quality assurance team providing QA for every release.
但是，一旦您从小型个人应用程序转向任何赚钱的东西，试用该应用程序就会变得更加正式，通常会有专门的质量保证团队为每个版本提供 QA。

None of this takes away from unit tests and other software tests – those remain extremely valuable, and test the core logic of your software. But when it comes to more complex things like “did that animation work correctly?” or “was that button easy to tap?”, or indeed a wide range of other tests that require actual judgement, human intervention is still necessary.
这些都不会影响单元测试和其他软件测试——它们仍然非常有价值，并且测试软件的核心逻辑。但是，当涉及到更复杂的事情时，例如“那个动画是否正常工作”或“那个按钮是否容易点击”，或者确实需要实际判断的各种其他测试时，人工干预仍然是必要的。

Ensuring 100% quality  确保 100% 的质量

This is where release checklists come in: they are documents that describe the key things a human tester must do. Ideally they are very specific to your app: “go to the X screen, tap Y, then select Z.”
这就是发布清单的用武之地：它们是描述人工测试人员必须做的关键事情的文档。理想情况下，它们非常特定于您的应用：“转到 X 屏幕，点击 Y，然后选择 Z。

However, there are lots of things in release checklists that are shared across many apps – is dark mode working well? Do videos enter full screen correctly? Can you export a photo? Do the widgets display properly in all sizes?
但是，发布清单中有很多内容在许多应用程序之间共享 – 暗模式运行良好吗？视频是否正确进入全屏？可以导出照片吗？小组件是否在所有大小下都能正确显示？

I’ve had many own release checklist for well over a decade, and although I customize it for individual apps the core items remain the same. I’ve taken all the items from there, cleaned it up a little (because my version was just for my use, and had grown a little messy over the years!), and I want to share it with you.
十多年来，我有很多自己的发布清单，尽管我为各个应用程序自定义了它，但核心项目保持不变。我已经从那里拿走了所有项目，稍微清理了一下（因为我的版本只是供我使用的，这些年来变得有点凌乱了！），我想与你分享。

It’s an Apple Numbers spreadsheet document, so you can amend it freely, adding lots of things specific to your app. And you should add your own things, because it’s important to pick out the key functionality for your app.
它是一个 Apple Numbers 电子表格文档，因此您可以自由修改它，添加许多特定于您的应用程序的内容。 您应该 添加自己的内容，因为为您的应用程序挑选关键功能很重要。

Anyway, I want to mention a few things that need some extra explanation:
无论如何，我想提几点需要额外解释的事情：

• The version, tester, and date fields at the top are important if you have a team of testers. Many companies file away these completed release checklists, so they can go back and refer to them if problems occur.
  如果您有一个测试团队，则顶部的 version、tester 和 date 字段非常重要。许多公司将这些完成的发布清单归档，以便在出现问题时可以返回并参考它们。
• There’s a difference between upgrading from the previous version and upgrading from an older version. One is from v3 to v4, and the other from v1 to v4. Both should work, but you need to be particularly careful if you have a Core Data schema that you’ve modified.
  从以前的版本升级和从旧版本升级是有区别的。一个是从 v3 到 v4，另一个是从 v1 到 v4。两者都应该有效，但如果您修改了 Core Data 架构，则需要特别小心。
• You’ll notice I’ve listed to test on the biggest and smallest iPad and iPhone, which should push your UI to its limits.
  您会注意到，我列出了在最大和最小的 iPad 和 iPhone 上进行测试，这应该会将您的 UI 推向极限。
• For multi-window mode, make sure you test the various sizes of your app – it might take up most of the screen, or just get a small slither.
  对于多窗口模式，请确保测试应用程序的各种大小 – 它可能占据大部分屏幕，或者只是获得一个小的滑行。
• On real devices, you can go to the Developer settings to enable Network Link Conditioner. This makes testing slow and no networks much easier.
  在实际设备上，您可以转到 Developer 设置以启用 Network Link Conditioner。这使得测试速度变慢且没有网络变得更加容易。
• With in-app purchase testing, using a StoreKit configuration file makes everything simpler. You can configure things like Ask to Buy there.
  通过 App 内购买项目测试，使用 StoreKit 配置文件会让一切变得更简单。您可以在此处配置“购买前询问”之类的内容。
• For VoiceOver testing, ideally your tester is able to complete this with the screen curtain enabled. This makes the entire screen black while still remaining responsive, so it’s the ultimate test of your VoiceOver capability.
  对于 VoiceOver 测试，理想情况下，您的测试人员能够在启用幕屏的情况下完成此作。这会使整个屏幕变黑，同时仍保持响应，因此这是对 VoiceOver 功能的终极测试。
• For localization I frequently set my app to torture mode, which is the double-length pseudolanguage where every word is repeated twice to simulate longer languages.
  对于本地化，我经常将我的应用程序设置为 torture 模式，这是一种双倍长度的伪语言，每个单词都重复两次以模拟更长的语言。
• There’s a Notes box at the end of each section, giving folks the chance to write in anything important. I remember not having this in the early days of running a team, and finding things scrawled in the margins in tiny letters, which made information easy to miss!
  每个部分的末尾都有一个 Notes 框，让人们有机会写下任何重要的东西。我记得在经营团队的早期没有这个，发现空白处用小字母潦草地写着东西，这很容易错过信息！

Again, these are all broad brushstroke things, but they should at least give you an idea of what to test.
同样，这些都是宽泛的笔触，但它们至少应该让您了解要测试什么。

Remember, this document is provided as a Numbers spreadsheet specifically so that you can customize it to fit your app. What are the critical points you need to add? By writing them down you’re formalizing them for the future, and if in the future you find a bug snuck through that can become another thing for your checklist.
请记住，此文档专门以 Numbers 电子表格的形式提供，以便您可以自定义它以适合您的应用程序。您需要添加哪些关键点？通过将它们写下来，你就是在为将来正式化它们，如果将来你发现一个偷偷通过的错误，那可能会成为你清单上的另一件事。

Good luck!  祝你好运！