Android
一、apk下载和安装
内部协作
软件的版本迭代、bug修复后如何打包，测试如何下方便下载和调试
协作工具：
蒲公英
地址：蒲公英-免费且不限次数的App内测托管平台|iOS|Android安卓|内测托管|内测分发|应用内测
介绍：开发者可将打包好的包上传到蒲公英，蒲公英记录每次上传的包信息，可设置上传邮件自动发送，生成下载安装包所用的二维码，下载链接；可根据环境不同创建多个项目版本，在不同版本内上传维护对应的包；如：debug包、预发包、线上包；蒲公英也可打开应用商店的更新信息，线上包发布后自动同步应用商店；
协作痛点：
1、每次发版 修复bug开发都会打一个新包丢给测试，测试需要通过开发提供的链接扫码下载，验证功能是否正常；一旦上线打的上线包又要重新下载；项目迭代过程中频繁修复bug、发布，测试来回下载浪费不必要时间；
2、三端不同步发布、开发口头表述让测试去蒲公英上找历史包，测试需要对上版本回归，保证上一版本兼容本次发布版本，服务端造成不必要的报错等信息；此时蒲公英上包的划分标识，就需要稳定维护才可体现出来；
3、大版本发布必须更新软件，而从端上更新会跳到一个新包地址，下载完成覆盖了原来的包，这就导致debug包自动被覆盖，需要重新下载；
解决思路：
发布小版本、bug修复，下载的debug包打开后让开发配置一个隐藏的可切换环境区域，有几个环境放几个，然后切换可触发自动热更新；若发版、修复完bug开发提测后，告知对应环境的版本号，打开app切换环境进行更新验证；
app版本更新迭代分为整包更新和热更新。整包更新是整个app安装包需要重新下载安装，它通过应用市场来更新，整包的体积比较大，下载速度慢。热更新就是动态下发代码，当用户打开app时，通过网络下载升级包来直接更新，不需要发布新版本到应用市场。升级包的体积比较小，下载速度快。
发布一个app新版本，要上架到应用市场是需要审核的。ios应用市场审核很严格而且审核需要一定的时间，android市场也一样，遇到一些节假日会往后延期。
热更新的方式可以绕过应用市场的审核，所以对于紧急的bug修复以及实时性较强的功能发布（比如运营活动）比较适合。
此处涉及到应用商城更新的问题，如果我们的Addroid项目借助应用商店更新较少，或已弃用，私欲扫码下载较多，那启动热更新还是可以的；
问题定位
在测试时，发现问题需要及时定位日志，如果没和开发约定好如何排查日志，如何抓包，那么就会导致测试只能停留在界面操作，无法观察接口请求，软件日志等等
协助工具：charles ；adb命令，服务端日志；
cherles使用和配置：
(143条消息) 苹果手机charles抓包_charles iphone抓包_牛大个的博客-CSDN博客
cherles 替换请求头、接口响应信息；
协作痛点：软件无法抓包，没有内部日志信息可以查看，无法快速定位问题；
解决思路：约定好debug包在那些环境可以实现简易抓包，在生产环境如何双向校验抓包，软件内嵌入调试排查工具在对应网站上可以观察日志；遇到闪退 崩溃之类的问题 adb调出日志；
3、功能测试覆盖思路
根据业务形式的不同，软件的功能，UI 等都不相同，但大部分测试场景和手段相同，要有思路的做测试，写用例，排查问题；归纳软件整体的业务代码及测试都是增，删，改，查，个别场景用到定时器；
页面查询的场景：
- 搜索框搜索：模糊查询，非模糊查询；展示内容是否正确；非查询条件的是否正常；
- 数据加载：页面加载速度；加载内容是否正常；后台新增或编辑后展示 加载内容是都正确；
添加的场景：
- 注册登录
- 领取xxx
- 新增xxx
- 合成xxx
- 购买xxx
- 抽取xxx
- 添加重复数据：若接口未做幂等、去重处理，快速请求会导致添加重复数据；
- 添加一些非正常数据，校验薄弱的话，都是在为之后埋坑
删除的场景：
- 端上一般只做逻辑处理，除非逻辑闭环非常严谨，才做删除操作，删除的数据无法追溯；
- 测试时若有复选框 可考虑 选择多条记录 删除，非批量删除观察删除的记录是否正确；
- 删除时同样需要考虑关联数据，如删除 订单记录，那该订单发货了数据如何展示，该笔消费订单详情如何展示；
修改的场景：
- 编辑xxx；
4、版本发布
app版本发布涉及到不同品牌手机的应用商店审核；这就导致不同品牌的用户通过应用商店下载app，更新app不同步；审核涉及到法律条规，若审核的业务和app不通过也会被拒；IOS-AppStore审核时间不确定，拒绝的风险也高；
目前方案：
1、贴入最新包地址的二维码，用户扫描下载；
2、点击链接在H5页面点击下载按钮；
-------持续更新中
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
