前言

这是我在社区发的第一篇帖子，因为文笔水平实在很差，一直都不习惯做记录。不过最近正好碰上职场上的调动，想想也该对这一人生阶段做一个总结了。

2017 回顾

下半年到新的技术服务公司就职，作为外包员工来到现在的甲方职场 (坐标深圳，互金行业，中小型公司)。
入职后才知道我们是这里第一批外包员工，对外包员工的管理体系才刚刚建立起来，基本就是来开荒的 (现在已有 20-30 名外包测试工程师，但只有我和另一位朋友是从一开始工作到最后，后来才知道有很多初期的外包做了没多久就被劝退的，现在想想自己还是蛮幸运的。)
初期各种权限限制：不能访问外网、数据库和 Linux 系统都只有查看没有修改的权限、截个日志图要手机拍照、部署环境要找其他同事帮忙 (也在这时候开始养成了查看 Jenkins 打包记录中开发提交代码的记录)，相信也是很多甲方职场的现状，极大地降低了工作效率。
刚入职没多久就碰上一资金存管项目，系统架构不熟悉、业务流程不了解、看其他同事讲的内容都是云里雾里的状况……虽然磕磕绊绊，但 2 个多月的时间里感觉自己还是成长了不少，对投资端平台有了初步的认识。
就这样踏入了 2018 年。

1 月-3 月

刚忙完投资端的大项目，正准备继续大展拳脚，结果没隔几天就被测试组长告知要调动到贷款端的测试组，有种一切要从头开始的感觉，初期是非常失落的。
不过我很快就振作起来，开始学习贷款端的业务了。别人整理的文档、JIRA 上的需求和缺陷都可以成为学习的资料。随着对贷款端业务的加深了解，那些以前在投资端工作时完全听不懂的名词和业务逻辑，慢慢变得明朗了起来。通过打通贷款端和投资端的业务流程，我终于真正理解我们公司的主要业务实际是什么，可以说提升了思维上的广度。日后和两个组的同事都能很好地进行沟通，现在看来真的非常感谢这短暂调动到贷款端的时光。
贷款端子系统非常多，而且业务流程上有很多的限制，一开始边问同事边踩坑。后来变成我来帮助同事解决环境和业务上的坑，大概是从这个时期开始，承担起为测试组同事解决问题的任务吧。

4 月-7 月

在贷款端刚做顺手，又被告知要调回投资端测试组……当时内心 OS：“这是要搞那样啦”。但是正好碰上投资端平台技术架构转型的好时机，对于自己来说也是急速成长的时期。
这个时期一个重要的里程碑就是：外包员工的各种访问操作权限终于放开，和内部员工基本一致。这意味着我再也不需要依靠别人来部署环境、修改配置、执行脚本，也能访问并获取 SVN 上的资料，遇到问题可以百度一下，还可以自己配置测试工具和 IDE 写脚本……踏上了自立自强的道路。
另一个重要的里程碑是，开发搭建了 GitLab，开放了部分项目的查看权限。可以查看开发提交代码的记录，甚至可以把开发代码下载下来自己研究。利用这一点可以做以下的工作：

• 确定开发提交修改的时间，然后就可以打包了 (不会再出现说测试催开发打包，但是开发说还没提交代码的)。
• 通过代码修改内容，大致确定测试范围 (有一点精准测试的味道)。
• 阅读功能代码实现，对业务也有更深层次的了解。对于稳定的功能，甚至可以通过阅读代码梳理原来的分支判断，和现在正在开发的代码逻辑做对比 (在重构项目中就试过通过这样找到了新代码逻辑的问题)
• 可以协助自己修改测试数据、造特殊场景 (通过接口地址->Controller->Service->ServiceImpl->Dao->Mapper 找到对应的 SQL，然后就可以自己改数据了。不需要所有问题都咨询开发）。
• 通过日志打印报错信息，找到对应的代码行，初步判断是环境、数据问题还是代码逻辑问题。虽然不完全懂写代码，但分支条件判断还是能看懂的。开发总说不要猜哪里有问题，但我觉得测试还是需要先猜测问题可能出现在哪里，再拿出证据支持自己的猜测。

下半年

从 4 月份开始，投资端平台这一年基本都在做微服务重构，技术栈就不多说了。讲一下自己总结的在测试重构项目中经常会遇到的环境问题：

• 配置问题：微服务架构中把部分配置文件抽取出来，统一用配置中心管理。但因为测试环境众多，各个环境所用的测试包版本又不一定一致，经常会有配置项没同步或配错值的现象。可以说是最初级的环境问题，作为模块负责人需要了解配置项的含义及作用，及时处理配置错误导致的环境问题，并且可以通过修改配置实现一些测试需求。
• 服务调用问题：系统拆分成多个微服务一个很显著的现象就是，一个功能逻辑设置多个微服务之间的调用，其中某一块有问题都可能导致业务流程不通。除去代码层的问题，最常遇到的问题就是服务调用失败。这要求测试人员了解：1、某个服务是怎么调用对应的另外一个服务的 (配置文件写的服务地址还是通过 consul 负载)。2、业务流程涉及到的微服务有哪些，它们之间的调用顺序又是如何 (我们需要去检查是哪个服务哪个环节出现了报错，定位是环境问题还是代码问题，再找对应的人员协助解决)

其他

除了常规业务测试，个人还做了几个小的实践。但因为测试组没有专门的自动化团队，所以自己做的很大程度上只是到 DEMO 级别

• pytest+allure+jenkins 实现接口测试，检测接口逻辑。
• MD5/RSA 签名工具，用于接口测试验签；HashCode 工具，计算数据库分表位置。
• PO 模式的 UI 自动化项目。

年末

2018 的最后几天里，测试组长告知，公司领导要求所有外包人员清场。虽略有震惊，但知道这一天总是要来的，只是来的稍微突然了一点。但总体来说我还是很感谢甲方职场让我学习了很多东西。接下来就是整理交接资料，比较可惜的是很多问题的解决方法都还没来得及沉淀成文档。准备转换职场，或许继续做外包去别的项目，但其实也挺想找个做自己项目的公司好好干，只是外包的这段经历会给我带来不少困难吧。

个人总结

可能有很多人觉得外包员工的测试深度不如内部员工，大多只会点点点。但我觉得并不是这样的，外包员工完全可以做得和内部员工一样甚至更好 (只是甲方公司不会培养你，要靠自己去提升)。一个好的工作环境给你提供了发展的基础和空间 (很高兴我所在的职场工作氛围很不错)，利用一切能利用的资源，能到什么样的高度就得靠自己了。