达内专注IT培训20年，覆盖70座城市，近342家校区遍布，开设Java大数据、软件测试、Python人工智能、web前端、Linux云计算、网络安全与运维、UI设计、运营、影视特效、全链路网络营销等IT培训、泛IT培训和非IT培训共12大IT课程，拨打客服电话预约了解课程详解及优惠！

　　达内软件测试课程全新升级，课程覆盖数据库、linux、 接口测试、手机测试等技术，并设有辅导课程，主讲编程语言Python，基于Python的接口框架和功能自动化工具Selenium和性能测试工具JMeter，学软件测试就来达内。

　　技术+业务双向赋能  3个月打造π型测试人才

　　9*大手工测试技术

　　测试计划、测试方案、需求分析、用例设计、用例执行、测试报告、缺陷管理、配置管理、用例评审

　　9*大自动化测试技术

　　接口测试、性能测试、WEB测试、APP测试、数据抓包、安全测试、linux、数据库、DevOps

　　11*大测试开发技术

　　python/java、白盒测试、测试框架、设计模式、持续集成、每日构建、UnitTest、Pytest、大数据测试、人工智能测试、华为云计算

　　9*大主流行业业务掌握能力

　　电商、金融、（银行、保险、理财等）、医疗、视频及直播、即时通信、社交、旅游、人工智能、游戏

　　5*大业务需求分析能力

　　用户需求挖掘分析、业务过程拆解、核心业务流程提取、测试点与测试场景提炼、用户真实场景模拟

　　7*大项目方案设计能力

　　手工测试用例设计、接口测试用例设计、功能自动化脚本编写、性能场景设计、性能测试脚本设计、白盒测试方案设计、安全测试方案设计

　　一名合格的软件测试工程师，应该是这样修炼的！

　　前言

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

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

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

　　本文将针对这些问题进行初步解答，主要阐述解决这些问题应该具备哪些能力及如何锻炼这些能力，至于实际工作中解决问题的具体操作步骤本文不做表述。

　　前两章主要探讨一名合格的测试工程师应该具备哪些能力，对列举的能力将会做简要说明。

　　第三章重点说明应该如何锻炼这些能力，此为本文的重点。

　　较后一章是笔者对软件测试虚无缥缈杂乱无章的一些想法。

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

　　下面，我们开始。

　　章综合素质

　　笔者以为，作为一名合格的测试工程师，综合素质是较重要的，综合素质也就是我们常说的软技能，它代表着一个人的潜力有多大，未来发展有多宽广。

　　核心素质有以下五点：沟通、分析、组织、学习、心态，下面将会分别阐述。

　　1.1. 沟通

　　作为一名软件测试工程师，加强的应该是哪方面的沟通能力?是文字沟通能力。

　　试想，如果连缺陷描述都无法准确清晰的用文字表达出来，还有开发愿意和你合作吗?特别是随着异地开发的项目越来越多，文字沟通的场景也会越来越多。

　　当然，口头沟通也很重要，通过面对面或者电话语音交流是很直接的方式，这也是为什么许多“鼓吹”敏捷开发的团队喜欢坐在一起的原因，认为这样会降低沟通成本。

　　但事实上，真的在任何时刻都能降低成本吗?无效冗长的会议大家都参与过，这里不做深入讨论。

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

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

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

　　1.2. 分析

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

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

　　再例如测试计划，我们做计划是拍脑袋乱猜吗?是掐指算命吗?肯定很多人回答不是，但实际上往往很多人就是这么做的。

　　测试计划的制定过程是首先收集大量相关信息，然后抽丝剥茧在杂乱无章的信息中寻找到关键点并梳理清脉络，较终据此定出计划。我们说部分未来是可以推测出来的，就是这个道理。在做计划时会用到许许多多辅助分析的理论方法，这里就不一一阐述了。艾森豪威尔有句名言：“A plan is nothing，planning is everything.(一个成型的计划无足轻重，分析的过程才是重中之重)” Planning就是分析的过程。

　　1.3.组织

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

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

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

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

　　1.4. 学习

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

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

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

　　学习较核心的是什么?知之者不如好之者，好之者不如乐之者。

　　1.5. 心态

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

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

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

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

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

　　第二章专业技能

　　《笑傲江湖》里有写到华山派分为剑气二宗，金大师在书中是褒扬剑宗的，令狐冲全无内力单凭神鬼莫测的剑法就打遍天下手。

　　那么在测试领域里，方法与技术哪个更重要?此话题争论太多一时半会说不清楚，但笔者是赞同方法更重要的。有道是万法归宗，一力降十会，就是这个道理。

　　下文所说的技能涵盖了方法与技术。另请注意，当专业能力上升到一定程度后，需要从广度转为深度，即要在某一特定领域内做深做强，切勿变成杂而不精。

　　2.1. 测试方法

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

　　《神雕侠侣》里有这么一段：

　　法王笑道：“人各有志，那也勉强不来。杨兄弟，你的武功花样甚多，不是我倚老卖老说一句，博采众家固然甚妙，但也不免驳而不纯。你较擅长的到底是那一门功夫?要用甚麽武功去对付郭靖夫妇?”

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

　　杨过反应是什么呢?

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

　　较终他的决定是什么?

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

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

　　笔者在日常工作中较常用的是路径法、场景法，以组合测试、探索性测试作为辅助。

　　路径法主要用来做测试需求分析，关注的是节点;场景法主要用来做测试设计，关注的是路径;组合测试主要用来对规则性的用例进行筛选，减少测试用例数量;探索性测试主要用于交叉测试或测试大扫除之类的测试活动。

　　这些方法的详细论述网上有很多，这里就不一一阐述了。如何把这些方法贯穿在一起?之前的分享有详细表述过，这里也不啰嗦了。

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

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

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

　　2.2. 基础技能

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

　　笔者遇到过不少刚入行的新人，他们问的较多问题是“测试人员是否需要懂编码”。笔者一般回答“欲穷千里目，更上一层楼”。

　　其实不仅仅是测试人员，但凡和技术沾边的工种都需要懂编码。编码是较基础的技能，无论哪一门语言，至少要会一种，如果能再具备一定的产品开发经验那就更好了。但请注意，过犹不及，不要单纯拿编码能力的高低来衡量测试人员水平的高低，测试人员较核心的技能仍是在测试设计上，不要本末倒置。

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

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

　　2.3. 测试模式

　　瀑布开发、开发、迭代开发、敏捷开发等等等等，这么多开发模式听着是不是犯晕?探讨哪种模式更好其实是扯淡，就象探讨是由“开明君主治理的封建制度”好，还是由“腐朽无能政府统治的民主制度”好一样，均属于哲学问题。

　　同理，测试模式有V模型、X模型、H模型、前置模型，淘宝还提出了SPR模型以及较近正在探索的CCI模型，哪种更好?合适的就是较好的。

　　尽信书不如无书，这道理很多人都说懂，实际上呢?大多数人依然是照本宣科，死搬硬套。在大多数情况下，工程师应该尽量追求神似而不是形似，特别是奋战在的工程师，要明白“将在外君命有所不受”的道理。

　　在当前以结果为导向这种西式管理的氛围下，更多的是要拿出让各方面满意的成绩单。当然，也有部分人以此为借口逃避流程逃避制度，高举敏捷大旗却行偷懒之实。要知道能量守恒，在某方面偷懒在其它方面会付出更多，这样做其实是把自身工作转嫁到他人身上，比方说把自身应该完成的增加产品质量工作转嫁给他人，这样的人要招天谴。

　　“适可而止”这四个字说起来简单，真要做到非常难，需要大量的实践经验，这也是为什么测试工程师职业生命周期较长的原因。

　　笔者认为，在当下绝大多数项目团队里，V模型足够使用，或者在部分地方进行改良即可适应项目团队工作的需要。要知道，经典是永远不会过时的。

　　那么在行政体系上呢?一个测试部门应该采用怎样的组织结构?目前流行的是一分为二，一部分做技术支撑，另一部分做产品测试，还有极端的是测试人员只做测试技术支撑，产品测试交由开发人员自行完成。至于在产品测试里再细分单元测试、集成测试或功能测试、性能测试等角色，窃以为不需要，因为在广义上，都是功能。测试要做的就是V&V，检验已实现的功能是否正确，检验是否正确实现了功能。

　　2.4. 测试工具

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

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

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

　　有人曾经争论什么才能称之为测试工具，例如针对某一特定产品开发的一段测试代码是否算是测试工具。笔者以为，从广义上讲是，但在通常所说的范围下不是，因为它不具备通用性，它只能为特定产品服务。

　　所以笔者常常告诫测试人员，不要总吹嘘自己开发了多少测试工具，充其量那只能算是一段测试代码;第二要理解测试工具的本质，开发了一堆工具结果根本不能有效提高测试质量、测试效率，无法帮助测试人员发现更多的缺陷，有意义吗?

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

　　未完待续~