App上线需要自查的list——主要针对产品、运营、

下午上线最新的安卓App新版本的时候，出了一个状况，直接把我吓到了，瞬间以为背锅妥妥的了，不过最终发现是第三方平台的锅，才稍稍淡定下来。

正常情况是这样的：

安卓手机用户在我们的App下载页中点击“立即下载”后，可以直接进行apk文件的下载，这个apk文件是我们预先存储在某个第三方云存储平台的。

每次有版本更新，只要把第三方云存储平台中的apk文件更新过，用户就能在下载页中下载到最新版本的app了。

下午的异常状况是这样的：

CTO发现从下载页下载的apk文件依旧是老版本的。然后我就震惊了，因为下午我确认已经上传了最新的apk文件到第三方云存储中。

后来逐步排除了安卓工程师打错版本包、我上传错apk文件的可能性后，最终把锅指向了第三方云存储。

发现是第三方云存储没有自动清除缓存导致的。人工清除了下缓存后，下载下来的包就是最新的了。

问题最终解决了，不过这也提醒我，下次上传新版本又多了一个地方要进行check。

产品版本上线前要check的地方那么多，不如就顺手撸一遍要考虑的点好惹，从产品、部分运营、部分测试工作层面进行列举：

产品层面（包括部分的运营，主要是DB工作）

1、要在需求冻结前确认需求分析，不然冻结进入开发后逻辑再一直改，猿们会崩溃，搞不好还会导致版本延期；

2、确认完需求之后，要告知运营同事们有哪些新功能，何时能交付版本，这样方便运营童鞋们也好对应的落实相关的运营工作。如果运营的部分/全部工作也是PM干的话，那么自己心里要有数；

3、该版本开始就要落实是否要做新的应用商店图、新的欢迎页、新的功能引导页，并且相应的安排人手。在上线前3天最好再确认一下，万一有漏，也有时间能再补；

注意：针对这三个东西，都有相应的文案要出；

4、确认这个项目中没有完成的需求或者中途协商修改的需求，都已经被记录下来，并且最好开始确认没有解决的需求怎么办，修改的需求怎么办的问题；

5、确认该新功能的打点列表是否给出；

6、确认新功能带来的相关新数据的查看地方以及方法，这里会涉及一些常用的统计平台；

7、确认新功能带来的后台新的管理模块使用或者从某个地方切换到另一个地方的使用方法的切换，培训过相关人员，并且已经正确掌握；

8、确认提交给应用商店的新功能文案是否有出；

9、确认最终提交给应用商店的应用商店图、新功能介绍更新了；

10、确认各个渠道中的最新版确实为最新版本；

注意：这个部分就是之前一直有所遗漏的，吃一堑长一智。原本以为理所当然的事情，还是要好好检查一下呢。（必须要说一下，姜还是老的辣呀^_^）

11、每个版本都要观察上个版本的打点数据是否正常，这样能及时发现是否打错点了，进行及时修正，避免数据浪费；

测试层面（仅涉及到部分，不展开描述）

1、该版本的新功能进行了完全测试，包括移动端、管理后台、网页端，这里包括测试用例是否覆盖全、测试过程中是否跟着测试用例走覆盖全、bug是否按照类型进行记录、调整状态；

2、涉及到新功能的页面、以及可能和新功能有关系的之前的功能都要再回测，以免出现问题；

注意：如果这边涉及到修改管理后台，那么要确认所有和被修改部分相关的产品测试是否ok。例如：如果两个产品共用一个后台，那么修改就可能会影响另一个产品的功能/显示正常，一定要确认；

3、这个版本测试过程中，发现的之前版本的一些不好的体验点或者bug，及时分类记录下来，帮助下个版本优化；

4、是否核对过新功能的UI，这个地方比较容易遗漏；

5、打点是否有打成功。出现过打点写错英文的、打在错的点上、点打反了等等情况，这个要注意；

6、欢迎页、引导页是否被替换了，猿们有时候会忘记这个的；

7、登录注册找回密码流程最好每个版本都测一测。在其他app中发现，更新了新版本之后，登录流程不行了，太影响使用和留存以及新用户的吸引；

好惹，这里就不涉及开发的自查部分，毕竟我不专业，非纯代码层面的内容，后面还有测试、产品进行把控…（为偷懒找个光明正大的理由，Orz）