如何测试微信应用号

lsekfe · 发表于 2016-10-8 16:43:26

每一次微信的动作都是商机，而随着微信应用号的即将面世，微信应用号的开发和测试又会成为一股新的风向。其实经常有人问到微信服务号或者微信订阅号怎么测试的相关内容，可能总觉得比较缺乏技术含量不太想说，这次看了下应用号，就把所有问题都统一起来一起说一下吧。

架构

做测试首先应该从整体看起来，架构体系决定了测试的思想。微信的整个开发都基于下面几个东西。

1.开发者信息

首先是开发者ID，包括Appid和AppSecret两个内容，在微信开发者上设置的。一个用来唯一标示应用类似于用户名，另外一个是登陆的类似密码的东西。

2.接口

接口测试测试工具，对于应用来说第一件事情就是通过前面的用户名appid和密码appsecret来获取token令牌。

在后续的请求中，使用令牌来完成（令牌有点cookie或者sessionid的概念，应该也有超时的控制）

3.前端页面

微信提供了一个前端调试工具（微信Web开发者工具），其实你也可以认为是一个chrome的定制版

在企业号、公众号这类的开发都是在这个平台上实现的。

4.交互

整个交互过程可以这样理解，通过微信的公开接口来获取一些微信用户的信息以及关键交互，而额外的内容是需要在自己服务器上实现的。可以这样理解，微信上来登陆，获取用户信息，把用户信息作为参数传送给自己应用的登陆部分并且绑定用户的一个UID，从而实现的微信账号和应用账号的绑定。

如何测试

在聊过上面4点架构内容以后，测试的内容就可以来说了。

1.功能测试

A.如果做基本功能，可能就不需要知道appid和appsecret了，这样的测试可以理解成没什么技术含量的点点过程。真的要深入测试，那么包含从微信接口上获取数据到自身系统的部分，检查下是不是数据过来了，过来的对不对，高级点可以抓一下包看一下，普通点就看数据库。

B.适配兼容，由于是H5的内容，在不同浏览器上和手机分辨率上仍然存在适配问题。

C.手机的一些专项测试，基本可以不要考虑，因为是H5的内容，所以大多数问题也解决不了的。
2.非功能测试

这块可以谈的东西比较多，包含性能、接口、自动化。

2.1性能测试性能问题主要有两个点：

A.微信接口的性能这个不归你管，你也不用测，因为微信自己有个规范来限制超时和连接数，所以系统在别人那边你做不了啥。
B.自己系统的性能虽然你要从微信的接口上拿数据，但是最终的处理还是会回到自己的系统上，所以这块的性能测试会比较重，加上微信的交互体系决定了什么都要去服务器上问，对服务器上接口的负载是很高的，一旦某一个请求或者某一个业务的请求出现点性能问题，可能就会功亏一篑。

那么要读微信接口的内容怎么办？做个Mock服务器就是必须的了，要么缓存掉微信服务器返回的数据，要么自己做个假的mock应答。

2.2 接口测试

由于所有的内容其实都是所谓的微服务，所以对于这些服务的接口测试是十分重要的，前面性能的问题解决了，接口的问题自然也就解决了。

可以说接口测试是所有测试中最重要的基本保障测试。

2.3 自动化测试

H5的自动化，就涉及到浏览器端和手机端，几乎就是robotium/appium+webdriver的天下。个人觉得意义不大，因为接口都测好了，而微信业务也相对简单，手工跑跑就差不多了。如果非要顶上一个遍历的概念，我还是觉得走monkey这类纯坐标体系的也许更好点，验证下是不是对应的请求都发出来了即可。

应用号到这里为止其实都在谈企业号，那么我们的主题不是应用号么？

接着来说下应用号，根据云层最近看到的文章和相关介绍，应用号是一个平行于企业号的东西，应用号的开发和企业号很像，但是有些区别，比如

可以看到开发UI的代码并不是H5的基本标签，而是换了一套微信自己的标签体系，可以这样认为微信为大家定制了一套UI控件（Frame），来解决以前H5某些无法实现的功能，而这些东西可能是基于Hybrid模式的，就是非完全H5的内容，而是基于微信体系的控件体系的。

类似于微软WPF中的XAML，将布局转化到xml，事件执行走JS体系，自己的容器完成了布局到CSS的挂接至于是不是生成一个源生的控件还是一个特殊封装的控件就要等结果出来了。

从开发人员的角度就是我靠，又要从B/S体系换回到C/S体系了，DOM这套不要折腾了。

对测试人员来说，其实变化不大，因为本来也不需要知道实现这层是怎么做UI的，更多关心的是控件或者按钮能不能用和服务器交互怎么样，从某些角度来说对测试是几乎透明的。应用号测试那么应用号测试的变化在什么地方呢？
A.调试可能会麻烦点，看微信怎么给平台。因为基于微信自己的体系，如果要非要在线调试就麻烦了。也就是说以前可以开个网页调试跟踪，现在要在线了，除非微信给你一个集成好自身体系的开发工具。

B.微信自己的坑，因为是基于微信的控件及某些模块体系，如果它自己做的有问题，那么你是无能为力的，所以只能躺着等微信改。以前貌似也这样，至于应用号是不是做的更好了一点，就不得而知了。

C.自动化能不能做，不知道最终微信这套内容下来的体系是怎么样的，是标准hybird还是自己再封装的。工具是不是能有效的识别到内部的对象，或者微信会不会给一个自己的自动化体系？ps.貌似以后是css定位的天下了，id没用了，xpath估计也危险了。

微信小程序是一个平台，对于开发人员来说缩短了开发周期，降低了开发难度（APP开发又要失业一堆人了），而对于测试来说，UI和基本交互可能出现的问题会进一步减少，对技术测试（接口，性能）的要求会进一步提升，甚至在调试工具上可能也会越来越多的要求测试介入。
在这点上有没有能力拿到AppID和Appsecert可能就是普通测试和高级测试的关键区别吧。