内容简介:1、开天辟地Hippy是什么呢?简单点,能用JavaScript来写Android和iOS应用的框架, 类似业界的React Native。好吧,我们还是严谨一点。Hippy是一个前终端一体化的JavaScript Framework,可以用JavaScript构建Native原生界面,以及调用Native的能力。同时可以一次编写Android和iOS两端运行。
编辑推荐: |
本文来自于云社区,本文章主要详细介绍了React Native框架,应该如何进行代码级别的测试保障,希望对您的学习有帮助。 |
1、开天辟地
Hippy是什么呢?简单点,能用JavaScript来写Android和iOS应用的框架, 类似业界的React Native。
好吧,我们还是严谨一点。Hippy是一个前终端一体化的JavaScript Framework,可以用JavaScript构建Native原生界面,以及调用Native的能力。同时可以一次编写Android和iOS两端运行。
2、Hippy架构和测试策略
(1)Hippy分层框架
通过代码阅读分析,我们得到的Hippy框架主要架构图,如下。
接下来我们对Hippy底层框架进行具体分析,制定相应的测试策略。
(2) 前端框架层
主要实现了JSX页面DOM转化、js/native桥接接口、View/Module的前端实现。
JSX页面DOM转化
这部分我们采用自动化,模拟生成各种类型JSX页面,通过遗传算法混合View和属性。然后将混合后的JSX做DOM解析,将解析后结果和预期做对比测试。
桥接接口、View/Module的前端实现
对于桥接接口、View/Module的前端实现,单独的前端单元测试难以验证实际效果,必须要和终端实现进行结合,所以我们这部分测试策略是进行前后端打通的接口测试。
(3) JS引擎层
JS引擎层主要是JS代码通过Google V8引擎执行,然后通过so调用 java 代码。主要作用是打通JS和Java代码调用通道。这部分由于Google自己产品已经有完善测试体系,我们不用在这个地方做重复建设。剩下的只是hippy桥接so,由于只是JNI接口没有太多业务逻辑。所以我们的测试策略是,采用Code Review和前后端接口测试进行保障。
(4)终端框架层
主要实现了Dom节点的终端渲染、View/Module的终端实现、Hippy的生命周期管理等功能。
Dom节点的终端渲染、View/Module的终端实现
这部分View/Module实现和View渲染工作,特别是View部分我们的测试策略是,采用前后端打通的接口测试进行。详情参考本系列第二弹文章,敬请期待。
Hippy的生命周期管理
通过代码分析得到Hippy的生命周期如下。
其中对启动速度影响最大的,莫过于“引擎初始化”和“业务JavaScript加载”时间了。其中,针对“引擎初始化”时间,测试策略是在开发阶段就进行代码埋点,多次进行性能测试后开发优化。
但是“业务JavaScript加载”时间,这个完全是由各业务自己决定和优化,并非Hippy底层能决定。所以,这里测试策略采用代码埋点,监控具体业务JavaScript加载时间,如果超过500ms就告警,防止业务用户体验下降。
3、 接口测试框架选型和实现
由前面第二章内容可见,前后端打通的接口测试是个重头戏,必须仔细选型构建。
(1) 测试框架对比
由于Hippy同类产品较少,公司外主要有Facebook的React Native,以及类似的渲染结构的Chrome内核。公司内部选取QQ浏览器内核作为对比对象。考察重点集中在:
1.使用的技术栈
2.测试条件构建
3.测试结果验证
4.测试运行形式
React Native
简介:React native框架是facebook推出的,通过JS代码构建跨平台APP的开发框架。
Github:https://facebook.github.io/react-native/
那么通过下载Github上的React Native的源代码,我们可以清晰看到React Native针对Android测试代码的整体结构如下。
同学们一眼就能看出这是标准的android接口测试代码形式,接下来我们针对关心的几个问题一一分析下。
使用的技术栈
很显然就是Android+JUnit+JavaScript。
测试条件构建
所有的测试条件都在前端通过JavaScript进行构造,如图。
测试结果验证
结果验证分为在Android端和JavaScript端两端验证,下图是Android端验证例子。
下图是在前端JavaScript验证测试结果,如下图。
测试运行形式
用例运行标准android接口测试运行,把Demo.apk和Test.apk安装在Android手机上,通过adb命令启动单元测试用例。
QQBrowser
简介:QQBrowser浏览器内核,针对html的渲染机制和hippy工作机制非常类似。只不过QQBrowser内核针对html渲染上屏、hippy针对JavaScript进行渲染上屏。
使用的技术栈
JavaScript+Html,主要思想是在不同的浏览器上运行js,查看浏览器对js的支持程度。
测试条件构建
测试条件直接通过页面JavaScript编写,如下图。
测试结果验证
结果的验证也是JavaScript的catch exception来检验,如果浏览器不支持某个JavaScript属性,就抛出exception,我们通过抓取exception判断结果不通过。
测试运行形式
浏览器直接加载页面运行,需要注意的是有一部分属性还不能完全自动化,需要人手工进行点击页面进行判断,如下图。
Chrome
简介:谷歌公司的开源项目Chromium中,关于webview(内核)部分渲染测试,和QQBrowser内核渲染测试比较类似。
使用的技术栈
Android+JavaScript+JUnit,主要思路是在终端Java中直接读取html和JavaScript代码,然后进行渲染结果确认。
测试条件构建
直接在终端Android代码中写入测试html。
或者读取本地html文件
测试结果验证
直接在Android代码中进行验证判断。
测试运行形式
Android接口测试运行形式。
对比总结
通过以上三种产品测试策略对比,我们列出如下表格数据方便决策。
由于产品形态类似,验证结构灵活性等原因,最后我们选择了类似ReactNative的测试架构。
(2)测试框架构建
从上一节结论可以知道,我们的接口测试架构采用类似ReactNative的测试架构,如下。
前端测试层
这里是针对Hippy“前端框架层”来说的。
Param Pip
用来将前端参数传递给终端Pip。
Assert Pip
用来将前端断言结果终端Pip。
终端测试层
这里是针对Hippy“终端框架层”来说的。
Pip
接收前端Pip发送的各种结果进行处理。
PreCondition
测试的前置条件,包含例如:jsbundle的设置、启动APP等。
Reflection
反射工具,针对各种属性和回调对象获取提供支持。
Gesture
用户动作模拟,封装了常用的用户操作。
Activity
作为测试Activity,其中会加载jsbundle并且在终端展示渲染效果。
Android Framework层
Configuration
提供运行环境配置管理。
Junit
Junit单元测试框架。
Instrumentation
标准的Instrumentation测试框架。
在整个TestCase驱动上,我们还是采用传统android单元测试方式,完全从android终端进行触发和最后验证。所有控制权都交给android终端,这样能够最大限度利用现有技术,不要重新发明轮子。测试用例的调用流程关系,见下图。
JavaScript测试代码(前端)
属性构造
例如:为了测试Text这个View的color属性,必须要构造这个输入性。然后在终端代码中进行验证。
方法调用/验证
方法调用主要是指在前端js中直接调用终端接口的能力。还有一种是终端完成回调js函数进行验证。
模块构造
进行一些模块的前置条件构造。
Android测试代码(终端)
属性验证
在前端JavaScript进行设置的属性,例如:Text的color属性,在终端代码就进行验证color设置是否生效。
方法验证和调用
验证前端JavaScript调用了终端函数成功。
模块验证
模块部分验证由于可以脱离前端JavaScript代码单独进行,所以我们采用完全在android标准接口测试既可以完成。但是还是有少部分模块需要前端构造条件的。
(3)关键问题解决
在接口测试框架中,有两个关键问题。
JavaScript控件ID如何传递给终端
这部分由于开发之前没有考虑这部分,所以我们自己开发了TestModule来解决这个透传问题。把前端View的ref->id做个映射,传递给终端。然后终端就可以按照ref找到id,从而通过反射获取各种View的属性进行TestCase的验证。参考测试框架中的“Param Pip”。
前端JavaScript验证结果如何传递给终端
针对部分需要在JS中验证的结果,同样采用TestModule来把测试结果透传给终端,终端收到结果后验证测试是否通过。参考测试框架中的“Assert Pip”。
(4)测试工程位置
在初期的时候,我们的测试代码和源代码放在同一个git工程下。当然这样做也是Android接口测试规范推荐的做法,但是后期我们出现了一个问题,那就是由于我们的jsbundle文件数量过多(400MB),导致开发同学每次更新代码都特别慢。所以我们采用测试代码和开发代码分不同工程存放的方式。
(5) 用例管理
测试用例的组织,分为按照View和模块分别组织。整体通过git进行版本管理。
View用例管理
终端测试代码按照每一个View的callback(回调)、function(函数)、property(属性)进行区分组织用例。然后每个用例对应的jsbundle都放在assets中对应目录存放,jsbundle的名字和Java用例文件名相同,方便查询。
模块用例管理
模块用例直接在目录下列表即可。
(6) 执行策略
在本地BVT机器上,每30分钟拉取一次hippy源代码,如果代码有更新内容,就全部运行一次所有androidTest目录中接口用例。如果没有更新就不执行测试。直接执行:gradle connectedCheck
(7) 覆盖率统计
刚开始的时候,我们采用默认的Android Gradle的覆盖率统计,如下图。
这种方式有一个很大的问题,必须所有TestCase运行成功才会有覆盖率数据。只要有1个Case失败,都没有覆盖率数据,这个不是我们想要的,所以我们引入Jacoco动态插桩获取覆盖率。然后在TestCase的基类tearDown中调用获取覆盖率函数即可轻松获取覆盖率,有TestCase失败照样能获取。
(8)适用范围
本接口测试框架适合Android拥有前端、终端交互的APP接口测试之用。重点在于章节3(3)中提到的前端、终端测试信息交互上,以及验证点位置设定上。
以上所述就是小编给大家介绍的《React Native框架如何白盒测试》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
C++ API设计
[美] Martin Reddy / 刘晓娜、臧秀涛、林健 / 人民邮电出版社 / 2013-8 / 89.00
现代软件开发中的一大难题就是如何编写优质的API。API负责为某个组件提供逻辑接口并隐藏该模块的内部细节。多数程序员依靠的是经验和冒险,从而很难达到健壮、高效、稳定、可扩展性强的要求。Martin Reddy博士在自己多年经验基础之上,对于不同API风格与模式,总结出了API设计的种种最佳策略,着重针对大规模长期开发项目,辅以翔实的代码范例,从而有助于设计决策的成功实施,以及软件项目的健壮性及稳定......一起来看看 《C++ API设计》 这本书的介绍吧!