微信小程序的测试方法

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

用例执行

测试报告

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:1024 设计师:我叫白小胖 返回首页
评论

打赏作者

帅气10足

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值