ios web应用程序
Year after year, Apple’s new releases of mobile devices gain a decent amount of traction in tech media coverage and keep attracting customers to obtain their quite pricey products. Promises of superior quality, straightforwardness of the integrated ecosystem, and inclusion of new, cutting edge technologies urge the company’s longtime fans and new customers alike to upgrade their devices to Californian designed phones, tablets and computers.
年复一年，苹果公司新发布的移动设备在技术媒体报道中获得了可观的吸引力，并不断吸引客户来购买价格昂贵的产品。 更高质量的承诺，集成生态系统的直接性以及新的，尖端技术的加入，促使公司的长期粉丝和新客户都将其设备升级到加利福尼亚设计的手机，平板电脑和计算机。
再起 (Resurgence)
Focusing on the mobile market alone, it is impossible to neglect the significant raise in Apple’s iOS market share of mobile operating systems. Its major competitor, Google’s Android has noted 70.68% of mobile market share in April 2020 — which is around 6 percentage points less than in October 2019. On the other hand, iOS, which noted 22.09% of the market share around the same time, recently has risen to 28.79%. This trend surely pleases Apple’s board, along with anyone who strives to monetize their app ideas in App store.
仅关注移动市场，就不可能忽略苹果公司iOS移动操作系统市场份额的大幅提高。 它的主要竞争对手Google的Android在2020年4月占据了70.68％的移动市场份额，比2019年10月降低了约6个百分点。另一方面，iOS在同一时间占据了22.09％的市场份额，最近已经上升到28.79％。 这种趋势肯定会令苹果董事会以及任何努力在App Store中通过其应用创意获利的人感到高兴。
Gaining revenue through in-app purchases sounds like a brilliant idea, but it requires plenty of planning, calculating risks, and evaluating funds for the project. Before publishing the software product, an idea has to be conceived, marketed, developed, and tested. Each step of this process of making an app aimed at providing paid content differs from the process of creating a custom-ordered software. And that also includes testing.
通过应用内购买获得收入听起来是一个绝妙的主意，但它需要大量的计划，计算风险和评估项目资金。 在发布软件产品之前，必须构想，营销，开发和测试创意。 制作旨在提供付费内容的应用的过程的每个步骤都不同于创建定制软件的过程。 这还包括测试。
要花多少钱？ (At what cost?)
But wait! Testing usually includes lots of repetition. So that would mean testers have to go through many transactions. Doesn’t that entail spending lots of money? Well, not exactly. Apple provides development teams with their own in-app purchase testing tool, Sandbox. But using it doesn’t make testing all fun and games.
可是等等！ 测试通常包括很多重复。 因此，这意味着测试人员必须经历许多交易。 那不是要花很多钱吗？ 好吧，不完全是。 Apple为开发团队提供了自己的应用程序内购买测试工具Sandbox。 但是使用它并不能测试所有的乐趣和游戏。
Sandbox allows for local development of in-app purchases without spending a dime on them. That happens by supplementing the ‘real’ Appstore account with the Sandbox one. Sounds fantastic, doesn’t it? But unfortunately, there are some inconveniences behind that.
沙盒可以在本地开发应用内购买，而无需花一毛钱。 这是通过用沙箱补充“真实” Appstore帐户来实现的。 听起来很棒，不是吗？ 但不幸的是，这背后有一些不便之处。
如果还没有破裂…… (If it ain’t broke…)
First of all, Sandbox accounts have to be created manually via iTunes Connect, which leaves much to be desired in terms of performance. These accounts require an email in a valid format. Testers will need plenty of Sandbox accounts because it is actually quite easy to ‘use them up’, especially when tested software has its own sign-in system (not related to Apple ID). If by design said app account is also associated with In-app purchase, each app account will require a new Sandbox account.
首先，必须通过iTunes Connect手动创建沙箱帐户，这在性能方面还有很多不足之处。 这些帐户要求使用有效格式的电子邮件。 测试人员将需要大量的Sandbox帐户，因为“使用它们”实际上非常容易，尤其是在被测试的软件具有自己的登录系统(与Apple ID不相关)时。 如果设计上说该应用程序帐户也与应用程序内购买相关联，则每个应用程序帐户将需要一个新的沙盒帐户。
Unfortunately, Apple’s Sandbox accounts can get really tricky to log into. When you’re trying to sign in to another Sandbox account, which was probably named similarly as all previous one for convenience, you’d think your muscle memory will allow you to type in the password without looking at the screen. Nothing more wrong. Sometimes, when you type in the credentials which consist of an email and a password, check twice and hit Sign In button in Sandbox login popover, nothing happens.
不幸的是，Apple的Sandbox帐户登录确实很棘手。 当您尝试登录另一个Sandbox帐户时(为方便起见，该帐户的名称可能与以前的所有帐户都类似)，您会认为自己的肌肉记忆力可以让您无需查看屏幕即可输入密码。 没错。 有时，当您输入由电子邮件和密码组成的凭据时，请检查两次并单击“沙盒”登录弹出窗口中的“登录”按钮，什么也没有发生。
User is not logged in, not even a sign in error is displayed. And you try again. Every character is exactly the same as before. And eventually, you manage to log in. It’s not really a big of a deal unless you lose your temper easily testing manually, but a simple message informing why Sandbox login failed would be much more user-friendly. In automated tests you could just write the code to try to log in until the email address used as login is displayed in the Sandbox account section in iOS settings, which means that the login was successful. It’s not something testers can’t live with, but addressing the issue by Apple would greatly improve the experience of working in iOS development.
用户尚未登录，甚至不会显示登录错误。 然后您再试一次。 每个字符都与以前完全相同。 最终，您将设法登录。这并不是什么大问题，除非您发脾气轻松地手动进行测试，但是一条简单的消息告知沙箱登录失败的原因将变得更加用户友好。 在自动化测试中，您只需编写代码即可尝试登录，直到在iOS设置的“沙箱帐户”部分中显示用作登录的电子邮件地址为止，这表示登录成功。 这不是测试人员无法忍受的事情，但是Apple解决该问题将大大改善iOS开发的工作经验。
隐秘著作 (Cryptic writings)
Problems arise when notifications informing that a particular Sandbox user is subscribed to an auto-renewable subscription are not delivered by Apple. Therefore, many subscription purchase attempts have to be made to actually make sure whether the development of the app went the correct way and it’s just Apple’s own system’s error, not a bug inside the app.
当Apple未交付通知特定沙盒用户已订阅自动更新订阅的通知时，就会出现问题。 因此，必须进行许多订购购买尝试，才能真正确保应用程序的开发是否正确，这仅仅是Apple自身系统的错误，而不是应用程序内部的错误。
Speaking of errors — during testing of in-app purchase features, it can become really difficult to point out to developers what went wrong to help them debug the problem. Errors displayed are very cryptic and long; therefore, investigating the root cause of the problem can consume a substantial amount of time. There are two main reasons for that: there’s no error documentation created by Apple for those long error messages or the message displayed is very generic.
谈到错误-在测试应用内购买功能期间，很难向开发人员指出出什么问题来帮助他们调试问题。 显示的错误非常隐蔽且很长。 因此，调查问题的根本原因可能会花费大量时间。 造成这种情况的主要原因有两个：Apple没有为那些较长的错误消息创建任何错误文档，或者所显示的消息非常通用。
Combining this with problems which include performance drops in ‘prime time’, problems with receiving server notifications, e.g. for Autorenewing Subscriptions or simply inability to connect to iTunes store and a simple task of testing monthly subscription can turn into a major regression testing suite.
将其与包括“主要时间”性能下降，接收服务器通知(例如，自动续订)或仅无法连接到iTunes Store的问题以及仅测试每月订阅的简单任务之类的问题相结合，就可以成为主要的回归测试套件。
喂Siri (Hey, Siri…)
Another issue with Sandbox testing that is not so convenient to work with and not so obvious to workaround are the irritating Sandbox login prompts. These occur randomly for the eternity of your app’s development cycle if the In-app purchases feature in the app under test includes auto-renewable subscriptions. What is problematic is that these login prompts pop-up at any given time, not just when the app is used or dropped to the background. Well, if you’re patient you can learn to live with it and dismiss it when it shows up. But problems may occur when the device used for testing said app is also utilized as a real device in automated tests, e.g. in conjunction with Appium.
沙盒测试的另一个问题是，沙盒登录提示令人讨厌，它操作起来不太方便，解决方法也不太明显。 如果被测应用程序中的应用程序内购买功能包括自动续订，则这些更改会在您应用程序开发周期的永恒中随机发生。 有问题的是，这些登录提示会在任何给定时间弹出，而不仅仅是在应用被使用或掉入后台时弹出。 好吧，如果您有耐心，您可以学习使用它，并在它出现时将其关闭。 但是，当用于测试所述应用程序的设备也被用作自动测试中的真实设备时，例如结合Appium，可能会出现问题。
This can be addressed by setting up Appium properties in testing framework to automatically dismiss system popups. That could prove somewhat helpful if the test suite doesn’t include any other interactions with system popups. Deleting the application which includes auto-renewable subscriptions from the device gets rid of the random Sandbox login prompts on the device, but that’s not how testing works. Another workaround might be building the app with subscription part removed, which requires additional work on developers’ side. These login prompts are surely a major problem which Apple should address.
这可以通过在测试框架中设置Appium属性来自动关闭系统弹出窗口来解决。 如果测试套件不包含任何其他与系统弹出窗口的交互，那可能会有所帮助。 从设备上删除包含自动更新订阅的应用程序会摆脱设备上随机出现的沙盒登录提示，但这不是测试的工作原理。 另一个解决方法可能是在删除订阅部分的情况下构建应用程序，这需要开发人员方面的其他工作。 这些登录提示肯定是Apple应该解决的主要问题。
发送增援 (Send reinforcements)
Despite all that, developers and testers alike can and eventually will get through the tedious process of developing and ensuring the quality of in-app purchases in Apple’s ecosystem. A good tactic for this in manual testing is to work out a solid testing routine, which will allow for quicker troubleshooting. Being cautious about each step in the testing scenario and monitoring the environment differences such as being logged in with proper Sandbox account instead of regular Apple ID, an appropriate combination of app account and the Sandbox account or the state of the app in relation to purchases made (whether an In-app purchase has been made within a particular installation or not) is key to understanding whether the application does what is expected and transactions are successful.
尽管如此，开发人员和测试人员都可以而且最终将通过繁琐的过程来开发和确保Apple生态系统中应用内购买的质量 。 在手动测试中，这样做的一个很好的策略是制定一个可靠的测试例程，以加快故障排除的速度。 请谨慎对待测试场景中的每个步骤并监视环境差异，例如使用正确的Sandbox帐户而不是常规Apple ID登录，应用程序帐户和Sandbox帐户的适当组合或与购买相关的应用程序状态(无论是否在特定安装中进行了应用内购买)，对于了解应用程序是否符合预期以及交易是否成功至关重要。
While Silicon Valley’s giant rises in the mobile market again, more and more ideas will be monetized in Appstore, making profits not only for the developers but also directly for Apple, which collects a hefty portion of the money spent on apps and paid extras. Let’s hope that sooner than later Apple will address the issues that have been annoying development teams for years now and make their jobs a bit easier.
硅谷的巨人再次在移动市场中崛起时，越来越多的想法将在Appstore中货币化，不仅为开发者带来利润，而且为Apple带来直接利润，Apple收取了在应用程序上花费的大部分钱，并支付了额外费用。 让我们希望，Apple迟早会解决多年来困扰开发团队的问题，并使他们的工作更加轻松。
Sources:
资料来源：
Originally published at https://grapeup.com on August 7, 2020.
最初于 2020年8月7日 发布在 https://grapeup.com 上。
翻译自: https://medium.com/swlh/in-app-purchases-in-ios-apps-a-testers-perspective-aa89b920be5f
ios web应用程序
899
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
