作者：陈庆 | QE_LAB
最近在项目上做移动 APP 的测试，与任何应用程序一样，移动 APP 测试也非常重要，因为用户更希望使用一个稳定、易用且没有错误的应用程序以使他们的工作和生活更轻松。同样的，有错误的产品往往得不到用户的青睐，甚至有可能导致用户损失、法律问题或品牌形象受损。然而在移动设备上测试应用程序往往也更具有挑战性。
比如：
等等
我们都知道测试的类型分为很多种：功能测试、性能测试、兼容性测试、界面/易用性测试、安全测试等等。虽然我们的期望是尽量覆盖所有的测试，但实际情况往往是由于时间和资源有限，以及个人经验的不足，导致我们可能无法覆盖到测试的方方面面，这里记录了一部分可能容易被忽略的测试场景供大家参考。
我们可以利用 Charles 等抓包工具捕获 APP 测试过程中发生的所有请求，在此过程中我们可以观察到更多的异常，它可以帮助你了解业务端到端的流程，了解 UI 背后都发生了什么，让你有更多的想法和测试场景。
案例：
那么，我们应该忽略它吗？
我们不应该。它虽然对用户界面没有任何影响，但它可能是一个未来的隐患，一定要跟 dev 团队沟通清楚我们为什么要这么实现，团队应该达成一致排除可能存在的隐患。测试不应仅限于探索移动应用程序和记录错误。作为 QA，我们应该了解我们向服务器发出的所有请求以及我们从中得到的响应。
考虑到此产品面向的用户大多数是国外用户，在国际化/本地化测试过程中，在除了语言，还需要考虑地域 (region，locale), 涉及到的一个重要场景就是数据格式的显示，不同地区在诸如货币、时间上显示的格式会不同，例如以下是我在 iOS 设备上修改了国家地区之后，iOS 给的区域格式示例，可以看到金额显示的区别。
中国大陆地区：
法国地区：
另一个场景就是键盘布局可能不同，例如以下是我截取的 APP 键盘布局，请注意小数点的区别哦！
中国大陆地区：
法国地区（改成法国地区后，小数点变成了逗号）：
我们了解到不同语言地区的区别后，还需要结合具体业务需求，像我们的业务就不需要跟随语言和地区做翻译和格式转换，那么就要保证切换语言和地区后，数据格式等一切都保持不变并且功能正常可用。
这里举个例子，用户反馈了这样一个 bug，说已经设置了 Face ID 登录，但是偶尔会不可用，提示要重新设置 Face ID，但是重启 app 之后就又变成正常了。我用自己的测试设备试了无数次，都无法重现。我在想，难道跟设备有关？但是遇到此问题的用户还不止一个。说明这个问题出现的概率还挺大的，那我一定是忽略了什么。无法重现问题，开发人员也不好定位问题出在哪。
看来还是得从用户出发，详细了解他在此过程中做了哪些操作。可是用户往往也记不清自己做了什么操作，但是还是从用户那得到了一个很重要的信息，那就是用户点击了消息通知。想一想，真实的用户场景会是什么呢？
那很大可能就是用户收到了一条通知消息，于是想点进去看：
第一步：kill app
第二步：锁屏
第三步：收到一条 push 通知
第四步：点击 push➡️调起 APP➡️触发 Face ID 登录
重试几次之后，问题果然复现了。以前我一直在默认执行一些测试用例，但是却忽略了真实用户会怎么使用。跟开发人员沟通完后，才了解到原来通过点击 push 调起 APP 的时候，可能会遇到 keychain 里保存的数据还是受保护的状态，而当前的实现方案无法获取到受保护的数据所以造成了 Face ID 获取失败。
问题水落石出，但是我们还需要继续思考一下，除了 Face ID，keychain 里存了那么多数据是不是都会存在类似问题呢？那就需要开发人员再逐一排查一下避免更多问题的产生。此后也需要更多的覆盖此类测试场景。
我们常常遇到一些业务功能和时间相关，比如某个功能只在某个时间段内生效等，不知道大家在测试功能的时候有没有想过这个时间是取用的设备本地时间还是服务器端时间。
这里列举两个例子：
a. 应用程序需要显示您上次登录的时间。
b. 应用程序有个授权功能，发起授权后有效期在 100 秒内，超过 100 秒后操作就会失败。
真实用户的设备是五花八门的，会出现不同的时区，甚至有些设备时间也有可能不准确，为了提高用户体验减少投诉，因此建议开卡之前可以先跟需求方或开发人员一起在对齐需求的过程中，将这些疑问抛出来，因为很多时候 AC 里并不会写的这么详细，各方都达成一致后，再进行代码开发。
测试路上任重道远，测试场景无法穷举，bug 分析为什么如此重要，一是有助于持续改进我们的测试策略，优化我们的测试用例。二是有助于我们更好的了解系统内部逻辑、数据处理流程等，如此才能更好的评估 bug 修复所影响的测试范围。
