1、没有需求文档时，如何测试小程序？
现在大多数公司的开发模式是：敏捷模式（用户故事） ，即以什么身份做什么事情会出现什么样的结果。
那实际测试过程中，没有需求文档时，测试可以采用以下方式更好的完成测试工作。
1）、熟悉被测系统，并形成可读性文档，方便后续查看，做到有迹可循
2）、找同类系统对比测试，这要建立 在测试人员对该行业有一定的了解
3）、自己找资料，如果实在不行，再找开发人员，问问功能的实现逻辑和业务背景
2、如何设计小程序的测试用例
设计测试用例分为：常用设计方法、用例设计思路
1）、常用设计方法：等价类、边界值、流程图、场景法、错误推测法
2）、用例设计思路：单模块、单模块的数据影响、模块与模块之间的数据流转、项目的整体功能
3、小程序的用例设计需要关注哪些点？
1）、和微信的切换，例如：微信有新消息，有视频电话时
2）、和对应的app,web的数据互通
3）、小程序和手机的交互，例如：通知管理、小程序的强制升级、横竖屏显示等
4、小程序具体需要测试哪些内容？
1）权限测试
需要检查以下几种情况下微信用户访问的权限
a、未授权微信登录小程序
未授权时，一般使用一些业务功能的时候，都会弹出提醒：先授权再操作对应功能。或者在提交
数据到后台的时候，会提示补充相关身份信息才能提交成功。
b、已授权微信登录小程序
授权微信访问小程序，意味着自己的微信账号可被小程序管理方所获取，自动以微信的身份行使业务操作权限，比如咨询、支付、数据查询等。
c、同一微信号在不同手机端登录授权查看数据权限
同一微信号在不同手机微信端授权登录同一小程序之后，所能查看的数据和操作的权限都应该是同步一致的。
2）、功能测试
a、按功能模块测试
根据设计好的各个大类功能模块划分，然后再逐级细化，覆盖到每个功能尽可能全面的测试点。
b、按业务流程测试
小程序的业务，比如咨询、支付、播放、查询、下载。把各个功能点串联起来形成完整的业务流
流程来检查；同一个业务，可能有不能的路径来实现，每个路径都需要覆盖检查。
c、按数据流向测试
根据数据从某一端操作输入和输出流向，设计基于数据流的测试用例，输出的数据也可能成为另外一端的输入，检查输入的数据是否按照代码逻辑执行正确的输出，是否数据发生异常（无法输入；有输入却无任何输出；输出不正确；多余的输出其他信息…）
d、同一功能不同的入口有效性的检查
小程序中在首页、列表页、详细页、其他的业务功能相关页面，都有可能存在同一个功能的入口，如付费咨询、免费咨询业务中，可以直接从首页进入付费咨询入口，也可以通过免费咨询入口再切换到付费咨询入口。
e、交互性检查
一般而言，产生数据和功能交互变化的情况主要有这几个分类：前台<–>前台、后台<–>后台、前台<–>后台。前台从A1页面提交的数据，可能
需要在前台A2页面查看到，也会在对应后台的B页面查到记录；后台B1页面修改或添加的数据，对应到前台的A页面产生交互变化，后台本身的不同页面之间也可能存在同一个数据的输出值。
3）、界面测试
设计是否美观、设计是否符合要求、尺寸是否合理、横竖屏切换操作
4）、兼容性
小程度和微信上的其他小程序、微信版本、手机平台、不同网络状态、系统
5）、交互
微信到小程序、交易小程序的付款、与手机系统自带的app交互、与微信其他功能交互
6）、易用性
a、导航
定位到页面某个模块所在位置，回到顶部或底部，导航条的收展，导航标签的文字是否容易理解。
b、功能入口
重要且常用业务的功能入口，是否在比较显眼的位置，是否方便搜索，业务操作过程是否便于大多数用户使用和查看。
c、上下层级进入和返回
首页<–>列表页、列表页<–>详细页 、首页<–>详细页。不同层级之间的进入和返回实现是否有相应按键易操作。
d、字体、图片、动态交互效果
字体：标签、标题、内容、动态播放字体…
图片：轮播图、背景图、封面图、触屏产生的交互图…
e、其他
页面的响应时间、资源占用、渲染时间、耗电量、白屏
7）、安全测试
接口：传递数据的时的保密、微信账号授权与取消、小程序与app账号的关联8）、其他
小程序的升级更新、分享、添加删除我的小程序、取消授权