微信小程序测试

小程序跟app一样，上线需要经过微信的审核。小程序实际是一种免安装的app。类似的比如、小米等手机厂商推出的快应用、支付宝小程序。微信小程序实际是运行在微信之上。小程序的类网页经过微信翻译之后以http数据的形式和服务器进行交互。小程序无法脱离微信来进行使用。

小程序产品的版本类型分为：

开发版、

体验版、体验版无需审核，只需要给微信号权限，经过扫小程序的二维码才能访问。

正式版

微信小程序的页面可以包含：

1，小程序页面（wxml+wxss）

M页页面（h5移动页面）

toast信息（过一段时间会自动消失的信息，比如登录成功的提示消息，1/2秒消失）

弹窗

别人没有遇到的问题

通过展示出来的性能数据，我们能够直观的看到实时的性能，比如切换页面时的页面切换耗时。如果想要看性能的整体的长时间变化趋势，则需要借助trace工具。

　　1、在调试小程序的真机中操作导出trace数据（前提是开启性能监控面板）

2、开发者工具中选中trace工具

3、选择保存trace记录的手机（前提是adb能连接上手机）

　　4、选择前面导出的trace数据

　Cpu变化趋势

Fps趋势（gpu绘制）

部分fps明显偏小，属于性能的bug。

　　内存趋势

其它

 

微信小程序特殊测试点

　　1、小程序包大小不能超过3M，开发版对大小没有限制，但是体验版和正式版都有限制。

　　2、页面层级跳转不能超过10次，比如分类-》居家-》布艺软装-》居家-》被枕-》居家-》。。。达到10次就无法跳转了，如果非要有这种跳转方式，需要考虑不让微信觉得是10次跳转。

　　3、缓存，微信小程序为了提升用户体验，会缓存用户的页面及数据，方便下次调用时直接使用。可能产生的问题：

　　1）微信小程序缓存的数据是否和服务器端一致。实际测试时可以先访问页面，然后修改服务器上数据，再回看小程序中页面，看数据是否一致。

　　2）切换相似的页面，看是否缓存的数据会产生混乱，比如居家和餐厨两个分类，切换分类的时候，会不会因为缓存导致具体信息不发生变化。

 

 

Appium加载的过程图解

　　Appium加载过程

　　调用Android adb完成基本的系统操作

　　向Android上部署Bootstrap.jar

　　Bootstrap.jar Forward Android的端口到PC机器上

　　PC上监听端口接收请求，使用Webdriver协议

　　分析命令并通过Forward的端口发给Bootstrap.jar

　　Bootstrap.jar接收请求并把命令发给Uiautomator

　　Uiautomator执行命令

　　Appium工作过程

　　Appium的C/S模式

　　Appium是基于Webdriver协议添加对移动设备自动化api扩展而成的，所以具有和Webdriver一样的特性，比如多语言支持

　　Webdriver是基于http协议的，第一连接会建立一个Session会话，并通过Post发送一个Json告知服务端相关测试信息

　　对于Android来说，4.2以后是基于Uiautomator框架实现查找注入事件的，4.2以前则是Instrumentation框架的，并封装成一个叫Selendroid提供服务

　　客户端只需要发送Http请求实现通讯，意味着客户端就是多语言支持的

　　Appium服务端是Node.js写的，所以你安装的时候无论哪个平台都是先装node，然后通过npm install -g appium命令安装Appium工具

　　BootStrap介绍

　　Bootstrap作用：

　　Bootstrap是Appium运行在安卓目标测试机器上的一个UiAutomator测试脚本，该脚本的唯一一个所做的事情是在目标机器开启一个socket服务器来把一个session中Appium从PC端过来的命令发送给UiAutomator来执行处理。

　　它会监听4724端口获得命令然后pass给UiAutomator来做处理。

　　Bootstrap在appium中扮演的角色：

　　首先，Bootstrap是uiautomator的测试脚本，它的入口类bootstrap继承于UiautomatorTestCase，所以Uiautomator可以正常运行它，它也可以正常使用uiautomator的方法，这个就是appium的命令可以转换成uiautomator命令的关键；

　　其次，bootstrap是一个socket服务器，专门监听4724端口过来的appium的连接和命令数据，并把appium的命令转换成uiautomator的命令来让uiautomator进行处理；

　　最后，bootstrap处理的是从pc端过来的命令，而非一个文件。

　　所使用的技术

　　Android上使用了instrumentation和uiautomator两套技术

　　iOS使用uiautomation

　　同时还支持firefox, 并可扩展其他平台

　　默认开启4723端口接受webdriver请求 ，4723是appium服务的，专门和脚本打交道；

　　默认开启4724用于和Android设备通讯

　　Desired Capabilities

　　Capabilities是由客户端发送给Appium服务器端，用来告诉服务器去启动哪种我们想要的会话的一套键值对集合。当中也有一些键值对是用来在自动化的过程中修改服务器端的行为方式。可理解成是java里的map，python里的字典，ruby里的hash以及js里的json对象。实际上Desired Capabilities在传输时就是json对象。

　　Desired Capabilities最重要的作用是告诉Server本次测试的上下文。客户端将这些键值对发给服务端，告诉服务端我们想要启动怎样的自动化Session。根据不同的Capabilities 参数，服务端会有不同的行为。

capabilities.setCapability("platformName capability","Android"); 　　capabilities.setCapability("platformVersion","4.3"); 　　capabilities.setCapability("appPackage","com.sogou.map.android.maps"); 　　capabilities.setCapability("appActivity",".MainActivity");

　　问题总结

　　服务端和设备如何通讯？

　　服务端和设备默认使用4724端口进行通讯的，底层调用Uiautomator工具，在测试的时候服务端会给设备扔一个jar包就是bootstrap.jar，会启动这个包，启动之后会在手机上创建一个Socket服务，暴露的就是4724的端口；相对于Socket服务来说，Appium服务端又是一个客户端；

　　服务端的4724可以修改，设备上的不可以；服务端收到脚本传递过来的命令之后，通过电脑上的4724端口，向设备上的4724端口发送指令，bootstrap.jar收到指令后回去完成点击，滑动其他的操作，完成之后再通过服务给服务端一个相应。服务端收到之后再去相应脚本。

 

 

敏捷开发

 

 

 

 

 

 

 

 

 

成了。这只是我正在经历并且一直在重复的上线流程，当然其中会经过多个环境的测试不说了，熟练之后整个上线过程可以在10几分钟内完成。并且我要告诉你的是，所有的线上服务器，我们都是上一台测试一台没有大问题之后再上另一台。可以说这个过程虽然麻烦点，但基本做到无痛更新，也算是稳定高效的，^_^ 。。。

　　当然上面说的最见的小幅更新或打补丁或增加新功能，有时候你会碰到破坏式的更新，需要数据库的变动并且修改不能兼容现在的生产环境，那么恭喜你，发个网站公告，高挂休战牌，找个半夜，速度更新吧，而网站更新流程基本和上边差不多。