关于ios:GrowingIO-数据采集-iOS-SDK-测试实践

43次阅读

共计 5854 个字符,预计需要花费 15 分钟才能阅读完成。

GrowingIO 是基于用户行为数据的增长平台,精准采集用户行为数据是公司业务的基石,只有及时、精确、牢靠的采集到数据,能力撑持下层的数据分析,用户画像,经营等业务,所以公司始终十分重视数据采集 SDK(Software Development Kit) 的质量保证工作。

iOS 开发交换技术群:563513413,不论你是大牛还是小白都欢送入驻,分享 BAT, 阿里面试题、面试教训,探讨技术,大家一起交流学习成长!

为了满足客户的各种业务与技术的需要,GrowingIO 提供了 Web、Android、iOS、Hybrid、各种小程序(微信、支付宝、头条、QQ 等)、微信内嵌页等多种平台,以及 React Native、Flutter、Cordova、Weex、API Cloud、AppCan 泛滥开发框架的 SDK,这无疑为 SDK 的测试工作带来的微小的挑战。

本文次要介绍 GrowingIO 在 iOS SDK 测试方面的具体实际,心愿对从事 iOS 测试的同学提供一些参考。

1. 数据采集 SDK 是如何工作的?

要测试一个软件或零碎首先必须要先理解其业务逻辑和技术实现,接下来咱们简略看下数据采集 SDK 是如何工作的。

GrowingIO 的数据采集 SDK 反对无埋点(全埋点)数据采集以及埋点数据采集,以满足不同的业务需要,其繁难构造如下:

在用户关上 App,浏览不同的页面,点击不同的元素(如按钮,文本框,图片),敞开 App 时,无埋点事件采集模块会将用户的具体行为主动采集并保留到手机的本地存储(对于无埋点数据采集的具体实现,欢送关注 GrowigIO 后续的文章分享,这里不再详述)。

埋点事件采集与之相似,不同之处是埋点事件是由 App 被动调用 SDK 的埋点 API 触发事件采集,当然不同事件的具体数据格式有所不同。

接下来是数据发送模块,其次要负责将数据通过 HTTP API 上报到数据接管服务。

须要阐明的是,为了节约用户的数据流量和电量,发送程序并不是实时上报的,它会依据设施的电量、网络类型、以及数据量进行发送机会的抉择,而且发送前还会对数据进行压缩和混同以升高传输数据量并晋升数据安全性。

当然数据发送程序还会解决数据上报中的各种数据发送失败,网络异样等谬误,采取适当的重试机制。

2. 如何测试?

通过以上构造剖析,能够看出数据发送模块跟外围的数据采集业务关系不大,并且很稳固,简直不会改变,因而咱们测试的重点次要是数据采集局部,尤其是无埋点数据采集。

要测试数据采集首先须要有一个蕴含各种页面和元素的 Demo App,而后切换不同的页面,操作页面上的元素或触发埋点事件,而后查看采集到的事件数据是否正确。

查看事件数据有两种形式,一种是将事件具体数据通过日志打印进去察看日志查看;一种是通过抓包程序获取数据发送而后查看。

后者个别须要配置简单的代理工具,而且数据量多,还须要思考数据的解压缩、解密,比拟难以精准定位到事件数据。所以在理论测试中个别应用前者。

上图是一个采集数据的日志截图,通过图中的事件数据咱们发现,其字段泛滥,且一些字段可读性不高,人工查看耗时较长。

此外 SDK 数据采集的次要逻辑根本不变,然而每次批改都必须进行足够的回归笼罩,免得脱漏谬误。

一旦脱漏了缺点到线上,其造成的损失是极其低廉的,即便在后续版本修复了缺点,其造成的影响也很难打消,因为挪动端 App 的降级周期是很难管制的。

在加上 GrowingIO 数据采集 SDK 兼容 iOS 8 及以上版本,须要对各个版本零碎做兼容性测试,其测试工作量不言而喻。

侥幸的是 SDK  的业务变动很少,断言内容比拟机械,特地适宜自动化测试。而且回归测试工作量微小,采纳自动化测试能够极大的晋升生产率和品质。

3. 抉择测试框架

工欲善其事必先利其器,发展自动化测试之前必须抉择一款适合的自动化测试框架。抉择框架的时候有几个方面要思考:

  • 开发的老本(反对语言,是否可调试,代码补全)
  • 保护老本(框架的稳定性)
  • 是否须要源代码
  • WebView 的反对(很多 App 都用到了 H5)
  • 对操作系统,开发工具的反对状况(是否反对 iOS 8)
  • 测试用例执行效率
  • 测试报告(截图,代码覆盖率,…)
  • 是否反对 CI(继续集成)
  • ……

以后反对 iOS  UI 自动化测试的次要框架比照如下:

思考抉择测试框架的几种影响因素。

首先,应用的语言和框架决定了测试人员的持续性学习老本,iOS SDK 测试人员对 Objective-C 相熟和把握水平高,不须要耗费额定的学习老本,测试与开发同一技术栈。

其次,测试 App 程序依据需要时有调整,应用开发效率高、调试不便的测试框架能使咱们在适应新 UI 变动、新需要时取得更小的投入产出比。

综合以上思考,KIF 框架曾经展示了他的劣势,并且 KIF 应用 XCTest 框架,使得其测试流程 iOS 程序的单测无异,可齐全复用单测的继续集成流程,保护继续集成的老本绝对升高;另外,KIF 是一个沉闷的开源测试框架,可扩展性好,降级更新快,有沉闷社区来探讨和解决应用过程中遇到的问题。

鉴于上述劣势,咱们抉择了 KIF 作为 iOS 的 UI 自动化测试框架。

KIF 的全称是 Keep it Functional,它是一个建设在 XCTest 的 UI 测试框架,通过 Accessibility 来定位具体的控件,再利用公有的 API 来操作 UI。因为是建设在 XCTest 上的,所以你能够完满的借助 XCode 的测试相干工具。

4. 自动化测试的施行

语言与工具

  • 语言:Objective-C
  • IDE:Xcode
  • 测试框架:KIF

搭建测试环境

  1. 在现有工程中增加 Target 实现,抉择 File → New → Target… 菜单项,从中抉择 iOS → Test 中的 UI Testing Bundle 模板,如下图所示:

  1. 单击下一步,进入 Target 选项页面,设置测试工程相干项
  • Product Name: KIF 测试工程名,能够自在命名,最好是测试工程名 + “Tests”。
  • Organization Name,Organization Identifier,Bundle Identifier,依据须要自行命名即可。
  • Language: 编码语言,有 Objective-C 和 Swift , 依据须要抉择,咱们应用的是 OC。
  • Project 和 Target to be Tested:为对应的要测试的工程名,肯定要保障是正确的。

  1. 实现 Target 设置后,点击「Finish」按钮,创立胜利。
  2. 装置 pod,在命令行终端输出以下命令。

sudo gem install cocoapods

  1. 批改或创立工程的 pod 文件 Podfile。

target ‘GrowingIOTest’ do

pod ‘SDCycleScrollView’, ‘~> 1.75’

pod ‘MJRefresh’

pod ‘MBProgressHUD’

end

target ‘GIOAutoTests’ do

pod ‘KIF’,’~> 3.5.1′

end

其中如下一段内容为新增加的

target ‘GIOAutoTests’ do

pod ‘KIF’,’~> 3.5.1′

end

  1. 在我的项目目录中执行以下装置命令,装置相应的依赖,测试项目筹备实现。

pod install

  1. 筹备好被测程序,在测试 Demo 我的项目中集成须要被测试版本的数据采集 SDK。

编写测试用例

测试环境搭建实现后,接下来就是编写具体的测试用例了,个别测试用例的次要步骤为:

  1. 筹备测试环境
  2. 执行测试步骤
  3. 测试后果断言
  4. 测试后果报告
  5. 清理测试环境

上面以 SDK 的无埋点元素点击事件自动化测试用例为例,阐明自动化用例的编写。

测试用例:

启动 App,模仿用户滚动屏幕找到对话框按钮,而后点击对话框按钮,显示对话框后点击敞开按钮,校验点击事件发送数据,发送内容正确。

代码实现:

  • (void)setUp {

    // 一些初始化操作

}

-(void)tearDown{

// 一些完结动作

}

-(void)testDialogBtnCheck{

/**

function: 对话框按钮点击,检测点击事件,

**/

[[viewTester usingLabel:@”UI 界面 ”] tap];

// 增加向下滚动操作

[tester scrollViewWithAccessibilityLabel:@”CollectionView” byFractionOfSizeHorizontal:0.0f vertical:10.0f];

[tester waitForTimeInterval:1];

[[viewTester usingLabel:@”LabelAttribute”] tap];

[[viewTester usingLabel:@”ShowAlert”] tap];

[tester waitForTimeInterval:1];

[[viewTester usingLabel:@” 勾销 ”] tap];

[tester waitForTimeInterval:3];

NSArray *clckEventArray = [MockEventQueue eventsFor:@”clck”];

// 是否发送 clck 事件

if(clckEventArray.count>=2)

{

// 判断点击事件是否字段发送正确

NSDictionary *chevent=[clckEventArray objectAtIndex:clckEventArray.count-1];

NSDictionary *clkchr=[NoburPoMeaProCheck ClckEventCheck:chevent];

//NSLog(@”Check Result:%@”,clkchr);

XCTAssertEqual(clkchr@”KeysCheck”, @”Passed”);

NSLog(@” 对话框按钮点击,检测 clck 事件测试通过 —Passed!”);

}

else

{

NSLog(@” 对话框按钮点击,检测 clck 事件测试不通过:%@!”,clckEventArray);

XCTAssertEqual(1, 0);

}

}

因为咱们次要测试 SDK 的性能,测试 Demo 是咱们本人设计的,次要笼罩各种 UI 元素和事件,其业务逻辑比大多数的业务类型 App 都简略,没有什么特地介绍的。

这里介绍下断言的设计。前文介绍过,咱们自动化测试的重点是数据采集规定正确,不关注数据存储与发送。

SDK 在采集数据时会将所有事件先退出一个队列,而后再保留到 DB,所以在执行测试时,只须要监听事件队列,即可在监听的事件队列中依照须要保留和获取须要断言的事件。点击事件发送的数据结构大抵如下:

对事件数据的校验,首先保障字段残缺且每个字段不为空,即数据的 Schema 正确;其次依据须要对事件的具体字段做校验,比方点击事件的类型 t 应该为 clck。这些查看被封装到了独自的 Check 办法中,如果查看通过则办法返回 Passed。

这里是通过 ClckEventCheck 办法实现了具体的业务校验。

执行测试用例

次要介绍下如何通过命令行执行测试。

装置 Command Line Tools(命令行工具包),App Store 装置 Xcode 默认不会装置 Command Line Tools,能够通过在命令行输出以下命令进行独自装置。

xcode-select –install

在应用命令行执行测试之前,还须要将我的项目设置成 Shared。关上 Product → Scheme → Manage schemes,查看我的项目是否是 Shared,如果不是,则选中前面的复选框将其共享。

命令行执行所有的测试用例

xcodebuild -workspace Growing.xcworkspace

-scheme GrowingIOTest test

-sdk “iphonesimulator13.5”

-destination platform=’iOS Simulator’,OS=13.5,name=’iPhone 11′

执行单个用例

xcodebuild -workspace Growing.xcworkspace

-scheme GrowingIOTest test

-only-testing:GIOAutoTests/ClckEventsTest/test7DialogBtnCheck

-sdk “iphonesimulator13.5”

-destination platform=’iOS Simulator’,OS=13.5,name=’iPhone 11′

更多 xcodebuild 的应用办法能够参考其应用阐明。

man xcodebuild

丑化测试报告

xcodebuild 的输入浏览起来不是太直观,应用 xcpretty 能够解决这个问题,并且它还能实现测试报告生成。

xcpretty 是一个高速灵便的 xcodebuild 输入格式化工具,其应用如下:

命令行装置 xcpretty

gem install xcpretty

命令行执行

xcodebuild -workspace Growing.xcworkspace

-scheme GrowingIOTest test

-sdk “iphonesimulator13.5”

-destination platform=’iOS Simulator’,OS=13.5,name=’iPhone 11′

| xcpretty –report html

生成的测试报告如下:

默认输入 html 报表在 build/reports/tests.html

5. 覆盖率统计

在执行自动化测试的时候,通常咱们想获取测试覆盖率报告,以度量自动化测试的笼罩状况。因为 KIF 是间接基于 XCTest 实现的,所以能够很容易地应用 Xcode 自带的覆盖率统计工具。其设置如下:

Product → Scheme → Edit Scheme,Code Coverage  把须要统计覆盖率的被测程序退出到 Targets 中。

测试实现后能够拿到覆盖率统计报告。

6. 继续集成

自动化测试的最大价值在于能够代替人工进行更高效、更频繁的测试。因而要施展自动化测试的价值,最现实的计划是,将自动化测试退出到继续集成环节中,每当有代码变更时,就主动的执行测试,疾速反馈后果。

咱们利用 Jenkins 监控代码仓库变更,当有新的 commit 提交时,Jenkins 会主动拉去最新的代码,并调用命令行执行相应的自动化测试用例,收集相应的测试报告,并将测试后果通过钉钉机器人及时的告诉给相干的开发和测试人员。

当测试失败时,相干人员能够第一工夫收到后果,并及时解决。

7. 总结

本文以 iOS 平台为例零碎的介绍了 GrowingIO 数据采集 SDK 次要工作原理,测试计划的设计以及自动化测试框架的选型与自动化测试施行。心愿对从事 SDK 测试工作的同学有所启发。

正文完
 0