一、上线过程
之所以要单独说上线前的测试，是因为对整个游戏来说，上线是最重要的一个环节，尤其是第一次上线，那么要做好上线前的测试首先要清楚对于游戏来说，正式上线都要经历那些环节，这里我举一个游戏的例子，如下图1-1
在上面的这个游戏中，游戏的主体内容可以分为四部分：
1、游戏玩法功能内容；
2、数据管理平台，通常会做一个独立与游戏之外的平台，用来录入运营活动，管理玩家数据，权限等；
3、发行SDK内容，发行商接入的功能比如直接使用微信登录，游戏内充值，分享等；
4、其它定制化SDK内容，比如对包体进行分割以方便玩家下载的第三方sdk接入。
正因为上线前该游戏有以上四大制作环节，所以测试的策略，也要根据这四个环节合理安排时间进行测试。通常游戏内容开发和管理平台的功能是同步进行的，所以可以同时测试，但是运营活动的录入要稍晚一些，因为要首先保证游戏的基本功能正常，发行SDK的测试通常有测试版本和正式版本，所以在测试功能期间可以同步进行sdk相关功能的测试，下面详细列举该游戏的每个测试环节都要测试那些内容。
二、详细内容测试示例（以下为某项目的上线前测试内容示例，仅供参考）
1、全量测试
全量测试是上线前第一个环节的测试，基本上包含所有相关功能的测试，具体测试内容如下：
①功能测试
- 系统测试
- 内容测试
- 数值测试
- 其它测试
- 音效
- 跨服功能
- 多语言
②中控测试
- 中控开关
- 其它
- 封号、禁言、踢人、全服邮件等
③SDK测试（测试环境）
- 登录、分享、充值等
④ 更新测试
- 热更流程
- 客户端
- 底包更新
- 资源包更新
- 服务器
- 热更
- AB服
- 白名单
⑤运营活动测试
⑥专项测试
- 服务器
- 容灾
- 玩家数据测试
- 删档测试
- 回档测试
- 压力
- 客户端性能
- 弱网测试
- 协议测试
- 客户端兼容
- 机型
- 类型
- 系统版本
- 模拟器
- 表格规则测试
2、 冒烟测试
冒烟测试指当所有全量功能测试通过后，对所有功能再做一次精简测试。
基础冒烟测试
新手流程
3、正式SDK测试
正式SDK指冒烟测试通过后游戏主体接入正式SDK的测试
①说明
- 提前一周准备
- 此时出包就是正式上线的包
②运营特殊需求测试
③ 正式SDK测试
- 服务器与客户端同步
④ 正式包checklist（一般由运营和测试同时制定），示例如下图2-3-1：
4、定制化测试
定制化测试指的是游戏主体接入的其它第三功能，该项内容的测试可以在全量测试期间就进行准备。
① 说明
- 乐变分包测试
- 提前一周准备
② 乐变SDK测试
③ 4G环境检查资源
④ 热更新再检查
5、 正式上线
至此可以通知相关部门准备正式上线的工作了。
三、注意事项
下面列举该游戏某次上线时遇到的问题，以供大家借鉴。
1、 策略问题
- 关键功能没有优先测
- 新手、任务、更新、副本流程
- 阻塞问题想办法饶过去
2、 SDK问题
- 正式SDK搭的太晚
- SDK需求没对接清楚
- 客户端与服务器保持同步
3、更新问题
- 测试太晚
- 改动未通知到测试
4、 需求问题
- 关键需求给测试太晚
- 部分需求不提，也不明确
5、 沟通
- 关键信息没有同步所有干系人
四、线上更新测试工作流程示例（以下为某项目的更新流程示例仅供参考）
正式服更新测试流程（从Release/Wartune出包）
1、 测试负责人确认在线更新表格客户端和服务器已提交完毕
这时候让负责测试的同学先把unity_release/wartune分支pull到最新先测试客户端的提交内容。
2、 确认策划的表已经准备好并进行对比
用BCompare对比线上环境备份的模版表和每日要更新的表，对照在线更新表格填的表；
如果没有多啪或者少啪的表让策划啪表并重编重启服务器；（如果没有服务器提交内容重启或者reload即可）；
3、 三表一致对比
Ⅰ、数据库对比：
将线上环境备份的表拷贝到自己本地把策划当日要更新的表合进去，然后啪到smith私服；（这个时候先把数据检索工具运行起来）
用shell连接109服务器输入sh dbccheck_release_smith命令进行比对，如果最终比对结果提示“Compare DB Success！”代表比对通过，否则不通过找对应负责人查原因并修复；
Ⅱ、客户端Lua比对：
将自己本地unity_release/wartune pull到最新，用BCompare对比本地Lua与啪到smith私服的Lua文件是否一致；
release/wartune本地Lua地址：自己工程存放目录\Assets\LuaScripts\game\tableinfo；
smith私服的Lua地址是自己在配置里填的本地目录比如：
这里如果对比没有问题就通知测试的同学开始进行全面测试；
Ⅲ、表格细节比对：
用BCompare对比每一个差异表格，找对应的策划现场确认每一个提交内容没有问题；
这时候数据检索工具差不多检索完了，打开检查结果查看是不是有填错的表；
4、 打更新包
确认三表对比一致，所有更新内容都测试通过后，通知负责打包的客户端、服务器同学开始打包并部署到外网功能、外网活动测试服；
（一般打包同学都知道要怎么操作，但为了保险期间还是得核对打包版本，并提示服务器同学别忘了同步数据库）
5、 更新测试
Ⅰ、客户端和服务器部署结束后，启动对应的手机端进入外网功能服，检查更新版本、更新包大小（与技术核对）没有问题，确保安卓和ios都能正常更新，并登入游戏验证任意更新项更新成功；
Ⅱ、更新测试没有问题后通知技术把要更新的文件放入正式服更新共享目录；
（正式服更新目录：一般由测试负责人在里面分别建好对应更新版本的“客户端”“服务器”的目录，可以参照历史格式）
备注：如果测试同学没有权限在unity编辑器上直接测试，可直接打出手机安装包或者更新包进行测试。
6、 正式服更新测试
Ⅰ、确认好正式服的更新时间后，由测试负责人用发包工具把要更细的包发给运维，并通知运维和运营具体的更新时间、更新版本以及客户端更新包大小；
（使用发包工具时一定要把当天负责的客户端和服务器负责人喊过来核对自己的操作以免出错）
Ⅱ、预发布更新测试：运维更新好预发布服后会通知测试验收，一般测试只要确认更新包大小没有问题，能正常更新并进入游戏简单冒烟即可；
Ⅲ、预发布服更新没有问题后通知运维更新正式服，运维操作结束后使用白名单帐号登入正式服确认更新版本、更新包大小没有问题，并可以正常登入即可；
7、 Release/mirror同步和备份
Ⅰ、正式服更新结束后通知当天各单位负责人将wartune更新数据同步到mirror（包含客户端、服务器、数据库、模版表）
（模版表把每日更新表分别合并到wartune和mirror）
Ⅱ、同步结束后由测试负责人进行校验比对并备份
对比确保策划git分支下wartune和mirror合并后的表格一致，并备份到测试共享文档；
对比确保wartune和mirror客户端LuaScripts目录下文件一致，并备份到测试共享文档；
对比确保wartune和mirror服务器Code目录下文件一致，并备份到测试共享文档；
对比确保wartune和mirror数据库一致，并将数据库文件导出备份到测试共享文档；
8、至此更新结束
<完>
个人浅见，欢迎留言交流。♪(＾∀＾●)ﾉ
