一、小程序简介
小程序（Mini Program），是一种不需要下载安装即可使用的应用，是内嵌在微信APP里面的一款新形态软件。它实现了应用“触手可及”的梦想，用户扫一扫或者搜一搜即可打开应用。也体现了“用完即走”的理念，用户不用关心是否安装太多应用的问题。应用将无处不在，随时可用，但又无需安装卸载。
1.小程序版本类型
3种版本类型：开发版（测试环境），体验版（预发布环境），
正式版（正式环境）。
项目中，我们一般会准备3套环境。开发版访问测试环境，体验版访问预发布环境，正式版访问生产环境。
开发版和体验版无需审核，需要给微信号配置权限，通过扫小程序的二维码才能访问。正式版需要通过微信审核流程。
微信小程序开发者工具使用之前就要扫码。开发版和体验版的区别，在于开发版小程序的二维码有效期比较短。
- 小程序的架构
1）微信小程序的框架包含两部分，View视图层、AppSerive逻辑层，
View视图层用力啊渲染页面结构，
App Serive逻辑层用来逻辑处理、数据请求、接口调用，它们在两个线程里运行。
2）View视图层使用WebView渲染，AppSerive逻辑层使用JSCore运行。
3）View视图层和AppSerive逻辑层通过系统层的JSBrigdage进行通信，AppSerive逻辑层把数据变化通知到WebView渲染，触发WebView渲染页面更新，WebView渲染把触发的事件通知到AppSerive逻辑层进行业务处理。
3.微信通知服务逻辑
微信内支持服务通知跳转到小程序。没有留意小程序的微信用户，甚至都不太注意服务通知这个名词。其实服务通知已经被大量的社交电商小程序所使用，俨然成为新的营销入口。
微信服务通知，需要小程序传一个 form id 的参数给微信，再根据服务通知模版来向微信用户发送微信服务通知的。然而 form id 不是小程序自行生成的，而是该微信用户在该小程序内操作时，微信产生并返回给小程序的。也就是说，如果用户在小程序页面上操作的时候，小程序前端页面没有把微信提供的 form id 收集下来，并返回给小程序后端，小程序后端是无法发送微信服务通知给用户的。不同的微信用户在小程序内的操作频率不同，form id 的数量也就不同。所以，那些把服务通知方式作为营销入口的小程序们，可真是费了一番脑筋。
二．小程序测试点
- 权限测试
未授权微信登录小程序：
1）未授权时，使用一些业务功能的时候，都会弹出提醒‘先授权再操作对应功能’;
2）在提交数据到后台的时候，会提示补充相关身份信息才能提交。
已授权微信登录小程序：
1）授权微信访问小程序，意味着自己的微信账号可被小程序管理方获取；
2）自动以微信的身份行使业务操作权限，比如咨询、支付、数据查询等 。
所能查看的数据和操作的权限都应该是同步一致的，同一微信号在不同手机端登录授权查看数据权限。
2．功能测试
1.按功能模块测试
模块设计好的各个大类功能模块划分，然后在逐级细分，覆盖到每个功能尽可能全面的测试点。
2.按业务流程测试
1）小程序的业务，比如：播放、支付（支付时注意支付状态：单次授权？免密？）；
2）把各个功能点串联起来形成完整的业务流程来检查；
3）同一业务员，有不同的路径来实现，每个路径都需要覆盖检查。
3.按数据流向测试
1）根据数据从某一端操作输入和输出流向，设计基于数据流的测试用例，输出的数据也可能成为另外一端的输入；
2）检查输入的数据是否按照代码逻辑执行正确的输出；
3）是否数据发生异常，无法输入、有输入却无任何输出、输出不正确、多余的输出其他信息等；
4.同一功能不同入口有效性检查测试
1）小程序在首页、列表页、详细页、其他的业务功能相关页面，都有可能存在同一个功能的入口；
2）每一个入口路径都需要覆盖检查；
5.交互性检查测试
1）一般而言，产生数据和功能交互变化的情况主要有这几个分类：前台与前台之间、前台与后台之间、后台与后台之间；
2）前台从F1页面提交的数据，可能需要在前台F2页面查看到，也会在对应后台的B页面查到记录；
3）后台B1页面修改或者添加的数据，对应到前台的F页面产生交互变化，后台本身的不同页面间也可能存在同一个数据的输出值；
6、支付测试
1）支付时的支付状态：单次授权、免密；
2）解除免密授权是否能进行支付；
3）支付时有金额、无金额、支付顺序等情况是如何处理的；
4）对于未支付的订单是如何处理的；
5）小程序没有授权支付，小程序是如何处理的；
7、UI测试
小程序的页面测试和app的界面测试一样，关注页面展示元素，如菜单、对话框、窗口和其他可视控件的布局、风格，文字是否正确。
页面是否美观，页面交互操作是否友好。操作是否设计频繁、是否易操作。
但注意一点，微信小程序页面层级跳转默认不能超过10次，达到10次就不能跳转了。一般在进行需求设计时，页面跳转尽量在10次以内。有超过跳转10次的应用场景，针对性开发。
8、易用性测试
1.导航
1）定位到页面某个模块所在位置；
2）回到顶部或者底部；
3）导航条的收展；
4）导航标签的文字是否容易理解；
5）页面最多跳转超过限定次数后是否失败（小程序原生页面存在10层限制问题，超过10层便无法打开新页面，而业务流程或者访问形成闭环时很容易陷入10层问题）。
2.功能入口
1）重复且常用业务的功能入口；
2）是否在比较显眼的位置；
3）业务操作是否便于大多数用户使用和查看。
3.上下层进入与返回
1）首页与列表页之间；
2）列表页与详细页之间；
3）首页与详细页之间；
4）不同层级之间的进入和返回实现是否有相应按键易操作；
4.字体、图片、动态交互效果
1）字体：标签、标题、内容、动态播放字体；
2）图片：背景图、轮播图、触屏产生的交互图；
3）操作是否过于繁琐。
9、网络测试
1.网络切换测试
1）WIFI切至2G/3G/4G/5G；
2）WIFI切至无网；
3）2G/3G/4G/5G切至WIFI；
4）2G/3G/4G/5G切至无网；
5）无网切至2G/3G/4G/5G；
6）无网切至WIFI；
2.验证各种网络情况下是否正常
关于网速的选择：
3G：300k-2Mbps左右
2.5G(GPRS)一般在100kbps
2G（GSM）一般在5-9kbps
如果不习惯自定义设置带宽等，可直接测试网速逐渐提升。设置好以后，就可以启动你的小程序进行各种网络测试了。
10、兼容性测试
手机系统：在 IOS上，小程序的逻辑代码运行于JavaScriptCore 中，在Android上，这个任务则是交给 X5 内核来完成。所以有条件的话，不仅要覆盖Android和 IOS，包括主流的Android和 IOS品牌也要覆盖，比如华为，小米，iPhone11，iPhoneXR等等。覆盖到最新的试用版和当前流行的主要版本。
微信版本：与微信版本的兼容性问题主要体现在小程序API库的版本上。因为微信小程序SDK的API版本一直都在更新，导致SDK的API有可能有向下的兼容性问题。例如在最新版本小程序SDK上开发的程序不能在低版本的SDK上像预期的那样运行。所以测试微信版本的兼容性之前要先确定小程序使用的库版本在哪些微信版本号上支持。
屏幕大小：微信小程序定义了一个新的尺寸单位rpx(responsive pixel)。它可以适配不同的屏幕大小，但是需要注意一个特殊的尺寸1rpx，因为这个尺寸经常在iphone7p上出现问题。所以，只需要关注一下即可。
11、版本配置测试
针对不同的模板，在前端程序代码中修改相应的配置参数，做到版本与版本之间的切换。
12、接口测试
目前大部分都是微服务的架构，小程序调用的是后台的接口，所以这里的接口测试和平时的接口测试是一样的，但我们需要了解微信小程序提供的接口是什么类型。
1）有接口文档的，参照接口文档进行接口测试。
2）没有接口文档的，使用Charles或Fiddler抓包(同App抓包)。
13、性能测试
1）页面的白屏时间；
2）首屏时间；
3）资源占用；
4）页面渲染时间
14、缓存测试
用户本地缓存（小程序文件、授权数据、登录数据等）不能超过10MB，缓存的作用是提高程序的流畅性、减少网络请求、节省服务器资源，其缓存测试点：清除缓存时是否强制退出、后台清理以及关机等情况，每次提交或退出时，是否清除了本次表单的缓存。
15、小程序埋点测试
小程序埋点测试与其他端流程基本一致：产品提出埋点需求，开发人员在平台配置埋点事件，然后进行代码埋点，测试人员再测试埋点。
注意：小程序测试过程中经常遇到的坑：层级页面跳转、兼容性、缓存。
三、小程序常见问题
1.小程序的架构是怎么样的？
小程序的架构：包含View视图层、AppService逻辑层。
View层用来渲染页面结构，AppService层用来逻辑处理、数据请求、接口调用，它们在两个线程里运行。
视图层使用WebView渲染，逻辑层使用JSCore运行。视图层和逻辑层通过系统层的JSBridage进行通信。
2.小程序测试和APP测试的异同点有哪些？
小程序测试和APP测试在功能测试上逻辑一样，主要是理解项目的需求设计等，查看功能模块、业务流程、同一功能不同入口时有效性检查、页面交互性检查、输入输出等逻辑进行测试。不同点包括以下几个方面：
开发方面：小程序开发周期一般在两周左右，需要在公众平台上进行审核，审核周期一般较短；APP的开发周期在一个月左右，APP需要应用商店进行审核，审核周期较长。
1)权限上的区别：微信小程序需要验证是否有微信授权，未授权/授权登录程序，同一微信号不同手机登录查看数据显示情况；APP测试则需要考虑是否可以访问手机通讯录、相册、相机等权限。
2）性能方面：小程序页面可能只会关注响应时间，而APP则还需要关心流量、电量、CPU、GPU、Memory等。
3)兼容方面：小程序是基于浏览器的，所以更倾向于浏览器和电脑硬件，而浏览器的兼容则是一般是选择不同的浏览器内核进行测试（IE、chrome、Firefox）。APP的测试则必须依赖客户端，不仅要看分辨率，屏幕尺寸，还要看设备系统。
4)从测试场景来看：APP是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件，小程序是基于浏览器的，所以不必考虑这些。
5)从系统架构来看：小程序测试只要更新了服务器端，客户端就会同步会更新。但是APP端是不能够保证完全一致的，除非用户更新客户端。如果是APP下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。
6)缓存方面：缓存的作用是提高程序的流畅度、减少网络请求，节省服务器资源，有时候用户会进行清理缓存的情况。APP和小程序都会存在缓存，但小程序最大只有10M的本地缓存，测试时需要考虑清除缓存时强制退出、后台清理、关机等情况。
7)运行流畅度：原生App运行在操作系统中，所有的原生组件可以直接调用GPU进行渲染；小程序运行在微信的进程中，只能通过WebView进行渲染。用HTML+CSS+JS开发，配合微信的解析器最张渲染出来的原生组件的效果，比H5体验上更好。
8)占用空间方面：App 会一直存在手机中占用空间，太多的 App 可能会导致内存不足；小程序因为不需要安装，占用内存空间忽略不计；
3.非公用部分
不同版本直接的切换，需要保证彼此的功能模块和数据独立性不受干扰，也就是不同版本的管理后台添加的数据只应该调用到各个对应模板的前台小程序中，不同的版本小程序从前台提交的数据也只会提交到各自管理后台。
4.公用部分
切换不同的版本，都会显示相同的功能模块和公共数据信息。
5.小程序测试技术
1)小程序的特点
1.类似WEB.非HTML5
2.即用即走，随手可得
3.拥有离线能力
4.基于微信跨平台
5.媲美原生操作体验
四、H5的认识
H5优势：
1.H5可以跨平台，开发成本相对较低；
2.H5可随时上线就更新版本，适合快速迭代；
3.H5可以轻量的触达用户，提供更快捷的服务；
4.在微信入口或者浏览器上，用户只需点开链接就可以获取我们所提供的服务。
H5劣势：
1.H5->的转化强依赖于浏览器；
2.H5目前基本无法将数据存储在本地，依赖实时性数据，网络状态不好的时候卡到哭。
3.性能相对较低，影响用户体验。
H5功能验证
1.通过H5网页（非手机的返回功能）的返回功能可以返回，不会出现无法返回的情况。
返回逻辑：
对于页面中的返回，以及浏览器自带的返回的测试。页面中的返回要考虑业务逻辑，返回到相应层次，需要从用户角度返回的转跳逻辑，不能出现死循环。并要注意返回后是否需要刷新页面请求通过H5页面（非手机自带返回键）的返回功能键返回，可以返回到正确的页面（上一级/退出H5）点击返回与back键，回退页面是否是期望页面。
横屏竖屏相互切换，能自适应，并且布局不会乱掉；或页面只支持横或竖屏限制。
在手机上从list点击进入detail页面，要在原窗口打开，这样可以通过页头的返回按钮返回，而不需要通过手机的返回键返回，这样交互上更友好。
关注页面请求，是否会有多余的请求，或者请求后有多余的数据返回，尽量精简，否则会浪费流量。
5.图片适配测试，根据不同屏幕和分辨率做适配，以及适配后的清晰度，高端机取双倍尺寸的图--app兼容测试。
