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识别)删除操作时有确认提醒的操作（弹框提示)
支持手指点击，双击，左右、上下滑动操作（下拉刷新、上拉加载)支持物理/虚拟键盘的常规操作（打开、关闭、返回)
停留在当前页面时，如果后台的数据发生变化后，通过操作菜单触发页面刷新后能更新成功
不同操作菜单对应有默认的显示状态
所有应用到金额的地方默认保留两位有效数字
