目录服务器
各类兼容性,多种分辨率, 多种异常状况。 会让移动APP上的测试更复杂。网络
移动互联网开发节奏很快,并且版本快速迭代, 建议彻底放弃传统的Tese Case, 不须要写详细的测试用例。 而采用feature list.app
好比使用思惟导图工具+功能点 的方法。 这样能节省大量的时间。 并且思惟导图比较直观,不容易漏掉功能。工具
大部分移动APP都是面向普通用户的,而不是企业用户。 要让本身成为APP的真实用户, 这样完全了解业务逻辑,测试
用户体验式APP成功的关键, 在这么小的屏幕上,用户体验关系着用户对APP的满意度ui
UI自动化大部分的时候,都没什么意义,投入大,收入少。 应该多关注后台借口的自动化测试设计
每日构建,每日测试的理念已经深刻人心, 不少时候咱们测试的是App的开发和Debug版本。 而不是最终的Release版本, 在打包最终的Release版本时。 咱们通常还要加上数字签名,或者再加上代码混淆。那么最终的发布版本和Debug的版本确定有不一致的地方。 极可能最终的版本会有问题。 好比Debug版本是彻底工做正常,可是上线后才发现会致使奔溃接口
许多App和后台服务都是经过HTTP来交互的,正常状况下都一切正常,为何须要测试HTTPS环境? 一些免费上网的环境中,好比,麦当劳,万达商城,他们的网络环境都须要输入用户名和密码,经过SSL认证来访问网络。 若是你使用HTTP Client 的Library对这种异常没有作捕获处理,那么你的APP,确定要奔溃。开发
后台服务的稳定性是你有时候很难去控制的,尤为是牵扯到DNS,空间服务商的状况下。 若是出现DNS解析故障,碰到这种状况,你对后台API的请求极可能就会出现404错误, 而你和API交互的数据应该是某种固定格式例如JSON和XML,这样你的数据解析好比会出现错误,抛出异常。若是你对异常没有进行正确的处理可能会致使程序不能正常工做。get
这四者之间不单单是网络速度的差异, 它们表明了不一样的网络环境。 常常会有些APP能在3G网络下运行,可是不能在wifi下运行。因此在须要check在不一样的网络环境。
一旦你的应用出现严重系统错误, 你修复版本基本不可能在很短期内在App Store上架。 那么你的用户就会离去。