测试设备——碎片
　　对于一个移动质量保证者来说，关于移动测试设备的关键问题是，“测试该用哪个工具比较好呢？”这个问题必须解决，因为无法在每台设备上都测试一遍！此来看，移动设备市场上有两大玩家：Android和iOS!但是因为地理位置的原因，一些其他平台也常用到。有Windows，BlackBerry， webOS， SymbianOS， 以及功能机。图一的表格中列出了中国、德国以及美国供应商提供的智能机操作系统的使用情况。

图一：智能机操作系统
数据来源：www.thinkwithgoogle.com/mobileplanet/en

　　几乎每个平台都有不同的供应商在售卖拥有不同硬件，软件规格和定制用户界面的智能机。比如安卓，有像Samsung， HTC， ASUS， LG， Motorola， Sony， Huawei等供应商。这是设备碎片的一个重要例子，且要找到恰当的测试设备真的很难。移动网页是另一个相当难搞的问题，因为移动浏览器种类太多，如：Safari， Opera Mini，Dolphin， Android and RIM native， Google Chrome， Firefox， Internet Explorer9以及其他功能机浏览器！那么到底该选什么测试设备呢？用新的浏览器版本吗？把市场上的每种设备都买来？还是使用模拟器？
　　在此对模拟器小注一下：别用模拟器测试！它们或许对基本测试有所帮助，但其结果与真机上的结果却是不同的。
　　以我之见，解决这个测试设备问题的一个不错的主意是将设备和浏览器组合起来。比如，移动测试员可以根据他们的硬件和软件规格将设备组合起来。每个组合确定一个优先事项，比如A=高，B=平均，C=低。每组都包含根据平台和供应商分配到那一类的设备。
　　可能的组合概述：
　　▪▪组1，优先事项C：CPU和RAM小，分辨率低的小设备。旧的软件版本和浏览器
　　▪▪组2，优先事项B：一般CPU， RAM<512 MB， 显示屏大小和分辨率好的中档设备。软件不是新的。
　　▪▪组3，优先事项A：双核/四核CPU， RAM>512 MB， 分辨率高的设备。新的软件版本。
　　这三组涵盖了一个特定平台上的绝大多数用户，也代表了市场上适合这一组的其他手机。这可以减少开发和测试过程中要求的工作。

　　总结：
　　▪▪组合并选出优先测试设备和浏览器版本。
　　▪▪不要用模拟器进行测试。

　　组合工具
　　正如之前所提到的，移动测试员必须对移动app进行测试自动化以保证代码变化不会影响现在的功能。另一个佳做法是组合测试工具并将它们集成为一个连续的集成服务器以便从中心开始执行这些工具。开发员需要为他们的代码写单元测试以确保每个细小的组件的且如期运作。另外，使用像Robotium或Keep It Functional一类的工具进行端到端的检查测试，像用户一样，很有用。

　　总结：
　　▪▪组合测试工具并将之集成为一个连续的系统。

　　内部Beta版本
　　如果一个移动团队想要早点与移动app的beta测试员沟通，他们可以创建他们自己的内部app商店，比如安卓的和iPhone.的。有了hockeykit [HOC01]工具，团队可以通过公司WIFI把app的新版本传给同事。这是从同事那获得重要反馈的有效方法，尤其是如果团队或测试员没机会向外界展示该app。Hockeykit也提供关于怎样测试该app以及同事们用了哪种OS版本和设备的有用数据。它还包括一个crash reporter以便看到导致现开发版本错误和崩溃的原因。

　　总结：
　　用内部beta版本获得早期反馈。