做移动互联网 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 必定会崩溃
掉。
3、进行网络异常、服务器宕机或出现 404、502 等情况下的测试
- 1
- 2
前往页