标签:
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。
??检查日志文件的错误或例外。
标签:
原文地址:http://www.cnblogs.com/daxiong2014/p/4415613.html