前言

我看到有同学希望大家能分享一下一些简历，大家可以参考讨论， 并且我记得也有位同学觉得很多时候学习知识，其实都是有潜在目的的。对着简历要求和描述，反过来去选择学习什么知识的方式会更有成效。 所以我就来写这么这篇文章了。 但乱发别人的简历是不道德的， 所以我把自己的简历脱敏后发出来给大家看看。 因为每个人涉及到的领域是不一样的， 并且工作经验不同简历的内容也是不一样的。 所以为了我会把自己 15 年的工作经历拆成几个阶段来展示，并且会解释一下这个阶段主要在做什么事情

还有就是简历会有裁剪，毕竟简历内容还是挺多的， 包括什么兴趣爱好啥的或者一些我觉得不重要的东西就直接剪掉了。 还有学历背景也不写了， 熟悉我的人都知道就是一个普通三本，计算机科学与技术系。

PS：我本人写简历其实没什么技巧， 完全是凭借着我这些年做面试的心里活动来倒推用人方喜欢什么样的简历。

第一阶段 -- 毕业 4 年半

首先要说一下因为实习和刚毕业那会实在没什么好写的， 因为真是啥都不会没有任何经验。 并且实习的时候直接转正了，也没写过什么简历。实习的时候在文思创新（后来改叫文思海辉， 俩外包公司合并了）， 我都略过了（也没什么好写的， 外包公司么， 就是点点点，只有在最后一家做了一些自动化的东西）。

个人擅长技术描述：

• 熟悉 java 语言，可使用 java + testng + selenium 编写自动化测试用例
• 良好的英语水平，可使用英语沟通工作内容

工作经历

2012/11 -- 2015/5 公司：和益达 (包公司) | 测试工程师
2010/07 -- 2012/11 文思创新 | 测试工程师

项目经历（一）

Ariba on-demand spend management

项目职责：

• 根据用户需求以及 bug 描述编写测试用例和测试计划。
• 运行代码覆盖率工具（Corbetura）编写单元测试用例（ariba 采用模块开发，部分数据迁移能力的单测可交给测试人员编写）。
• 使用 Selenium 编写 web UI 自动化脚本。自动化小组 3 人共维护用例规模 -- 4 千。 采取 selenium grid 作为浏览器集群加速用例运行。
• 负责开发测试工具，编写产品后门程序帮助测试。
• 赴美国参与新功能的开发测试，包括功能，数据迁移等。

项目描述：Ariba 支出管理 (Spend Management) 解决方案，帮助企业分析、理解、及管理整个企业的支出，以节约成本与提升流程效率，其解决方案包括专业咨询服务、信息技术、以及供应商网络的全面组合。主要地分为如下几个部分：1）寻源及招投标为主的上游，2）下游的采购到支付的执行，3）能见度解决方案，以及与其它如 ERP 等应用系统的集成部分。

项目经历（二）

MSTV（微软数字电视系统）

项目职责（这份工作偏运维）：

• 根据测试需求配置网络环境以及系统环境，后期编写 power shell 编写自动化配置工具。
• 日常测试与开发机器的运维工作，机器规模 -- 300

项目描述：该项目是微软收购了一家电视公司后成立的，功能与一般数字电视相似. 客户主要为美国民众，提供收费电视服务。

总结

嗯， 确实没了，在外包的这几年里能拿的出手的东西确实有限。 不过总算是自动化入了门， 能搞的了 UI 自动化， 能开发一些简单的小工具， 在微软那会接触到了一些运维的东西，那其实对后面帮助不大，因为微软的技术都是 C# 和 power shell，离了微软的生态圈是屁用都没有， 外面的公司是不可能用这套东西的。 不过好歹这段经历也是个加分项吧，毕竟有运维的经验和编写脚本的经验。 加上在 ariba 项目中涉及到的 java 和 UI 自动化，单元测试这些，在当时是可以让我从外包跳槽到互联网的，毕竟 2015 年那个时候，讲道理能写代码的测试也不是很多的。即便是我跳槽到了 58 到家，也发现整个公司几百人，测试团队几十人里， 能写代码的就那么几个人。 那个时候在这些小公司里测试人员就是点点点的点工，但当时在大厂，已经有很多测试人员懂代码了。 再上 15 年那会正是互联网爆发的那几年， 创业公司如雨后春笋的冒出来，工作岗位也比较多，所以凭借着这个履历也是在 2015 年的时候跳槽到了 58 到家， 这也算是我摆脱了外包的身份进入了互联网领域。

这里想说一句， 其实跳出外包圈子进入互联网在当初那个时期也没那么容易， 虽然我上面写的轻描淡写的。 但在外包公司里想找个能写代码的工作其实是很不容易的。9 成 9 的人都是在点点点。 甚至我入行的时候底子更差，实习的时候就不是测试工种，有点类似行政人员一样， 在微软的办公区里打杂。 后来发生过很多事情，比如：

• 离职被卡，导致下家公司说好的项目没进去，因为都是在微软项目中，就是换了个公司，导致原公司到微软投诉了，当时这个行为还是挺敏感的。 所以那个项目我就没进去，然后我就被安排到了一个偏远的小屋子里，去看着人做类似众包测试了，就是当时有个练习用手机打字的软件（嗯，那会智能机刚刚冒头很多人其实不会用手机打字），然后请那些小时工（大多都是学生兼职挣外快的，请过来干几个小时就结算几个小时的钱）。 我就负责看着这些学生，然后收集测试结果， 我有时候也上手测试，但其实就是用软件打字。
• 实习的时候就不是测试团队的， 为了能挤进测试团队（虽然只是个本地化国际化测试小组），我自己私下找了一些测试组长，求他们收留我。 后来总算是微软的 hotmail 组把我收编了，算是入行了测试领域。 当然这就是个做本地化国际化的，没有任何技术含量，甚至测试用例都是美国那边写好了我们执行的。所以就没写在简历里，因为实在不是什么光彩的岗位。
• 在微软的时候为了能接触自动化又是求爷爷告奶奶的， 主动找到 manger 希望能去自动化小组。 后来几经辗转，总算是拿到了这个机会。 算入门自动化了， 那段时间工作很努力， 天天写代码非常开心。
• 去美国也不是很舒服， 语言不通（我的英语都是工作用于，生活上很难）， 再加上穷，连个头都舍不得减（那边剪头是真的贵，找个街边菲律宾的剪头师傅都得 20 美元），所以在美国最长的一次有大半年， 天天都吃酒店和公司的免费餐， 但免费的大家都懂得， 没什么好东西。 周末就去吃快餐， 那边麦当劳倒是很便宜， 2.5 美元就是一个最简单的套餐，并且可乐无限续杯。 在那 2 年里有一半时间都在美国呆着， 吃着这些垃圾食品，其实对身体是有害的，我现在肠胃很不好， 也怀疑是那个时候落下的病根。 还记得有一次是在馋的受不了了， 让我们老大带我们找了一家中国餐馆。 我们看见菜上桌的时候眼睛都绿了， 就跟那狼群进了羊圈一样。 全程没人说话， 就是在风卷残云的吃。不过老实讲那那段物质上欠缺了一些， 精神上还是不错的， 练了英语，硅谷工作环境也好，时不时的老大会带我们出去走走（基本不花钱那种），感觉像旅游一样。

上面说的挺多的，其实就是想表达在当初从外包转到互联网，尤其还是进互联网的写代码的岗位，也是很不容易的。 挺多时候机会是需要自己争取的，就像为了能出来实习，我们 4 个同学晚上给导员送礼（当时学校不让我们出来实习， 因为我们报的培训机构本来是和学校有合作的，但后来合作谈崩了，学校就不让我们出去了。所以我们才来求导员睁一只眼闭一只眼）。实习和工作的时候为了能进更好的组也是主动找领导去聊，主动去跳槽到更好的团队，这些都是要自己争取的。 并且我大二那年就报了培训班学了 3 个月 java，学习期间成绩很好，争取到了机会在大三免费给培训班老师打了一年工练手。所以有 java 的底子的，这在后面找自动化测试的工作才算有了一定程度的依仗。 很多时候真的， 机会不是什么都不做就等着从天上掉下来的。

当然， 运气也很重要， 而且十分重要，并且在那个时候互联网刚兴起， 从业人员不多，所以工作相对比现在好找太多了，这也算入行早的优势，能在早期用比较低的门槛进入这个行业，然后快速的去积累行业经验在这里站稳脚跟，后面的路就顺畅多了。 现在入行的小同学们。。。。嗯， 是真的难

第二阶段 -- 2015 年的 10 个月

2014 年和女王大人相识相恋，谈婚论嫁，让我更加迫切的感受到了经济压力。 所以离开外包进入互联网迫在眉睫。 当时 O2O 兴起， 58 也入了局，成立了一家新的公司 -- 58 到家， 我闻声而动找了在里面工作的同学， 把简历推荐了进去。 获得了面试机会并成功进入这家公司。 但由于很多操蛋的事情也就呆了 10 个月就走了。 这段时间的履历补充在下面。

个人擅长技术描述：

• 熟悉 java 语言，可使用 java + testng + selenium 编写自动化测试用例
• 熟悉 jmeter，可根据 jmeter 公开的工具包进行二次开发，可分析性能缺陷，使用监控工具。
• 熟悉接口自动化测试，可独立开发接口自动化测试框架
• 良好的英语水平，可使用英语沟通工作内容

工作经历

2015/5 - 2016/3 58 到家

项目经历（一）

nocode 接口自动化测试工具独立开发：

• 该工具使用 java 语言，由于业务测试人员普遍不懂得编写代码，所以采取关键字驱动的设计，利用反射原理，把用户在 execl 中编写测试用例翻译成代码执行接口自动化测试。
• 推广该工具，并带领业务测试人员完成相关的接口自动化测试工作。

项目经历（二）

56 到家 APP 测试工作

• 测试以及线上环境巡检监控工具的开发： 为解决线上和测试环境不稳定的问题，开发相关自动化工具周期性巡检环境并在异常时告警，主要方式有服务的心跳检测（端口探活），自动化测试的定期巡检。集成到公司的 jenkins 平台中稳定运行。
• 测试环境资源管理平台开发 (包括自动化部署，资源管理，权限管理等等。参与后端开发)
• 引入 Jemeter，并培训业务线人员进行性能测试。制定性能测试方案并排查与分析性能缺陷。 整体方案使用 jmeter+influxdb+grafana，监控平台为 58 内部平台。
• 数据恢复工具与数据准备服务的开发。实现一键准备测试数据。简化业务线测试人员的测试工作
• 推进持续集成，使用 jenkins 编写 job，将自动化测试加入到持续集成流水线中。
• 定期组织技术分享会，培训业务线人员技术能力。

总结

在 58 只呆了 10 个月， 但我其实很珍惜这个能进入互联网，并且还是在测试开发组里工作的机会。 所以这段时间拼命的学习， 我记得看了 mysql 的一本书， 看了 jenkins 的一本书，还看 linux 的部分内容（主要看性能分析上了， 全套的真没看下来）。 所以做出的成果也不少， 搞了接口自动化测试工具的开发（当时还兴冲冲的搞了关键字驱动的，但在后来我十分看不上关键字驱动的东西。。。。），把性能测试也搞下来了（看 linux 和 mysql 的书也是为了性能测试），还二开了 jemeter。 入门了持续集成，搞了 jenkins。零零碎碎的小工具也有一些。 这个时候就彻底转型成技术工种了， 这也为后面进入第四范式打好了底子，因为第四范式的测试团队真是全员测试开发，不会写代码的连外包岗都进不去。

这里有个小插曲，我当时写简历的时候还厚颜无耻的给自己加了个测试架构师的 title，当时眼光很浅，觉得自己挺了不起了。 毕竟当时圈子里的 9 成 9 的人都是在点点点， 我这又二开 jmeter，又玩 jenkins 又开发测试框架的，着实是自大了一把。 后来进了范式以后， 接触了那么多更复杂的技术栈，才明白， 在 58 的这个时期的我，充其量也是小桌坊， 属于矬子里拔大个的水平。

第三阶段 - 入行 AI 大数据与云原生阶段

这里的简历就比较长了， 因为在第四范式呆了差不多 5 年半， 时间太长了， 所以做的东西有些多。

工作经历

2016/3 - 2021/7 质量部下属工程效能组组长

自我介绍/个人擅长

• 熟悉编程语言：golang, java, python, js ，ts
• 擅长容器领域（docker&&k8s）内的各种实战项目。曾经推动并设计开发了公司内的各项容器化项目，包括但不限于：
  • 公司内核心产品，自动化测试等工程的容器化改造。
  • 设计并开发基于原生云架构下的混沌工程工程。
  • 编写基于 k8s 的产品部署工具和环境治理系统。
  • 整合 jenkins pipeline 与 K8S 优化 CICD 流水线。
  • 编写 k8s operator 优化各项测试工具。
• 擅长大数据领域的各项测试方案，主要应用 spark，flink 和 kafka 相关技术栈，曾经推动并设计开发了公司内数据平台内各项场景的测试方案。包括：
  • 大数据的批处理和流计算的黑盒，白盒，性能，兼容性，稳定性，一致性测试
  • 数据质量监控
  • 大规模造数平台的开发
• 擅长机器学习领域相关业务，熟悉机器学习的商业模式，各项算法测试方法， 主导并设计了公司内算法的效果，性能，兼容性等测试方案和工具的开发工作。 曾经带领过算法平台的测试团队。
• 擅长各项自动化测试实践， 设计并开发了公司内大部分的自动化测试项目，包括:
  • Web 端 UI 自动化测试
  • 接口自动化测试
  • SDK 自动化测试
  • 部署自动化测试
  • CLI 自动化测试
• 热爱技术分享，在国内最大的测试社区 Testerhome 撰写专栏《测试开发之路》。 参与了 2017 到 2021 年的 MTSC 测试开发大会（讲师和幕后工作都有涉及）

项目经历（一）

基于原生云的混沌工程平台
产品全部围绕机器学习的生态构建，并且核心产品均使用微服务 +k8s 的架构，而由于机器学习业务数据量大，计算时间长的特点。 如果代码，环境，或其他原因造成的不稳定导致任务失败所带来的成本代价非常大，而因为产品使用微服务架构，我们需要涉及到上百个服务的故障注入，工作量巨大。基于此背景下，由工程效能部发起成立混沌工程专项，开发全自动化混沌工程项目，实现全自动化的针对每个服务进行故障注入，测试验证以及结果分析。 目前该项目已经到 20 年的 MTSC 深圳大会上进行分享。 我的角色是该项目的负责人，初中期负责整个项目的推进沟通和代码开发工作，后期交给团队成员负责。

主要的技术实现简介如下：

• 对于 K8S 故障注入采取容器领域常见的 side car 模式，向业务 POD 注入故障生成容器，配置参数共享网络，进程，目录名称空间。可以达到最细粒度的故障注入且不会影响其他服务正常运行。对于物理机和虚拟机采用开源工具 chaos-blade 直接以 server 模式启动， 调度程序控制 server 执行故障的注入和恢复。最后整合 K8S 和物理机两种注入方式统一调度。
• 监控技术采用取普罗米修斯，监控 K8S 集群和物理机的各项指标
• 由于 TO B 类型的业务没有线上环境导流，所以测试过程采取在测试环境针对单个服务注入故障的同时运行全自动化测试用例，同时测试用例对接普罗米修斯，统计测试用例的执行情况最终计算出每个服务的 SLA。
• 分层测试方案上，要求测试人员把服务接口的幂等性测试列为常规的回归测试内容。

项目经历（二）

数据平台测试项目
数据平台核心产品之一， 实际上在所有产品中都涵盖到了非常多的数据能力（包括离线批处理和在线流计算）。所以需要在整个公司产品层面设计一个合理的数据质量保障方案。 我的角色是该项目的负责人，初中期负责方案的设计执行，开发对应的测试工具。 后期交给业务线 QA 独立完成。

主要的方案条目如下：

• 白盒测试方案： 公司所有产品均使用 spark 和 flink 完成产品的离线和在线业务，所以白盒测试方案上我们深入研发代码中， 规范研发的代码规范。 第一步针对数以百计的 UDF 和 UDAF 进行最小粒度测试。 第二步要求研发拆流，讲计算流按业务拆分成若干子流，QA 针对子流进行集成测试。
• 黑盒测试方案：主要分为两种形式，第一种编写 spark 程序扫描数据表，分析数据分布，值阈，类型等维度，建立 Data Profiling 机制验证数据本身的质量以及数据处理程序是否按预期运行。 第二种通过造数平台，在离线和在线业务上通过造数工具准备固定的数据，精确验证数据处理程序是否如预期运行。
• 性能和异常场景测试方案：开发造数平台，创建不同的数据分布（针对数据倾斜）数据规模（针对大数据和宽表）数据类型（针对各个业务对字段的要求）异常场景 (空表，空列，异常字符) 等等满足各种场景的测试需要。 造数平台采取 spark+hadoop 技术栈， 利用 spark 的分布式计算特性和 hadoop 的集群资源在短时间内造出数十亿甚至百亿级别数据。
• 数据兼容性测试：公司内部各个产品使用了不同的数据处理框架，比如 spark1，spark2，spark3，和 flink，而整个产品策略上各个产品线的数据需要能够互相流转形成闭环。 所以测试方案上要求每个数据处理算法都要兼容各种数据格式， 包括 txt，parquet，csv。同时也要兼容各个数据框架产出的数据，也就是所有算子都要能够处理其他算法框架产出的数据。 所以我们建立相应测试框架，让每个算法都在不同的数据上运行验证兼容性能力。
• 一致性：在整个机器学习生命周期中保持数据离线和在线的一致性非常重要，所以测试方案上验证离线的数据处理结果与在线的结果需要一致。
• 稳定性：主要涉及流计算业务，产品要求我们的数据需完成进准一次性语义，保证数据不会出现丢失，重复和重复消费的情况， 所以我们以混沌工程的思维，使用故障注入的方式验证流计算的过程中不会出现上述情况。 同时也是保证流计算所有节点均有精准一次性语义的设计。
• 效果测试：机器学习业务要求每个算法要达到一定的效果方能上线， 所以我们成立 beachmark 委员会，与客户沟通，收集脱敏数据，在固定数据集上运行算法，统计相应的评估指标，验证算法效果是否回退。

项目经历（三）

由于公司产品采取微服务 +k8s 架构，我们面临上百个模块的每日的更新与构建，过于复杂的架构和人肉的工作方式会严重拖慢产品迭代进程。 所以需要一个高度工程自动化的持续交付系统来满足公司的对发布周期的需求。我的角色是该项目的负责人， 前中期主要负责项目的推进，设计与开发， 后期交给每个模块的研发与测试人员自行维护。

主要的技术方案如下：

• 主要采取 jenkins 与 K8S 整合的方式， 利用 K8S 动态启动 jenkins slave node 的形式执行 pipeline，利用 K8S 的分布式能力加强持续交付系统的负载均衡和高可用能力。
• pipeline 中加入 UT，代码扫描，镜像制作，环境部署，自动化测试一整套链条。 部署工具同样基于 K8S 进行部署。
• 开发测试平台，其中包括环境治理，项目管理，提测管理和质量可视化模块。 打通公司内各个平台的数据，在各个流程加入卡点， 比如研发提测时会检查提测环境的 dailybuild 是否执行，测试通过率是否满足要求，当前是否还存在 Block 级别 bug 等卡点。如不满足需求降阻止提测。 而质量可视化模块会收集到公司各平台内的数据统计项目进度，场内工单，bug，dailybuild 等等数据，完成数字化的全链路可视化度量。
• 测试团队同样接入 pipeline，完成全量部署到版本发布的整个联调的流水线化处理，在整个流程中加入 UI 自动化， 接口自动化， sdk 自动化，部署测试自动化工具等类型的自动化测试。

总结

其实在范式这么多年， 不可能只有这三个项目， 但是其他的我当时都没有写。 我自己觉得，简历么，不能太长篇大论。 我自己做面试官的感受是每天工作很忙， 不想在简历里花太多时间， 要是候选人写了特别多的东西， 在一家公司的经历里我最多看前三个。 而且写的太多了，我就比较难判断出他最擅长什么的。 所以我写简历的时候就习惯了只写 3 个我觉得最有亮点的东西。 当初挺纠结的， 因为简历写 AI 的东西少了很多， 没有突出在 AI 方面的亮点。 比如在项目中开展的模型效果测试， 机器学习框架的测试等等，这也算当初写简历的时候一个败笔吧， 当时没太重视 AI 的东西。 如果现在让我写，我就会把 AI 的东西放到最前面了。

其实在范式这边简单来说就比较深入的研究了 3 个领域吧：

• AI
• 云原生（docker 和 k8s）
• 大数据

在这 5 年半里的成长真的是飞速的， 技术上我觉得是质的改变。 在这之前的都是通用领域的东西，不管自动化测试方案还是性能测试这些其实技术难度都不高。 有底子有机会的同学花个 1,2 年时间都能做的到。 底子和机会没有那么好的同学（比如我）， 花个 3,5 年也差不多了。 而在范式里研究的这三个领域，就算是有门槛了，因为这里面的东西是真的难， 到现在我都觉得我在这几个领域里的造诣在真大牛面前不值一提。 而且这几个领域相对小众，当初能拿到机会从事这个领域的测试人员非常少（干这个事的公司也少， 在阿尔法狗出现之前我们公司去谈客户都不敢说自己是搞 AI 的，怕人家以为我们是骗子， 谁又能想到后面阿尔法够和大模型的出现，给 AI 续了这么长时间的命，我觉得这也算运气了， 我当初选这个赛道是真没想到后面是这样的）。所以感觉运气这个东西也很奇妙的，当初选择深入研究这 3 个领域， 然后偏偏这三个领域这几年却都火了起来。 这也导致了我在 21 年跳槽的时候（正好满 35 岁），完全感受不到 35 岁危机，毕竟火了那招的人就多。

第四阶段 -- 当前公司

因为当前公司的高压线实在不敢碰，所以我不敢写当前公司的东西。 而且我也没有跳槽的打算，简历也没有写。 不过如果写的话大概也就是强调突出以下几个方面：

• 云原生方面，参与测试了商用 K8S 的测试工作，重点测试性能和高可用。期间开发了一些工具。 比如：
  • 性能测试方面引入 kubemark 开发了模拟大规模 K8S 节点的工具，模拟了 2000 节点的性能测试。
  • 性能测试方面引入普罗米修斯，开发监控平台，开展容量测试，自动化的性能测试
  • 高可用方面二次开发了 chaos-mesh，新增了部分故障类型。
  • 根据 k8s 的 listandwatch 机制，在监控平台中开发了 k8s 异常事件监控
• AI 方面，对比在第四范式的时候接触了计算机视觉和大模型的产品测试工作。比如：
  • 计算机视觉：负责产品超过 100 个识别场景的效果测试，开发 sdk，微服务和端到端的自动化效果测试框架，需要强调的是端到端效果测试中引入了 orc 能力来识别告警帧。
  • 计算机视觉：使用 opencv/ffmpeg/easydawin（流媒体服务器）/blink 模型/yolo 模型 等技术开发出了一套数据处理工具链。 可实现数据采集，挖掘，增强，设备模拟，抽帧，视频合成等功能来辅助效果，性能和功能测试。
    
  • 大模型方面：主要是接触了一些智能客服产品（其实做的有限），了解到了大模型的各种测试场景。
• 大数据方面：这个没什么太多可以说的， 因为跟在范式的时候用的技术栈是一样的，无非就是多学习了一些大数据组件，比如 ck， 在 ck 上还开发了一些性能分析的工具什么的。

结尾

这些年的工作履历就差不多这样了， 当前公司的东西实在不敢提跟业务有关的一个字，所以也就写写测试技术上的东西。