3、使用JavaScript引擎执行代码：JavaScript引擎的选择

iOS中可以使用系统自带的JavaScriptCore框架执行。Android中可以使用Rhino作为执行引擎，Rhino 是一种使用 Java 语言编写的 JavaScript 的开源实现，原先由Mozilla开发，现在被集成进入JDK 6.0。当然也可以选择Chrome的V8引擎执行，选择Rhino引擎的原因是它用Java语言编写，可以直接以jar包的形式集成到项目中。

4.1、JavaScript调用Native端插件执行命令：JavaScript和Native端通信方法

如果使用WebView来显示网页，可以利用WebView的特性进行JavaScript和Native端（统指iOS和Android端）通信。但直接使用JavaScript引擎时，无法使用shouldOverrideUrlLoading()等方法进行拦截具体指令，并且Native代码和JavaScript分处不同的作用域，相互之间不能共享对象，因此无法直接相互调用。针对这种情况，工程师在JavaScript的内存空间维持一个指令队列，每当JavaScript需要调用Native代码时，把指令推入指令队列，Native端从指令队列中取出一个指令执行，执行完毕后，检查指令队列中是否有下一个指令继续执行，直到所有指令执行完毕。

4.2、JavaScript调用Native端插件执行命令：JavaScript和Native端通信协议

JavaScript指令队列中的每一条指令，包括插件名称、目标、参数三部分。

Native端收到插件名称后，查找预先在Native端注册的插件，传入具体“目标”和“参数”来执行。

每一条指令可以以“插件名称://目标?参数”的形式来传递。

例如在测试代码中经常使用的perform_event插件：IMG_260

以上指令代表执行Native端的“点击界面上的7日年化收益率”用户操作。

5.1、根据指令运行测试业务：Native端使用插件执行指令

Native端启动时需要注册一系列插件，例如perform_event插件代表执行用户动作，snapshot代表截图。由于插件实现在Native端，所以要根据平台特性进行具体实现，例如“perform_event://client?text=7日年化收益率”这条指令，在iOS端可以从UIViewController的View开始，向下查找每一层的UILabel，看是否有包含特定文字的项目，然后在该项目上执行点击动作。而在Android端，可以使用solo这种测试框架来直接点击屏幕上的特定文字部分。

使用代码来模拟用户行为，例如打开“购买”页面，既可以点击“购买”按钮（perform_event://client?text=7日年化收益率），也可以直接启动购买页面（open://购买页面）。为了更加真实的模拟用户行为，建议测试过程中尽量模拟用户的真实行为，不要跳过用户操作直接实现结果，例如前例中建议从页面的所有View中找到带有“购买”文字的按钮，实现按钮的点击操作。

5.2、根据指令运行测试业务：测试数据准备

测试中从Native端请求的REST API必须使用模拟的测试数据，以保证在任何时刻页面数据的一致。

模拟数据一方面可以在Native端通过Mock一个HTTP Server来截断所有HTTP请求，但是这样同样需要iOS和Android两个平台都进行编写，日后也需要维护两部分数据。更好的方法是直接在测试服务器上搭建一个模拟的REST API服务，针对每一个测试用例，返回固定的模拟数据，如果数据简单，使用静态JSON文件即可。

6、数据收集和对比

截图之后的图片直接在Native端通过HTTP协议上传至服务器。在服务器端，通过手机型号、操作系统、操作系统版本、业务名称、编号进行分类保存，这样可以迅速查找到某一个设备上某一个业务的所有截图。测试服务器中保存所有录制数据，每一次从测试设备收集到测试截图后，在服务器端和录制的数据进行像素对比，然后把测试结果返回给移动端的Unit Test Case。

三、总结

通过以上方式，每次完成一个模块的集成测试，工程师都会编写完整的测试代码，并录制测试对象在所有设备上的截图。日后有任何修改，都会在所有测试设备上进行整个系统完整的回归测试，像素级别的比较可以保证系统所有的页面、每一个像素、在每一台设备上都没有变化，大大节省了回归测试的时间。

通过服务器端统一部署的方式，省去了在iOS和Android两端分别编写测试代码的工作。并且用于测试的JavaScript中，只需要编写面向用户操作的交互指令，大大降低了编写测试代码的技术要求和时间成本。

当系统变得日益复杂、开发人员越来越多、需要适配的机型不断增加时，这种跨平台的自动化UI测试，可以有效保证移动端的质量，毕竟一个移动端的致命bug，有可能需要通过升级版本、应用商店审核、最终用户更新的漫长过程才能得到解决，而这个过程会导致用户的流失。

当然，自动化的测试只能作为人工测试的辅助，完成不适合人类的工作，在第一轮测试中主动发现问题不是自动化测试的长处，即使可以发现，也要付出更多的成本。快速大量的回归测试才是自动化系统擅长的事情。

测试中没有银弹，提高人的主观能动性、避免形式化的束缚、使用自动化技术替代机械劳动，不断提高系统交付质量这条路上永远没有终点。

文章来源：网络 版权归原作者所有

上文内容不用于商业目的，如涉及知识产权问题，请权利人联系小编，我们将立即处理