第二章 专业技能

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

　　测试方法

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

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

　　杨过第一反应是什么呢？

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

　　最终他的决定是什么？

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

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

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

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

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

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

　　基础技能

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

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

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

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

　　测试模式

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

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

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

　　测试工具

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

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

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

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

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