从毕业至今已经 2 年半了，公司已经陆陆续续裁员大半年了，同事陆陆续续的走，感觉也快到我了，想提前梳理下自己工作历程。
校招进入的公司，进入公司实习期 6 个月，干的事，从现在来看还是有一定的挑战难度的；
首先第一个负责项目的是主营业务例行的发布系统，公司的主营业务全部依靠这个发布到 rc、stage、prod 环境，算是很重要的内部系统，在我来之前这个系统没有测试接手过，业务文档 0，逻辑全靠问和自己梳理，没有测试环境，没有 stage 环境，有的只是本地 + 线上；开发是运维自己写着用，也是第一次找测试走正常的上线流程；分配到这个项目的第一时间，没怎么理解逻辑和发布流程就着手写测试用例（犯了忌讳），自己看着系统就写了一大堆 UI 和文案的测试用例，哈哈哈，能想到一堆大佬评审的表情吗？现在想想就想笑。都是在磕磕绊绊中成长的；后续梳理了该发布系统 RC 环境、stage 环境、prod 环境的发布新 tag 的流量的摘挂，发布方式主要是滚动发布、灰度发布；算是该系统第一篇测试梳理的业务文档，也被运维同学引于后续的全员分享文档中。如何确认流量确实摘掉了？当时是登录堡垒机，进入对应的主机使用命令 ping 的，查看对应的字段的返回值去确认和去阿里云管理端查看，发布系统页面展示的不可信，因为这个玩意测试没有测试过。流量的摘挂测试大场景分为滚动和灰度，每一大场景包含 tag 版本发布错误、回滚、多次发布、前后环境影响、等多种场景排列组合场景，去查看流量摘挂、版本发布是否对，哈哈哈没办法，新人只能多试试，多覆盖来保证减少问题带到线上。如何确认新的 tag 发布完毕，找前端组要了一个内部工具，做了小改动，新版本打开页面会在控制台输出一段话 “这是新版本”，可以利用这个特性测试新版本的发布和回滚功能；
第二个负责的系统是泛微 OA，测试方：公司实际使用的业务（财务）+ 技术方测试（我）+ 技术运维（沟通和反馈问题）
测试场景挺多的，什么电脑换新的审批工单、公章外带、什么日常报销、福利金等一系列内部审批流程；测试了 3 周，写了 3 个 wiki，每个 wiki 大概 30 个左右的 bug 记录，主要记录 bug 的发布步骤 + 截图 + 影响评估，当时也算聪明创建 wiki，非内部开发，没有办法创建 jira，不然周报没得说；印象最深刻 bug 的是 Android 提报销工单，可以输入第三位小数，提交系统自动四舍五入到第二位，如果用户不小心输入，可能会造成多报 1 毛钱，哈哈哈；印象第二深，就是和乙方沟通，这个修不了，哪个修不了，谁是甲方？后来我一个人提的 bug 不被重视，业务提的乙方重视，慢慢淡出这个的项目了，由公司业务去测试验收。反正这玩意整了很久，有没有免费的开源的好用还是一说；现在后知后觉，团建费报销场景使用最多，每个部门都要用，所以泛微 OA 最重要的测试场景一定是使用场景最多的流程