软件测试修炼之道

chenxuan

前言

软件测试发展到今天，已经逐渐形成一门学科，但是还不够系统。

初学者面对铺天盖地的资料应该如何选取？应该从哪里入手？如何迅速的掌握各种业务各项测试技能以便开展工作？在保证测试质量的前提下，一日内编写或执行1000个测试用例是不是梦想？

入行多年者面对复杂的业务逻辑，海量的测试需求，如何在最短的时间内进行测试？如何尽可能更早的开展测试？如何对系统架构进行测试？如何全面提高测试质量与测试效率？如何百尺竿头更进一步？

本文将针对这些问题进行初步解答，主要阐述解决这些问题应该具备哪些能力及如何锻炼这些能力，至于实际工作中解决问题的具体操作步骤本文不做表述，可关注后续文章。前两章主要探讨一名合格的测试工程师应该具备哪些能力，对列举的能力将会做简要说明。第三章重点说明应该如何锻炼这些能力，此为本文的重点。最后一章是笔者对软件测试虚无缥缈杂乱无章的一些想法。

本文的读者群涵盖所有对软件测试感兴趣的朋友。

下面，我们开始。
第一章 综合素质

笔者以为，作为一名合格的测试工程师，综合素质是最重要的，综合素质也就是我们常说的软技能，它代表着一个人的潜力有多大，未来发展有多宽广。核心素质有以下五点：沟通、分析、组织、学习、心态，下面将会分别阐述。
沟通

作为一名软件测试工程师，优先加强的应该是哪方面的沟通能力？是文字沟通能力。试想，如果连缺陷描述都无法准确清晰的用文字表达出来，还有开发愿意和你合作吗？特别是随着异地开发的项目越来越多，文字沟通的场景也会越来越多。

当然，口头沟通也很重要，通过面对面或者电话语音交流是很直接的方式，这也是为什么许多鼓吹敏捷开发的团队喜欢坐在一起的原因，认为这样会降低沟通成本。但事实上，真的在任何时刻都能降低成本吗？无效冗长的会议大家都参与过，这里不做深入讨论。

不知道其他人有没有这种体验，笔者偶尔在查阅测试用例库或阅读工作邮件的时候会忍不住哈哈大笑，语句不通错别字也就罢了，写的像聊天记录一样尽是口头语就让人很无奈了。

所以，这里首先强调的是提高文字表达能力，其次才是口头沟通能力。

另外要特别注意的是，沟通能力包含两方面，一方面是说（写），一方面是听（读），表达与聆听同等重要。笔者发现很多测试工程师表达能力不错，但聆听能力很差，有时候甚至忽略聆听。对方话没讲完就急匆匆的打断，即使听了两句也马上反驳对方，这是恶习，比抽烟喝酒打老婆还要恶虐。
分析

早期我们认为测试的唯一工作就是发现问题，在很多文献资料上均有类似描述。但笔者以为，测试发展到今天，单纯的发现问题已不再是测试工作的全部，测试工作应包含发现问题、分析问题、解决问题三个方面。发现问题以测试人员为主开发人员为辅，分析问题开发测试共同完成，解决问题以开发人员为主测试人员为辅。

在测试工作中每时每刻都需要用到分析能力，同时，分析能力是评估一名测试工程师是否优秀最重要的考核点。就像我们常说的缺陷预防一样，怎么预防？对已发生问题的产生原因能准确定位并把类似问题进行归类，对未发生问题能充分预知风险并准备应对方案，这就是我们追求的零缺陷，这些工作有不需要高度分析能力的吗？

再例如测试计划，我们做计划是拍脑袋乱猜吗？是掐指算命吗？肯定很多人回答不是，但实际上往往很多人就是这么做的。测试计划的制定过程是首先收集大量相关信息，然后抽丝剥茧在杂乱无章的信息中寻找到关键点并梳理清脉络，最终据此定出计划。我们说部分未来是可以推测出来的，就是这个道理。在做计划时会用到许许多多辅助分析的理论方法，这里就不一一阐述了。

艾森豪威尔有句名言：“A plan is nothing，planning is everything．” Planning就是分析的过程。
组织

刘备自己不会带兵打仗，为什么他下面的五虎将会死心塌地的服从他？因为五虎将会将兵，刘备会将将。“运筹帷幄之中，决胜千里之外”，这是帅才；“三军中取敌上将之首级如探囊取物”，这是将才。帅才也好将才也好，都离不开组织能力。这里说的是广义上的组织能力，不仅仅指团队管理、跨部门协调这些内容。

不少人认为开发与测试的工作是对立的，经常会有冲突，没错，的确会有。出现冲突怎么办？这时候需要通过高度的组织能力对双方的合作关系进行充分的调整。人与人之间本来就会不断的有磨擦，有人的地方就有恩怨，有恩怨就有江湖，人就是江湖。那为什么有的人能左右逢源，让人感觉与他合作如沐春风呢？这就是组织能力的表现。

再比方说，在真正的敏捷团队中，无论工作有多苦多累，无论团队成员构成有多复杂，整个团队都会有一个共同的表象，那就是“开心”，真正的敏捷团队一定是个开心的团队。所以笔者常说，敏捷团队的领导者一定要有非常强烈的人格魅力，能牢牢的把整个团队凝聚在一起，这种人格魅力往往就体现在组织能力上。

有人也许会问，举办大型活动算不算组织能力的体现？算，当然算。但现在很多人白白浪费了这样的机会，在筹备过程中仅仅起到工作分解或传声筒的作用，可惜。
学习

“一目十行过目不忘”，这种天才是有的，笔者非常羡慕有时甚至是嫉恨他们。普通人需要花费一两年才能掌握的知识，这些天资纵横的人只用一两天就可以了，并且很多技能仿佛天生就会，根本不用后天的学习。幸好这种人非常少，否则根据社会达尔文主义的观点，我们普通人没有任何生存空间。

软件测试从业人员有个明显特点——复合型。“知己知彼百战百胜”，当我们要对某项产品进行测试，那么必然要先了解此产品的各种背景，这导致测试人员需要学习各种各样的知识，并且要不断的学习，快速的学习。入行几年后或许我们会感到掌握的技能杂而不精，此时需要深入的学习，全面的学习。

学习能力往往被看作是一个人有无潜力的重要标志，针对软件测试工程师而言，“快速学习”尤为重要。笔者一直想寻找一种方法，能让测试人员不了解行业背景不懂测试技术也能正常开展测试工作，但可惜的是一直没找到。那么变通下，通过“快速学习”是否也能达到类似的效果呢？应该是可以的。

学习最核心的是什么？知之者不如好之者，好之者不如乐之者。
心态

多年前笔者读过一篇文章——《写给浮躁的IT同仁》，读后深有同感。一个浮躁的社会造就了众多浮躁的人，软件测试本该是个做学问的领域，可惜啊可惜。

人往往是自私的，荀子曰：“人之初，性本恶。”笔者深以为然。绝大多数人都认为自己是最可怜最委屈最被不公正对待的，扪心自问真是这样吗？佛教有个观点“明心见性”，这是笔者孜孜不倦所追求的精神境界，与大家共勉。

大家应该都明白，没有绝对的公平社会，从来就没有，纵观古今中外历朝历代什么时候绝对公平过？我们不要一味的怨天尤人，如果改变不了环境就努力的去适应它，这是升斗小民应该具备的心态。

先做人后做事，不论是综合素质还是专业技能，在所有能力中，心态是最重要的。但要特别说明下，心态和态度不是一码事。此外，有人认为工作态度高于工作能力，笔者并不赞同这种观点，更有甚者把工作态度与是否听话混为一谈这就更扯淡了。

国人讲究“君以国士待我,我必国士报之”，一颗平常心加上一颗感恩心，足够了。

chenxuan

第二章 专业技能

《笑傲江湖》里有写到华山派分为剑气二宗，金大师在书中是褒扬剑宗的，令狐冲全无内力单凭神鬼莫测的剑法就打遍天下无敌手。那么在测试领域里，方法与技术哪个更重要？此话题争论太多一时半会说不清楚，但笔者是赞同方法更重要的。有道是万法归宗，一力降十会，就是这个道理。下文所说的技能涵盖了方法与技术。另请注意，当专业能力上升到一定程度后，需要从广度转为深度，即要在某一特定领域内做深做强，切勿变成杂而不精。
测试方法

目前测试领域内大大小小的测试方法上百种，有的被广大测试工程师所接受并在实际工作中大量运用，有的仅停留在理论研究阶段，还有的只是某些机构为了发表学术论文东拼西凑胡乱编造的。那么这么多方法应该如何选择？《神雕侠侣》里有这么一段：

法王笑道：“人各有志，那也勉强不来。杨兄弟，你的武功花样甚多，不是我倚老卖老说一句，博采众家固然甚妙，但也不免驳而不纯。你最擅长的到底是那一门功 夫？要用甚麽武功去对付郭靖夫妇？”这几句话可将杨过问得张口结舌，难以回答。他一生遭际不凡，性子又是贪多务得，全真派的、欧阳锋的、古墓派的、九阴真 经、洪七公的、黄药师的，诸般武功著实学了不少。这些功夫每一门都是奥妙无穷，以毕生精力才智钻研探究，亦难以望甚涯岸，他东摘一鳞、西取半爪，却没一门 功夫练到真正第一流的境界。遇到次等对手之时，施展出来固然是五花八门，叫人眼花撩乱，但遭逢到真正高手，却总是相形见绌，便和金轮法王的弟子达尔巴、霍 都相较，也是颇有不及。他低头凝思，觉得金轮法王这几句话实是当头棒喝，说中了他武学的根本大弊。

杨过第一反应是什么呢？

他走出茅棚，在山顶上负手而行，苦苦思索，甚是烦恼，想了半天，突然间心念一动：“我何不取各派所长，自成一家？天下武功，均是由人所创，别人既然创得，我难道就创不得？”想到此处，眼前登时大现光明。

最终他的决定是什么？

杨过睡了半夜，次晨一早起来又想。七日之中，接连昏迷了五次。说要综纳诸门，自创一家，那是谈何容易？以他此时的识力修为固然绝难成功，那更不昃十天半月 间之事。但连想数日之後，恍然有悟，猛地明白诸般武术皆可为我所用，既不能合而为一，也就不必强求，日後临敌之际，当用则用，不必去想武功的出处来历，也 已与自创一派想差无几。想明白了此节，登时心中舒畅。

这就是笔者想要表达的。作为一名合格的测试工程师首先一定要见识广博，最新的行业动态，各种测试方法等等都需要了解。然后在此基础上，实际工作中需要用到什么方法就用什么方法，信手拈来，千万不要书到用时方恨少。笔者一直在劝喻团队中的工程师，不要整天只知道埋头干活像鸵鸟一样，要经常抬起头来放眼看世界，井底之蛙坐井观天是要不得的，这样下去路只会越走越窄。最后，当各方面积累到一定程度会发生量变到质变，如果还具备过人的天赋并能百尺竿头更进一步，则可开宗立派自成一家，就象杨过最后自创“黯然销魂掌”一样。

笔者在日常工作中最常用的是路径法、场景法，以组合测试、探索性测试作为辅助。路径法主要用来做测试需求分析，关注的是节点；场景法主要用来做测试设计，关注的是路径；组合测试主要用来对规则性的用例进行筛选，减少测试用例数量；探索性测试主要用于交叉测试或测试大扫除之类的测试活动。这些方法的详细论述网上有很多，这里就不一一阐述了。如何把这些方法贯穿在一起？之前的分享有详细表述过，这里也不啰嗦了。

现在业内有两种测试理念很流行，一种是基于模型测试（MBT），一种是云测试。笔者以为这两种测试方式一定是未来测试行业发展的大方向。随着测试智能化的发展，今后测试工程师入行的门槛会越来越低乃至于消失。到那时，只需要很少一部分测试精英维护测试智能化平台，其它大部分的测试工作可交由任何人来完成，真正实现“IT民工”的梦想。

很多人应该都读过“四人帮”的《设计模式》，大多数人虽然看不懂但都明白这是核心，是重中之重。测试方法也是如此，它是测试工作的灵魂，测试用例与测试脚本孰重孰轻？不言而喻。

最后说明一点，在笔者印象中测试人员是肯定要参与需求分析及系统设计过程的。记得很早前有位工作十来年的开发工程师对笔者说：“你真牛叉这些工作你都参与”。实际上他没明白，这本身就是测试人员的工作，测试人员本来就需要具备这些能力。所以笔者总说现在国内合格的测试工程师很少，大部分都是滥竽充数，同时也是笔者为什么在所带领团队中大力提倡组员多研究测试方法的原因。
基础技能

基础，或许说基本更合适一点。工欲善其事，必先利其器。前面已经谈到测试人员是复合型的，要对待测产品的行业背景、技术背景有深入了解。在测试智能化远没有发展成熟的今天，测试工程师必需掌握基础技能。

笔者遇到过不少刚入行的新人，他们问的最多问题是“测试人员是否需要懂编码”。笔者一般回答“欲穷千里目，更上一层楼”。其实不仅仅是测试人员，但凡和技术沾边的工种都需要懂编码。编码是最基础的技能，无论哪一门语言，至少要会一种，如果能再具备一定的产品开发经验那就更好了。但请注意，过犹不及，不要单纯拿编码能力的高低来衡量测试人员水平的高低，测试人员最核心的技能仍是在测试设计上，不要本末倒置。

同样，像数据库、操作系统、网络协议、建模等等都属于基础技能的范畴。可能测试人员在这些技能的掌握程度上没有专业人士强，没关系，因为这些技能最终是为测试专有技能所服务的，如此而已。当然，如果个人有兴趣深入研究那是最好。笔者记得刚接触Linux系统的时候拼命读源码，刚接触网络协议的时候厚厚几本《TCP/IP详解》放在床头，可惜的是都没坚持下来。

为什么说测试工程师转岗容易？现在该明白了吧。
测试模式

瀑布开发、快速开发、迭代开发、敏捷开发等等等等，这么多开发模式听着是不是犯晕？探讨哪种模式更好其实是扯淡，就象探讨是由“开明君主治理的封建制度国家”好，还是由“腐朽无能政府统治的民主制度国家”好一样，均属于哲学问题。同理，测试模式有V模型、X模型、H模型、前置模型，淘宝还提出了 SPR模型以及最近正在探索的CCI模型，哪种更好？合适的就是最好的。

尽信书不如无书，这道理很多人都说懂，实际上呢？大多数人依然是照本宣科，死搬硬套。在大多数情况下，工程师应该尽量追求神似而不是形似，特别是奋战在一线的工程师，要明白“将在外君命有所不受”的道理。在当前以结果为导向这种西式管理的氛围下，更多的是要拿出让各方面满意的成绩单。当然，也有部分人以此为借口逃避流程逃避制度，高举敏捷大旗却行偷懒之实。要知道能量守恒，在某方面偷懒在其它方面会付出更多，这样做其实是把自身工作转嫁到他人身上，比方说把自身应该完成的保证产品质量工作转嫁给他人，这样的人要招天谴。“适可而止”这四个字说起来简单，真要做到非常难，需要大量的实践经验，这也是为什么测试工程师职业生命周期较长的原因。

笔者认为，在当下绝大多数项目团队里，V模型足够使用，或者在部分地方进行改良即可适应项目团队工作的需要。要知道，经典是永远不会过时的。那么在行政体系上呢？一个测试部门应该采用怎样的组织结构？目前流行的是一分为二，一部分做技术支撑，另一部分做产品测试，还有极端的是测试人员只做测试技术支撑，产品测试交由开发人员自行完成。至于在产品测试里再细分单元测试、集成测试或功能测试、性能测试等角色，窃以为不需要，因为在广义上，都是功能。测试要做的就是V&V，检验已实现的功能是否正确，检验是否正确实现了功能。
测试工具

这里所说的工具是广义上的，可以说各种各样只要能辅助测试人员开展测试工作的工具都包含在内。

为什么Mercury（笔者还是习惯称为mercury而不是hp）的产品能得到广大测试工程师的认可？因为它满足了测试工程师工作的需要。工具干嘛用的？辅助测试工作用的。笔者一直觉得Mercury的架构师真是不得了，产品设计的如此漂亮。什么是测试架构师？这就是。

测试工具有很多，这里不一一列举了。每年国际上会评选年度最佳测试工具，有兴趣的朋友可以多了解下，这算是测试工具的风向标。

有人曾经争论什么才能称之为测试工具，例如针对某一特定产品开发的一段测试代码是否算是测试工具。笔者以为，从广义上讲是，但在通常所说的范围下不是，因为它不具备通用性，它只能为特定产品服务。所以笔者常常告诫测试人员，第一不要总吹嘘自己开发了多少测试工具，充其量那只能算是一段测试代码；第二要理解测试工具的本质，开发了一堆工具结果根本不能有效提高测试质量、测试效率，无法帮助测试人员发现更多的缺陷，有意义吗？

当然，有一点肯定没错，多试用不同种类的测试工具并研究其原理，如果能对其进行改进，那么恭喜，离专家又进了一步。

chenxuan

第二章 专业技能
《笑傲江湖》里有写到华山派分为剑气二宗，金大师在书中是褒扬剑宗的，令狐冲全无内力单凭神鬼莫测的剑法就打遍天下无敌手。那么在测试领域里，方法与技术哪个更重要？此话题争论太多一时半会说不清楚，但笔者是赞同方法更重要的。有道是万法归宗，一力降十会，就是这个道理。下文所说的技能涵盖了方法与技术。另请注意，当专业能力上升到一定程度后，需要从广度转为深度，即要在某一特定领域内做深做强，切勿变成杂而不精。测试方法
目前测试领域内大大小小的测试方法上百种，有的被广大测试工程师所接受并在实际工作中大量运用，有的仅停留在理论研究阶段，还有的只是某些机构为了发表学术论文东拼西凑胡乱编造的。那么这么多方法应该如何选择？《神雕侠侣》里有这么一段：
法王笑道：“人各有志，那也勉强不来。杨兄弟，你的武功花样甚多，不是我倚老卖老说一句，博采众家固然甚妙，但也不免驳而不纯。你最擅长的到底是那一门功夫？要用甚麽武功去对付郭靖夫妇？”这几句话可将杨过问得张口结舌，难以回答。他一生遭际不凡，性子又是贪多务得，全真派的、欧阳锋的、古墓派的、九阴真经、洪七公的、黄药师的，诸般武功著实学了不少。这些功夫每一门都是奥妙无穷，以毕生精力才智钻研探究，亦难以望甚涯岸，他东摘一鳞、西取半爪，却没一门功夫练到真正第一流的境界。遇到次等对手之时，施展出来固然是五花八门，叫人眼花撩乱，但遭逢到真正高手，却总是相形见绌，便和金轮法王的弟子达尔巴、霍都相较，也是颇有不及。他低头凝思，觉得金轮法王这几句话实是当头棒喝，说中了他武学的根本大弊。
杨过第一反应是什么呢？
他走出茅棚，在山顶上负手而行，苦苦思索，甚是烦恼，想了半天，突然间心念一动：“我何不取各派所长，自成一家？天下武功，均是由人所创，别人既然创得，我难道就创不得？”想到此处，眼前登时大现光明。
最终他的决定是什么？
杨过睡了半夜，次晨一早起来又想。七日之中，接连昏迷了五次。说要综纳诸门，自创一家，那是谈何容易？以他此时的识力修为固然绝难成功，那更不昃十天半月间之事。但连想数日之後，恍然有悟，猛地明白诸般武术皆可为我所用，既不能合而为一，也就不必强求，日後临敌之际，当用则用，不必去想武功的出处来历，也已与自创一派想差无几。想明白了此节，登时心中舒畅。
这就是笔者想要表达的。作为一名合格的测试工程师首先一定要见识广博，最新的行业动态，各种测试方法等等都需要了解。然后在此基础上，实际工作中需要用到什么方法就用什么方法，信手拈来，千万不要书到用时方恨少。笔者一直在劝喻团队中的工程师，不要整天只知道埋头干活像鸵鸟一样，要经常抬起头来放眼看世界，井底之蛙坐井观天是要不得的，这样下去路只会越走越窄。最后，当各方面积累到一定程度会发生量变到质变，如果还具备过人的天赋并能百尺竿头更进一步，则可开宗立派自成一家，就象杨过最后自创“黯然销魂掌”一样。
笔者在日常工作中最常用的是路径法、场景法，以组合测试、探索性测试作为辅助。路径法主要用来做测试需求分析，关注的是节点；场景法主要用来做测试设计，关注的是路径；组合测试主要用来对规则性的用例进行筛选，减少测试用例数量；探索性测试主要用于交叉测试或测试大扫除之类的测试活动。这些方法的详细论述网上有很多，这里就不一一阐述了。如何把这些方法贯穿在一起？之前的分享有详细表述过，这里也不啰嗦了。
现在业内有两种测试理念很流行，一种是基于模型测试（MBT），一种是云测试。笔者以为这两种测试方式一定是未来测试行业发展的大方向。随着测试智能化的发展，今后测试工程师入行的门槛会越来越低乃至于消失。到那时，只需要很少一部分测试精英维护测试智能化平台，其它大部分的测试工作可交由任何人来完成，真正实现“IT民工”的梦想。
很多人应该都读过“四人帮”的《设计模式》，大多数人虽然看不懂但都明白这是核心，是重中之重。测试方法也是如此，它是测试工作的灵魂，测试用例与测试脚本孰重孰轻？不言而喻。
最后说明一点，在笔者印象中测试人员是肯定要参与需求分析及系统设计过程的。记得很早前有位工作十来年的开发工程师对笔者说：“你真牛叉这些工作你都参与”。实际上他没明白，这本身就是测试人员的工作，测试人员本来就需要具备这些能力。所以笔者总说现在国内合格的测试工程师很少，大部分都是滥竽充数，同时也是笔者为什么在所带领团队中大力提倡组员多研究测试方法的原因。基础技能
基础，或许说基本更合适一点。工欲善其事，必先利其器。前面已经谈到测试人员是复合型的，要对待测产品的行业背景、技术背景有深入了解。在测试智能化远没有发展成熟的今天，测试工程师必需掌握基础技能。
笔者遇到过不少刚入行的新人，他们问的最多问题是“测试人员是否需要懂编码”。笔者一般回答“欲穷千里目，更上一层楼”。其实不仅仅是测试人员，但凡和技术沾边的工种都需要懂编码。编码是最基础的技能，无论哪一门语言，至少要会一种，如果能再具备一定的产品开发经验那就更好了。但请注意，过犹不及，不要单纯拿编码能力的高低来衡量测试人员水平的高低，测试人员最核心的技能仍是在测试设计上，不要本末倒置。
同样，像数据库、操作系统、网络协议、建模等等都属于基础技能的范畴。可能测试人员在这些技能的掌握程度上没有专业人士强，没关系，因为这些技能最终是为测试专有技能所服务的，如此而已。当然，如果个人有兴趣深入研究那是最好。笔者记得刚接触Linux系统的时候拼命读源码，刚接触网络协议的时候厚厚几本《TCP/IP详解》放在床头，可惜的是都没坚持下来。
为什么说测试工程师转岗容易？现在该明白了吧。测试模式
瀑布开发、快速开发、迭代开发、敏捷开发等等等等，这么多开发模式听着是不是犯晕？探讨哪种模式更好其实是扯淡，就象探讨是由“开明君主治理的封建制度国家”好，还是由“腐朽无能政府统治的民主制度国家”好一样，均属于哲学问题。同理，测试模式有V模型、X模型、H模型、前置模型，淘宝还提出了 SPR模型以及最近正在探索的CCI模型，哪种更好？合适的就是最好的。
尽信书不如无书，这道理很多人都说懂，实际上呢？大多数人依然是照本宣科，死搬硬套。在大多数情况下，工程师应该尽量追求神似而不是形似，特别是奋战在一线的工程师，要明白“将在外君命有所不受”的道理。在当前以结果为导向这种西式管理的氛围下，更多的是要拿出让各方面满意的成绩单。当然，也有部分人以此为借口逃避流程逃避制度，高举敏捷大旗却行偷懒之实。要知道能量守恒，在某方面偷懒在其它方面会付出更多，这样做其实是把自身工作转嫁到他人身上，比方说把自身应该完成的保证产品质量工作转嫁给他人，这样的人要招天谴。“适可而止”这四个字说起来简单，真要做到非常难，需要大量的实践经验，这也是为什么测试工程师职业生命周期较长的原因。
笔者认为，在当下绝大多数项目团队里，V模型足够使用，或者在部分地方进行改良即可适应项目团队工作的需要。要知道，经典是永远不会过时的。那么在行政体系上呢？一个测试部门应该采用怎样的组织结构？目前流行的是一分为二，一部分做技术支撑，另一部分做产品测试，还有极端的是测试人员只做测试技术支撑，产品测试交由开发人员自行完成。至于在产品测试里再细分单元测试、集成测试或功能测试、性能测试等角色，窃以为不需要，因为在广义上，都是功能。测试要做的就是V&V，检验已实现的功能是否正确，检验是否正确实现了功能。测试工具
这里所说的工具是广义上的，可以说各种各样只要能辅助测试人员开展测试工作的工具都包含在内。
为什么Mercury（笔者还是习惯称为mercury而不是hp）的产品能得到广大测试工程师的认可？因为它满足了测试工程师工作的需要。工具干嘛用的？辅助测试工作用的。笔者一直觉得Mercury的架构师真是不得了，产品设计的如此漂亮。什么是测试架构师？这就是。
测试工具有很多，这里不一一列举了。每年国际上会评选年度最佳测试工具，有兴趣的朋友可以多了解下，这算是测试工具的风向标。
有人曾经争论什么才能称之为测试工具，例如针对某一特定产品开发的一段测试代码是否算是测试工具。笔者以为，从广义上讲是，但在通常所说的范围下不是，因为它不具备通用性，它只能为特定产品服务。所以笔者常常告诫测试人员，第一不要总吹嘘自己开发了多少测试工具，充其量那只能算是一段测试代码；第二要理解测试工具的本质，开发了一堆工具结果根本不能有效提高测试质量、测试效率，无法帮助测试人员发现更多的缺陷，有意义吗？
当然，有一点肯定没错，多试用不同种类的测试工具并研究其原理，如果能对其进行改进，那么恭喜，离专家又进了一步。

chenxuan

第二章 专业技能

《笑傲江湖》里有写到华山派分为剑气二宗，金大师在书中是褒扬剑宗的，令狐冲全无内力单凭神鬼莫测的剑法就打遍天下无敌手。那么在测试领域里，方法与技术哪个更重要？此话题争论太多一时半会说不清楚，但笔者是赞同方法更重要的。有道是万法归宗，一力降十会，就是这个道理。下文所说的技能涵盖了方法与技术。另请注意，当专业能力上升到一定程度后，需要从广度转为深度，即要在某一特定领域内做深做强，切勿变成杂而不精。
测试方法

目前测试领域内大大小小的测试方法上百种，有的被广大测试工程师所接受并在实际工作中大量运用，有的仅停留在理论研究阶段，还有的只是某些机构为了发表学术论文东拼西凑胡乱编造的。那么这么多方法应该如何选择？《神雕侠侣》里有这么一段：

法王笑道：“人各有志，那也勉强不来。杨兄弟，你的武功花样甚多，不是我倚老卖老说一句，博采众家固然甚妙，但也不免驳而不纯。你最擅长的到底是那一门功 夫？要用甚麽武功去对付郭靖夫妇？”这几句话可将杨过问得张口结舌，难以回答。他一生遭际不凡，性子又是贪多务得，全真派的、欧阳锋的、古墓派的、九阴真 经、洪七公的、黄药师的，诸般武功著实学了不少。这些功夫每一门都是奥妙无穷，以毕生精力才智钻研探究，亦难以望甚涯岸，他东摘一鳞、西取半爪，却没一门 功夫练到真正第一流的境界。遇到次等对手之时，施展出来固然是五花八门，叫人眼花撩乱，但遭逢到真正高手，却总是相形见绌，便和金轮法王的弟子达尔巴、霍 都相较，也是颇有不及。他低头凝思，觉得金轮法王这几句话实是当头棒喝，说中了他武学的根本大弊。

杨过第一反应是什么呢？

他走出茅棚，在山顶上负手而行，苦苦思索，甚是烦恼，想了半天，突然间心念一动：“我何不取各派所长，自成一家？天下武功，均是由人所创，别人既然创得，我难道就创不得？”想到此处，眼前登时大现光明。

最终他的决定是什么？

杨过睡了半夜，次晨一早起来又想。七日之中，接连昏迷了五次。说要综纳诸门，自创一家，那是谈何容易？以他此时的识力修为固然绝难成功，那更不昃十天半月 间之事。但连想数日之後，恍然有悟，猛地明白诸般武术皆可为我所用，既不能合而为一，也就不必强求，日後临敌之际，当用则用，不必去想武功的出处来历，也 已与自创一派想差无几。想明白了此节，登时心中舒畅。

这就是笔者想要表达的。作为一名合格的测试工程师首先一定要见识广博，最新的行业动态，各种测试方法等等都需要了解。然后在此基础上，实际工作中需要用到什么方法就用什么方法，信手拈来，千万不要书到用时方恨少。笔者一直在劝喻团队中的工程师，不要整天只知道埋头干活像鸵鸟一样，要经常抬起头来放眼看世界，井底之蛙坐井观天是要不得的，这样下去路只会越走越窄。最后，当各方面积累到一定程度会发生量变到质变，如果还具备过人的天赋并能百尺竿头更进一步，则可开宗立派自成一家，就象杨过最后自创“黯然销魂掌”一样。

笔者在日常工作中最常用的是路径法、场景法，以组合测试、探索性测试作为辅助。路径法主要用来做测试需求分析，关注的是节点；场景法主要用来做测试设计，关注的是路径；组合测试主要用来对规则性的用例进行筛选，减少测试用例数量；探索性测试主要用于交叉测试或测试大扫除之类的测试活动。这些方法的详细论述网上有很多，这里就不一一阐述了。如何把这些方法贯穿在一起？之前的分享有详细表述过，这里也不啰嗦了。

现在业内有两种测试理念很流行，一种是基于模型测试（MBT），一种是云测试。笔者以为这两种测试方式一定是未来测试行业发展的大方向。随着测试智能化的发展，今后测试工程师入行的门槛会越来越低乃至于消失。到那时，只需要很少一部分测试精英维护测试智能化平台，其它大部分的测试工作可交由任何人来完成，真正实现“IT民工”的梦想。

很多人应该都读过“四人帮”的《设计模式》，大多数人虽然看不懂但都明白这是核心，是重中之重。测试方法也是如此，它是测试工作的灵魂，测试用例与测试脚本孰重孰轻？不言而喻。

最后说明一点，在笔者印象中测试人员是肯定要参与需求分析及系统设计过程的。记得很早前有位工作十来年的开发工程师对笔者说：“你真牛叉这些工作你都参与”。实际上他没明白，这本身就是测试人员的工作，测试人员本来就需要具备这些能力。所以笔者总说现在国内合格的测试工程师很少，大部分都是滥竽充数，同时也是笔者为什么在所带领团队中大力提倡组员多研究测试方法的原因。
基础技能

基础，或许说基本更合适一点。工欲善其事，必先利其器。前面已经谈到测试人员是复合型的，要对待测产品的行业背景、技术背景有深入了解。在测试智能化远没有发展成熟的今天，测试工程师必需掌握基础技能。

笔者遇到过不少刚入行的新人，他们问的最多问题是“测试人员是否需要懂编码”。笔者一般回答“欲穷千里目，更上一层楼”。其实不仅仅是测试人员，但凡和技术沾边的工种都需要懂编码。编码是最基础的技能，无论哪一门语言，至少要会一种，如果能再具备一定的产品开发经验那就更好了。但请注意，过犹不及，不要单纯拿编码能力的高低来衡量测试人员水平的高低，测试人员最核心的技能仍是在测试设计上，不要本末倒置。

同样，像数据库、操作系统、网络协议、建模等等都属于基础技能的范畴。可能测试人员在这些技能的掌握程度上没有专业人士强，没关系，因为这些技能最终是为测试专有技能所服务的，如此而已。当然，如果个人有兴趣深入研究那是最好。笔者记得刚接触Linux系统的时候拼命读源码，刚接触网络协议的时候厚厚几本《TCP/IP详解》放在床头，可惜的是都没坚持下来。

为什么说测试工程师转岗容易？现在该明白了吧。
测试模式

瀑布开发、快速开发、迭代开发、敏捷开发等等等等，这么多开发模式听着是不是犯晕？探讨哪种模式更好其实是扯淡，就象探讨是由“开明君主治理的封建制度国家”好，还是由“腐朽无能政府统治的民主制度国家”好一样，均属于哲学问题。同理，测试模式有V模型、X模型、H模型、前置模型，淘宝还提出了 SPR模型以及最近正在探索的CCI模型，哪种更好？合适的就是最好的。

尽信书不如无书，这道理很多人都说懂，实际上呢？大多数人依然是照本宣科，死搬硬套。在大多数情况下，工程师应该尽量追求神似而不是形似，特别是奋战在一线的工程师，要明白“将在外君命有所不受”的道理。在当前以结果为导向这种西式管理的氛围下，更多的是要拿出让各方面满意的成绩单。当然，也有部分人以此为借口逃避流程逃避制度，高举敏捷大旗却行偷懒之实。要知道能量守恒，在某方面偷懒在其它方面会付出更多，这样做其实是把自身工作转嫁到他人身上，比方说把自身应该完成的保证产品质量工作转嫁给他人，这样的人要招天谴。“适可而止”这四个字说起来简单，真要做到非常难，需要大量的实践经验，这也是为什么测试工程师职业生命周期较长的原因。

笔者认为，在当下绝大多数项目团队里，V模型足够使用，或者在部分地方进行改良即可适应项目团队工作的需要。要知道，经典是永远不会过时的。那么在行政体系上呢？一个测试部门应该采用怎样的组织结构？目前流行的是一分为二，一部分做技术支撑，另一部分做产品测试，还有极端的是测试人员只做测试技术支撑，产品测试交由开发人员自行完成。至于在产品测试里再细分单元测试、集成测试或功能测试、性能测试等角色，窃以为不需要，因为在广义上，都是功能。测试要做的就是V&V，检验已实现的功能是否正确，检验是否正确实现了功能。
测试工具

这里所说的工具是广义上的，可以说各种各样只要能辅助测试人员开展测试工作的工具都包含在内。

为什么Mercury（笔者还是习惯称为mercury而不是hp）的产品能得到广大测试工程师的认可？因为它满足了测试工程师工作的需要。工具干嘛用的？辅助测试工作用的。笔者一直觉得Mercury的架构师真是不得了，产品设计的如此漂亮。什么是测试架构师？这就是。

测试工具有很多，这里不一一列举了。每年国际上会评选年度最佳测试工具，有兴趣的朋友可以多了解下，这算是测试工具的风向标。

有人曾经争论什么才能称之为测试工具，例如针对某一特定产品开发的一段测试代码是否算是测试工具。笔者以为，从广义上讲是，但在通常所说的范围下不是，因为它不具备通用性，它只能为特定产品服务。所以笔者常常告诫测试人员，第一不要总吹嘘自己开发了多少测试工具，充其量那只能算是一段测试代码；第二要理解测试工具的本质，开发了一堆工具结果根本不能有效提高测试质量、测试效率，无法帮助测试人员发现更多的缺陷，有意义吗？

当然，有一点肯定没错，多试用不同种类的测试工具并研究其原理，如果能对其进行改进，那么恭喜，离专家又进了一步。

chenxuan

第二章 专业技能

《笑傲江湖》里有写到华山派分为剑气二宗，金大师在书中是褒扬剑宗的，令狐冲全无内力单凭神鬼莫测的剑法就打遍天下无敌手。那么在测试领域里，方法与技术哪个更重要？此话题争论太多一时半会说不清楚，但笔者是赞同方法更重要的。有道是万法归宗，一力降十会，就是这个道理。下文所说的技能涵盖了方法与技术。另请注意，当专业能力上升到一定程度后，需要从广度转为深度，即要在某一特定领域内做深做强，切勿变成杂而不精。
测试方法

目前测试领域内大大小小的测试方法上百种，有的被广大测试工程师所接受并在实际工作中大量运用，有的仅停留在理论研究阶段，还有的只是某些机构为了发表学术论文东拼西凑胡乱编造的。那么这么多方法应该如何选择？《神雕侠侣》里有这么一段：

法王笑道：“人各有志，那也勉强不来。杨兄弟，你的武功花样甚多，不是我倚老卖老说一句，博采众家固然甚妙，但也不免驳而不纯。你最擅长的到底是那一门功 夫？要用甚麽武功去对付郭靖夫妇？”这几句话可将杨过问得张口结舌，难以回答。他一生遭际不凡，性子又是贪多务得，全真派的、欧阳锋的、古墓派的、九阴真 经、洪七公的、黄药师的，诸般武功著实学了不少。这些功夫每一门都是奥妙无穷，以毕生精力才智钻研探究，亦难以望甚涯岸，他东摘一鳞、西取半爪，却没一门 功夫练到真正第一流的境界。遇到次等对手之时，施展出来固然是五花八门，叫人眼花撩乱，但遭逢到真正高手，却总是相形见绌，便和金轮法王的弟子达尔巴、霍 都相较，也是颇有不及。他低头凝思，觉得金轮法王这几句话实是当头棒喝，说中了他武学的根本大弊。

杨过第一反应是什么呢？

他走出茅棚，在山顶上负手而行，苦苦思索，甚是烦恼，想了半天，突然间心念一动：“我何不取各派所长，自成一家？天下武功，均是由人所创，别人既然创得，我难道就创不得？”想到此处，眼前登时大现光明。

最终他的决定是什么？

杨过睡了半夜，次晨一早起来又想。七日之中，接连昏迷了五次。说要综纳诸门，自创一家，那是谈何容易？以他此时的识力修为固然绝难成功，那更不昃十天半月 间之事。但连想数日之後，恍然有悟，猛地明白诸般武术皆可为我所用，既不能合而为一，也就不必强求，日後临敌之际，当用则用，不必去想武功的出处来历，也 已与自创一派想差无几。想明白了此节，登时心中舒畅。

这就是笔者想要表达的。作为一名合格的测试工程师首先一定要见识广博，最新的行业动态，各种测试方法等等都需要了解。然后在此基础上，实际工作中需要用到什么方法就用什么方法，信手拈来，千万不要书到用时方恨少。笔者一直在劝喻团队中的工程师，不要整天只知道埋头干活像鸵鸟一样，要经常抬起头来放眼看世界，井底之蛙坐井观天是要不得的，这样下去路只会越走越窄。最后，当各方面积累到一定程度会发生量变到质变，如果还具备过人的天赋并能百尺竿头更进一步，则可开宗立派自成一家，就象杨过最后自创“黯然销魂掌”一样。

笔者在日常工作中最常用的是路径法、场景法，以组合测试、探索性测试作为辅助。路径法主要用来做测试需求分析，关注的是节点；场景法主要用来做测试设计，关注的是路径；组合测试主要用来对规则性的用例进行筛选，减少测试用例数量；探索性测试主要用于交叉测试或测试大扫除之类的测试活动。这些方法的详细论述网上有很多，这里就不一一阐述了。如何把这些方法贯穿在一起？之前的分享有详细表述过，这里也不啰嗦了。

现在业内有两种测试理念很流行，一种是基于模型测试（MBT），一种是云测试。笔者以为这两种测试方式一定是未来测试行业发展的大方向。随着测试智能化的发展，今后测试工程师入行的门槛会越来越低乃至于消失。到那时，只需要很少一部分测试精英维护测试智能化平台，其它大部分的测试工作可交由任何人来完成，真正实现“IT民工”的梦想。

很多人应该都读过“四人帮”的《设计模式》，大多数人虽然看不懂但都明白这是核心，是重中之重。测试方法也是如此，它是测试工作的灵魂，测试用例与测试脚本孰重孰轻？不言而喻。

最后说明一点，在笔者印象中测试人员是肯定要参与需求分析及系统设计过程的。记得很早前有位工作十来年的开发工程师对笔者说：“你真牛叉这些工作你都参与”。实际上他没明白，这本身就是测试人员的工作，测试人员本来就需要具备这些能力。所以笔者总说现在国内合格的测试工程师很少，大部分都是滥竽充数，同时也是笔者为什么在所带领团队中大力提倡组员多研究测试方法的原因。
基础技能

基础，或许说基本更合适一点。工欲善其事，必先利其器。前面已经谈到测试人员是复合型的，要对待测产品的行业背景、技术背景有深入了解。在测试智能化远没有发展成熟的今天，测试工程师必需掌握基础技能。

笔者遇到过不少刚入行的新人，他们问的最多问题是“测试人员是否需要懂编码”。笔者一般回答“欲穷千里目，更上一层楼”。其实不仅仅是测试人员，但凡和技术沾边的工种都需要懂编码。编码是最基础的技能，无论哪一门语言，至少要会一种，如果能再具备一定的产品开发经验那就更好了。但请注意，过犹不及，不要单纯拿编码能力的高低来衡量测试人员水平的高低，测试人员最核心的技能仍是在测试设计上，不要本末倒置。

同样，像数据库、操作系统、网络协议、建模等等都属于基础技能的范畴。可能测试人员在这些技能的掌握程度上没有专业人士强，没关系，因为这些技能最终是为测试专有技能所服务的，如此而已。当然，如果个人有兴趣深入研究那是最好。笔者记得刚接触Linux系统的时候拼命读源码，刚接触网络协议的时候厚厚几本《TCP/IP详解》放在床头，可惜的是都没坚持下来。

为什么说测试工程师转岗容易？现在该明白了吧。
测试模式

瀑布开发、快速开发、迭代开发、敏捷开发等等等等，这么多开发模式听着是不是犯晕？探讨哪种模式更好其实是扯淡，就象探讨是由“开明君主治理的封建制度国家”好，还是由“腐朽无能政府统治的民主制度国家”好一样，均属于哲学问题。同理，测试模式有V模型、X模型、H模型、前置模型，淘宝还提出了 SPR模型以及最近正在探索的CCI模型，哪种更好？合适的就是最好的。

尽信书不如无书，这道理很多人都说懂，实际上呢？大多数人依然是照本宣科，死搬硬套。在大多数情况下，工程师应该尽量追求神似而不是形似，特别是奋战在一线的工程师，要明白“将在外君命有所不受”的道理。在当前以结果为导向这种西式管理的氛围下，更多的是要拿出让各方面满意的成绩单。当然，也有部分人以此为借口逃避流程逃避制度，高举敏捷大旗却行偷懒之实。要知道能量守恒，在某方面偷懒在其它方面会付出更多，这样做其实是把自身工作转嫁到他人身上，比方说把自身应该完成的保证产品质量工作转嫁给他人，这样的人要招天谴。“适可而止”这四个字说起来简单，真要做到非常难，需要大量的实践经验，这也是为什么测试工程师职业生命周期较长的原因。

笔者认为，在当下绝大多数项目团队里，V模型足够使用，或者在部分地方进行改良即可适应项目团队工作的需要。要知道，经典是永远不会过时的。那么在行政体系上呢？一个测试部门应该采用怎样的组织结构？目前流行的是一分为二，一部分做技术支撑，另一部分做产品测试，还有极端的是测试人员只做测试技术支撑，产品测试交由开发人员自行完成。至于在产品测试里再细分单元测试、集成测试或功能测试、性能测试等角色，窃以为不需要，因为在广义上，都是功能。测试要做的就是V&V，检验已实现的功能是否正确，检验是否正确实现了功能。
测试工具

这里所说的工具是广义上的，可以说各种各样只要能辅助测试人员开展测试工作的工具都包含在内。

为什么Mercury（笔者还是习惯称为mercury而不是hp）的产品能得到广大测试工程师的认可？因为它满足了测试工程师工作的需要。工具干嘛用的？辅助测试工作用的。笔者一直觉得Mercury的架构师真是不得了，产品设计的如此漂亮。什么是测试架构师？这就是。

测试工具有很多，这里不一一列举了。每年国际上会评选年度最佳测试工具，有兴趣的朋友可以多了解下，这算是测试工具的风向标。

有人曾经争论什么才能称之为测试工具，例如针对某一特定产品开发的一段测试代码是否算是测试工具。笔者以为，从广义上讲是，但在通常所说的范围下不是，因为它不具备通用性，它只能为特定产品服务。所以笔者常常告诫测试人员，第一不要总吹嘘自己开发了多少测试工具，充其量那只能算是一段测试代码；第二要理解测试工具的本质，开发了一堆工具结果根本不能有效提高测试质量、测试效率，无法帮助测试人员发现更多的缺陷，有意义吗？

当然，有一点肯定没错，多试用不同种类的测试工具并研究其原理，如果能对其进行改进，那么恭喜，离专家又进了一步。

chenxuan

第二章 专业技能

《笑傲江湖》里有写到华山派分为剑气二宗，金大师在书中是褒扬剑宗的，令狐冲全无内力单凭神鬼莫测的剑法就打遍天下无敌手。那么在测试领域里，方法与技术哪个更重要？此话题争论太多一时半会说不清楚，但笔者是赞同方法更重要的。有道是万法归宗，一力降十会，就是这个道理。下文所说的技能涵盖了方法与技术。另请注意，当专业能力上升到一定程度后，需要从广度转为深度，即要在某一特定领域内做深做强，切勿变成杂而不精。
测试方法

目前测试领域内大大小小的测试方法上百种，有的被广大测试工程师所接受并在实际工作中大量运用，有的仅停留在理论研究阶段，还有的只是某些机构为了发表学术论文东拼西凑胡乱编造的。那么这么多方法应该如何选择？《神雕侠侣》里有这么一段：

法王笑道：“人各有志，那也勉强不来。杨兄弟，你的武功花样甚多，不是我倚老卖老说一句，博采众家固然甚妙，但也不免驳而不纯。你最擅长的到底是那一门功 夫？要用甚麽武功去对付郭靖夫妇？”这几句话可将杨过问得张口结舌，难以回答。他一生遭际不凡，性子又是贪多务得，全真派的、欧阳锋的、古墓派的、九阴真 经、洪七公的、黄药师的，诸般武功著实学了不少。这些功夫每一门都是奥妙无穷，以毕生精力才智钻研探究，亦难以望甚涯岸，他东摘一鳞、西取半爪，却没一门 功夫练到真正第一流的境界。遇到次等对手之时，施展出来固然是五花八门，叫人眼花撩乱，但遭逢到真正高手，却总是相形见绌，便和金轮法王的弟子达尔巴、霍 都相较，也是颇有不及。他低头凝思，觉得金轮法王这几句话实是当头棒喝，说中了他武学的根本大弊。

杨过第一反应是什么呢？

他走出茅棚，在山顶上负手而行，苦苦思索，甚是烦恼，想了半天，突然间心念一动：“我何不取各派所长，自成一家？天下武功，均是由人所创，别人既然创得，我难道就创不得？”想到此处，眼前登时大现光明。

最终他的决定是什么？

杨过睡了半夜，次晨一早起来又想。七日之中，接连昏迷了五次。说要综纳诸门，自创一家，那是谈何容易？以他此时的识力修为固然绝难成功，那更不昃十天半月 间之事。但连想数日之後，恍然有悟，猛地明白诸般武术皆可为我所用，既不能合而为一，也就不必强求，日後临敌之际，当用则用，不必去想武功的出处来历，也 已与自创一派想差无几。想明白了此节，登时心中舒畅。

这就是笔者想要表达的。作为一名合格的测试工程师首先一定要见识广博，最新的行业动态，各种测试方法等等都需要了解。然后在此基础上，实际工作中需要用到什么方法就用什么方法，信手拈来，千万不要书到用时方恨少。笔者一直在劝喻团队中的工程师，不要整天只知道埋头干活像鸵鸟一样，要经常抬起头来放眼看世界，井底之蛙坐井观天是要不得的，这样下去路只会越走越窄。最后，当各方面积累到一定程度会发生量变到质变，如果还具备过人的天赋并能百尺竿头更进一步，则可开宗立派自成一家，就象杨过最后自创“黯然销魂掌”一样。

笔者在日常工作中最常用的是路径法、场景法，以组合测试、探索性测试作为辅助。路径法主要用来做测试需求分析，关注的是节点；场景法主要用来做测试设计，关注的是路径；组合测试主要用来对规则性的用例进行筛选，减少测试用例数量；探索性测试主要用于交叉测试或测试大扫除之类的测试活动。这些方法的详细论述网上有很多，这里就不一一阐述了。如何把这些方法贯穿在一起？之前的分享有详细表述过，这里也不啰嗦了。

现在业内有两种测试理念很流行，一种是基于模型测试（MBT），一种是云测试。笔者以为这两种测试方式一定是未来测试行业发展的大方向。随着测试智能化的发展，今后测试工程师入行的门槛会越来越低乃至于消失。到那时，只需要很少一部分测试精英维护测试智能化平台，其它大部分的测试工作可交由任何人来完成，真正实现“IT民工”的梦想。

很多人应该都读过“四人帮”的《设计模式》，大多数人虽然看不懂但都明白这是核心，是重中之重。测试方法也是如此，它是测试工作的灵魂，测试用例与测试脚本孰重孰轻？不言而喻。

最后说明一点，在笔者印象中测试人员是肯定要参与需求分析及系统设计过程的。记得很早前有位工作十来年的开发工程师对笔者说：“你真牛叉这些工作你都参与”。实际上他没明白，这本身就是测试人员的工作，测试人员本来就需要具备这些能力。所以笔者总说现在国内合格的测试工程师很少，大部分都是滥竽充数，同时也是笔者为什么在所带领团队中大力提倡组员多研究测试方法的原因。
基础技能

基础，或许说基本更合适一点。工欲善其事，必先利其器。前面已经谈到测试人员是复合型的，要对待测产品的行业背景、技术背景有深入了解。在测试智能化远没有发展成熟的今天，测试工程师必需掌握基础技能。

笔者遇到过不少刚入行的新人，他们问的最多问题是“测试人员是否需要懂编码”。笔者一般回答“欲穷千里目，更上一层楼”。其实不仅仅是测试人员，但凡和技术沾边的工种都需要懂编码。编码是最基础的技能，无论哪一门语言，至少要会一种，如果能再具备一定的产品开发经验那就更好了。但请注意，过犹不及，不要单纯拿编码能力的高低来衡量测试人员水平的高低，测试人员最核心的技能仍是在测试设计上，不要本末倒置。

同样，像数据库、操作系统、网络协议、建模等等都属于基础技能的范畴。可能测试人员在这些技能的掌握程度上没有专业人士强，没关系，因为这些技能最终是为测试专有技能所服务的，如此而已。当然，如果个人有兴趣深入研究那是最好。笔者记得刚接触Linux系统的时候拼命读源码，刚接触网络协议的时候厚厚几本《TCP/IP详解》放在床头，可惜的是都没坚持下来。

为什么说测试工程师转岗容易？现在该明白了吧。
测试模式

瀑布开发、快速开发、迭代开发、敏捷开发等等等等，这么多开发模式听着是不是犯晕？探讨哪种模式更好其实是扯淡，就象探讨是由“开明君主治理的封建制度国家”好，还是由“腐朽无能政府统治的民主制度国家”好一样，均属于哲学问题。同理，测试模式有V模型、X模型、H模型、前置模型，淘宝还提出了 SPR模型以及最近正在探索的CCI模型，哪种更好？合适的就是最好的。

尽信书不如无书，这道理很多人都说懂，实际上呢？大多数人依然是照本宣科，死搬硬套。在大多数情况下，工程师应该尽量追求神似而不是形似，特别是奋战在一线的工程师，要明白“将在外君命有所不受”的道理。在当前以结果为导向这种西式管理的氛围下，更多的是要拿出让各方面满意的成绩单。当然，也有部分人以此为借口逃避流程逃避制度，高举敏捷大旗却行偷懒之实。要知道能量守恒，在某方面偷懒在其它方面会付出更多，这样做其实是把自身工作转嫁到他人身上，比方说把自身应该完成的保证产品质量工作转嫁给他人，这样的人要招天谴。“适可而止”这四个字说起来简单，真要做到非常难，需要大量的实践经验，这也是为什么测试工程师职业生命周期较长的原因。

笔者认为，在当下绝大多数项目团队里，V模型足够使用，或者在部分地方进行改良即可适应项目团队工作的需要。要知道，经典是永远不会过时的。那么在行政体系上呢？一个测试部门应该采用怎样的组织结构？目前流行的是一分为二，一部分做技术支撑，另一部分做产品测试，还有极端的是测试人员只做测试技术支撑，产品测试交由开发人员自行完成。至于在产品测试里再细分单元测试、集成测试或功能测试、性能测试等角色，窃以为不需要，因为在广义上，都是功能。测试要做的就是V&V，检验已实现的功能是否正确，检验是否正确实现了功能。
测试工具

这里所说的工具是广义上的，可以说各种各样只要能辅助测试人员开展测试工作的工具都包含在内。

为什么Mercury（笔者还是习惯称为mercury而不是hp）的产品能得到广大测试工程师的认可？因为它满足了测试工程师工作的需要。工具干嘛用的？辅助测试工作用的。笔者一直觉得Mercury的架构师真是不得了，产品设计的如此漂亮。什么是测试架构师？这就是。

测试工具有很多，这里不一一列举了。每年国际上会评选年度最佳测试工具，有兴趣的朋友可以多了解下，这算是测试工具的风向标。

有人曾经争论什么才能称之为测试工具，例如针对某一特定产品开发的一段测试代码是否算是测试工具。笔者以为，从广义上讲是，但在通常所说的范围下不是，因为它不具备通用性，它只能为特定产品服务。所以笔者常常告诫测试人员，第一不要总吹嘘自己开发了多少测试工具，充其量那只能算是一段测试代码；第二要理解测试工具的本质，开发了一堆工具结果根本不能有效提高测试质量、测试效率，无法帮助测试人员发现更多的缺陷，有意义吗？

当然，有一点肯定没错，多试用不同种类的测试工具并研究其原理，如果能对其进行改进，那么恭喜，离专家又进了一步。

wangleis18

非常好的一篇文章！

hendi1

呵呵~又是一杯具！顶一下了。  
   
   
   
   
   
   
  
  
  
  
  

chenxuan

第三章 能力修炼
修炼要素

以下列举的十八要素仅供参考，这些要素并没有优先级或前后顺序，但有一点是必需确保的，那就是坚持，至少坚持一个月。如果能把全部要素坚持做一个月，笔者保证测试工程师自身能力会有大幅度提高。如果能坚持一年甚至更长时间直至养成习惯，那么恭喜，离牛人不远了。

1、  每日至少抽出30分钟关注测试行业新闻，包括各种业内动向，技术前沿等。推荐国内网站：51testing、ITPUB、Javaeye、infoq、博客园、Oracle中国用户组……。

2、  每日写一篇博文，200字左右，记录当日工作完成情况及次日需完成工作，流水帐也可。

3、  每晚入睡前回顾当天表现，检讨一言一行。

4、  每日清晨计划当日需完成工作并确定优先级。

5、  每日早晚对着镜子微笑一次。

6、  每日阅读，书的种类不限，不一定是技术类。

7、  每日选取一位从来没交流过的同事进行交流。

8、  每日至少编写30行代码。

9、  每日收看新闻联播，重播也可。

10、              每日洗澡。

11、              至少每隔两日看一集推理类电视剧，推荐《金田一少年事件簿》。

12、              至少每隔三日参加一次益智分析类游戏，推荐“围棋”、“三国杀”。

13、              每三日研究一个技术类工具并发表研究文章，推荐从Excel开始研究。

14、              每周至少与朋友外出活动一次，推荐极放松的活动，例如喝酒。

15、              一周内不要连续两天加班。

16、              每周至少一次与上级开展交流。

17、              每月至少单身外出一次，推荐西湖边静坐。

18、              每月至少储蓄20％当月收入，至多储蓄60％。
测试工程师的一天

7：30  起床

7：35  洗漱，计划当天工作

8：00  出门，面对镜子给自己个微笑

8：30  早餐，什么都不要想

8：50  公司，开机接收邮件、消息

9：10  浏览业内新闻

9：40  大多数人已到公司，开始当天工作

12：00 中饭，小饭桌上别谈工作更别一副忧国忧民的样子大谈国计民生

13：00 技术研究并沉淀

14：00 继续本日工作，编码，主动与没交流过的同事进行交流，组织晚上活动

18：00 晚饭，总结本日工作

18：30 撰写当日工作博文

18：45 加班

19：45 三国杀

21：00 回家，洗澡

21：30 中央新闻频道，喝酒

22：00 电视剧，喝酒

22：30 读书，喝酒

23：00 上床，自我反省

23：15 呼呼呼呼

注意：以上主要表达一种思路，勿纠结勿全部模仿。
进阶目录

通常情况下，能力提升是一个渐进过程，但提升到某一高度遇到瓶颈时则需要突破。这有点类似大乘佛法里所说的，从渐修到顿悟，再从顿悟到圆修。本身中国佛教界对此就有不少争论，南方慧能系（称南顿）与北方神秀系（称北渐）分别讲究顿悟与渐悟，而在顿悟中又有道生顿悟、禅宗顿悟，所以说每个人的进修道路是不尽相同的，也不一定有高下之分，主要看对自我认知是否清晰，在不同阶段需要何种提升方式，这才是重点。

在个人能力提升的道路上，上级主管的支持及培养是非常重要的。好主管会因地制宜因人而异，每次安排超出其能力一点的工作，让其不断的有挑战。同时在实施过程中，主管会默默支持，与其一同制定解决方案并跟进实施过程，最终让其独享成功的成果与喜悦。

此外，每人擅长的领域不同，有的人所具备的能力很契合当前工作，因此会成为主攻手，有的不太符合只能做辅助。但请注意，在多方协作工作中，必然有人在前攻城拔寨做明星，有人在后默默耕耘做后勤，这些不能单纯的以高下来衡量，况且说不定哪天换成其它工作，这主次之分就倒过来了。

以下是能力渐进提升的阶梯目录，从前到后有顺序之分。

1、 基础：前文所说的基础技能必需掌握，推荐Java＋Oracle＋Uml组合。掌握程度一般不用太深，测试工具开发职位的除外。特别注明，Junit是一定要掌握的。市面上书籍很多，笔者推荐《Java编程思想》、 《Oracle 9i 参考手册》、《UML精粹》。

2、 专业：前文所说的测试方法、测试工具必需掌握。其中对于测试工具，如果开源则尽可能阅读源码。推荐书籍《计算机软件测试技术》、《软件测试艺术》、《软件测试》。

3、 实战：前文所说的测试模式必需掌握。 至少全程参与二十次项目，至少参与两次50人以上规模的项目，至少编写测试用例10000个，至少发现缺陷5000个，至少编写测试脚本20000行，至少担任过三次测试负责人，所有产品发布后遗漏缺陷总数小于50个并呈收敛趋势。推荐书籍《设计模式》、《人月神话》、《软件测试经验与教训》。

4、 沉淀：深入了解质量控制原理，对功能性（含安全）、效率、易用性、可移植性、可维护性、可靠性等质量特性均有实际测试经验。推荐书籍《质量无泪》、《质量免费》、《ISO9126》等所有软件质量相关国标。

5、 领域：选取一至两门测试技术作为长期研究的方向，中途可适当调整，这里说的长期指的是五年、十年及以上，在这个层次重点是要做到专精。推荐方向“云测试”、 “基于模型测试”。

6、 专家：理论计算机科学研究。笔者不是专家，因此不敢臆测到达此层次后应该做些什么以及怎么做，但“P/NP问题”是笔者一直有兴趣并持续关注的，也是很多科研工作者选取的研究课题，在此郑重推荐。
第四章 杂谈

笔者刚入行时有次参加公司组织的培训，是一个微软的老外来讲课。培训那天会议室的前三排基本没人坐，有位副总站起来骂“这就是Chinese”，当即有人反问“你不是Chinese？”，说起来他还真不是，已经移民到加拿大了。做人切勿忘本，做事前要先学会做人。作为一名测试人员不要崇洋媚外迷信权威，但也不能做土八路。业内一般的说法是“做事要高调做人要低调”，笔者以为“做事要高调做人也要高调”，心有多大，舞台就有多大。

测试行业发展到今天需要求新求变，就象当年武侠小说一样。笔者一直很喜欢古龙，不知道谁能成为测试行业的古龙。

有位伟人曾经说过，“不管黑猫白猫能抓到老鼠的就是好猫”。同理，不管黑盒白盒能找到缺陷的就是好盒。工作中不论用的是正道、奇道还是王道，不论用的是阴谋还是阳谋，能解决问题的就是我们所需要的。

男女搭配，干活不累，这是至理名言。测试团队的男女比例1：3最好。

社会是个大染缸，测试人员要保持一颗纯真的心。做事要又猛又持久，做人要很傻很天真。

世上不如意事十常居八九，人生总会经历很多挫折。真的爷们，敢于直面惨淡的人生，敢于正视淋漓的鲜血。如果不爱测试，请尽早离开。
后记

终于写完了，原本就想写一千来字的，结果提笔后洋洋洒洒的写了这么多，看来还是高度不够，语言不够精炼。

文中提到的锻炼方法还有待临床验证，故征集小白鼠，欲被蹂躏者可向笔者报名。

笔者已能预计到本文发出后会引来多少质疑与唾骂，但没关系，“我可以不同意你丫说的话但我誓死捍卫你丫得瑟的权力”。欢迎大家拍砖，争议越多越好，讨论越激烈笔者越出名，哇哈哈哈哈。

转载务必注明出处Taobao QA Team

chelili

修炼之道看自己的情况了