[转]移动App测试中的最佳做法

Daniel Knott 用过各种不同编程语言和软件质量保证工具。他在软件开发和测试方面干了七年，自2010年起，他一直在德国汉堡的XING AG公司就职，几个项目里，比如XING调查和XING建议，他负责测试管理，测试自动化和测试执行。Daniel现在是XING移动和XING API团队的质量保证团队负责人。在XING移动团队中，他还负责XING安卓和iPhone Apps的测试管理和测试自动化。Daniel在包括像Robotium， KIF (Keep It Functional)， Selenium and Java一类工具的软件测试自动化方面经验丰富。他还在各类敏捷大会上作了陈述且定期发表到他的博客上和XING博客上。

 

　　一提到软件测试，测试员基本想到的就是去检查文件，功能，API，性能并确定软件是否安全，以及关于软件特定部分的其他事项。而对于移动测试，测试员不得不基于用户移动使用模式考虑移动相关的功能。
　　本文是基于我的工作经验而写的。作为一名敏捷软件开发团队的软件质量保证经理，我一心投入iPhone， Android， Windows Phone 7的移动apps和移动web apps。在XING移动团队的日常工作以及与其他移动测试专家交流的过程中，我深刻了解了移动测试工作的困难。渐渐地，我明确了什么是帮助改进同事们和我的测试工作并为用户提供更高质量app的移动最佳做法。

　　功能测试
　　每项开发的新功能都需要进行测试。移动app测试中功能测试是一个重要方面，移动测试员应该要进行手动测试和自动化测试。刚开始测试时，测试员必须把移动app 当做“黑盒”一样进行手动测试，看看提供的功能是否正确并如设计的一样正常运作。除了经典软件测试，像点击按钮看看会发生什么，测试员还必须执行更多功能的移动设备专门的测试。
　　如今，现代移动设备都有触摸屏，要求多点触控动作来与它们互动。设备可以是纵向或横向显示屏。它们提供动作，倾斜和螺旋传感器。它们有不同的接口可以连接其他设备或服务，比如GPS，NFC，照相机，LED等等。
　　移动软件测试员必须确保app的所有特定设备功能在app里都能用。移动设备的种类这么多，测试时要将所有的覆盖是不可能的，所以功能测试时测试员要专注于他们app的关键之处。什么是真的简单有效的呢？设备旋转。我测试工作期间发现有许多bug仅需将设备从纵向旋转为横向再旋转回来就好了。
　　除了整个手动测试过程，测试自动化对移动app也很重要。每个代码变化或新功能都可能影响现存功能及它们的状态。通常手动回归测试时间不够，所以测试员不得不找一个工具去进行自动化回归测试。现在市面上有很多移动测试自动化工具，有商业的也有开源额，面向各个不同平台，如Android，iPhone，Windows Phone 7， BlackBerry以及移动web app。根据开发策略和结构，质量保证专家需要找出最适合他们环境的自动化工具。
　　安卓的话，就有Robotium[ROB01]， Robolectric [ROB02]， Roboguice [ROB03]， MonkeyTalk [MON01]，Monkeyrunner [MON02]， NativeDriver [NAT01] and Calabash for Android[CAL01]等开源工具。自动化工具Robotium已经变成开源界的实际标准。它用起来很简单且是基于安卓测试设备的。
　　iPhone的测试自动化工具包括KIF (Keep It Functional) [KIF01]，UIAutomation [UIA01]， MonkeyTalk [MON01]， Calabash for iOS [CAL02]，Frank [FRA01]， Zucchini [Zuc01]等等。所有这些工具也可以在设备或iOS模拟器上模拟真实用户互动。选择一个工具对测试自动化并不容易，但做决定时有一点要牢记，因为很重要: 测试自动化应该使用同样的编程语言作为产品代码。如果测试和产品代码用一样的语言去写，那对测试员和开发员都有好处，因为这就使得他们做配对代码时可以轻松些。测试员可以和开发员在同一水平进行交流，他们可以执行测试和产品代码的代码审查。对于测试自动化，开发员可以用他们习惯的语言编写他们自己的脚本。

　　总结：
　　▪▪把app作为“黑盒”进行测试并试着中断它。
　　▪▪打开移动app的每个屏幕并将设备从纵屏变为横屏再变回纵屏。
　　▪▪别忘了去测试设备特定的功能，比如传感器和通信接口。
　　▪▪为移动app编写测试自动化脚本。
　　▪▪选择一个适应公司策略和结构的测试自动化工具。
　　▪▪测试和产品代码应该用同一种语言。

　　非功能测试
　　移动app测试的另一重要方面是移动app的非功能需求。移动app在推出市场或进行进一步开发前，移动测试员有许多需要测试的问题。
　　早期开发阶段要进行的第一个测试应该是实用性测试。通常是由alpha用户或同事进行的。走进一家咖啡馆或餐厅，问问里面的人他们的app使用情况。让他们看看现阶段开发的第一个版本并收集反馈，看看用户是否能很好地使用新功能，以便得出第一印象。
　　检查app的性能。将推出的版本与当前版本做一番比较，看看性能是一样？更好？还是更差？将app安装到旧的设备上，看看该app在旧设备上是否仍能运作，无论硬件设备好或差。最先进的设备也一样要这么做。
　　测试电话，短信，彩信，微博或其他通知进来时app的反应。使用app时检查一下电量。确保测试过程测试设备是充满电的并每十分钟检查一下电池使用情况，看看该app有没有太耗电。在低电量时把app安装到设备上看看会发生什么。检查app的内存使用情况。如果app在本地文件系统中存储数据，测测不同内存卡的使用情况。想想看本地存储快满时会发生什么呢——app会崩溃或弹出出错提醒框来通知用户吗？
　　测试app的安装和删除过程。更重要的是，测试从老版本升级为新版本的过程。或许本地数据库已经改变了，这样就会引起一些严重的迁移问题。
　　App被本地化了吗？测试员需要用不同的语言测试app。记得在不同的网络载体上以不同的网速进行测试。确定该app在GPRS， EDGE， UMTS， LTE和WiFi环境下都能运作。
　　别忘了检查网络连接不好或完全掉了时app会怎么反应。飞行模式下使用该app看看如果一个请求失败了会发生什么。将测试设备连接到电脑上并检查开发日志文件有没有例外、警告或其他奇怪的异常之处。这些只是移动测试员和开发员开发和测试一个app时应该考虑的非功能需求中的一部分。每方面都检查到位是绝不可能的，因此整体团队应该支持QA成员尽量覆盖更多方面以防用户得到不好的体验。 

　　总结：
　　▪▪做实用性测试。
　　▪▪比较app已推出版本和新版本的性能。
　　▪▪检查电话，短信，彩信或微博或进来时app的反应。
　　▪▪检查测试设备的电量。
　　▪▪测试app的内存使用情况。
　　▪▪安装并删除app。
　　▪▪测试从旧版本升级到新版本的过程。
　　▪▪检查语言的转换。
　　▪▪在不同的载体和网络连接，如GPRS，WiFi， or LTE，环境中使用app。
　　▪▪检查日志文件的错误或例外。

测试设备——碎片
　　对于一个移动质量保证者来说，关于移动测试设备的关键问题是，“测试该用哪个工具比较好呢？”这个问题必须解决，因为无法在每台设备上都测试一遍！就此来看，移动设备市场上有两大玩家：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版本获得早期反馈。

了解顾客
　　如果开发员和测试团队了解以后将会使用app的顾客的话，移动测试就会更加有效。收集顾客信息的好地方是特定供应商的app商店（Apple App Store， Google Play Store， Windows Marketplace等）。如果一个团队在这些商店中已有了一款app，他们就会获得关于顾客使用的设备，软件版本，语言以及载体的信息。下面图2是Google Play Store的实例，展示了一个已发布的安卓app的数据。而移动网页，却没有app商店提供相关用户数据。所以，收集关于移动网页里所使用的“用户代理”（设备，浏览器）的信息就有意义了。意识到这点，团队就可以优化各种设备和软件版本并减少花在开发和测试它们上的精力了。

 图2： Google Play Store关于使用的安卓设备和OS版本的数据

　　除了用户数据，app商店里的顾客评论也需要细细整理以便收集重要的反馈以及他们对新功能的期待，并对所报bug做出回应。

　　总结：
　　▪▪了解你的顾客所使用的设备和软件版本
　　▪▪利用来自供应商市场的数据
　　▪▪认真对待app商店里的评论

　　在论坛社区主动出击
　　这是最后一个最佳做法，它与日常移动测试工作不直接相关，但或许可以帮你从不同的角度思考并获得新的想法。
　　在社区里做一个主动积极的软件测试员，就像：
　　▪▪ utest (www.utest.com)
　　▪▪ mobileqazone (www.mobileqazone.com)
　　▪▪ softwaretestingclub (www.softwaretestingclub.com)

　　在这样的社区里，软件测试员可以和其他（移动）质量保证专家就各种测试话题交流观点意见。他们可以共享知识，帮助其他人解决他们遇到的问题。测试员可以在写测试用例时得到很棒的想法：关于如何写出好的bug报告，并且还可以提高他们自己的测试和测试自动化技能。