MQC功能测试大揭秘

最新推荐文章于 2024-07-04 14:53:16 发布

dicyt

最新推荐文章于 2024-07-04 14:53:16 发布

阅读量1.2k

点赞数

摘要：对于安卓自动化测试来说，功能测试是最基本也是最常用的方案，那么功能测试到底能做什么？有什么优点？以及如何做好功能测试？ MQC 团队推出系列文章，为大家讲解 Appium 技术干货以及 MQC 功能测试服务。

一、从Android自动化测试谈起

In software testing, test automation is the use of special software (separate from the software being tested) to control the execution of tests and the comparison of actual outcomes with predicted outcomes. Test automation can automate some repetitive but necessary tasks in a formalized testing process already in place, or perform additional testing that would be difficult to do manually. Test automation is critical for continuous delivery and continuous testing. —— wikipedia

维基上对自动化测试的定义简单来说，就是通过软件来替代人来执行测试用例，并得到测试结果的过程。当然，对于自动化测试来说，包含的范围十分大的，对于服务端接口与代码接口来说，通常采用非Ui自动化的测试方法，如：Unit Test、API Test等等；对于包含Ui元素的完整App、GUI程序来说，Ui自动化的测试方法有：mock、功能测试等等。

对于安卓自动化测试来说，功能测试是最基本也是最常用的方案，那么功能测试到底能做什么？有什么优点？以及如何做好功能测试？ MQC 团队推出系列文章，为大家讲解 Appium 技术干货以及 MQC 功能测试服务。维基上对自动化测试的定义简单来说，就是通过软件来替代人来执行测试用例，并得到测试结果的过程。当然，对于自动化测试来说，包含的范围十分大的，对于服务端接口与代码接口来说，通常采用非Ui自动化的测试方法，如：Unit Test、API Test等等；对于包含Ui元素的完整App、GUI程序来说，Ui自动化的测试方法有：mock、功能测试等等。

功能测试如何帮助改善产品质量

对于大多数敏捷开发团队来说，要完成对一款大型产品各个方面进行全方面的测试是十分困难的。一方面，我们需要根据每次变更有针对性的测试重点模块，那么必然会遗漏对其它模块的测试；另一方面，很多模块的测试工作是机械性的，如回归测试、性能测试、机型适配等等，全部交给人工测试将大大增加人工成本。

功能测试可以将测试开发从繁琐的重复劳动中解放出来，把精力集中到重点模块，同时有余力设计编写完善的测试用例，并通过功能测试提高测试覆盖率，降低隐患。

功能测试的用例不是万能的

对于测试开发来说，追求100%的测试覆盖率是无可厚非的，但是事实上很多的测试工作是机器难以完成的，比如文字验证码识别。优先设计完成稳定模块的用例来保证今后功能不断回归的工作，之后再考虑时间成本、人力成本的前提下再去考虑更多复杂问题的用例设计。

另一方面，对于频繁发生变化的模块，用例也应当适应这种变化不停迭代，从而快速的在各个机型上进行功能验证。

功能测试无法发现新问题

我们在编写和调试用例的时候，或许能够发现一些功能性问题，而用例在进行回归后，发现问题的可能性就很低了。功能测试其实就是一个用例不断重复的过程，功能测试本身应当是一个“守护者”而非“探索者”，它可以帮助我们更加确定应用没有问题或者发现一些回归性的问题，而不是新问题。MQC 在探索问题的方向上自主研发了一款兼容性测试工具 Ripper，在达到高覆盖率的同时保证较高的 Bug 检出率，有兴趣的小伙伴欢迎试用 MQC 兼容性测试。

功能测试是需要成本的

我们通过功能测试用例来保证产品的质量，同时需要专业的工程师来保证用例的质量。设计开发一个合格的用例也是需要不断的调试、迭代与维护的，这就需要一个好的平台系统来帮助完成相关工作。MQC为开发者提供了完善的用例库管理功能，同时，为测试开发团队打造了专业的一站式测试协作平台，帮助团队进行应用管理、协同工作、任务分发、报告统计。

通过以上几点内容，相信大家对功能测试的概念已经有了一定的了解。MQC 在 Android 功能测试上选择使用了 Appium 测试框架，其开源社区较为活跃，兼容性好、功能丰富，相信能满足绝大部分功能测试的需求；在脚本开发方面，MQC 提供了在线真机录制、云端真机回放等多种服务，来帮助提高用例脚本的开发、调试效率；最后，平台提供了 App 用例管理、用例历史报告查看、编辑脚本、上传脚本等功能，帮助用户通过平台来完成功能测试的迭代维护需求。更多服务，欢迎来阿里云移动质量中心进行体验。

二、Appium环境搭建

这章将会介绍如何搭建与安装 Appium 的开发环境，主要介绍 Windows 平台的环境搭建，mac 或 linux 需要的相关环境与 Windows 是一样的，环境搭建本身并不困难，遇到问题大家可以多做尝试。

Appium server

Appium 是移动端的测试工具，所以 Android、iOS 的 sdk 是必不可少的。

1.到https://developer.android.com/studio/index.html下载android sdk，若不想下载android studio，可以滑动到最下面，找到仅获取命令行工具

2.若要测试iOS应用，推荐安装 XCode 8 及以上的开发环境。

Appium server 是用 Node.js 编写的一个服务器。我们可以用源码编译或者从 NPM 直接安装。

通过 npm 安装 appium 可能遇到一些镜像地址连接超时、appium启动权限报错的问题，同时命令行启动 appium 时需要添加一些参数，对于新手，我们更加推荐使用 appium 的桌面客户端工具。Appium 桌面客户端封装了运行 Appium 服务端的所有依赖，而不需要担心怎样安装Node.js。其中还包括一个Inspector工具，可以帮助你检查应用的界面层级让你更方便地编写测试用例。

1.到https://github.com/appium/appium-desktop/releases/tag/v1.2.0-beta.1下载最新的 appium 客户端。目前 appium-desktop 提供了自动更新的功能，所以不再需要担心 appium-server 更新的问题了。 2.最新的桌面客户端启动界面如下，指定 Host 到本地，设定一个空闲的端口（默认 4723）就可以启动 appium-server了

Appium client

Appium Client 支持绝大部分语言，包括 Java, Ruby, Python, PHP, JavaScript 和 C#，这些库都实现了 Appium 对 WebDriver 协议的扩展。当使用 Appium 的时候，你只需使用这些库代替常规的 WebDriver 库就可以了。

java 开发相关依赖可以到 https://github.com/appium/java-client/blob/master/docs/Installing-the-project.md 找到;
python 开发相关依赖可以到https://pypi.python.org/pypi/Appium-Python-Client进行下载安装。

好的开始是成功的一半，任何框架都是需要从搭建环境开始做起的，遇到问题多利用各个搜索渠道去解决，相信搭建appium环境一定难不倒大家。

三、Appium基础篇

上文回顾

上一篇为大家介绍了如何通过appium桌面客户端的方式来快速搭建appium环境，桌面客户端的appium版本目前为1.6.4，更新稍慢于appium项目，但目前已经支持在线更新，大家不用再有客户端版本过低的顾虑。

接下来将介绍如何使用python来开发appium功能测试脚本，包括启动、控件定位、操作、函数封装、组织用例五个部分。

启动

Appium启动时需要指定一些通用配置，统称为Desired Capabilities，具体的一些参数可以参考Appium服务器初始化参数。这里介绍一些通用的参数与一些常见的问题。

automationName

自动化测试的引擎，Appium （默认）、Selendroid、Uiautomator2。Appium使用的是UI Automator v1，相比之下UI Automator v2修复了一些v1的bug，在结构上也有一些优化。对于Android7.0以上的系统，UI Automator v1可能在查找控件时出现超时导致appium服务端报错，这时候可以考虑改用Uiautomator2。

platformName

手机操作系统。

platformVersion

手机操作系统版本。

deviceName

手机类型

app

待测app的路径

newCommandTimeout

两条appium命令间的最长时间间隔，若超过这个时间，appium会自动结束并退出app

noReset, fullReset

noReset 不要在会话前重置应用状态。默认值false。 fullReset (Android) 通过卸载而不是清空数据来重置应用状态。在Android上, 这也会在会话结束后自动清除被测应用。默认值false。

unicodeKeyboard, resetKeyboard

在输入的时候，可能出现键盘挡住控件的情况，这时候需要使用 appium 提供的输入法（支持输入多语言，没有键盘 ui ），unicodeKeyboard 为 true 表示使用 appium-ime 输入法。 resetKeyboard 表示在测试结束后切回系统输入法。

appActivity, appPackage

appActivity与appPackage指用于启动待测app的activityName与packageName，appium（1.6.4）已经支持activityName与packageName的自动检测，这两个参数已经可以省略了

appWaitActivity, appWaitPackage

appium需要等待的activityName与packageName，与appActivity不同的是，对于有启动动画的app来说，appWaitActivity应该是启动activity消失后出现的activity。这两个参数可以指定多个。

有了以上介绍的这些参数，我们可以启动appium并开始测试app了。将desired capibilities进行封装，python脚本如下：

控件定位

android sdk的tools目录下自带一个元素查看工具-uiautomatorviewer，通过这个工具可以获取到app的各个元素属性，辅助我们编写相关的脚本，uiautomatorviewer的界面如下：

如图为了定位尚未登录这个控件，我们推荐以下几种方法：

xpath: xpath定位效率低，但胜在定位准确，在控件没有明显的唯一特征时，xpath的优势就体现出来了。使用xpath时可以选择以控件树的最近公共祖先的节点开始生成查询路径。

id: 为了定位方便，开发一般会为部分控件添加resource-id属性，一般来说可以在一个页面中唯一确定一个控件，对于存在多个相同resource-id控件的页面，可以通过index来定位这些控件中的某一个

text: 定位控件较为简洁清晰地一种方式，就是通过text来查找控件。

操作

swipe: 很多App都会有引导页需要左滑，这里提供一个左滑的例子，注意，滑动速度不应太快，否则容易导致引导页滑动不成功。

TouchAction: touchaction可以用来实现点击坐标，滑动等操作，需要注意的是在android系统上，TouchAction的move_to函数是相对坐标。

Scroll: 对于ListView这样的控件，若要滑动到某个控件位置，按照坐标滑动的方式很难适配不同分辨率的手机，这时候需要考虑使用scroll的方式进行滑动。

Keyevent: 通过系统按键可以实现很多操作，如HOME、POWER、MENU、音量等功能。具体的一些keyevent可以到https://developer.android.google.cn/reference/android/view/KeyEvent.html查看。

long_press：利用TouchAction，可以实现长按操作：

hidekeyboard: 若 desiredcapbility 没有指定使用 unicodeKeyboard，在输入的时候需要注意键盘 ui 可能会挡住控件的情况，这时候使用 hidekeyboard 函数隐藏键盘

函数封装

在写脚本的时候，把一些常用的功能合理封装起来，能够大大提高脚本执行的成功率。

滑动函数: 通过一组坐标点来进行滑动，从而实现一些曲线形的滑动。我们可以实现一个函数用来支持曲线滑动，输入为形如[[x1, y1],[x2, y2]]的一组坐标点。

查找控件: 对于在调试的时候一切顺利的脚本，真正到了云测平台海量真机上测试的时候，却经常出现控件找不到导致脚本执行失败的问题。实际真机运行的时候，可能会有很多和本地并不相同的环境情况，比如网络延迟导致控件较迟刷新出来，我们应当封装一个较为稳定的控件查找函数。

appium本身有提供waitUntil的api，现在要找图中的个人中心控件，使用显示等待的方法如下：

我们也可以封装一个多方式定位控件的函数，这里需要自己把握超时时间

组织用例

unittest是python的一个单元测试框架，它可以帮助我们有效组织用例，把用例的不同部分区分开来。结合已经封装好的函数，我们写一个登录的测试脚本：

四、MQC 功能测试 DEMO

MQC为大家提供了海量的适配真机、强大的在线录制、遍历的用例管理、定制化的报告展示等功能，这篇文章将会通过一个 DEMO 教会大家如何利用好 MQC 提供的这些服务来回归测试自己的 App。

如何使用 MQC 功能测试服务？

Appium 基础篇有提到，desired capabilities 会提供 appium 运行时的各项环境参数，MQC 在功能测试开始前会动态生成desired capabilities类，用户脚本只需要调用相关 api 即可快速启动 Appium。

除此之外，MQC 提供了许多定制化的操作，只需要按照格式进行简单的 log 打印，就可以实现记录步骤、截图、记录执行状态等等操作，使得报告更加完善。当然，不打日志同样可以使用功能测试服务，只需要上传一个可执行的 main.py 文件(打包成zip文件)。

一个合理且容易被解析的日志结构应该如下：

那么，我们可以把上篇文章的 DEMO 进行改造，脚本如下：

准备好脚本后，就可以到 MQC 平台进行提测了：

1.将这个脚本打包成zip包，到 MQC主页添加待测app, 之后进入用例库页面

2.创建一个新用例，取名为登录

3.进入功能测试提测页面进行用例提测, 用户自己上传脚本创建用例需选中已上传用例，使用在线录制服务创建的用例需选择已录制用例

4.将上面的 DEMO 脚本提测后，24小时内便可查看测试报告。

怎么使用在线录制？

大家写功能测试脚本的时候一定有想过录制回放这样的功能，就是通过工具把操作录制下来，而后再通过引擎回放录制的动作。在线录制结合了云真机机型多的优势，提供了这么一项在线服务。在线录制可以大大加速用例的生成，但是，一个好的用例是需要不断地验证打磨的，除了基本的点击、滑动操作外，若您有具体的功能验证需求，如图片上传、随机密码键盘等等，都是需要有经验的工程师来修改完善脚本的，在线录制仅仅是用例脚本设计中的第一步。当然，若您有复杂的用例设计需求，也可以联系我们，通过在阿里云购买人工支持用例设计，让阿里云的测试专家为您的 app 量身定制用例。

在使用在线录制的时候，可以看到下图所示界面

1.在点击的时候若出现控件树不准确的情况，需要手动点击刷新(框1)来重新解析控件树；2.框2中的内容是控件的坐标、resource-id[index]、text信息；3.有些 app 有左滑的起始页，这里封装了一些滑动操作，可以有效避免录制的左滑动作过快或过短导致回放失败的问题；对于一些输入操作，录制时直接使用键盘输入可能没有准确识别出该步所有输入文本，可以使用输入按钮来完成输入的操作；4.框4和框5是直接使用在线录制回放脚本，可以快速验证录制脚本的准确性，框4能够直接支持单步回放，框5可以构建appium脚本再使用appium引擎进行回放。