前不久在北京的大学同学聚会，毕业13年了，在家庭里，工作上，社会中摸爬滚打十几年，都有了不少感悟和话题，席间大家不约而同地谈到一个话题，自己行业这碗饭吃得怎么样，还能吃多久。

奔四的年龄恰处在人生的一个拐点时刻，青春理想的惯性动力已经慢慢消失，对社会环境职场生存的人事开始形成一些自己的观点和判断，能接受残酷和无奈，也能观察机会和希望。如果说二三十岁是一个靠机会凭直觉的青春型成功时期，那么四十岁就是靠理性主动寻找人生价值来获取个人成功的阶段。

如今社会有不少极端案例，自焚，流血甚至危害公共安全，我有观察过，事主有不少是在45岁左右，这看起来有点奇怪，既不是热血青春的冲动青年，也不是已近暮年的老人，45岁大概是“看破”的年龄，是成功者最得意风发的人生阶段，也是失意者最没落绝望的时期。古往今来很少有人能够在四五十岁之后还能大幅度改变人生轨迹的人，除非时势造英雄，如八十岁的姜太公，当然时势也能打造狗熊，“时来天地皆同力，运去英雄不自由”。

“菩萨畏因，凡人畏果”，我是一凡夫俗子，当然担心40岁之后如何讨生活的问题，要想好好地谋划未来，就得狠狠地总结过去，这也是为什么我想写这篇文章的原因。

2002年我计算机应用小硕毕业，毕业课题有关软件性能测试，这给当时毕业的我出了一个“测试还是开发”的哈姆雷特问题，不过当时的IT行业正在高潮期，实际也是中国走向全球化的快速发展时期，到处都是新想法和机会，我不是哈姆雷特，却如阿Q一样，眼看周围同学纷纷走向外企和民企，便高喊着“同去！同去！”，就这样稀里糊涂地踏入了软件测试行业。

现在想想，人生最重要的决定往往是最不经意做出的。可能是因为小时叛逆想远远离开父母而选择到另外一个城市奋斗，这里后来成就了你的所有人脉；可能是因为网上偶遇认识了你的另一半，而从此你们在余生互相消耗折磨对方直到70岁才宽慰“我终于可以忍受他上床不洗脚了”。古人有句话“很好的姻缘都是天成的”，我再加上一句“很坏的姻缘也是天成的”，你只能在现有的条件下，努力打好手上的牌。

1.零起点从测试开始

第一份工作就这样开始了。负责一个功能模块的UI手工测试，还兼做公司几个产品上线前的性能测试。工具就是loadrunner，录脚本，设场景，看报告，三板斧下来，总会发现一些性能问题，这项工作是给测试团队加分的，因为人对自己不了解的领域会有本能的敬畏和尊重，在十年前，谈到“”高并发”“大负载”，连开发人员也会觉得新奇。后来测试业界又出现了更多的性能概念名词，如“伸缩性”，“压力测试”，“容量测试”等等。我一直有个不善良的猜测，业界一些利益相关者出于某种目的，将能够说简单的事情复杂化，有意给读者设置理解障碍，就像社会某专家一样，大谈“幸福指数”，“等离子”，想跟我对话辩论，先明白些名词吧，不过名词的解释权可在我手里哦，一些中国所谓专家就是这么练成的，信息和术语的垄断太可怕了。

于是，2004年，我在论坛写了《让loadrunner走下神坛》，在2006年出了第一本关于loadrunner的入门书，这促使了我对性能测试做一些思考，loadrunner能证明系统存在瓶颈，能找出瓶颈在哪里么，再前进一步，我们能够消除甚至提前避免瓶颈出现么？这些问号，使我最后回到一个简单的问题上来，到底什么是“瓶颈”，它到底在软件系统的哪个地方出生，身材相貌，成长背景，我竟然对它一无所知，这太荒谬了，就像社会都说“有关部门”，但谁也没看过“有关部门”的住址门牌。

手工测试里重复工作多，不知什么时候开发出来一个build，就要开测，忙得一塌糊涂。测得不顺要加班，测得顺利又没bug可提。这种日子一天连着一天，一直在想能不能把测试工作做得像开发一样，理性有序。于是抽点时间就搞了几个想法，测试案例管理，执行自动化，报告生成。这几个工作大大地提高了测试效率，获得了领导的肯定，单独找我谈话：“小liu同学，我要提拔你，以后你可以与开发平起平坐，共商软件质量大计”，打住，醒醒，哥们，你是在炖测试版的心灵鸡汤呢吧？

我不是写小说，我要做的是如实地面对自己的过去，诚恳对待自己，还有看到我的文字的人们。

改善手工测试的种种努力，在项目实践中收效甚微，不是无果而终，就是半道中卒。那些在教科书中写着的知识，在国外已经成熟的经验，为什么在我们自己的项目里就应用不起来呢。比如测试流程管理，目的将测试中的工作规范化，测试自动化是为了提高执行效率，这些看起来都是很好的愿景，没有错啊，那是什么地方出了问题呢。

我有几年一直在努力从测试技术上寻找答案，后来终于有了一点想法。

当我们把过多的关注焦点放在在如做好软件测试的时候，下意识里有一个隐含的前提，就是测试是独立于开发的，我们可以不用太关心软件开发，就可以经营好自己的测试领域，从而反推开发提升软件质量。这种逻辑对不对，可以从实践中求证，有没有哪个软件企业开发做得混乱无序，而测试做得井井有条呢？

当我们在低头苦苦寻找答案时，不妨得闲抬头望望星空。有过人生阅历的人可能会有体会，最棘手的问题往往最后是两难共存的，而不是简单的一方消灭另一方。

开发和测试这对冤家是整个软件生产过程的一部分，矛盾有对立也有统一，离开了开发模式谈测试流程是空谈误国，离开了开发技术谈测试技术也是纸上谈兵。一个需求频繁变化的软件项目，连开发都忙得焦头烂额，你能指望测试工作整齐有序么？ 一个用户界面“一周小变样，一月大变样”的系统，你能设立UI自动化测试目标达到50%的覆盖率么？

软件开发和测试本是人为设定的两个概念，你把它当成一个软件概念更容易想明白一些问题。当前有一个趋势，开发和测试越来越向对方融合，开发也要做自己的测试，测试也要做自己的开发，开发思维和测试思维并存，才能做出好软件。

到了2005年，无论做性能测试，还是手工测试，遇到的问题和事情让我有了一个内心冲动，去做开发！我要去看看开发工作到底在做什么，为什么会有bug产生。

我像一个大山里的孩子，每天对着大山，山那边到底是什么对我来说是新奇的，我渴望想翻过那座高山，看看山那边到底是那么样子。

2. 测试还是开发，这是一个问题

从软件测试转开发，是很有难度的。第一，从自身看，开发比测试的技术和经验要求更高，有人说，我们做测试的也会写代码啊，其实写代码是开发人员的一个基本条件，开发人员的经验不光是写代码，还有技术架构的选型和设计，对开发流程的熟悉等等，这些都是测试转开发的困难。第二，从用人单位看，大多数企业给开发定的工资比测试高，他们不太愿意用能给开发的工资雇佣一个只有测试背景的人。

所以，做测试要转开发，时间上就要计划一个提前量，用心学习和准备。要在面试官前展现出来至少不逊于一般开发人员的技术素质，才有可能被录取。

我当时准备了半年，在这段时间里把c语言和数据结构的书又看了一遍，然后研究一些网上的面试题，主要是算法问题。

面试了公司很多，其中曲折历程不多讲，电话面试就失败，运气好进入现场面试，最佳战绩也是只到了第二轮没了下文。后来放弃开发，测试职位竟然也屡试不中，从刚开始自信满满到后来斗志涣散，开始怀疑自己的能力。

在几乎放弃希望的时候，收到了一个M公司的开发职位offer，还是高级开发工程师的抬头。以M公司的名气和这个开发岗位，我都感觉像做梦，不真实。

好吧，来吧，一切未知的已知的，困难的容易的，都来吧，我要开始新的航程。

尽管在转开发之前，我做了一些知识的准备，但进入M公司之后，发现那些知识混弄面试还凑合，但应对工作却远远不够，尤其是一个高级软件开发工程师的岗位。

这给我带来了巨大的压力，人最危险的状态是“名不副实”，往前一步是泡沫，往后一步是原形，深深太平洋的深深伤心啊。
M公司主要开发语言是C和C++，而且大多产品已经发布，处在维护阶段，而我的任务就是负责一个产品上的新功能开发，实际上也可叫做补丁。要改代码，就要先读懂老代码，几万行的代码，一份功能文档，要在一两个月内看懂，压力很大。毕竟我大多的开发经验只是在研究生阶段做过一些小规模的原型开发，还从来还没有接触过大系统的开发工作。

有人说，正规的公司应该有入职培训，安排工作导师啊，这些在M公司不是没有，大多是常规的笼统的，所谓“师傅领进门，修行在个人”，具体到工作上的细节，大多还是靠自己来琢磨。向工作导师求教是一个不错的途径，但工作导师不是学校的老师专门负责答疑解惑，他也有自己的工作任务。所以，对于一个新员工，如何能够从有经验的同事那里快速学习到知识是很一件重要的本领。

我们十几年所受的教育模式是，好多年轻人听一个长者讲，然后要精准无误，丝毫不差地将这些知识通过**再反馈给长者，尤其文科类科目，政治语文历史等等，**像是复印机性能竞赛，谁复印得越清楚，谁得分就越高。在这个教育过程中，年轻人只用到耳朵和手，没用到嘴巴，而倾听和表达是人际交流中最关键的两个信息交流方向，人们通过倾听收集信息，在大脑里分析这些信息，然后又通过讲话校验和表达这些信息，再倾听，再反馈，进而通过交流获得自身能力的提高。

在软件过程中，有一个活动叫代码审查，由代码开发者走读自己的代码，很多时候，开发者在复述自己代码的过程中，就发现了其中的问题，可见在组织语言的过程中，大脑同时也在进行思考和校验。语言能力提高到一定水平后，运用简单的逻辑和质朴的词汇，就能说清楚一件复杂的事，这是一种巨大的人格魅力。

张嘴说话，至少有两个好处，别人能了解你的想法，你能获得有效的反馈。

和同事的交流最好从一个问题开始，因为做技术的人很少愿意做漫无目的的谈话，而且，交流过程中也会发现更多的问题，得到的答案越多，进步就会越快。可以说，提出一个好的问题就是成功了一半。

从哪里搜集问题呢？工作环境中有很多挺好的渠道，比如大公司内部的文档库，邮件列表， bug数据库等等。拿出测试工程师的耐心和细心，总会找到一些线索。我有一次在程序里发现某个网络会话对象构建得非常大，达400多Ｋ，而且在网络交互中，客户端没做cache, 一次登陆会发生多次数据包往返，测试的职业敏感让我想到了这里可能存在的性能问题，于是通过计算，证明在百兆局域网里只要有12个用户以上同时登陆，就会导致网络瓶颈。做出这个结论，我没有做任何真实的loadrunner并发，只是在脑子里模拟了一下场景。当时我把这个问题反映给负责的同事，他惊讶得下巴都快掉下来了。

转型压力依然非常大，汤师爷说过“步子迈大了，容易扯着蛋”，我的这次转型有两个跨越，第一，测试转开发，缺少上手开发的经验。第二，大系统的开发工作，没有丰富代码经验的人也很难摸到门路。

就是因为扯了蛋，我面对新工作就经常蛋疼。

在这里，给那些想从测试转开发的朋友建议，如果你想做开发，可以多看自己项目里开发人员写的代码，没吃上猪肉，至少也能见过猪跑，看多了，自然会有理解，再吃猪肉，就不那么发怵了。

日子一天天过，我就那么一点点啃代码，虽然进度慢点，但按照这个思路下去，也应该至少是一个笨鸟先飞，新警察入道的传统故事，毕竟古人说过“世上无难事，只怕有心人“嘛，但别忘了，古人还说过”人算不如天算“。在我进入开发工作几个月后的一天，公司突然传来消息，由于种种原因，项目要发生变动，人员也要调整。原来，这个项目在我进入之前就已经不稳定了，这也是当时我为什么会如此”幸运“的一个重要原因。

经历这件事之后，在我梦里，经常出现两艘大船，一个是泰坦尼克号，一个是诺亚方舟，应该上哪艘船呢。

3. 测试里的那些事

天上掉馅饼，也掉秤砣。我收到了O公司的offer，就又回到测试行业里来了（不要问我为什么）。当今电视选秀中一群坐在高高龙椅上的导师嘉宾经常问选手的问题“你有什么梦想啊”，“你为什么选择这个行业”。我想，对这种问题的回答大多不可能是真实的。就像王石不会告诉你，他的前岳父是广东省委副书记；马化腾不会告诉你，他父亲是盐田港上市公司董事；刘志军不会告诉你，他当年是因为娶了武汉铁路局局长的侄女后平步青云。

进了O公司，负责一个产品的模块测试。应该说，O公司相比其他公司测试人员地位还是有点分量的，给我印象深刻的是测试人员居然参与代码单元测试，在业界还在争论单元测试应该是由开发还是测试来做的时候，O公司的策略很简单也很务实，无论开发和测试谁一方做单元测试，最后都要经过对方的review。没有一个强大的测试技术团队是不可能争取到这个地位的。

1）单元测试

首先说说单元测试，任何工作都要遵循投入产出比最大化，单元测试是一项距离开发最近的测试工作，开发人员做单元测试无疑效率最高，因为设计单元测试案例要理解代码的功能，单元模块之间的调用，继承关系，把这些搞清楚，相当于重新开发一次代码。但这也不绝对，如果是一些标准规范化的功能，测试人员也可以介入单元测试的，比如涉及到编码，解码，文档MIME规范等等，这些功能input和output都比较简单和固定，测试人员如果有一定代码水平，做起来完全没有问题。但无论哪一种实现，都需要人工投入。有的小公司小项目，测试就几个人，忙手工测试还手忙脚乱，谈单元测试那无疑是纸上画饼。从我个人来看，我倾向于将来单元测试会成为开发必做的工作，当然也可以指导测试人员去做这项工作，最关键的是需要一个透明的流程机制来定时运行，维护，更新这些单元测试案例，hudson是一个比较不错的框架，就是太偏重开发。

2）UI自动化测试

UI自动化测试就像一个梦中情人，听说过，但从来没真正地享受过。UI自动化测试的关键之处不在工具，也不在技术，而在于产品的管理，流程给UI自动化测试添加了非常多的干扰因子。比如吧，花了一周开发的测试脚本，可能在产品版本的升级后，就跑不起来了，花了半天才定位出是因为页面上的某个labe属性变化了，好吧，修改脚本，再运行，下个版本又出错，再修改，最后算算，自动化上花费的时间可能比手工测试还要多。要避免这种风险，需要谨慎考虑自动化测试介入的时机，和自动化测试案例的功能范围。凭个人经验，介入不宜过早，可以选择在稳定的回归测试开始之后；自动化覆盖率不宜过高，能达到20%就是一个不错的比率了。如果各项条件都不成熟，可以暂时不做，把自动化测试计划得更远一些。至于QTP，Winrunner，Selenium等等工具，不比做太多的伯仲之争，我一向的观点是，工具就是工具，用的爽了就用，用的不爽就换，自动化测试人员随着经验增长，应该把更多的精力转移到自动化的整体方案上来，能不能用，用什么，怎么用，怎么和开发流程整合，怎么生成报告的问题上来。而对于测试经理来说，UI自动化测试可能是一个毒丸，需要根据实际对自动化测试实施做恰当的决策，软件产品周期长功能稳定，自动化测试必须考虑在测试计划里，软件项目周期短变化快，自动化测试可以考虑适时而为，虚虚实实结合，对上既有政绩，对下又有业绩。

性能测试呢，是一个技术性较强的工作，开发能做，之所以是测试人员来做，因为它是性能测试。但尴尬的是对于测试人员来说，性能测试的要求又太高了，几乎要囊括了体系设计，系统平台，中间件，数据库等各方面的知识专家，当然可以说这些知识测试人员应该有，但是到了那个层次后，他恐怕就不叫测试人员了，可以叫DBA，叫System administrator。所以，性能测试人员的最大作用是将性能测试推动起来，能够将这些不同的知识专家们集结到一个性能问题上，当然，如果能够对性能问题做一些定量的分析，判断问题范围，那就更完美了。在性能测试里，沟通也是一个重要的本领，谦虚是必须的，因为你面对的是专家，随意下结论很显然是自取其辱的最快捷方式。

3）安装测试

在测试过程里，不少产品都有一个安装测试，负责部署环境。安装包括server端的安装和客户端安装，安装测试是典型的简单高重复工作，因此也是自动化测试实施的重点领域。如果是web页面，需要和不同的浏览器不同的版本进行兼容，如果是桌面客户端就更麻烦了，windows，linux，还有mac，现在智能终端的兴起又有iphone, ipad, android。另外，插件也是客户端的一种方式，插在浏览器上，outlook上，这又牵出一堆的版本矩阵。安装测试工作的关键点在于测试场景的整理，优先级的规划，测试计划安排。首先可以整理出一个测试场景矩阵，估算工作量，测试机器资源等等，然后进行计划安排，自动化测试的规划等等。如果自动化测试做得不错，安装测试会是一个比较稳定有序的工作。

再谈谈按照行业划分的测试

4）全球化测试

全球化测试(Globalization)，是一个固定的知识集合，包括数据层上的字符转化，应用层上的时间，日程，货币格式，BIDI等等各种不同locale。虽然Global feature相比base feature级别要低一些，但是Globalization的特点是知识独成一体，贯穿到开发的设计，实现，到测试的设计与实现。比如你的产品要支持全球化，那在产品设计初期就要规划好支持多少种locale，资源文件采用什么格式，翻译的process等等，在实现的时候，时间处理，字符长度计算，人名显示等等，要调用正确的globalization API, 避免默认英文的hard code，最后交给测试人员来验证。全球化的测试人员上手并不困难，遇上好的导师，一个新人上手全球化测试也就两三个月的时间，但是要做深入，还是要研究不少知识的，至少MIME规范，RFC，Unicode等等。如果做得好，可以进入Globalization的开发甚至设计，而不会受到业务的限制。个人的看法全球化测试工作稳定，可以做很长时间，但挑战性较小，毕竟unicode一统天下的时代开始了。

5）业务相关的测试

业务性很强的测试（比如金融，电信）。产品带有两个很强的属性，业务属性和软件属性，懂软件，同时也要对业务有理解，比如银行，证券等，无法通过常识来判断软件是否运行正确，需要一定的行业知识积累，这里的软件测试人员更像一个行业用户。同时，金融行业对于软件质量有着自己的要求，主要是功能正确，交易安全，至于其他的易用性什么的，不是考虑重点，所以在这个行业的测试人员我看到的都比较辛苦，经常做回归测试，而且对遗漏bug的追查也非常严格，再加上行业特点太强，他们不属于普通意义的软件测试人员，职业生涯和行业前景密切相关。

6）云计算下的测试

相比之下，云计算是软件属性非常强，按业界流行划分为IAAS, PAAS和SAAS三个层次，IAAS上对计算资源，存储资源，网络资源的虚拟化，PAAS上提供管理，计费，通知等公共服务平台，SAAS上则向用户提供最终服务。云计算的革命性是它提供了一种与以往传统软件不同的生长模式，从安装，部署，升级到扩容，都有统一的策略，这给软件界带来的影响是深远的。云计算不是突然产生的，其实像GoDaddy之类的网站空间运营商已经可以算的上是PAAS提供商了，下一步IT厂商将会在云计算领域进行更加剧烈的竞争，而大的IT公司（如电商，金融，通信）会向私有云靠拢，中小企业则会向公有云转移。云计算的兴起带来的是对软件开发人员的开发模式，流程工具都会有改变，而对测试人员的要求有更多的技能，甚至有可能将开发人员转做测试人员，总之，开发和测试的界限会越来越模糊。

7）用户体验与测试

用户体验(User Experience)是一个热点，如何能让软件的界面有更直观易用的风格，让用户喜欢，这是很多互联网公司正在做的事情，比如facebook的招聘计划里，user experience工程师名列薪水榜首，可见多么吃香紧俏。

软件测试工程师可以推动用户体验，反过来，用户体验又可以加强软件测试。可以想想，让你实现一个操作订单的功能（包括增加，查询，修改，删除在同一个页面里），这个功能很容易实现，但是怎样能够在不影响性能的前提下，让用户感觉更方便易用呢。这需要有两个基本条件，第一，对业务功能有深刻的理解，知道订单的上下文，工作流，操作权限等等。第二，对用户使用习惯有经验理论，如人体工学，人机交互学，信息结构等等。在UI测试中，如果测试人员能够留心UI的功能布局，页面风格，图标设计，响应输出，就能积累UE经验，甚至提出UE的bug。在不少互联网公司的bug数据库里有一个叫做“易用性”的bug类型，测试人员也可以提易用性的bug。

4. 管理团队

在软件测试的这几年，我先后做单元测试，测试设计，自动化测试，后来获得了一个晋升的机会，就成为了test manager。多了一些管理的工作，团队的规划，培养，分工。

1）招人

招人，是团队搭建的一个重要工作。任何团队，不管是技术型还是业务型，找到合适的人是关键第一步。有凝聚的团队，管理集中在怎样做事； 而众口不一的团队，管理就要花费精力在管人上。这倒不是孰优孰劣，因为在不同时期，不同背景下，所要求的团队类型也会不一样。比如，战争时代会涌现一大批有个性有想法能做事的人才，有名的是湘军，桂军等，都以个性刚直勇猛为名；而到了和平时期，社会成功者大多是一些能够协调好关系，处理好矛盾的全面人才，尤以江浙一代的师爷文化为代表。所谓“飞鸟尽，良弓藏；狡兔死，走狗烹”，其实也有一定的客观的社会事实基础。

2）业绩考核

在流行的管理学里，一般会用态度和能力两个维度来描述一个职员的职场表现，于是排列组合下来，就有了态度好能力强，态度好能力弱，态度差能力强，态度差能力弱四种类型。毋庸置疑，态度和能力俱佳的人，应该是骨干人才，要留住并提拔的；态度差能力差的人，是要被职场淘汰的。态度差能力强和态度好能力差这两种类型是要谨慎对待的。在现实里，情况可能还要更复杂多，对于软件测试人员来说，至少还要有一个重要的能力，就是交流，如果细分的话，还可以有文档交流，邮件交流和对话交流。在外企的话，涉及不同的文化差异，交流能力更加重要，直接影响晋升，甚至职业前程。在比较小的项目里，开发和测试团队如果能安排坐在同一个办公室里，会能提高工作效率，因为交流成本很小。但如果一些大的项目，工作合作要跨部门甚至跨国，需要沟通和协作，如何通过交流清楚地表达自己和理解对方，这就是一个重要的本领了。有的人喜欢写长邮件，有的人则喜欢写短邮件，这可能会起到完全不同的的效果。另外，对于测试人员容易犯的交流错误是表达问题不准确，而又盲目对问题做结论性的描述，比如“这个bug非常严重”，“开发人员谁谁开发的质量不好”等等。这些都不是很好的交流方式，应该尽量做到客观，理性，明确bug的重现场景，搜集bug的准确信息，这样表现了专业能力，又能跟开发人员是“我们在一条船上”的态度。再次强调，理解开发工作是做好测试的一个必要条件。

3）定目标

在这几年里，经常有人问我，创建一个新的测试团队，或者开始一个新的测试项目，应该从哪里开始入手，测试里有很多工作，包括测试计划，测试自动化，测试流程等等，总不能在刚开始时就眉毛胡子一把抓啊。要搞清楚这个问题，就要先想想我们测试工作的关键价值在哪里，毫无疑问，测试的最根本工作还是发现并提交bug。一个多么简单的道理！没有人会说软件质量是“测”出来的，也没有哪个测试团队不花大力气去找bug，换句话说，如果长时间不提bug，测试团队就会心里发慌；如果软件里没有bug，软件测试也就失去了存在的意义。

IT行业发展成熟，会使软件市场充分竞争，提高软件质量要求，软件测试得到重视，这是软件行业的一般规律。而中国有自己的国情特色，GDP大半部分是靠政府花纳税人的钱投资拉动，花别人的钱都不会太理性的，不会追求效益最大化，也不尊重行业的一般规律，于是我们看到一些匪夷所思的事情，明知测试不充分存在安全隐患，但为了sb大献礼，高铁也要准时上线；army的软件系统提出最严格的需求，但软件项目竣工时专家都不到场就合格验收。在这种形势下，连软件开发本身可能都不是整个项目的关键，何谈重视软件测试呢？ 这种“中国特色”能够解释很多现象

1. 国外的软件技术人员职业寿命可以到60岁退休，而中国，做到35岁就纷纷考虑转管理

2. 软件行业里很多都是“娃娃兵”

3. 来自客户需求每天都在变，今天某个客户领导A有了新想法，明天领导B又有了新想法。

等等。不一胜数。

我们每个工作在第一线的技术人员都是一颗渺小的种子，能不能顺利发芽长大，大多靠自己的基因，能长成一株小草，还是一棵参天大树，更多取决于这个森林规则。前不久，马云，柳传志企业家不约而同地在公开场合主张“莫谈国事”，这真让人怀疑他们面对公众的立场和诚意。只求自己闷声发大财，哪管别人苦与难。

企业家代表不代表企业，人大代表不代表人民。每个人可以只关心自己一亩三分田的今天长势，但没有权利批评别人收听天气预报，未雨绸缪，就像那个HH代表文艺界表态不闹事一样，在一间漏雨的屋子里，怂蛋看到的是漏雨，勇士却看到的是屋外横挂天空的彩虹。

在我这篇自白中，夹杂了“私货”，正如像我在跟一个空气中的自己做真诚的对话，无关技术，只有人生。

5. 从开发的角度看测试

后来的事情呢，我的团队在自动化测试方向做得还好，有过一个比较关键的突破，受到高层管理团队的肯定，用大boss的话来说“这个方案解决了公司自xx领域产生20年以来的空白”。实际上，为此我们也付出了相当的努力，持续几年的投入，将近10万行代码的开发量，终于在最后一刻灿烂了，那种感觉真的很棒。

再后来呢，一个机会，我的测试团队直接转为开发团队，负责云平台上的服务开发，经过测试转型和新聘开发人员，磨合碰撞中，终于上了正轨，花了一年多的时间，团队内建立了敏捷开发的流程，开发规范，还有一套自动化测试验证框架，使bug尽量在最早的开发阶段被发现。因为做过测试，所以我对测试更加重视。

下面从开发的角度来看看bug是怎样产生的

1）性能bug

软件性能在本质上是一个空间和时间转换的问题。

1. cache的使用

应该考虑为重复使用的数据设计cache机制。cache中常规的有配置数据，用户信息，resourcebundle等等，这些读概率非常高的数据一般都在app启动时就加载到内存的cache里。我还遇到一个有趣的现象，发现java的反射机制是十分消耗时间的，在10ms级别。因此，在第一次反射后就将annotation放在cache中会大大提高效率。实际上， cache里什么都可以放，对象，甚至interface和class的定义也可以放进cache。cache在提高效率的同时，也会带来新的问题，比较头疼的就是cache同步。在多节点的环境里，测试人员可以设计多节点同步，restart app server，shutdown db等测试案例，发现可能的cache的问题。

2. log的级别

之所以把它放在第二位，是因为它不起眼，但是却能制造大麻烦。在一般情况下，log可以设置error级别，但开发人员在开发过程中，容易把一些不重要的信息都塞进log里以便调试，如果不注意调整，log就成为潜伏最深的性能问题，我遇到过访问一个页面，后台写了45次error log, 每次log都要占用20多ms, 对性能影响非常大。

3. DB server的问题

对于Oracle ＤＢ, 最好用的性能监控报告是awr了。awr最初级的指标就是top sql。可以发现哪些sql耗费时间，能够发现不合理的table设计，索引问题。对ｄｂ性能有杀伤力的是trigger，trigger可以方便解决一些场景，但性能上比较耗时间，慎用，有的公司ＤＢ设计规范就不建议用trigger。我看过一个大型的电信系统数据库竟然使用了几百个trigger，真是开了眼界。

4. java 线程同步

在java里，经常使用synchronized关键字定义同步的代码块。但对于synchronized的高昂代价java开发者一直非常谨慎。在stackoverflow里有讨论。

http://stackoverflow.com/questions/1671 ... ve-in-java

多个线程并发情况下，synchronized只会允许一个线程进入代码块。

5. java对象复用

在javadoc里，有一些object是建议复用的。比如simpleJdbcCall，httpclient等， 因为它们在初始化的时候，要使用非常多的资源，为了提高效率，需要复用。采用单点实例是一个不错的办法。性能测试中，通过监控java的heap，可以观察到对象的数量和创建频率。

2）全球化的bug

globalization涉及到的知识较多。比较常见的是数据garble,truncate，翻译错误等。

1. 翻译的fall back

通常jdk的resourcebundle会提供locale的fall back, 但有一些特殊的fall back场景需要开发人员加上处理逻辑。比如有一个常规场景，zh_HK要fallback到zh_TW， 而pt不做fallback. 这需要开发人员做特别的处理

2. 字符串的truncate

truncate大多是对字符串的长度计算有误造成的。String.lenth()是计算字符个数，但是数据库的字段有些是以byte为单位的，这就导致字符在存储的时候导致数据库溢出。

3. 字符garble

字符的garble是因为在encode和decode过程中，字符集错误或丢失。

3）设计上的bug

1. 技术选型

在java的世界里，一种功能可以找到多个技术实现的方案。比如发送rest请求，可以选择的library就有jersey, jackson, fastjon, xstream等等。但每种技术方案都有各自的特长和适用领域。jersey使用起来功能强大，适合用在server端，client端的解析pojo的性能相比其他library要差一些， fastjson轻巧灵活，速度快，一般场景都能用。这些都是技术选型的时候需要考虑的因素

2. 单节点与机群设计

单节点时代已经过去，复杂庞大的应用一般会采用集群拓扑，会带来性能的提升和良好的扩展性。但是多节点的集群需要考虑的就是各个节点之间的同步。有缓存的同步，DB的同步，session的转移等等，这在选定集群模式时就要纳入到设计中。

3. 可配置性

遇见过最头疼的软件系统是code里一堆hard code，甚至time out，interval,retry times都是直接写死，这样的系统无法根据实际负载情况进行调优，在某一个场景下interval=10ms可能是合理的，而在另外一个场景下就会造成巨大的性能损耗，必须能够进行调整。

4）高可靠性的bug

高可靠性的一个考虑就是错误恢复。在发生错误的时候，有retry机制。而且针对不同的错误，有不同的retry策略。

1. 没有retry次数

2. 没有retry间隔

3. retry次数和间隔不可配置

4. 一些永久性的错误不适合retry策略

5. 职场注意事项

再来谈谈职场关系

1）开发与测试的关系

做测试时经常抱怨开发问题多，做开发又瞧不起测试整天瞎忙还经常打小报告。这种看法使得开发和测试处在对立的角色里。甚至有的企业职场文化还传授一些职场诀窍，邮件抄送对方领导，揪住bug不放等等。刻意地强调开发和测试的不同身份，会割裂两者的内在联系。就像当今的社会矛盾越来越大，一谈到城管就色变，一提及领导就是伟光正，一说起百姓就是草根，这种人格身份化是文化断裂，道德崩溃的原因之一。

显而易见，开发和测试先有共同的质量目标，才能坐在一起共事，而担负任务不同，但这个不同是建立在同的基础上的。作为开发，我希望测试能够通过他不同的角度发现软件中一些问题，来弥补开发中的不足；作为测试，我希望能考虑周全可能多的用户使用场景，来纠正开发过程中的偏差和错误。在斗争中获得团结，是双赢的结果。孔子讲的“君子和而不同，小人同而不和”讲的才是和谐社会。

我做测试的时候，和一个开发人员交流得非常好，他总会告诉我一些很有用的信息，比如我提交的bug是因为代码哪块出了问题，他是怎样fix的，可能会对我哪些test case有影响，这让我对代码有种inside box的认识，而不是out of box，同时测试因为目标明确质量也有了提高。后来，在我们研发部门，开发人员在做bug fix的同时，还要解释root cause，fix方案成为了规范流程，开发和测试合作十分愉快。

我做开发的时候，也很注意测试的关系。有一个测试人员会时常给我发邮件提醒我哪些bug还在open的状态，我对他十分欣赏，后来他的promote得到了我的recommendation。

2）上下级的关系

上下级的关系是公司文化的重要部分。应该来说，人员分工的不同，素质的差别，规模的大小，处理方式都会不一样。即使同一个团队，在刚开始组建的时候，团队领导需要细致而明确的指导新人工作，等到团队逐渐磨合成熟后，员工具备了独立工作的能力，领导就不要管得太死，从指导变为支持下属员工。

规模较大的组织，都有一个明确高效的管理制度，个人要想在组织中获得成功，就应该注意一些职场原则， 比如越级汇报，商业道德等。一般来说，上级应该对下级爱护，培养，不要涸泽而渔，而下级以“帮助领导成功就是我的成功”态度来尽心尽力做好自己的每一份工作。在一些巨型组织里，几万人一起合作工作，要做到出项目，不出乱子，必须要有合理明确甚至森严的制度保障。据说华为就有个说法“要么忍，要么滚”，上下级贯彻效率可见一斑。有些新人对公司的制度不太理解，觉得领导太强势，不合理，但很有可能的原因是这样的公司已经不需要个人的个性，而是靠团队的力量来推动工作。所以，个性很强的人要思考一下什么地方才能适合自己的发挥。

另外，职场上比较忌讳的是上下级发生冲突，这无疑是一种双输而对团队无益的内耗，大多数的结局是以员工离职收场。强势的老板不会容忍下属挑战，而跟温和的老板对抗也不会为自己加分。

我做了manager后，最大的收益就是知道了怎样做一个好下属。

3）“80后”，“90后”问题

社会上一直有个说法叫做“80后”，现在又有了“90后”，意指年轻人这一代有很强的时代特征。客观来讲，环境确实会影响人，建政60多年，国家和社会一直在发生变化，每个时代的人都有独特的时代烙印和行为特点，这种差别不光体现在80后，就算50后和60后，60后和70后之间也都会有不同。

“80后”，“90后”成为社会热点，是因为随着时代的发展，主流价值的缺失，年轻人越来越有个性，这种个性从学校带进工作之后，对传统职场文化是一个冲击，给合作交流带来困难，这恐怕是“80”，“90”被诟病的一个重要原因。

回想起来，在从毕业到现在的职业生涯里经历过几个转折，有运气的成分，在性格里有一些因素也帮助了我。

1. 好奇心，想要知道更多，然后就立刻行动去验证自己的想法。第一份开发工作出于此，自动化测试也是，总在想为什么不能更好一些，动手就做。

2. 我天生是一个不聪明的人，理所当然的常识，我总要花时间去想为什么是这样。

3. 耐心，我一直相信最慢的路就是最快的。

谢谢看我文字的各位朋友。