在网上看到一个很好的就复制过来，以便日后查看
1. 小程序产品的版本类型
小程序分为三种版本类型：开发版，体验版，正式版。
开发版和体验版无需审核，需要给微信号配置权限，通过扫小程序的二维码才能访问。正式版需要通过微信审核流程，也就是说，在开发阶段，产品还未成型开始，无论你想怎么折腾，微信都有办法知道。这可不像你在网上找了个框架或是工具，在本地怎么玩都没人知道。微信小程序开发者工具使用之前就要扫码的。开发版和体验版的区别，在于开发版小程序的二维码有效期比较短。
项目中，我们一般会准备三套环境。开发版访问测试环境，体验版访问预发布环境，正式版访问生产环境。
2. 前后端分离的技术架构
小程序产品大多采用前后端分离的技术架构。虽说前端也有逻辑处理，更多是为了优化体验做缓存，关键流程和状态流转还是要通过调用后端接口来落地的。接触过前后端分离的Web 或 App 项目的测试人员，在小程序产品的测试中是很容易上手的。
RESTful API，http/https 协议，json 数据传输，websocket 协议… 这些基础知识就是测试人员必修课了。还要加强问题的分析和定位能力。发现问题时，需要快速判断是前端，后端，又或是第三方组件的问题。由于小程序产品有不同类型的版本，还需要排除是否不是最新的开发版，是否是多个环境未处理好导致串数据了… 而快速定位问题，需要依据完备的日志。不光是后端接口日志，前端页面在捕获到特殊的客户端异常时也应该上报。这往往是开发人员容易疏忽的地方。
开发架构和团队情况决定了测试策略。小程序的 UI 测试更多是让产品和设计人员去做，测试人员需要关注前后端交互，后端接口测试自动化，兼容性测试等工作。诸如前端是否在应该做缓存的地方没有做，而是频繁调用接口，影响网络体验？…
虽说小程序的 UI 自动化是可行的 (https://github.com/applewu/testlab-python/blob/master/example/enter_into_mini_programs_ex.py) 但界面毕竟变化太快，自动化测试的重心会放在接口层。
测试工具上，我习惯用 burp 抓包，soapui 接口自动化，偶尔用 wssip 来看 websocket 消息。其实微信开发者工具就带有类似 Chrome devtools 功能，测试过程中用着也挺方便。
3. 微信服务通知逻辑
微信内支持服务通知跳转到小程序。没有留意小程序的微信用户，甚至都不太注意服务通知这个名词。其实服务通知已经被大量的社交电商小程序所使用，俨然成为新的营销入口。
微信服务通知，需要小程序传一个 form id 的参数给微信，再根据服务通知模版来向微信用户发送微信服务通知的。然而 form id 不是小程序自行生成的，而是该微信用户在该小程序内操作时，微信产生并返回给小程序的。也就是说，如果用户在小程序页面上操作的时候，小程序前端页面没有把微信提供的 form id 收集下来，并返回给小程序后端，小程序后端是无法发送微信服务通知给用户的。不同的微信用户在小程序内的操作频率不同，form id 的数量也就不同。所以，那些把服务通知方式作为营销入口的小程序们，可真是费了一番脑筋的。
4. 小程序码的兼容性问题
目前小程序不支持直接分享朋友圈，只能分享微信好友。所以很多小程序都采取了“曲线救国”的方式，通过生成带有小程序码的图片，用户可以退出小程序将图片发布到朋友圈。
既然把小程序码作为图片的一部分，就涉及到小程序码的位置，尺寸，还得不影响原有图片的美观，生成的小程序码还需要是可识别的。这需要前端工程师费功夫做不同屏幕尺寸的适配。
我们干脆请了外包公司做兼容性测试。
5. 个人思考
小程序产品作为微信生态的产物，要利用这个流量入口，就得费心力去了解里面的条条框框。正如移动互联网时代，App 并没有替代 Web 系统一样，即便接下来的两三年是微信互联网时代，微信小程序也不会替代 App。然而，正如 App抢走了一部分 Web 使用场景一样，小程序也会抢走一部分 App （工具类，社交电商类）使用场景。所以，从技术人员的角度而言，没必要纠结要不要跳进小程序开发的浪潮里。如果是个人玩票学学也不难，如果是工作使用还是得聚焦于自己选择的行业，行业需要怎样的交互方式和载体，需要提供怎样的服务给客户。
