美文网首页自动化测试技术江湖
一文带你读懂百亿级SDK测试及自动化实践

一文带你读懂百亿级SDK测试及自动化实践

作者: 个推大数据 | 来源:发表于2020-05-08 21:32 被阅读0次

    引言

    如何在产品快速迭代、功能越来越多,但是测试人力资源有限的情况下保证产品的质量呢?这期文章,我们邀请了在SDK测试方面有着丰富经验的个推高级测试工程师Keal,为大家分享个推在SDK测试及自动化方面的实践。在保证新功能得到充分测试的前提下,我们引入自动化测试,借助pytest+appium等框架,减轻了测试人员在个推SDK回归测试以及机型兼容性测试上的工作量。本文我们将向大家介绍个推SDK测试实践、自动化测试以及一些提升测试效率的小技巧。

    作者 个推高级测试工程师  Keal

    正文

    SDK的定义

    SDK (Software Development Kit )即“软件开发工具包”,是一套开发工具集合,可以为特定的软件包、应用软件、软件框架、硬件平台、操作系统等产品提供服务。通俗来说,它指的是由第三方服务商提供的工具包,用以帮助实现软件产品某项功能。

    一个产品想实现某些特定功能如消息推送,便可以找到相关的第三方SDK,工程师直接接入SDK,不用再重新开发。这样,工程师可以将更多的时间和精力投入到其他产品业务相关功能的开发上。

    SDK测试与APP测试的区别

    个推专注于开发者服务,旗下SDK产品主要有个推消息推送、应用统计、用户画像、一键认证。截止至2019年12月,累计SDK安装量超520亿。由于这些SDK是提供给APP用于集成,所以我们的测试方式是将SDK集成到Demo APP中进行测试。众所周知,SDK测试与APP测试联系紧密,那么这两者又有什么区别呢?这里以个推推送SDK测试为例:

    测试侧重点不同

    1、APP测试时更加侧重于业务功能、用户交互、用户体验;

    2、SDK没有用户界面,测试时更加注重测试API的功能以及SDK对不同品牌手机、不同厂商ROM、不同Android版本的适配。

    测试角度不同

    1、APP测试要站在用户的角度考虑问题;

    2、SDK测试不仅要站在终端用户角度考虑问题,还需要站在APP开发者的角度考虑问题。比如SDK的集成方法是否简便、容易上手;API是否满足开发者灵活的自定义需求以及在保证功能的前提下,如何尽量降低流量、电量的消耗,减小SDK的体积等等。

    测试的方法不同

    1、 APP测试更多的是界面上的操作,客户端与服务端的通讯通过Fiddler等抓包工具查看。

    2、 SDK测试通过Demo的按钮或服务端下发消息,触发SDK的API代码执行。我们通过分析手机上SDK的运行日志来判断SDK功能是否正常。同时,我们也要对SDK上行请求数据的加密情况进行测试。

    所需知识储备不同

     1、APP测试时,一般情况下,测试人员只要将研发提测的APK或IPA包,安装到手机上就可以测试了。

    2、SDK测试时,研发通常提测的是JAR或AAR包,而测试人员需要掌握Android Studio、Xcode等工具的使用, 将对应的JAR/AAR包集成到Demo工程中才能构建出APK/IPA包。所以SDK测试人员需要了解一定的Android开发知识、Android系统知识及常用ADB命令等。

    个推SDK测试流程

    个推SDK测试流程如下:

    1 、进行需求/技术方案评审和测试用例评审过程中,研发与测试需要进行充分沟通,保证双方对需求的理解达成一致,并明确需求的每一个细节。

    2、测试用例评审后,测试人员整理一份自测的注意点与常见异常点提供给研发,作为研发自测的参考。

    3、研发自测时,不仅要确保各自负责的模块功能正常,还需要保证所有模块集成后其系统功能自测通过。

    4、研发自测通过后,提交测试时首先会触发Jenkins自动构建打包SDK与Demo APK,随后触发研发的单元测试;若单元测试通过,Jenkins将自动运行测试人员编写的自动化用例。只有自动化测试通过了,才算是提测成功。

    5、测试过程中使用专业的BUG管理工具,可以大大提高研发测试协作效率,方便测试人员实时把握项目整体质量情况。

    个推SDK自动化测试

    业务测试自动化

    为了节约回归测试和机型兼容测试的时间,我们将部分功能回归测试用例自动化,减少测试人员的重复性工作。在个推实践中,其SDK自动化框架主要用来实现UI层面的自动化。我们选择的编程语言是Python3,使用的APP UI自动化框架是当前最流行的Appium,使用的测试框架则是成熟的Pytest。

    测试报告

    自动化框架与Jenkins集成后,Jenkins会执行用例,待其执行完毕,它会以邮件的形式发送测试报告给相关人员,邮件样式如下图:

    邮件附件报告内容如下,包括运行环境、测试结果汇总、测试详情:

    用例校验方法

    下图展示的是个推SDK最基本的通知功能,服务端推送消息后,手机通知面板会展示消息通知。

    个推SDK自动化测试校验方法主要有三种:手机UI校验、手机Sdcard日志校验、服务端数据校验。

    手机UI校验

    通过Appium提供的API,操作手机UI页面,检查通知面板是否有展示消息通知,关键代码如下:

    手机Sdcard日志检验

    个推SDK收到通知后,Sdcard上的日志文件会打印日志信息,校验关键代码如下:

     服务端数据校验

    APP调用SDK的API后,将部分信息传递到服务端,这时需要调用服务端接口查询APP传递的数据是否在服务端成功入库,关键代码如下:

    自动化成效

    每个迭代版本大约能节省20%的回归测试时间。

    持续集成与自动化测试

    持续集成(CI/Continuous Integration) 强调开发人员提交了新代码之后,Jenkins立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。集成测试示意图如下:

    图片来源:CSDN

    (https://blog.csdn.net/qq_35368183/article/details/84558134)

    在研发持续集成的流程中加入测试人员的自动化测试,是对研发单元测试的补充,可以提高测试覆盖率,一定程度上也减轻了研发人员的自测工作量。

    效率提升工具

    自动化测试借助于测试工具、测试规范,可以局部或全部代替人工进行测试,能极大提高测试效率。由此可见,自动化测试不仅仅只有上文提到的这种“大而全”的自动化框架或工具。日常工作中编写的一些辅助测试的脚本,以及一些小工具均能有效提高工作效率,并且投入更小,收益更大。

    个推SDK测试时,经常会涉及到应用安装卸载、清空应用数据、管理日志目录及文件、导出安装的应用APK文件等操作, 我们可以通过编写Python脚本将几条ADB命令及Shell命令组合在一起,一键实现多步手工操作,能有效提高效率。

    示例一: 一键“卸载应用+清空日志目录”

    D:\gitlab\sdk_effect_tool>python main.py -f 1 -p {package_name}卸载应用+删除日志目录adbuninstall {package_name}Successadbshell rm -rf /sdcard/{log_path_1}/adbshell rm -rf /sdcard/{log_path_2}/注:1.{package name}: 占位符,此处表示APP的包名2.  {log_path_x}: 占位符,此处表示日志文件所在目录

    示例二: 一键“导出日志+解密日志”+“打开查看日志(使用Note Pad++)”

    D:\gitlab\sdk_effect_tool>python main.py -f 2 -p {package_name} -d 2020-04-06将日志文件从手机复制到电脑adb pull /sdcard/{log_file_path} logs//sdcard/{log_file_path}: 1 file pulled. 8.8 MB/s (119600 bytes in 0.013s)解密日志java -jar recover_sdk_log.jar logs/{log_file_name} 1打开查看日志"C:/Program Files (x86)/Notepad++/notepad++.exe"logs/{log_file_name}注:1.  {package name}: 占位符,此处表示APP的包名2.  {log_file_path}: 占位符,此处表示手机上日志文件路径3.  {log_file_name}: 占位符,此处表示电脑上日志文件名称

    结语

    个推在SDK测试中引入自动化测试,减轻了测试人员在个推SDK回归测试以及机型兼容性测试上的工作量,极大地提高了测试人员的工作效率。在软件项目测试中,大家可以留心观察日常工作中进行的频繁操作,优先考虑是否可以通过脚本、小工具简化操作步骤,提升工作效率。

    相关文章

      网友评论

        本文标题:一文带你读懂百亿级SDK测试及自动化实践

        本文链接:https://www.haomeiwen.com/subject/lpaqnhtx.html