那年头，JAVA没有什么Struts-Spring-Hibernate，有我也不会；Oracle会简单写点存储过程、函数啥的；Linux会点基本操作命令；Weblogic会点简单配置。当我连C/S和B/S有啥区别都不清楚的时候，我就正式开始参与项目编码了。
项目周期短，工作量大。我估计了下，从开始到结束，大概有接近三个月的时间没有一天休息，每天是8：30到9：30，忘说了，公司“法定”每周上六天班。有一次实在熬不住，下班就回宿舍了。第二天一上班，迎接我的就是狂风暴雨。这里奉劝下诸位应届生，除非你真的天质过人、才华横溢，或有相当的背景，否则就夹着尾巴乖乖做人。老鸟都没走你凭啥走，没事做？没事也要在这傻坐着！
还有件事也是我一直刻骨铭心的。
走廊上碰见领导，领导问：“进度怎么样？”
我：“还可以。”
领导一边往厕所走一边问：“什么叫还？有什么问题？”
我跟着领导往厕所走：“没有没有。”
领导站那嘘嘘：“年轻人要谦虚，多象老员工学习。”
我在旁边连连点头：“一定一定。”
领导抖了两抖，收拾好后拍了拍我的肩：“好好干。”
我脸上堆满笑容：“明白明白。”
这就是社会。
看着现在很多应届生对身处的环境不满，你们他妈的有什么不满的。
项目结束后，很顺利的，我涨工资了。
小记：做人要靠自己。
一直想通过故事把工作几年对软件行业，特别是软件测试的种种个人想法汇总表达出来。
个人博客上一直断断续续在写，但不连贯，只是些零散的思考。
这次是准备花功夫写下。
前面主要是铺垫，后面就准备融入软件测试来叙述了。
在项目期间有几件事要讲。
第一个是我头发剪了。项目期间，全国四十几个省市的政府单位来参观，活动做的很大。插一句，在这家公司说一百样不好，但有一样是公认的，那就是实实在在开阔了眼界，包括后来温JB都来视察过。为避免影响市容，开大会的时候老总专门点名说那个谁发型要换下，但我没听。后来在机房调试的时候，另一个老总加两位总监跑过来说这发型真不合适，没办法，只有剪了，本来还想留长点扎辫子的。
理发店就在宿舍隔壁，看着不起眼，剃完收了我60，MB。隔天到公司又引起轰动，鲁迅变成瘌痢头啦。
第二个是喝酒。我们一帮武汉过来的，包括后来又陆陆续续来的几个，长发美女也来了，一起在宿舍楼下大排档喝酒。结果其他人还好，长发美女和B喝多了。不知道受了啥刺激，两人在楼下抱头痛哭，我和S怎么拦都拦不住。左邻右舍看着都以为是咱俩干了什么天怒人怨的事，最后还是S麻利，直接往肩膀上一扛，一人一个扛了上去。后来我和老婆说起这件事，她打死不承认，鄙视！
第三个，我不想做开发了。现在回想起来，根源上应该是对编码没兴趣。但做测试也要编码啊，特别是我离开开发也没有直接做测试，而是做了段时间DBA、 SA、SCM、售前，最后才转到测试的。为什么不想做开发？这问题我也问了自己好久。最后才明白，不是不想做开发，而是单单对编码没兴趣，并且没兴趣的原因是我不擅长，或者说我认为自己的天赋不在这上面。经过这几年，也慢慢验证了这一点，我更擅长的领域是需求分析、系统设计、项目管理，喜欢做前瞻性、预演性的工作，看来当年的决定没错。
许多人都曾经问我，为什么总能保持这种旺盛的精力，这种对工作的激情。无他，知之者不如好知者，好之者不如乐之者，如此而已。
就这样，我一面忍气吞声的做项目，一面勾搭长发美女，一面准备转岗。
小记：成功＝99％的努力＋1％的天份，也就是说没有那1％的天份永远成功不了，秀才永远比不上天才。每个人或多或少都有属于自己的天份，一定要正确找到自己的天份，很多时候往往和兴趣是一致的。
再记：郭靖有天份吗？有——“毅力”。这种天份无与伦比！
记忆中，大概是2002年底离开开发职位的。在没转测试前中间做过几个不同的职位，但时间都不长。其中映象最深的是Oracle DBA，当时公司用的是Oracle 9i。要说我对数据库了解有多深那是吹牛，但我对数据库确实很敏感。
刚来的时候F买了本Oracle 9i管理员手册，厚厚的一本，叫嚣要一周内看完。我劝他，这又不是看小说，重点在于理解运用，他不听。后来在某个项目设计数据库的时候，会上他侃侃而谈，实际操作却一筹莫展，最后还是我做的，坐实了纸上谈兵这四个字。这也是后来我转DBA很顺利的原因之一。过了几年后，我再次兼任DBA，发觉当初的一点基础还在。一方面是工作几年一直都在和Oracle打交道；另一方面是除了测试外我对数据库的兴趣最浓。
废话少说，总之期间兜兜转转一大圈，最后终于转到软件测试上了。也是我持之以恒，到今天也不离不弃的行业。具体转入的时间真记不清了，只记得在后来差不多一年的时间里，我连升三级，当然工资也涨了三次。在我2003年底离开公司的时候，周围同事说：“cx走了，公司没人懂测试了。”这句话是对我第一份工作最大的肯定。
在这不到一年的测试工作中，从对软件测试一无所知，到测试部门主管，其中发生的事情太多太多，各位看官且听我慢慢道来。
对了，还有件小事。2002年11月9日21点37分，我和长发美女确定关系了，开始了漫长的六年的马拉松式爱情长跑。
小记：闻道有先后，术业有专攻，如是而已。
刚接触软件测试的人员一般都是由功能测试开始，很多人也认为是黑盒测试，也有称之为数据驱动测试的。一般说的黑盒测试方法包括：等价类划分、边界值分析、因果图、判定分析表、正交实验设计等。其实这些方法在白盒测试中运用的也不少。
等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭示程序中的错误都是等效的。等价类划分的办法是把程序的输入域划分成若干具有相同特性的部分，然后从每个部分中选取少数代表性数据当作测试用例。
所谓边界条件，是相对于输入情形，输出等价类直接在其边缘上，稍高于其边界和低于其边界的这些状态条件。边值分析是对等价类划分的有效补充。
因果图着重分析输入条件的各种组合，每种组合条件就是“因”，它必然有一个输出的结果，这就是“果”。而在一些数据处理问题中，某些操作是否实施依赖多个逻辑条件的取值，即在这些逻辑条件取值的组合所构成的多种情况下，分别执行不同的操作。处理这类问题的一个非常有力的分析和表达工具是判定表。通常，因果图和判定分析表是结合起来使用的。
正交实验设计是从大量的实验点中挑选出适量的、有代表性的点，应用依据伽罗瓦理论导出的“正交表”，合理地安排实验的一种科学的实验设计方法。它其实是组合测试里的一个分支，组合测试是什么后面再讲。
除此之外，还有组合测试、基于模型测试、错误推测、测试场景分析、随机测试、猴子测试等很多测试方法。其中场景分析是近几年我常用的测试设计方法。组合测试、基于模型测试这两种是各大高校、科研机构的重点研究对象，每年发布的论文有不少。题外话，我对这两种方法不感冒。
很多测试新人一接触测试就拼命看这些资料，其实最开始要了解测试思想。
首先，如果从标准论来看软件测试，可以定义为软件测试就是"验证（Verification）"和"有效性确认（Validation）"活动构成的整体，即软件测试 = V&V。"验证"是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求（如正确性、完整性、一致性、准确性等）相一致。相当于，以Spec为标准进行软件测试活动，验证软件产品和Spec的一致性。"有效性确认"是确认所开发的软件是否满足用户真正需求的活动。相当于，保持对软件需求定义、设计的怀疑，一切从客户出发，理解客户的需求，发现需求定义和产品设计中的问题。这主要通过各种软件评审活动来实现。
其次，业内有两种截然相反的指导思想。一种认为要验证软件是"工作的"，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。其代表人物是软件测试领域的先驱Dr. Bill Hetzel （代表论著《The Complete Guide to Software Testing》)。另一种认为要证明软件是"不工作的"，以反向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统的弱点，试图破坏系统、摧毁系 统，目标就是发现系统中各种各样的问题。其代表人物是G.J.Myers（经典著作《The Art of Software Testing》)。他给出了与测试相关的三个重要观点：测试是为了证明程序有错，而不是证明程序无错误；一个好的测试用例是在于它能发现至今未发现的错误；一个成功的测试是发现了至今未发现的错误的测试。这两种都有很多的拥护者。在我所见过的测试活动中，采用第一种指导思想进行测试工作的多，特别是设计测试用例的时候。
当思想与基本方法了解的差不多了，是不是就可以开始做测试设计了？当然不行，还要熟悉业务。2004年在北京的时候和当时雅虎中国的技术总监交流，我说我一直想寻找一种方法可以跨行业开展工作，说白了不熟悉业务也能进行测试，回答是做梦。到现在2009年，我还是想寻找这么一种方法。这也是我认为测试理论、方法高于测试技术、手段的原因。
准备工作做好，可以尝试做下测试设计了。我的做法是，拿到PRD，按照因果图、判定分析表的规则进行业务、功能分析，然后针对每个功能进行等价类划分、边界值分析。恕我数学没学好，正交试验设计每次用到一半就进行不下去了。
当然，现在测试设计时采用的方法已经不同。更多的是使用路径法划分功能点，场景法设计业务流程。
业内还有个争论，是否需要编写详尽的测试用例？我当时没这些过多的想法，只知道熟能生巧。所以在自己学习及后来参与的前几个项目中，画了大量的图（几百幅是有的），写了大量的测试用例（几万个是有的）。量变到质变这句话是有道理的。再后来一拿到PRD，脑海里就会自动拆分功能点，自动梳理业务流程。历史总是惊人的重复发生，项目也一样。当你做了上百个项目后，你会发现开展的测试活动大同小异。也许，此时只有大型（比如项目团队人员规模在千人左右）、超大型、非常有特点的项目才能吸引你。
紧跟着做的几个项目没什么好说的，无非就是从测试需求分析开始，然后经过测试团队组建、测试环境构建、测试计划、测试设计、测试实施、测试结果收集与分析、测试总结等阶段，最后项目结项。
测试流程、测试模型啥的后面再说。这里要先叙述下和Intel合作的一个测试项目，就是这个项目，给我打开了一扇崭新的测试大门。
小记：我亦无他，唯手熟尔。
传说中的Intel，一说起它不知道别人首先想到的是什么，我脑海里最先出现的是“嘣～嘣嘣嘣嘣”。
和Intel合作的是一个系统集成测试项目，这样说可能很多人不明白，啥叫系统集成？去google。公司是家系统集成商，当时有个大项目要评估下硬件平台、软件平台的支撑能力。硬件平台选择的是Intel的安腾系列，软件平台选择的是Redhat AS 3、Oracle 9.2.0.2、Weblogic 6、Openldap，仿佛是这几个版本。简单讲，就是在安腾服务器上运行这些软件，检测运行状况、性能，其中Oracle主要验证的是集群性能。现在明白为什么要和Intel合作了吧。当时64位服务器刚出来，安腾老贵的，据说一台上百万。公司一口气弄了三十多台扔在机房里做实验，结果被我们当成了板凳。细节不多说，大体上讲有点类似于标准测试(benchmark)，但远没有那么复杂。
Intel上海实验室的测试工程师只有6个人，据说就是这6个人负责中国大陆的所有测试工作。啧啧，真是敬仰之情犹如……后来才知道并不是这样，中国大陆是只有6名，但美国总部有庞大的测试团队提供支持。
参与这个项目的我方一共四人，Intel四人，基本上一对一。这里要特别提到一个人，当时的测试主管C。
C也是湖北的，和我一般高，浓眉大眼，家在农村，非常勤奋、质朴，来公司两年了，此项目由他负责。之前他认识了个女孩，当老师的。他是落花有意，女孩却流水无情，每天愁眉苦脸的想着该咋办，后来不知咋地烧香烧到我这来了。
我给他出主意：“女人嘛，推倒了就是你的。”
C挠挠脑袋：“咋推倒？”
我一脸藐视：“灌醉撒还用问！”
C恍然大悟：“是哦……咋灌醉？”
文章来源于领测软件测试网 https://www.ltesting.net/
