【转】如何测试微信应用号

如何测试微信应用号

by云层

原文地址：http://mp.weixin.qq.com/s?__biz=MzA4NDIzNTIzNA==&mid=2654370226&idx=1&sn=38885f86e5d346f8c636d04ba82c3e68

---

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

---

架构

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

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可能就是普通测试和高级测试的关键区别吧。