十年茫茫软件路

gj518889

回复 19# sunshinelius
最近面试了3家，感觉都是觉得10多年的经验人家用不起，不敢用，虽然降低身价，人家还是觉得你干不长，一有机会就会跳，接近40就成破衣服了么？

sunshinelius

尽管在转开发之前，我做了一些知识的准备，但进入M公司之后，发现那些知识混弄面试还凑合，但应对工作却远远不够，尤其是一个高级软件开发工程师的岗位。
     这给我带来了巨大的压力，人最危险的状态是“名不副实”，往前一步是泡沫，往后一步是原形，深深太平洋的深深伤心啊。
    M公司主要开发语言是C和C++，而且大多产品已经发布，处在维护阶段，而我的任务就是负责一个产品上的新功能开发，实际上也可叫做补丁。要改代码，就要先读懂老代码，几万行的代码，一份功能文档，要在一两个月内看懂，压力很大。毕竟我大多的开发经验只是在研究生阶段做过一些小规模的原型开发，还从来还没有接触过大系统的开发工作。
    有人说，正规的公司应该有入职培训，安排工作导师啊，这些在M公司不是没有，大多是常规的笼统的，所谓“师傅领进门，修行在个人”，具体到工作上的细节，大多还是靠自己来琢磨。向工作导师求教是一个不错的途径，但工作导师不是学校的老师专门负责答疑解惑，他也有自己的工作任务。所以，对于一个新员工，如何能够从有经验的同事那里快速学习到知识是很一件重要的本领。
    我们十几年所受的教育模式是，好多年轻人听一个长者讲，然后要精准无误，丝毫不差地将这些知识通过考试再反馈给长者，尤其文科类科目，政治语文历史等等，考试像是复印机性能竞赛，谁复印得越清楚，谁得分就越高。在这个教育过程中，年轻人只用到耳朵和手，没用到嘴巴，而倾听和表达是人际交流中最关键的两个信息交流方向，人们通过倾听收集信息，在大脑里分析这些信息，然后又通过讲话校验和表达这些信息，再倾听，再反馈，进而通过交流获得自身能力的提高。
    在软件过程中，有一个活动叫代码审查，由代码开发者走读自己的代码，很多时候，开发者在复述自己代码的过程中，就发现了其中的问题，可见在组织语言的过程中，大脑同时也在进行思考和校验。语言能力提高到一定水平后，运用简单的逻辑和质朴的词汇，就能说清楚一件复杂的事，这是一种巨大的人格魅力。

蹇自勤

期待LZ转开发后对测试的新视野

girl04

原来是《让loadrunner走下神坛》的作者呀，敬佩敬佩！前辈。

这是多年来看到且印像非常深刻的文章。

omg

如何快速学习，融入新项目和新公司，真的是个难题，看到不少人，速度真的比较慢。

夕阳西下°

楼主测试转写作吧，文采飞扬，不当作家可惜了，太厉害了！

sunshinelius

回复 20# omg
谢谢关注，后面会提到

sunshinelius

张嘴说话，至少有两个好处，别人能了解你的想法，你能获得有效的反馈。
和同事的交流最好从一个问题开始，因为做技术的人很少愿意做无目的的谈话，而且，交流过程中也会发现更多的问题，得到的答案越多，进步就会越快。可以说，提出一个好的问题就是成功了一半。
从哪里搜集问题呢？工作环境中有很多挺好的渠道，比如大公司内部的文档库，邮件列表， bug数据库等等。拿出测试工程师的耐心和细心，总会找到一些线索。我有一次在程序里发现某个网络会话对象构建得非常大，达400多Ｋ，而且在网络交互中，客户端没做cache, 一次登陆会发生多次数据包往返，测试的职业敏感让我想到了这里可能存在的性能问题，于是通过计算，证明在百兆局域网里只要有12个用户以上同时登陆，就会导致网络瓶颈。做出这个结论，我没有做任何真实的loadrunner并发，只是在脑子里模拟了一下场景。当时我把这个问题反映给负责的同事，他惊讶得下巴都快掉下来了。
转型压力依然非常大，汤师爷说过“步子迈大了，容易扯着蛋”，我的这次转型有两个跨越，第一，测试转开发，缺少上手开发的经验。第二，大系统的开发工作，没有丰富代码经验的人也很难摸到门路。
就是因为扯了蛋，我面对新工作就经常蛋疼。
在这里，给那些想从测试转开发的朋友建议，如果你想做开发，可以多看自己项目里开发人员写的代码，没吃上猪肉，至少也能见过猪跑，看多了，自然会有理解，再吃猪肉，就不那么发怵了。

sunshinelius

日子一天天过，我就那么一点点啃代码，虽然进度慢点，但按照这个思路下去，也应该至少是一个笨鸟先飞，新警察入道的传统故事，毕竟古人说过“世上无难事，只怕有心人“嘛，但别忘了，古人还说过”人算不如天算“。在我进入开发工作几个月后的一天，公司突然传来消息，由于种种原因，项目要发生变动，人员也要调整。原来，这个项目在我进入之前就已经不稳定了，这也是当时我为什么会如此”幸运“的一个重要原因。
   经历这件事之后，在我梦里，经常出现两艘大船，一个是泰坦尼克号，一个是诺亚方舟，应该上哪艘船呢。
   天上掉馅饼，也掉秤砣。我收到了O公司的offer，就又回到测试行业里来了（不要问我为什么）。当今电视选秀中一群坐在高高龙椅上的导师嘉宾经常问选手的问题“你有什么梦想啊”，“你为什么选择这个行业”。我想，对这种问题的回答大多不可能是真实的。就像王石不会告诉你，他的前岳父是广东省委副书记；马化腾不会告诉你，他父亲是盐田港上市公司董事；刘志军不会告诉你，他当年是因为娶了武汉铁路局局长的侄女后平步青云。
   进了O公司，负责一个产品的模块测试。应该说，O公司相比其他公司测试人员地位还是有点分量的，给我印象深刻的是测试人员居然参与代码单元测试，在业界还在争论单元测试应该是由开发还是测试来做的时候，O公司的策略很简单也很务实，无论开发和测试谁一方做单元测试，最后都要经过对方的review。没有一个强大的测试技术团队是不可能争取到这个地位的。

sunshinelius

回复 23# 蹇自勤
我喜欢你用视野这个词，确实看得宽了，有挺多纠结的问题都能找到答案，这就是成长。

sunshinelius

回复 21# gj518889
特别理解软测人员的职业瓶颈，在国内环境下，35岁可以算是一个分水岭。用人单位担心35后的可能不是跳槽，而是安排不了一个合适的岗位。在国外，我见到五六十岁还在做软测的人。我在后续的帖子里讨论这个差别，谢谢关注。

wason21cn

O公司 Oracle ?

omg

看样子，这O公司，的确不错。

sunshinelius

回复 33# omg
大公司内部各个产品部门都会有差别的。

sunshinelius

首先说说单元测试，任何工作都要遵循投入产出比最大化，单元测试是一项距离开发最近的测试工作，开发人员做单元测试无疑效率最高，因为设计单元测试案例要理解代码的功能，单元模块之间的调用，继承关系，把这些搞清楚，相当于重新开发一次代码。但这也不绝对，如果是一些标准规范化的功能，测试人员也可以介入单元测试的，比如涉及到编码，解码，文档MIME规范等等，这些功能input和output都比较简单和固定，测试人员如果有一定代码水平，做起来完全没有问题。但无论哪一种实现，都需要人工投入。有的小公司小项目，测试就几个人，忙手工测试还手忙脚乱，谈单元测试那无疑是纸上画饼。从我个人来看，我倾向于将来单元测试会成为开发必做的工作，当然也可以指导测试人员去做这项工作，最关键的是需要一个透明的流程机制来定时运行，维护，更新这些单元测试案例，hudson是一个比较不错的框架，就是太偏重开发。
    UI自动化测试就像一个梦中情人，听说过，但从来没真正地享受过。UI自动化测试的关键之处不在工具，也不在技术，而在于产品的管理，流程给UI自动化测试添加了非常多的干扰因子。比如吧，花了一周开发的测试脚本，可能在产品版本的升级后，就跑不起来了，花了半天才定位出是因为页面上的某个labe属性变化了，好吧，修改脚本，再运行，下个版本又出错，再修改，最后算算，自动化上花费的时间可能比手工测试还要多。要避免这种风险，需要谨慎考虑自动化测试介入的时机，和自动化测试案例的功能范围。凭个人经验，介入不宜过早，可以选择在稳定的回归测试开始之后；自动化覆盖率不宜过高，能达到20%就是一个不错的比率了。如果各项条件都不成熟，可以暂时不做，把自动化测试计划得更远一些。至于QTP，Winrunner，Selenium等等工具，不比做太多的伯仲之争，我一向的观点是，工具就是工具，用的爽了就用，用的不爽就换，自动化测试人员随着经验增长，应该把更多的精力转移到自动化的整体方案上来，能不能用，用什么，怎么用，怎么和开发流程整合，怎么生成报告的问题上来。而对于测试经理来说，UI自动化测试可能是一个毒丸，需要根据实际对自动化测试实施做恰当的决策，软件产品周期长功能稳定，自动化测试必须考虑在测试计划里，软件项目周期短变化快，自动化测试可以考虑适时而为，虚虚实实结合，对上既有政绩，对下又有业绩。
      性能测试呢，是一个技术性较强的工作，开发能做，之所以是测试人员来做，因为它是性能测试。但尴尬的是对于测试人员来说，性能测试的要求又太高了，几乎要囊括了体系设计，系统平台，中间件，数据库等各方面的知识专家，当然可以说这些知识测试人员应该有，但是到了那个层次后，他恐怕就不叫测试人员了，可以叫DBA，叫System administrator。所以，性能测试人员的最大作用是将性能测试推动起来，能够将这些不同的知识专家们集结到一个性能问题上，当然，如果能够对性能问题做一些定量的分析，判断问题范围，那就更完美了。在性能测试里，沟通也是一个重要的本领，谦虚是必须的，因为你面对的是专家，随意下结论很显然是自取其辱的最快捷方式。
    在测试过程里，不少产品都有一个安装测试，负责部署环境。安装包括server端的安装和客户端安装，安装测试是典型的简单高重复工作，因此也是自动化测试实施的重点领域。如果是web页面，需要和不同的浏览器不同的版本进行兼容，如果是桌面客户端就更麻烦了，windows，linux，还有mac，现在智能终端的兴起又有iphone, ipad, android。另外，插件也是客户端的一种方式，插在浏览器上，outlook上，这又牵出一堆的版本矩阵。安装测试工作的关键点在于测试场景的整理，优先级的规划，测试计划安排。首先可以整理出一个测试场景矩阵，估算工作量，测试机器资源等等，然后进行计划安排，自动化测试的规划等等。如果自动化测试做得不错，安装测试会是一个比较稳定有序的工作。

omg

前辈在O公司做多久？经历上面的事项吗？

sunshinelius

回复 36# omg
既然问到这了，我就说一下大概我的个人职业历程，从测试到开发，到自动化测试，到测试经理，逆袭开发经理，目前任云计算方向的高级开发经理。我在本贴的观点皆出于本人经历和观察，之所以写本贴，是个人测试到开发的一个总结，权当向51testing论坛朋友的致敬和告别，另外，就是看到测试业界自负和自卑，热情和迷茫并存，希望能提供一个视角让大家平和看待开发和测试。

omg

厉害。做到开发经理，又是扯上云计算的。

夕阳西下°

回复 37# sunshinelius

为什么要告别呢？

flyinglus

mark,期待下文