2017年1月9号微信小程序正式上线，不需要安装，只要在微信里找到这个小程序打开即可使用。

以前测试手机端会接触到原生程序、H5页面和混合型程序，现在又多了个小程序。

我们该如何测试微信小程序呢？

功能测试

功能测试以需求文档和交互视觉文档为准，如果没有这些文档，参考APP的测试方法，也就是说就把它当做手机的APP来测试即可。我看到网上有人说把小程序当做WEB来测试（原因大概是里面有不少JS代码），这一点我不认同，因为我们现在测的是功能和主流程，并且是在手机上进行的测试。

兼容性测试

操作系统兼容性

这里的操作系统主要是指android系统和iOS系统。小程序运行在微信中，看起来是跟操作系统没关系，实际上还是有关系的，因为底层调用依赖于具体的操作系统。按照官方文档在微信小程序在ios上是运行在JavaScriptCore中但在Android上是通过X5JSCore来解析的。

如果有条件，不仅要覆盖android和iOS，包括主流的Android品牌也要覆盖，比如华为，VIVO等等。覆盖到最新的试用版和当前流行的主要版本。

屏幕兼容性

普通的手机APP会有屏幕兼容性的问题，小程序同样有这样的问题，只不过相对少了些。微信小程序定义了一个新的尺寸单位rpx(responsive pixel)可以适配不同尺寸的屏幕，在页面上定义对象的单位是rpx就可以在不同的屏幕上适配。但1rpx的像素经常在iphone7p上出现断线的情况。因此需要在测试过程中关注1rpx像素的显示。

微信兼容性

因为微信小程序SDK的API版本一直都在更新，导致SDK的API有可能有向下的兼容性问题并最终会影响到在最新版本小程序SDK上开发的程序不能在啊低版本的SDK 上像预期的那样运行。所以测试微信版本的兼容性之前要先确定小程序使用的库版本在哪些微信版本号上支持。

网络测试

网络测试可以参考APP的测试，比如网络状态和环境的切换，断网，通过设置代理进行弱网的测试等等。主要是考察小程序在各种网络状况下的运行情况。

接口测试

目前大部分都是微服务的架构，所以前端的小程序调用的是后台的接口，所以要对接口进行测试，这里的接口测试和平时的接口测试是一样的，没有特别之处。但是我们需要了解的就是，微信小程序SDK提供的接口时websocket，这是另外一种接口形式。

易用性

APP的易用性该如何测试，小程序的易用性就如何去测试

功能交互   

因为小程序是在微信里面，所以还需要验证一些跟微信的交互

入口

可以通过微信聊天页面的下拉框找到小程序（如果已经打开过一次）；也可以通过“发现”模块下的“小程序”中的搜索框搜索到对应的小程序；还可以通过“附近的小程序”找到小程序

交易

小程序支持交易，那么它与微信的钱包、卡包都是可以交互的。如果有交易功能，需要验证各种交易场景。

缓存

比如需要验证清空微信的缓存是否对小程序有影响

消息限制

根据开发文档，有如下消息限制

支付当用户在小程序内完成过支付行为，可允许开发者向用户在7天内推送有限条数的模板消息（1次支付可下发1条，多次支付下发条数独立，互相不影响）

提交表单 当用户在小程序内发生过提交表单行为且该表单声明为要发模板消息的，开发者需要向用户提供服务时，可允许开发者向用户在7天内推送有限条数的模板消息（1次提交表单可下发1条，多次提交下发条数独立，相互不影响）

性能测试

小程序的性能不是测试小程序的重点，优先级也比较低。小程序的性能和WEB的性能测试非常类似，性能的常用指标也大致相同。包括页面的白屏时间，首屏时间，资源占用，页面渲染时间，帧率等等。

小程序开发版中打开性能窗口即可看到页面的性能数据, 但如果是正式发布的版本需要通过埋点才能搜集这些信息。

安全

小程序是内嵌到微信的，但腾讯并未花太多精力在小程序的安全性上，2017年小程序的大漏洞就说明了这一点。不要指望腾讯帮你提升完全性。对于测试人员，安全相关的测试能做的毕竟有限，我们所要做的就是知道小程序有安全隐患就行了，比如小程序运行后在手机上能看到一个wxapkg的一个包，这个包解压后就是可以认为是小程序的源代码。

权限

这里的权限指的是访问权限是否授权，所以权限测试分为“已授权”和“未授权”，所以需要测试在跳转到微信小程序时“允许访问”和“不允许访问”这两种情况下小程序是否各项功能能够正常工作。

测试人员也可以参考小程序官方的文档 https://developers.weixin.qq.com/miniprogram/design/index.html

2017年1月9号微信小程序正式上线，不需要安装，只要在微信里找到这个小程序打开即可使用。

以前测试手机端会接触到原生程序、H5页面和混合型程序，现在又多了个小程序。

我们该如何测试微信小程序呢？

功能测试

功能测试以需求文档和交互视觉文档为准，如果没有这些文档，参考APP的测试方法，也就是说就把它当做手机的APP来测试即可。我看到网上有人说把小程序当做WEB来测试（原因大概是里面有不少JS代码），这一点我不认同，因为我们现在测的是功能和主流程，并且是在手机上进行的测试。

兼容性测试

操作系统兼容性

这里的操作系统主要是指android系统和iOS系统。小程序运行在微信中，看起来是跟操作系统没关系，实际上还是有关系的，因为底层调用依赖于具体的操作系统。按照官方文档在微信小程序在ios上是运行在JavaScriptCore中但在Android上是通过X5JSCore来解析的。

如果有条件，不仅要覆盖android和iOS，包括主流的Android品牌也要覆盖，比如华为，VIVO等等。覆盖到最新的试用版和当前流行的主要版本。

屏幕兼容性

普通的手机APP会有屏幕兼容性的问题，小程序同样有这样的问题，只不过相对少了些。微信小程序定义了一个新的尺寸单位rpx(responsive pixel)可以适配不同尺寸的屏幕，在页面上定义对象的单位是rpx就可以在不同的屏幕上适配。但1rpx的像素经常在iphone7p上出现断线的情况。因此需要在测试过程中关注1rpx像素的显示。

微信兼容性

因为微信小程序SDK的API版本一直都在更新，导致SDK的API有可能有向下的兼容性问题并最终会影响到在最新版本小程序SDK上开发的程序不能在啊低版本的SDK 上像预期的那样运行。所以测试微信版本的兼容性之前要先确定小程序使用的库版本在哪些微信版本号上支持。

网络测试

网络测试可以参考APP的测试，比如网络状态和环境的切换，断网，通过设置代理进行弱网的测试等等。主要是考察小程序在各种网络状况下的运行情况。

接口测试

目前大部分都是微服务的架构，所以前端的小程序调用的是后台的接口，所以要对接口进行测试，这里的接口测试和平时的接口测试是一样的，没有特别之处。但是我们需要了解的就是，微信小程序SDK提供的接口时websocket，这是另外一种接口形式。

易用性

APP的易用性该如何测试，小程序的易用性就如何去测试

功能交互   

因为小程序是在微信里面，所以还需要验证一些跟微信的交互

入口

可以通过微信聊天页面的下拉框找到小程序（如果已经打开过一次）；也可以通过“发现”模块下的“小程序”中的搜索框搜索到对应的小程序；还可以通过“附近的小程序”找到小程序

交易

小程序支持交易，那么它与微信的钱包、卡包都是可以交互的。如果有交易功能，需要验证各种交易场景。

缓存

比如需要验证清空微信的缓存是否对小程序有影响

消息限制

根据开发文档，有如下消息限制

支付当用户在小程序内完成过支付行为，可允许开发者向用户在7天内推送有限条数的模板消息（1次支付可下发1条，多次支付下发条数独立，互相不影响）

提交表单 当用户在小程序内发生过提交表单行为且该表单声明为要发模板消息的，开发者需要向用户提供服务时，可允许开发者向用户在7天内推送有限条数的模板消息（1次提交表单可下发1条，多次提交下发条数独立，相互不影响）

性能测试

小程序的性能不是测试小程序的重点，优先级也比较低。小程序的性能和WEB的性能测试非常类似，性能的常用指标也大致相同。包括页面的白屏时间，首屏时间，资源占用，页面渲染时间，帧率等等。

小程序开发版中打开性能窗口即可看到页面的性能数据, 但如果是正式发布的版本需要通过埋点才能搜集这些信息。

安全

小程序是内嵌到微信的，但腾讯并未花太多精力在小程序的安全性上，2017年小程序的大漏洞就说明了这一点。不要指望腾讯帮你提升完全性。对于测试人员，安全相关的测试能做的毕竟有限，我们所要做的就是知道小程序有安全隐患就行了，比如小程序运行后在手机上能看到一个wxapkg的一个包，这个包解压后就是可以认为是小程序的源代码。

权限

这里的权限指的是访问权限是否授权，所以权限测试分为“已授权”和“未授权”，所以需要测试在跳转到微信小程序时“允许访问”和“不允许访问”这两种情况下小程序是否各项功能能够正常工作。

注：

测试人员也可以参考小程序官方的文档 https://developers.weixin.qq.com/miniprogram/design/index.html

作者：九遐
链接：https://www.jianshu.com/p/b9d2e66af160
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

https://developers.weixin.qq.com/miniprogram/design/

微信小程序的定义

依附于微信而无需再次下载安装的移动端应用程序

微信小程序的特点

无需下载，即用即走
功能丰富，清爽体验
流量大、易裂变

微信小程序的局限性

数量:每个应用最大支持页面层级为10层
大小:小程序支持不超过8M的源码文件(分包加载，单个分包不超过2M)
逻辑:过于复杂逻辑存在不可控的异常问题

前期准备

申请开发者APPID
https://mp.weixin.qq.com/
下载稳定版微信开发者工具

测试人员需要了解以下三部分：

前端和后台的通讯模式

web端和小程序的区别

APP和小程序的区别

微信小程序的文件类型

小程序的项目和产品

https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/login.html

小程序的功能测试设计

需求分析

1.1需求来源
外部〔用户}
内部（客服.运营.团队、老板）

1.2需要展现
需求说明书文档
产品型图、没计图

1.3分析思路
总:从产品介绍及背景把控被测对象
分:按照需求拆分功能模块，直到能够设计用例
总:从产品层面串联整个模块设计测试场景

1.4分析结果
Xmind测试点整理
业务流程图
测试点文本

计划和方案

测试计划的要素构成：
项目概述：目的、背景、其他
目的：指导整个项目实施的测试过程：明确测试对象、范围内容：能够指导完善测试结果的输出。
背景：为什么做，做的目标是什么，为了提升特色产品的线上销售，借助微信的大流量入口，方便有移动网络的用户通过微信小程序

测试任务：测试目标、测试对象、测试范围、测试准则、测试环境、测试资源。

测试目标：
1.通过测试，需要达到以下目标:
2.产品能够覆盖需求说明书中的所有需求;
3.在网络正常的情况下，小程序能够持续无故障运行;
4.缺陷数量在可控范围内，上线要求缺陷修复率达到95%以上;能够达到专项测试指标

测试对象：

测试范围：

测试准则：
1、启动测试的时间：
开始接入测试:
确保单元测试通过
模块之间的联调测试通过
确认提交的测试版本
冒烟测试通过（测试）

2、结束准则：
结束测试:
确保核心测试用例执行完毕；
确保中级以上的缺陷全部修复，且 bug 修复率达95%以上；
测试由于其他原因中断无法进行，通知相关领导进行下一步确认；

测试环境的确认：
(1）开发环境
开发工具:PhpStoxm、微信开发者工具
硬件平台: 1核CPU+ 1 GB内存+50GB硬盘
操作系统: Windows10、CentOs 7
(2）测试环境
测试手机:手机（Android、i0S）、终端模拟器、测试PC (windows10)
服务器:Centos 7（云服务>
服务器配置:1核CPU+2G内存+50GB硬盘
技术框架:Linux + Apache + MySQL+ PHP（LAMP>
(3）正式环境
平台应用环境:LAMP 【CentOS7.O+Apache2.4+MySQL5.5+ThinkPHP5.0】
小程序应用环境:微信公众平台小程序正式版发布

测试资源：
工作量安排

测试阶段、任务、工作量（人.天）、人员分配、预计开始时间、预计完成时间、备注。

测试里程碑：

项目风险：风险来源、风险影响、风险处理

风险来源：
1、产品层面
设计不完善
需求挖掘不深入
需求发生变更

2、开发层面
设计有缺陷
设计没有文档
缺陷修复不严谨

3、测试层面
测试环境、测试工具
设计测试用例有遗漏
测试业务不熟，导致验证缺陷不完善
第三方账号或工具的准备

4、其他层面
法律制度影响

风险影响：
正面影响:积极引导，持续跟进
负面影响:正向转化或引导(重点关注)

风险处理：
回避、转移、减少、接受

测试方案：设计方法、测试工具、测试策略
设计方法：
黑盒测试的方法：等价类划分法、边界值法、流程图法、因果图判定法、正交表错误推测法、状态迁移法
白盒测试的方法:逻辑覆盖、循环覆盖、基本路径测试

测试工具：
测试中使用的 BUG管理工具为禅道
接口测试工具为Postman
服务器连接工具 xshell
数据库连接工具 Navicat
微信开发者工具（模拟器）

测试策略：
总则：
80/20原则，用最少的资源发现最多的缺陷
1.同步进行一些核心节点:测试计划与方案+测试点的提取
2.设计测试用例的需要制定优先级，方便提取核心测试用例（冒烟测试）
3.测试执行过程中，对于部分用例进行同步更新和完善
4.在执行过程中，按照测试用例模板要求做好执行日志记录
5.提取测试重点任务，进行有技能经验的测试人员参与测试

细则：
1.功能测试阶段
测试轮次，必须达到三轮以上，明确不同环境下的测试区别，提取不同的测试用例;回归验证重要缺陷时，需要确认对应缺陷的相关联业务是否受影响。

2.UI测试阶段
前期需要结合UI设计图进行手动测试;
后期结合UI自动化的技术提升效率

3.性能测试阶段
(略)
4.可靠性测试阶段
需要前端发布上线后，在一年内不会出现重大故障

测试实施：按阶段实施
单元测试阶段
验证代码本身的逻辑或者语法，主要由开发人员完成。
集成测试阶段
针对单个模块的组装测试，更多的是验证模块接口是否存在问题，主要由开发人员完成。
系统测试阶段
业务产品角度，去验证产品是否符合产品需求。
验收测试阶段
在用户角度，结合实际用户使用场景，进行测试验证。

测试管理：文档管理、缺陷管理
文档管理
将项目实施过程中产出的文档进行归档维护管理，一般由 git或者SVN授权部分人员去维护。|

缺陷管理
根据缺陷管理工具，针对当前项目模块的所有缺陷进行分类管理，分析模块或者产品层面的质量。最终目标是发现项目过程中出现问题阶段的人员、资源质量、技术等、方便后期的提升和改进。

用例设计

用例ID
用例标题
所属项目
用例优先级
预置条件
测试数据
执行步骤
预期结果

测试用例编写方法：

.1 常见规则
所有设计需符合国家法律法规行业标准要求UI元素显示根据屏幕大小进行自适应
手指操作能够正确响应，有响应效果（默认显示、触摸显示、操作完毕显示）
尽可能减少用户编辑的操作，提供便捷快速的选择（单/复选、下拉列表选、OCR识别)删除操作时有确认提醒的操作（弹框提示)
支持手指点击，双击，左右、上下滑动操作（下拉刷新、上拉加载)支持物理/虚拟键盘的常规操作（打开、关闭、返回)
停留在当前页面时，如果后台的数据发生变化后，通过操作菜单触发页面刷新后能更新成功
不同操作菜单对应有默认的显示状态
所有应用到金额的地方默认保留两位有效数字

用例执行

测试报告