在看过吴穹对2014年测试的展望之后真的对于移动无线测试的未来大有信心。在文章中再次看到了熟悉的“测试金字塔”，该金字塔是分层测试思想的重要钥匙。我自己是移动互联网出身的测试，所以突发奇想从移动无线应用的测试角度重新来审视了下该金字塔并做了扩展，希望对于大家有一定的帮助。
首先我们先来看下经典金字塔，如下图所示：
这对于传统互联网的测试而言非常清晰的一个层次结构，但我相信对于很多移动互联网的同学们而言也许就多少有些迷茫，这不单单是因为技术上的实现不同于以前，也有些是名词定义问题。经过我思考之后，发现发现移动互联网的应用测试角度出发可以从该图上拆分出很多的东西，并且图还有些小小的变化，如下图所示：
单从这个图上来看的话的确是比较迷惑的，那么我们接下来就一层一层来剥，以下内容很黄很暴力，大家做好准备了吗？
我们先来说第一层：UI层。UI层顾名思义就是用户看到产品时候所长的样子，从技术实现角度而言，那就是产品的一层皮。那么UI层在移动无线应用的测试中分成哪些主要的部分呢？
1.用户体验
2.控件显示
3.功能交互
4.代码接口
5.用户体验
移动互联网应用是一款产品，相对其他类型的产品而言，其用户体验已经到达了举足轻重的地步，在我的新书《大话测试——移动互联网应用测试指南》中有单独阐述用户体验的一个章节，有兴趣的朋友可以等出版之后仔细阅读。
现在各个公司也出现了大量的和用户体验相关的岗位，比如“产品体验师”、“产品设计师”、“交互设计师”等，也越来越说明着用户体验对于移动无线应用的重要性。
很多人觉得用户体验好就是一定要画面优美，交互酷炫，界面上没有出现明显的瑕疵就可以了，虽然没有错，但这些仅仅是用户体验的表面一层。我们来看下以下的几个例子。还是那句老话，也许你觉得他们的成功或失败与用户体验关系不大，但其实从移动无线应用能够成功的情况来看，用户量、用户黏性才是最主要的，这些归根结底还是用户体验。在我的书中着实已经吐槽了非常多的应用了，在这里就再吐两个大家都认识的、知名度很高的应用。我们使用无线应用的时候难免碰见网络不好的情况，这也是现在大量测试工程师正头疼的事情（幸好fiddler和Charles能够为我们解决这个问题），但我相信如果我们在网络不太好，却看到以下界面显示的时候，肯定恨不得想摔手机。
也许我不说，大家也能够猜得出来是哪家的应用了吧。我几乎每次在餐馆想要使用一些优惠券的时候就会看到这个界面，恨之入骨。难道网络慢弹出个提示就那么难吗？难道为用户考虑一下就那么难吗？你能够告诉我“createorderxxx”这串外星文用户真的认识是什么吗？所谓用户体验好，就是要让用户觉得应用在说“人话”，而不是“火星语”。你采取如下方法都比现在的做法好：
可以选择在用户点击的时候就向服务器做请求，此时并不跳转界面，短时间超时之后给出一个“网络差”的提示
可以选择进入这个界面，但不要给用户看到“火星文”，短期超时之后再给出一个“网络差”的提示，并自动返回上一页
说着说着我的火气就上来了，不过还有更可气的了。我们来看下面这个应用的行为。
硕大的logo，这个是什么场景呢？现在支付宝和“喜士多”、“7-11”等多家便利店合作了，不但方便了大家的购物，同时也减少了零钱和假币的流通，的确是个大好事。便利店网络不好的情况也尤其多，当我选择好了很多商品，最后拿出支付宝，看到这个鸟样，我心里真的千万只草泥马奔过。但此时想想没有关系阿，我作为iOS高大上的用户可以杀进程，于是我熟练的杀掉支付宝的进程再次打开，事实证明我无法改变这个鸟样。我真的很焦虑，我知道支付宝要联网，但它不是一个网游吧，为什么没有网你就不能让我打开呢？我真的觉得让我看到一个进入的界面或者设置一个短时间就超时都比我看着一坨黑色上面有个“菊花”强数百倍吧，于是，我的手机真的被我摔坏了。
控件显示 现在往往很多测试说测UI了就是拿过来看看界面显示对不对，所谓UI Automation也就是模拟用户的操作，但是真的仅仅只是如此吗？Android的应用界面一切都是以View来构成：
请问有多少工程师关心过这些所谓的界面上的控件显示的到底对不对呢？像素值和比例与需求一致吗？我们一般可以通过三步来解决这个的问题。
A． 先验证每个界面显示之后控件是否存在
B． 再验证这些控件具体的位置、大是否正确
C． 最后验证整体显示是否正确
其中B可以使用如下所示的这个类来验证：
而C的话我更偏向于自己去写，而不是用MonkeyRunner自带的图片对比方法，其精准度不高，很难判断图片是否真的有细小的差异性，我自己更偏爱用PIL库。iOS的话Xcode也自带了Inspector可做相关验证。
功能交互
手动测试，自动化的话可用框架太多。Robotium，Instrumentation，Appium，这里不多做解释。
代码接口
某些应用往往逻辑很复杂，但界面却很简单明了。其复杂程度体现在它的逻辑和数据场景。这类情况对于测试工程师而言尤其的痛苦，那么自然我们就可以跳过界面层来做功能代码的接口测试。
接着我们来说下Service层。与传统金字塔描述的Service不同的是，移动互联网的应用同时存在“Service”和“Inner Service”（感谢晋恒温提供这样一个我觉得很不错的新词）这里的Inner Service主要指的是Android基础组建里面也有一个叫Service
这里提到Inner Service这个概念就是为了和服务器端的Service区别开来。在这个金字塔中Service被虚线所区分开，原因有两个：
Service不再单纯的指后台服务器的Service
不是所有应用都有Inner Service或者Service
其中后台的服务Service测试方法已经相对成熟，参考的资料也相对多，而Inner Service的测试相比困难很多，除了监听Service是否正确启动以及反馈之外，还有很多测试细节可挖掘。
最后就是共同的Unit了。其实我们拨开金字塔的上面几层，到Unit test的时候就已经和应用所在的平台的特性关系不大了。Android使用Junit Test，iOS使用Xcode自带的OCunit，WP使用Windows Phone Toolkit Test Framework等。除了编写测试用例的语言不同以外，其用例的设计方法等已经不再去考虑Android、iOS、WP等系统架构或其他特性上的区别了。
我个人是认为移动无线应用的金字塔理念不仅仅适用于功能测试，更多的也适用于压力、性能、自动化甚至安全等测试中。当我们需要加大测试颗粒度的时候，那么借助分层的理念往往能够让我们豁然开朗，找到新的突破口。
最新内容请见作者的GitHub页：http://qaseven.github.io/
