关于移动端近我相信越来越多的测试人也觉得已经不仅仅是客户端的测试了，如我2012年说的，移动测试和传统测试是分不开的。随着移动互联网的发展，rom硬件层出不穷，比如近老罗大张旗鼓发布的“锤子”手机。应用本身从“单机游戏”慢慢的转化成了“网络游戏”。其实各种都能够看得出其中的猫腻。

　　将来的HTML5 web app我们暂且不谈，毕竟现在只是趋势。而现在大部分的网络应用又该如何测试呢？测试本身是在段时间内要抓住要点以及核心功能，对于移动端来讲首当其冲的是要真正的去用，去用核心功能，去体验核心功能的用户体验。在这一点上面，我还是那句话，不要去想什么自动化，不要认为自动化是神！别的领域我不说，移动互联网来讲，用户体验说明了一切。当然，这里的体验不仅仅说的是UI，交互，还有很多。

　　对于CS架构的应用来讲，其核心功能（我们先假设obc或者java反应到UI层是正确的话）基本都存在于服务器。当然，很多测试也会说，服务器的测试会有专门服务器的测试人员来做。这里又说到曾经我一篇文章提到的“使用代码这样一个工具为黑盒测试服务”的思想了，并且我坚信，这点黑盒工程师肯定比白盒工程师做的更好。

　　那么问题是我们到底怎么测试呢？我先举个简单的例子，假设有一个应用是进行数字的计算，其计算的过程通过服务器的api然后传到客户端，由客户端的UI层再反应出来。那么在这个例子中计算本身是核心的功能价值。那么我们可以这样做。假设服务器端的代码如下：

　　那么我们可以绕过客户端进行测试，如：

　　本例子中进行了一个api的简单的测试，不难得出一个结论，算这个测试通过了其实也不能说明客户端的行为是正确的。的确，但是当面对一个逻辑很复杂的应用的时候，从逻辑上进行黑盒的测试远远比从UI层测试来的方便并且可行的多。那么我们不难得出以下结论：

　　假设我要测试一个新浪微薄的应用，我会进行以下步骤：

　　1、模拟用户登陆

　　2、模拟各种用户行为（比如发布照片，文字，链接，表情等）

　　3、模拟自己登陆，模拟自己的好友登陆，模拟非好友登陆

　　4、分别经过3的登陆之后去检查照片，文字，链接，表情等是否发布成功

　　....

　　以上我们可以看出这样的测试和单元测试本质上的区别。移动端的测试依然要测试，而核心功能可以通过这样的测试保证逻辑是正确的，至少客户端从服务器得到的信息不是错误的，那么一旦客户端这里出现不正确的现象那么必然是客户端的问题。这样既能够更好的定位问题，又能够在长期的项目中减少regression bug。