无论是上架到应用市场还是直接安装在一些硬件上的APP，测试中都会测到在线升级这个场景。
最近在工作中就涉及到了给客户现场硬件上的APP在线升级，第一次检测更新的时候报“http error 404”，这个报错比较好解决，是因为更新地址填错了，缺少部署升级环境时开通的端口号，本以为把端口号加上后就没有问题了，但是这个时候却报了“http error 403”。
what？我在自己的测试环境明明是OK的呀，查看客户升级环境里上传的安装包和update文件的正确性、存放路径都没有问题，本人表示一脸懵逼，遂前往百度寻求一众网友的解答。
看到这个报错，我的第一反应是意识到这是服务器那边有哪些限制，网上的说法也大同小异，如下图这样，看完之后觉得很有道理，但就是不知道怎么解决问题，客户的服务器又不是我们能随意登进去的。
怎么办呢？于是我们又回到了这个硬件终端的本地日志中，打算从硬件终端的角度，再次查看请求检测更新的地址。
把请求地址用硬件自带的浏览器打开的时候，发现根本进不去这个地址所在的页面，而我们自己的测试环境确实可以的。
到这里我们仿佛明白了什么，原来还是权限的问题。可是这个权限要怎么设置呢？
我们把客户环境和自己测试环境的请求更新地址分别在电脑上用浏览器无痕模式打开，发现客户环境的地址需要登录，我们自己的可以直接访问请求地址的页面。
之后我们就明白了，原来客户环境是需要我们开放对当前文件的读写权限，重新看了一下部署升级的页面后，我们找到了设置权限的方式，如下图：
这里的设置不仅可以针对当前文件来开放可读可写权限，也可以指定文件前缀来设置。
表面上看起来无从下手的服务器问题，抽丝剥茧之后，发现了可以解决问题的真相。确实，对于测试同学来说，环境部署、服务器之类的东西不能够面面俱到，但是抓住现象再往深就研究是我们应该去思考的，就比如最近也遇到一种人脸识别设备，初始使用的时候一直识别失败，抓包发现是需要我们给设备一些耐心，因为那是它在不断从服务器上拉上千张人脸特征码存储到它本地的过程呀，等它拉完了，肚子里有东西了，任凭谁来识别，都能“呼之欲出”。
