想你的应用程序没有bug? 注意了,近一半的问题都是客户发现的。
为什么不是开发人员发现这些缺陷呢? 都怪糟糕的测试，实际上一些流行的测试策略是会破坏你的应用程序的。
幸运的是糟糕的测试是很容易避免的。这里有五种最常见的移动应用程序测试错误方式以及如何去做的例子。
1. 公测
当应用程序进行公测，开发商发布警告，启动程序，看发生什么。但本质上，实际用户做了beta版的测试者。
为何要避免
有几个理由可以说明公测是危险的，首先，你无法控制用户体验。你只是发布了一个应用程序，但是不知道如何响应客户动作，网络环境以及市场需求。
这是一个巨大的风险，如果你的用户体验糟糕的话，你的应用程序口碑和你的品牌形象都会受到伤害。
其次，公测没有一个系统的方法来记录和解决问题。即使再忠实的客户也不可能让他们用一致的方式报告崩溃和其他问题。
一些开发商用雇佣测试人员来为他们的应用程序做出反馈，来作为变通手段。
那么问题是？
所有的应用程序测试者，无论是有组织的用户还是众包雇员，都是在不受控制，可变条件下使用应用程序的。导致在德国连接3G网络死机的原因与在巴西使用LTE导致死机的原因并没有什么关系。
所以不要把你的程序抛在那些有可能你无法跟踪发生了什么的地方，更不用说解决那些肯定会出现的问题了。
2. 接入点映射
欢迎使用接入点映射，一个理论上确实非常好的测试想法。
开发商雇佣测试人员（哦哦，我们已经排除了一个坏的开始）来进行公测。
但是无论何时何地，测试者都是通过绕特定区域街道开车或步行，来观察在不同位置以及网络中的执行情况，而不是使用应用程序。
为何要避免
接入点映射要比公测稍微可控，但是条件仍然不理想。
即使你雇佣了大量的测试人员在他们自己所在城市和社区进行接入点映射测试，但他们最终用户体验还是对应他们各自的条件。
在应用程序使用中涉及的位置，设备以及网络创建的一个个个性化的体验，只适用于这个人在特定的某天时间。
换句话说，从在周三下午的托莱多使用3G网络进行应用程序测试的Bob那里收集的任何数据，都不适用于在周三上午三藩市使用Wi-fi连接网络的Suzie。
接入点映射测试是一个卑鄙的测试方法，因为能感觉到不同条件下真实人的真实数据是不错的，问题是，这些条件不能适用于所有用户，导致这个方法只能是部分有效。
3. 去带宽
一旦你意识到任何形式的公测都是不可依赖的时候，就是进入实验室模仿在受控环境条件下的真实条件的时候了。
许多开发商以及企业进入测试实验室但是走的不够远，进行所谓什么“部分仿真测试”。仿真获取了一些，但不是所有影响应用的真实世界条件。
为何要避免
部分仿真往往忽略了重要的环境因素，创建不完整的测试并没有捕捉到全方位的用户体验。
考虑到网络带宽，应用程序通常是在静态带宽的条件下进行测试，但现实生活中，带宽却很少是静态的。用户可以在 3G 和 4G 网络，4G 网络和 Wi-Fi 之间互相切换来感受不断波动的信号强度。
延迟也是一个很重要的因素——对于很多应用程序性能这也是主要决定因素。与移动环境的其他方面一样，延迟是高度动态的。这取决于很多因素，如路由器等网络设备间的信号交换，编码技术，和网络协议。
既然现实世界的移动环境是如此的不同，那么在实验室中创建静态条件来测试移动应用程序还有一定价值的。
4. 忽略抖动
在一个移动应用程序测试环境中抖动很难作为代表，静态变量的带宽或延迟更容易创建。因此一些测试淡化抖动值。
为何要避免
不考虑流媒体需求，冒着严重到令人失望的终端用户体验的风险（更不用说失去潜在的收入和推荐）去测试你的应用程序。
当评价应用程序是如何执行的时候，需要考虑两个关键领域：如何让程序自身进行操作以及如何在特定网络上进行程序操作。换一种方式，忽略抖动就意味着忽略网络性能。
归功于带宽，视频特别容易抖动，流媒体质量很大程度上受位置，网络类型，服务提供商和其他等因素的影响。
5. 纯功能检测
纯功能检测是开发者只测试应用程序那些功能性的元素，并没有将性能纳入到测试过程中去。
为何要避免
一个移动应用程序的成功不单只基于功能。
一个应用程序的功能必须做什么（就是说，当某个功能被选中或者某个按钮被按下时发生什么）。一个应用程序的执行，另一方面，是要做的怎样（就是说，在一个特定网络上使用时要如何快速的反应）。
测试当用户发出命令时会发生什么是功能测试，测试应用程序如何快速响应要求，从另一方面是性能测试。
为获得整体应用程序能力的一个三维视图，功能和性能两个都必须进行测试。
你当然希望应用程序功能正常，测试功能而不测试性能将永远得不到你的应用程序可能（或不能）给你的全部画面。正如我们迄今所看到的，整体应用程序的性能很大程度受外界因素的影响，如网络性能。
这就意味着，为创建最准确的测试可能，功能，性能和外部的影响都要考虑在内。
一定要考虑一下的内容：
- 什么网络条件是被虚拟化了的？
- 那些条件是基于实际网络的么？
- 你模拟了多个网络条件了么？
- 你代表的是分布式用户群么？
最后一点至关重要，功能测试往往忽视需要虚拟化不同用户的不同限制条件。
基于云的移动应用程序测试也应谨慎，请记住，功能云测试只是提供一个单一定位视点，并不代表整个用户群。云测试也不能对真实的用户如何在网络上使用应用程序给出准确的画像，因为云连接往往比家庭或者其他网络的速度更快。
要采取哪些措施
所以如果要公测的话，静态带宽测试，部分仿真，纯功能测试要避免。那怎么在往市场推出应用程序前进行准确的测试呢？
1. 做功课
在测试你的应用程序前有很多工作要做。
你首先要非常了解影响功能，性能和用户体验的各种因素。
研究网络条件，基础设施，用户位置，以及一旦开始就需要考虑在内的其他环境条件。
对于如何，何时，何地使用你的应用程序才能帮助你创建一个虚拟的能准确代表真实世界用户体验的测试环境，要有一个彻底的三维理解。
2. 去虚拟
创建虚拟条件包括前一步中发现的所有因素。
创建包含用户在现实生活中所经历的各种各样的变化的虚拟网络条件是非常重要的。
你创建的虚拟网络与功能性能工具应该能够无缝集成，用来进一步提高测试的真实性与可靠性。
3. 分析与优化
接下来是分析你的结果的时候了。寻找功能和性能两方面的故障，以及可以归因于网络故障的任何错误的解决方法。
最后，开发系统来测试分析优化你的应用程序。
做正确的移动应用测试
为了确保你的移动应用程序的性能最佳，关键是要建立一个能准确反映现实世界条件的测试环境。
- 不推出未经事先测试的应用程序
- 不要浪费时间与金钱在接入点映射上
- 请记住现实世界中的带宽是可变的
- 考虑视频网络可能会影响应用程序的功能和性能
- 永远要对功能和性能进行测试
- 深入研究影响你最终用户的环境因素
- 创建三维，真实世界的测试环境
- 分析你的测试结果，并持续优化系统
考虑到在现实条件下你的应用程序的功能和执行，通过仿真所有这些虚拟测试条件，你就可以准确有效的预测你的应用程序一旦推出用户体验如何。
