2016 年初给自己在测试这边定了 1 个目标，因为人力缩减和投入方向关系真得有点惨，还是要总结下。

计划内容

版本内容除外

其他完成度 60%

• 大于 100% 预期项数量:1

• 小于 50% 预期项数量:5（掩面）

可公开部分目标

… …有些自己都想喷自己了（掩面）。

2016 年总结

更完善了测试流程和平台到游戏的测试，就差灰度发布了。

更淡定的背了一些锅。

参与 1 楼公司 4 款项目，1 款 17 年初上线，1 款项目结尾交给其他人做。

参与 2 楼公司 1 款项目以及硬件驱动测试，全平台项目，主要是电视和索尼。完成了 6 月底重要版本就回 1 楼了。

参与公司 1 个项目对应的海外版本和 web 端版本。

维护了公司 1 个项目 6 个海外版本和大概 7 个特殊渠道版本。

公司项目平台->sdk->充值等测试。

[版控]

有 2 个项目需要测试来合并版本和比对冲突。

版本计划->版本内容 list->测试信息备注->内网验证通过->diff->增量更新->测试服->外网开白名单->更新特征测试和冒烟。

增量更灵活，内容少就是测试服只配置，直接外网白名单。不过增量加载资源策略这部分还是没优化。Ps:增量和出各种标签整包都是自动化了。

Unity 走 C# 脚本增量，后面我去楼下了，就没参与了。

合服（提前）->合服计划生产合服配置表->生成外网帐号->内网业务验证->跳引导脚本->脚本验证->合服后区服配置表

合服（当天）->运维合服->登陆测试账号->测试平台到游戏->检查配置->通过后等待开服->开服后等待一定时间（这个算小灰吧）

每次合服基本会超时，这锅测试就不一个人背了。

合服预演一开始会有，2016 年成熟了。

[海外版本]

游戏版本密度比较频繁，所以定义了专人去测试，也有对应的冒烟测试列表。执行情况好坏主要看测试者个人。

支持 jenkins 发布和平台配置不同的入口

配置表版控，配置表和 svn 内容的 diff

合服和别的一样

[Web 端版本]

是 B/S 结构，资源也是按手游方式来加载，尺寸大小也是较大的都是位图。

做了大量的下载资源优化和拆包处理。

弃用了手游的 plist，采取按需加载，控制加载在节省带宽情况下不会卡住。

这个算是拔草了，毕竟之前公司只推演过可行方案，加载资源机器人脚本是改写我几年前的。

[全平台项目]

Wp,Android,Ios 14 年大部分内容都拔草了，16 年拔草 XBOX，PS，安卓电视机

Unity 通过宏开关来控制是哪个平台，硬件本身识别也可以。

3D 项目测试内容增加了更多的碰撞检查，动作弹轨，位置同步等。

担任了那个 TA，在不同平台下，着色器产生了不少兼容性问题，显示 + 报警影响帧数。

二次开发了 3 个检查脚本（可视场景资源 tag 检查，配置表条件检查等）。

排查性能是做先大范围再小，定位问题做减法，这个可以看年底游戏测试手册。

电视机上性能测试没实现，就去楼下了。

充值接口留下测试文档和流程。

玩具测试留下测试对需求的文档和测试用例。

音效测试在的时候完成了 1 次。

[其他]

其他也没啥好提的，都是常规的。

引擎跨度也不大，业余学习了 Ue4 引擎。

2017 年

重新定 1 个计划，16 年过去了当时定高了，有些坑也就不填了。

比其他大猫瘦。

很多知识靠炒冷饭，16 年未完成的，17 年换个姿势炒冷饭。