【十年】茫茫软件路

sunshinelius · 发表于 2014-5-5 17:16:50

前不久在北京的大学同学聚会，毕业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。