这里有五种最常见的移动应用程序测试错误方式以及如何去做的例子。
　　1. 公测
　　当应用程序进行公测，开发商发布警告，启动程序，看发生什么。但本质上，实际用户做了beta版的测试者。
　　为何要避免
　　有几个理由可以说明公测是危险的，首先，你无法控制用户体验。你只是发布了一个应用程序，但是不知道如何响应客户动作，网络环境以及市场需求。
　　这是一个巨大的风险，如果你的用户体验糟糕的话，你的应用程序口碑和你的品牌形象都会受到伤害。
　　其次，公测没有一个系统的方法来记录和解决问题。即使再忠实的客户也不可能让他们用一致的方式报告崩溃和其他问题。
　　一些开发商用雇佣测试人员来为他们的应用程序做出反馈，来作为变通手段。
　　那么问题是？
　　所有的应用程序测试者，无论是有组织的用户还是众包雇员，都是在不受控制，可变条件下使用应用程序的。导致在德国连接3G网络死机的原因与在巴西使用LTE导致死机的原因并没有什么关系。
　　所以不要把你的程序抛在那些有可能你无法跟踪发生了什么的地方，更不用说解决那些肯定会出现的问题了。
2. 接入点映射
　　欢迎使用接入点映射，一个理论上确实非常好的测试想法。
　　开发商雇佣测试人员（哦哦，我们已经排除了一个坏的开始）来进行公测。
　　但是无论何时何地，测试者都是通过绕特定区域街道开车或步行，来观察在不同位置以及网络中的执行情况，而不是使用应用程序。
　　为何要避免
　　接入点映射要比公测稍微可控，但是条件仍然不理想。
　　即使你雇佣了大量的测试人员在他们自己所在城市和社区进行接入点映射测试，但他们最终用户体验还是对应他们各自的条件。
　　在应用程序使用中涉及的位置，设备以及网络创建的一个个个性化的体验，只适用于这个人在特定的某天时间。
　　换句话说，从在周三下午的托莱多使用3G网络进行应用程序测试的Bob那里收集的任何数据，都不适用于在周三上午三藩市使用Wi-fi连接网络的Suzie。
　　接入点映射测试是一个卑鄙的测试方法，因为能感觉到不同条件下真实人的真实数据是不错的，问题是，这些条件不能适用于所有用户，导致这个方法只能是部分有效。
... ...
查看本期杂志更多精彩内容，请点击下载：http://www.51testing.com/html/07/n-3649907.html
4. 忽略抖动
　　在一个移动应用程序测试环境中抖动很难作为代表，静态变量的带宽或延迟更容易创建。因此一些测试淡化抖动值。
　　为何要避免
　　不考虑流媒体需求，冒着严重到令人失望的终端用户体验的风险（更不用说失去潜在的收入和推荐）去测试你的应用程序。
　　当评价应用程序是如何执行的时候，需要考虑两个关键领域：如何让程序自身进行操作以及如何在特定网络上进行程序操作。换一种方式，忽略抖动就意味着忽略网络性能。
　　归功于带宽，视频特别容易抖动，流媒体质量很大程度上受位置，网络类型，服务提供商和其他等因素的影响。
5. 纯功能检测
　　纯功能检测是开发者只测试应用程序那些功能性的元素，并没有将性能纳入到测试过程中去。
　　为何要避免
　　一个移动应用程序的成功不单只基于功能。
　　一个应用程序的功能必须做什么（就是说，当某个功能被选中或者某个按钮被按下时发生什么）。一个应用程序的执行，另一方面，是要做的怎样（就是说，在一个特定网络上使用时要如何快速的反应）。
　　测试当用户发出命令时会发生什么是功能测试，测试应用程序如何快速响应要求，从另一方面是性能测试。