做移动互联网App，你的测试用例足够吗？

我在面试测试工程师时，经常问到的一个问题是“给出Word另存为这个功能的测试用例”。除开基本的测试用例外，考虑到各种异常情况，例如内存已满、硬盘空间不足是非常重要的。但是针对移动互联网App来说，情况还要复杂的多。

一个重要原则是：测试你最终要发布给用户的App版本。

可能每日构建、每日测试的理念已经深入人心，我们很多时候测试的只是App的开发和Debug版本，而不是最终的Release版本。在打包最终的 Release版本时，我们一般还要加上数字签名，或者再加上代码混淆。那么最终的发布版本和Debug版本肯定有不一致的地方。我们iPhone的 App曾经使用过一个第三方开源库，在Debug版本时完全工作正常，但是正式上线后才发现必定会导致崩溃。这个代价和经验非常宝贵（其实这个开源库的论 坛上已经讨论并警告过这个问题）。我们后来花了许多力气来修正和弥补这个问题。如果在一开始就针对Release版本进行了测试，这样的问题是不会出现 的。

测试网络相关的App，有三个非常重要的最佳实践。

1、2G、3G、wifi都要覆盖

这三者之间不仅仅只是网络速度的差别，它们代表了三种不同的网络环境。另外你可能没有想到一种特殊的情况可以用它们来测出问题：开发环境和生产环境。

一个有经验的开发团队会在内网搭建测试环境来进行开发时的测试，在上线时将配置切换到线上的生产环境。这个切换应该是在发布流程中需要Check的一个环节。但是，我们有可能遗漏。

所以这个测试用例可以用来防止这种情况的出现，在wifi下内网环境可以work fine，但是2G和3G就不行，只有真实的环境下2G和3G才能正常工作（想想2G和3G是否可以正常访问http://192.168.1.xxx这样的地址就可以了）。

2、HTTP、HTTPS都要覆盖

许多App和后台服务都是通过HTTP来交互的，正常情况下都一切正常。为什么需要测试HTTPS环境？在一些免费上网的环境中，例如在麦当劳、星巴 克里，它们的网络环境都要输入用户名和密码，通过SSL认证来访问网络。如果你使用HTTP Client的library对这种异常没有做捕获处理，那么你的App必定会崩溃掉。