题图： from Zoommy

最近一直在忙GTLC与GIAC两个大会的事，所以公众号更新晚了几天，还请各位读者担待。

今天来跟大家聊下我当年做测试的一些经历。

每次问我有关职业发展的问题时，我都会反问两个问题。一是你当下最喜欢做的工作是什么，二是你当下最擅长做的工作是什么。

面对这两个问题，大部分人的回答都很相似。先是一愣，然后含含糊糊的说三个字 “不知道…” 或  “没想过…”。

的确，吃喝玩乐，娶妻生子，才是大多数人的基本诉求，什么理想与目标，似乎都不是你蹦一下就能够得到的，这种感觉像极了一头拉磨的驴子，只能蒙着眼睛不停的向前跑，否则就会挨鞭子。

我常说，哪有什么人生规划，都是历史机缘的巧合罢了。

就像我的简历，凡是看过的人都会问：“你做过测试？为什么会选择去做测试呢？”

选择？对和多人来说，职业生涯的发展真的是选出来的吗？一切都是被迫的，一切都是莫名其妙的。

在 #我是技术男，也曾创业过，也拿过风投……# 的篇尾，我说自己带着两年的创业史，身背近五十万的债务，来到了大智慧办理入职手续，开始了新的人生。

这段台词非常耳熟，像极了小时候看到的童话小说，王子和公主从此过上了幸福快乐的生活，恩爱一生。

很可惜，人生毕竟不是小说，把一个人写死了，还可以用某个场景让他复活。

相信大部分的人都有过走投无路的经历，在残酷的现实面前，什么理想，什么目标，都变得毫无价值，能活下去，才是当务之急。

2011年底，那场创业悲剧，让我和我的家人几乎陷入了万劫不复的地步。

在公司开始清盘的第二周，有位朋友给我介绍工作，说是大智慧在招聘架构师，对口研发中心的HRBP正好是他女朋友，问我有没有兴趣。

这真是天无绝人之路，来早不如来得巧，关系那么铁，我自认为八九不离十。

“太感谢了，没想到就我这点破事，你还挂在心上了。”

“先别忙着谢，有个事情要先说下，这个正在招聘的岗位归属测试团队，也就是说，如果你过去，职位最多是测试架构师……”，电话那头的声音显得有些无奈。

“不知道你是否在意？听说这个岗位他们招了半年，一直不理想，我觉得你肯定能够胜任。”

对当时的我来说，与岗位和职务相比，收入与稳定性对我的吸引力更大。

“无所谓，帮我安排面试吧，”，这种爽快程度，连我自己都不敢相信。

“你下午就过去吧，我女朋友那边已经给你安排好了。”

以前的我从来都不信什么牛鬼蛇神，也不信小说上那种纯情的完美结局，但此时此刻，我似乎感觉面对未来以后充满了希望，但又无法面对。

面试进行了2个小时，面试官是当时的测试总监，近四十的年纪，说话很稳重。

在谈话中，我们交流了有关阻抗测试的各种问题，并探讨了一些传统测试转型的方法。

这方面的记忆力是我的强项，至今我任然记得一些：

1、只能发现问题，无法解决问题

测试环节，常常在代码编写之后，就算测试小伙伴的能力再强，通过九牛二虎之力测试了致命性问题，但为时已晚，要想重新折回头处理其中的问题是要花费一些时间和精力的，降低了交付效率，如果不打回修复，则无法保证质量。

2、有能力的不愿意做测试

从事测试工作的小伙伴，一般都没有研发能力，有研发能力的一般也不会来做测试，毕竟无论从地位，还是收入，开发都要比测试高一些。

这就形成了马太效应，好的越好，差的越差。

3、业务测试与业务验证，傻傻分不清

通常情况下，讨论需求的时候，业务方都会叫上开发，毕竟需要开发去实现，但绝不会叫测试。

这里会形成一种尴尬，因为测试员不可能理解所有的代码，而且没有参加需求环节，所以漏掉一些重要的测试是很有可能的。但业务方不会遗漏，毕竟这是他们的工作核心。

因为，我们经常会碰到，测试没测出的问题，却在业务验证时发现了。

然后有趣的场景出现了，业务怪开发，开发怪测试，测试直喊冤枉。

4、测试环境是世界级难题

测试环境，是每家公司最头痛的问题。比如测试通过，生产报错，再比如测试人员编写的测试是依赖的文档或其他东西，而不是代码，配置和数据存在任何不一致的地方的时候，就会造成问题。

另外，如果测试不是自动进行的，那么极有可能不会被频繁、经常性地进行，这大大降低了发现环境问题的可能性。

在敏捷尚未盛行，职能分工当道的时代，这些似乎都是测试团队的死穴。

而在他们眼里，只要能找到一位具有丰富架构经验的 ‘冤大头’，并组建一个测试架构部，这些问题应该都会迎刃而解。

就这样，我稀里糊涂的成为了那个 ‘冤大头’。

之前也曾与朋友聊起过这段经历，有朋友说，这些问题用敏捷和DevOps就能解决，用不起来是企业文化的问题，找谁来都只能填坑，起不了什么作用。

一切脱离时代背景的评价，都是耍流氓。

在当时，知道敏捷的人不少，了解DevOps的人也挺多，但真正能体系化将这两样东西落地的企业却很少。理论大家都懂，但如何在现有基础上逐步实践落地，并取得想要的成果，没一个人能说的明白。

而且，伴随着交付压力的增大，研发与测试之间的交流越来越少，所以想通过一些方法，打通交流的障碍。

第一阶段：应用与基础的测试分离

在入职后的半年里，我的主要工作是参与各测试团队的工作，一来混熟人头，二来熟悉业务与现有工作模式。

半年后，我开始与测试总监一起，针对一系列问题进行改进。

先来说说组织结构。

大智慧的系统是建立在C/S架构之上的，所以研发被天然的分割成 “前端” 与 “后端”，又因公司业务分为 “股票实时行情” 与 “金融数据服务” 两个板块，把 “后端” 分为行情服务端与数据服务端。

当时的组织架构采取的是职能式组织模式，既然研发被分成为三个团队，测试也只能紧随其后。

与客户端、行情服务端相比，数据服务端的问题就显得非常多。

以上交所Level-2行情为例，业务场景固化，无论接入协议，还是数据加密，都是非常公开且成熟的技术，而且需求变更少，改动不频繁，只要没有新市场接入，一年到头几乎没几个需求。

反观数据服务端，连续几年公司都重金投入，不仅先后并购了几家数据供应服务商，还对外喊出了 “天天发版” 的口号，气势一浪高过一浪。

这下可苦了研发与测试的小伙伴们，由于并购的公司技术栈各有不同，这家用SQLServer，那家就用MySQL，这家用Java，那家就用C++，环境与集成类的问题层出不穷，为了赶进度，只能胡子眉毛一把抓，管他什么应用还是框架，拼凑拼凑，跑通了就上，报错？拉下来改改，接续上。

一般说，遇到这种紧耦合的情况，就只剩 “拆” 这一条路。

为了不对现有业务的迭代速度造成影响，与研发团队设立了两条拆分原则：

• 原有业务：如有需求调整，强制迁移至新架构，并将基础与应用进行分离。
• 新增业务：基于新架构，并将基础与应用进行分离。

经过半年的折腾，无论老业务还是新业务，大部分核心部分基本都已迁移至新架构上。

随即，数据服务测试团队也被拆分成 “基础测试” 与 “应用测试”，一个保障基建，一个保障业务。

就因这一波操作，经公司领导决定，将 “基础测试” 与 “应用测试” 划归我的名下。

我就这样，莫名其妙的睡了一觉，醒来的时候变成了测试经理。

第二阶段：尝试集成测试驱动开发

工作与生活差不多，烦心事总是一波接着一波。

某天午后，领导找我谈话，说开发、测试与运维之间相互推诿的情况日趋严重，想听听我有没有好建议。

咱是读过孙子兵法的人，一听就明白了。立即搬出一番DevOps的方案，领导听了连连摆手，说：“这种大而全的东西少拿来忽悠，来点实际的吧。”

我一愣，想了想说：“要不拿我的两个团队来试点，再不改变现有流程的情况，尝试测试驱动开发怎么样？”

领导笑了，点了点头，说：“嗯，你很主动，大胆的去干吧，我支持你！”

尼玛，我感觉这根本不是谈话，分明是挖了个坑让我自己跳。

什么叫测试驱动开发？

对敏捷比较熟悉的同学，相信一定听说过TDD（Test-Driven Development）。

大致是说在明确要开发某个功能后，在开发功能代码之前，先编写测试代码，然后编写功能代码并用测试代码进行验证，如此循环直到完成全部功能的开发。

在技术圈，很多人都讨厌这种看似完美的理论，因为与现实中的情况距离太远。因为还以黑盒测试为主要手段的我们，就单单 “编写测试代码” 这一项，就会把我们挡在门外。

所以，我们只能寻找一些适合我们当前技术实力的出路。

与其他公司一样，我发现大部分的测试爆发点都集中在集成测试阶段，举个例子证实下。

案例：业务系统新上一个A功能，同时涉及客户端、基础与应用的修改与新增，结果如何呢？

从这张表中可以明显看到以下几点：

• 各开发都说自己做过了单元测试，并顺利通过，所以我没问题。
• 各测试都说自己跑过回归测试，并顺利通过，所以我没问题。
• 每次提交，客户端测试都在群里喊，请大家注意配置项的提交，没人说话。

想起当时有小伙伴调侃过，说每个环节都说自己没问题，但只要放在一起就出各种问题，难道是机房风水有问题？

显然不是，那问题究竟出在哪里呢？

又经过半年的折腾，对环境、配置与组织进行了一系列的调整：

我相信一句话，这世界上从来就没有什么救世主，你强了，你坚信了，困难就变弱了。

到2012年底，我们基本达成 “集成测试团队驱动开发” 的效果，协助开发进行问题排查，并且取代了项目管理的工作。

又因这一波操作，经公司领导决定，将集成测试团队也划归我的名下。

就这样，我似乎又睡了一觉，醒来的时候变成了测试副总监。

第三阶段：试图统一流程与工作方式

三国演义开篇说，天下大事，分久必合，合久必分。

随着棘手问题的逐渐得到缓解，大家开始把注意力放在了流程与规范上。

当时，各测试团队虽然名义上都归属于测试部，但基本都各自为战，你有你的流程，我有我的套路。

比如上级想得到BUG修复率或提测效率这样的报告，基本是不可能的。

另外，像测试流程不规范，测试文档不健全、测试文档也没有控制和管理等问题也非常突出。

2013年初，经公司领导决定，将剩余的客户端、行情服务端这两个测试团队合并至我的团队，成立新测试部门。

我的职务也从测试副总监，升为测试总监。

目标是在年底之前，完成新测试部门的岗位职能、测试流程、测试文档规范、日常项目工作、部门考评机制以及测试部门人员技能与业务的培训等多方面的规划，为公司明年的产品战略提供更高的质量保障。

回想当时的我，满脑子装的都是 “如何帮助研发团队释放潜力” 的激进词汇。一拍脑袋，要求测试所有团队将工作工具从 “Excel+脚本” 切换到Atlassian下。

或许是这一步迈得太大，而且在整个推进的过程中，我也非常强势。

就这样，惹恼了测试团队中的一些老人，为此还吵过几次，气氛开始变得不愉快起来。

细心的朋友可能已经发现，不仅每个阶段的涉及范围都很广，而且都牵涉到了组织结构的调整，那为什么我还会推动的如此之快呢？

强势与强压，是我惯用的两个手段。

在我心里一直坚信，既然高层把这项艰巨的任务交给我，我就要不惜一切代价搞定。

现在回想起来，我像极了商鞅，改革是成功了，人也得罪光了，有人罩着你的时候，或许一切都显得顺风顺水，一旦那个罩你的人不在了，你的死期也就到了。

2013年7月，大智慧已连续亏损几年，业务低迷，人心惶惶，内部进行了一次结构调整，我受到牵连，被调到了一个新成立的部门，负责新技术的探索。

说白了，就是被踹了，被撸了。

2013年9月，我提交了离职申请，离开了大智慧。

一转眼，六年过去了。

每次谈起这段经历，我都说，如果上天再给我一次机会重来，我应该会更圆滑一些，至少能让 “审判日” 来的更晚一些。

人生没有如果，只有后果和经历，而经历却可以转化为财富，为将来的职业生涯做好铺垫。

有的人说，我身上的故事真多，感觉总写不完。

有的人说，我可以去当编剧，故事编的很溜。

我只想说，我是个搞技术的，不会编故事，只不过天生臭脾气，遇到的坎坷自然会多一些。

另外，我愿意将这些事情记在心里，再写出来与大家分享。

如果你也愿意，相信会比我更加精彩。