测试金字塔新解之移动无线应用测试(2)

控件显示 现在往往很多测试说测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等系统架构或其他特性上的区别了。

　　我个人是认为移动无线应用的金字塔理念不仅仅适用于功能测试，更多的也适用于压力、性能、自动化甚至安全等测试中。当我们需要加大测试颗粒度的时候，那么借助分层的理念往往能够让我们豁然开朗，找到新的突破口。

原文转自：http://www.testwo.com/article/89