软件测试职业发展的 A 面和 B 面

草帽路飞UU

软件测试职业发展的 A 面和 B 面

1.所谓的软件测试技术到底包含什么？                                                                                             

梅子：我先来从传统意义上来谈一下测试技术，主要就是测试分析，测试设计，测试管理，测试执行，自动化测试技术，专项测试技术，缺陷分析技术等。

Monkey：对于测试技术，这的确是个很好的话题。首先在这样一个快速变化的时代，我们应该勇于拥抱变化。我觉得之所以现在测试行业很多测试人员会困惑于测试技术很大一部分原因就在于很多人冥顽不灵，不愿意接受新鲜的事物和变化。

在我看来，抛开以前书本上的死知识，软件测试技术现在包含两部分：

• 我们自己认为的软件测试技术
• 别人认为测试应该学会的技术
  

那我们一个一个来讲吧，先说我们自己认为的软件测试技术。软件测试用例设计方法，软件测试思维，软件测试策略等等，这些其实我不想在这里浪费篇章去说明这些，为什么？因为这些并无法真正量化，也很难去考评，在现实的行业中也无法给你带来直接的升职加薪，所以我认为就算我写了大家也没有兴趣看。

那么别人认为测试理论上会的又是什么呢？

• 点点点，很重要
• 所谓的软件测试思维，其实并不是那么的重要
• 编程能力，最好什么都会，很重要
• 很强的沟通交流能力，很重要
• 很强的业务理解能力，很重要
• 能兼职产品经理，项目经理等，很重要
• 质量意识，最好能够感染整个团队和企业，很重要
• 加班能力，很重要
  

这些为什么有的很重要，因为你跳槽需要，KPI考评的时候需要，这些就足够了，不是么？

我们回到这个问题上来看吧，就如同很多时候我们觉得自己做的怎么样并不重要，重要的是大家普遍到底觉得你是怎么样的。加强对于“我们自己认为的软件测试技术”的学习这是我们测试人员的情怀，但加强对于“别人认为测试应该学会的技术”的学习这是我们测试人员为了找到一份不错的工作，为了生存而需要面对的，其实就那么简单。

梅子：刚才monkey讲到了不那么重要的测试思维，让我又重新去思考到底什么是测试思维，以及测试思维是如何影响我的。

我对测试思维的认识主要有2个阶段：

第一阶段：我认为测试思维就是测试如何去分析被测对象的视角，可以概括为测试类型（性能测试、可靠性测试、兼容性测试这种）和功能交互分析（就是把很多功能放在一起考虑）。这个测试思维能够帮我系统的分析被测对象，让我可以很容易的就比别人发现更多产品的问题，而且问题还蛮有价值的。我还发现，这个思路还可以用在需求的评审，设计的评审上，可以帮我快速找到需求或者说设计考虑得不周全的地方，这让我慢慢的赢得了开发的尊重，他们会主动找我讨论方案，我后来才知道这就叫产品的失效规律，也是我当时对于产品团队的独特价值——缺陷预防。

第二阶段：慢慢的我发现我真的没有必要对所有被测对象都进行那么全面的分析，有的功能特性好像不怎么测试也可以，有些功能测试却真的需要非常深入细致的测试，并且哪些需要详细测试，哪些不需要详细测试是动态变化的，我认为测试的核心，就是要在项目中把握这种动态性，有策略的进行测试。我开始注意项目的成本，思考如何用最小的成本来获得最好的测试效果。我发现但考虑测试，策略无法做好，很自然的，我开始全局，端到端的去考虑策略，慢慢的我发现我可以做项目经理，可以做一些质量和流程方面的工作了。我觉得测试思维也许并不应该只是狭义的理解为测试中才需要考虑的思维，测试思维是一种探索式的思路，它不仅适合于测试，也适合于产品的其他角色。我觉得他重要，是因为我们需要有一种思考方式，来指导我们的行为，只要你在团队中，你的思考方式的演进，都可以帮助你更好的服务你的团队，也能给你带来更多的机会。

2．为什么说测试需要开发技能，测试策略和开发 技能到底哪个重要？

梅子：对测试来说，开发技能是基础。我特别不喜欢”代码能力不行就去做测试”这样的论调，别的不说，如果测试一点代码能力都没有，你该要怎么和开发沟通？完全不在一个频道上又何谈协做。

但我也不认为，开发技能是测试的核心，我认为测试策略才是测试的核心。

无论产品开发的方式如何演进，用户对产品质量的期望都是客观存在的。质量＝符合要求，而探索和评估质量最有效的方式就是测试，20年前如此，20年后还是如此。对被测对象的准确把握，是探索产品迷宫的罗盘，关键因素包括代码复杂度，开发的技能和经验准备度，需求的质量等。有了这些，就可以判断风险的所在，在把握失效规律和失效影响的前提下，有的放矢的来开展各种测试活动。而实际的情况却是，我们太缺少对被测对象的分析和思考，这让我们做了很多看起来必要实际却很低效的事情。

举一个回归测试的例子。如果开发修改问题改得非常好，我们的bug 99%都可以回归通过，那么我认为测试没有必要再做回归测试，因为投入产出比非常小。我们可以这样算一笔账，假设一个周期为两个月的产品有200个bug，测试人员一天可以验证10个bug，这就是20人天的工作量，这还不算回归测试中的测试设计或者是发散测试的工作量。我们完全可以把这个时间放在测试其他的更值得测试的地方，或者干脆把发布周期提前一周又为何不可呢。

再举一个自动化的例子。某测试团队加班加点把某个功能接口全部自动化了，大概有1000多个自动化脚本，运行却只发现了2个问题，后面反复运行都再也没有发现过问题了。换句话说，上面提到的这部分系统，可能本来就是不太需要测试的系统，就算是完美的回归流程、测试设计、自动化测试，意义又有多大呢？

所以对相对于自动化测试，测试设计，流程等相对固定的东西之外，测试还需要一个可以审时度势，动态的分析和调整的技术，让测试可以聪明的工作，关键是，我们要能意识到，测试最核心的东西是动态的，是和整个研发过程和市场定位紧密捆绑的。不管测试的竞争力如何变化的，唯一不变的是我们的应对原则：根据被测对象和测试团队制定合适的测试策略。

所以，我个人认为，测试策略是测试技术中最核心的部分。测试，简单来说就是，测什么和怎么测，这都是策略的范畴。相比自动化、工具、测试设计等，测试策略往往更能更举足轻重地影响测试的质量和效率——测什么和怎么测决定了质量，实际也决定了效率。如果能在深入分析的基础上大幅度减少测试用例，测试效率提升一定比自动化还高。然后再对最值得自动化的部分进行自动化，而不是为了自动化而自动化，测试效率又会大幅度提高。实际上，系统越来越复杂，我们总有分析不清楚的时候，如果自动化平台足够强大，我们多测试一些也没有关系，可以避免一些低级遗漏。所以，策略是重要的，但是毕竟是基于经验的，总会有不完善的地方，工具和自动化可以很好的补充。测试还没有达到科学或者工程定量的程度，但也不是只有少数人才会的艺术，而是一门基于经验，可复制性的工艺学科，只是还没有达到可以给出明确标准的批量复制程度。也正是因为如此，才更需要我们去做深入的思考和分析。

Monkey：这个的确是个好问题，但我觉得很多会问这个问题的主要问题在于

• 自己根本就没有怎么做过测试，跟风问题
• 对测试策略的理解太浅
  

在我看来测试策略其实已经是一个很高等级的词汇了，能做到这个根本就是屈指可数，其根本就和所谓的开发技能不在一个水平面上，所以不能去做一定的对比。行业中很多次拿出来对比在我看来就是大家的理解太过浅层次。

拓展开来这里先说测试用例设计方法，现在实际项目中一板一眼的根据设计方法去设计的应该已经是不存在的了，测试用例的设计方法更多的是为了培养测试人员的测试思维，如何通过一些总结出来的方法去测试产品。这也是作为一个测试人员最最基本要明白的。

其次就来讨论下开发技能，这里的开发技能更多的其实指的就是看代码能力和写代码能力，现在行业里基本上都是考核写代码能力了。我们撇开所谓的自动化（因为在我看来，很多测试做的最多只不过是半自动化，远远达不到自动化的程度）和测试工具来讲，我们要了解一个复杂的项目的时候必须去深入了解其技术设计和实现，那么对于一个测试人员的研发能力就有着很高的要求。无论是代码能力还是架构思维都是为了能够更快的更准确的去理解被测对象打下扎实基础的，从而才能够制定出正确的测试策略。所以从我的理解上来讲，测试人员越往上走就需要越强的研发技能，否则只会依赖于PRD或者与研发鸡同鸭讲，最终只了解产品的皮毛。

最后来谈下测试策略吧，在我理解的测试策略并不是你掌握了一个很厉害的用例设计方法或者看看几个PRD，会写几行代码就能够制定出来的，测试人员制定一个真正的测试策略应该至少满足以下几点：

• 丰富的项目经验
• 拥有不错的代码能力和架构思维
• 经历过大项目复杂业务，对业务有深入的理解
• 深入正确的理解PRD和项目架构
• 了解项目在企业中的定位
• 了解项目需要哪些团队来合作
• 测试团队目前资源分配的现状
• 等等
  

只有一个测试人员同时了解这些的情况才可能真正的去制定所谓的测试策略，所以无论我们说的研发技能还是测试用例设计方法还是沟通交流能力等等这一切都是制定测试策略的基础。对测试人员真正重要的就现在而言真的就是一个综合的能力，而不是单独的某一个技能。

894452087

顶一下

梦想家

赞

草帽路飞UU

5.软件测试的职业应该怎么规划
Monkey：其实这个问题很大，而且其实之前我写过一篇关于这个主题的文章了，但实在太露骨了，不方便在这里放出链接。同样的，我也不想很官方的去回答这个问题。所以我就简单的接地气的来回答下吧。无论你是从一开始就做软件测试的还是半路出家，其实要真能规划出来一条很成功的路，那个人只可能是你自己，不会是其他人。所以我只能给点建议：

行业浮躁，不要太在意身边的噪音和鸡汤，一时的困惑和热血成不了大事，踏踏实实的去打好基础，学习技术，是你的终究是你的。
远离QQ和其他社交软件。
不要死学技术和死看书，要懂得多和人交流，积累自己的人脉和人际圈。
不要只看测试或者技术相关的书籍和文章，突破公司和行业带给你的条条框框。
好记性不如烂笔头。
学会使用互联网这样一个武器。
好好学习营销。
一定要使用任务管理软件来管理自己要做的事情。
强大自己的肉体和思想。
做任何事情之前要去了解，不要道听途说。同样的，也不要优柔寡断，现在流行一言不合就干，实践出真知。
相信你会成功的。

梅子：我认为，“职业发展规划”，大多是不靠谱的，测试也不例外。

我们只要百度或者知乎下，就能找到成千上万的对测试职业发展的建议，这些建议基本都能总结为如下两点：

先手工测试两年，然后去做自动化或者去做管理，因为手工测试是最没有前途的。
做管理的路线都是，3年一小升，5年一大升，8年就要是第一把手大主管了。
这个标准，光是让人看到就会觉得很有压力。很多朋友都会拿这个标准和我聊天，觉得很自己现在职业发展遇到了瓶颈，公司无法给自己充足的发展空间，自己又找不到合适的跳槽的机会，感到特别的焦虑，郁闷，看不进书，吃不下饭，问我该怎么办。这时我都会拿我自己来举例：我测试了十年了，但我每天还是会花几小时来做那些大家觉得low的手工测试。我在公司的测试职位，说白了就是基层班长。我问他们，你觉得我low吗？他们说不觉得啊，感觉你混得挺好的啊。然后我就说，但这就是我的真实的状况，如果你觉得我混得还行，那你到我那时一定比我混得好，所以我们先不要焦虑、郁闷。然后我们仔细来思考思考，我们前面认为的职业发展瓶颈是真的存在，还是我们对“职业发展”有不正确的认识？——职业发展就一定要做不同类型的事情吗？职业发展title就一定要变化吗？如果客观环境不能满足，我们就只有不断的跳槽这条路吗？

有一个“秘书九段”的故事也许会给我们一些启发：

总经理要求秘书总经理要求秘书安排次日上午九点开一个会议。在这件事上，通知到所有参会的人员，然后秘书自己也参加会议来做服务，这是“任务”。但我们想要的结果是什么呢?下面是一至九段秘书的不同做法。

·       一段秘书的做法: 发通知——用电子邮件或在黑板上发个会议通知，然后准备相关会议用品，并参加会议。

·       二段秘书的做法: 抓落实——发通知之后，再打一通电话与参会的人确认，确保每个人被及时通知到。

·       三段秘书的做法: 重检查——发通知，落实到人后，第二天在会前30分钟提醒与会者参会，确定有没有变动，对临时有急事不能参加会议的人，立即汇报给总经理，保证总经理在会前知悉缺席情况，也给总经理确定缺席的人是否必须参加会议留下时间。

·       四段秘书的做法: 勤准备——发通知，落实到人，会前通知后，去测试可能用到的投影、电脑等工具是否工作正常，并在会议室门上贴上小条:此会议室明天几点到几点有会议，会场安排到哪，桌椅数量够用吗？音响、空调是否正常？白板、笔、纸、本是 否充分？我的准备，在物品上，环境上，可以满足开会的需求了吗？

·       五段秘书的做法: 细准备——发通知，落实到人，会前通知，也测试了设备，还先了解这个会议的性质是什么?议题是什么?议程怎么安排，然后给与会者发与这个议题相关的资料，供他们参考(领导通常都是很健忘的，否则就不会经常对过去一些决定了 的事，或者记不清的事争吵)。提前的目的是让参会者有备而来，以便大家开会时提高效率。

·       六段秘书的做法: 做记录——发通知，落实到人，会前通知，测试了设备，也提供了相关会议资料，还在会议过程中详细做好会议记录(在得到允许的情况下，做一个录音备份)。

·       七段秘书的做法: 发记录——会后整理好会议记录(录音)给总经理，然后请示总经理会议内容没有问题后，是否发给参加会议的人员，或者其他人员。要求他们按照执行。

·       八段秘书的做法: 定责任——将会议上确定的各项任务，一对一地落实到相关责任人，然后经当事人确认后，形成书面备忘录，交给总经理与当事人一人一份，以纪要为执行文件，监督，检查执行人的过程结果和最终结果，定期跟踪各项任务的完成情况，并及时汇报总经理。

·       九段秘书的做法: 做流程——把上述过程做成标准化的“会议”流程，让任何一个秘书都可以根据这个流程，复制优秀团队，把会议服务的结果做到九段，形成不依赖于任何人的会议服务体系。

这个寓言（或者说鸡汤）对我的影响很大，我认识到，我们对职业发展的理解，不应该仅仅限制在做的事情的变化，或者说title的变化，“段位”的提升也是一种发展，而且是我们更应该追求的东西。

这个思想改变了我的工作思路。我每接到一个工作，不管是大家看得上还是看不上的工作，我追求的都是如何提升做好这个工作的段位。比如有段时间我做性能测试，我先研究了通用的测试方法学，掌握了工具，然后结合测试的硬件、架构、场景设计出了性能测试方案，然后把测试项目自动化，然后我还对这些所有的测试项目做了数学建模，让模型可以得到我们产品任何配置下的性能值，最后还把这个做成了个工具提供给前场人员，方便他们确认产品是否可以满足用户的性能需求。我不停的在探索如何提升性能测试的段位，我学到了大量的知识，每天都觉得很开心。之后我又被安排做用例设计的事情，自动化的事情等等，我都是用这样的方式去工作，我真的没有感到发展的瓶颈。

我觉得真的没有必要非常刻意的去规划自己的职业，但我们需要不断的去发展自己，挑战自己可以做到的深度，去感受自己的成长——有什么比自我成长更棒的呢。有时候一些成长点看起来是孤立的，但是有些看似无关的事情，总有一天会联系起来，为你带来巨大的能量，那时即便我们从来没有去刻意追求职业发展，我们的职业发展也一定不会错的。

最后谈一下如何确定目标。我的建议是把目标制定为一个“以结果为导向的周期性的任务”，这里的结果一定要有明确的自己的输出，比如10篇读书笔记，2篇分析报告，或者是做出什么工具。例如三个月主要参考XXX书，掌握python基础，做出一个XXX的小工具。

最后祝你的计划成功。

草帽路飞UU

3.测试前移，无专职测试，内测，灰度发布，测试开发等会是测试未来的发展趋势么？
梅子：我认为这些活动一定会是测试未来发展的一个趋势。

其实“质量活动提前”、以“内测、灰度发布等手段来替代传统测试”等这些新的测试实践，最后都会导致“无专职测试人员”，“无专职测试人员”或者说“专职测试人员”会变少，会是未来测试的一个发展趋势，但这并不等于未来就“没有测试活动”了，相反，测试活动会分散到产品开发活动的各个阶段，产品经理，开发，运维都要进行各自层面的测试（例如验收测试由产品经理来进行，功能测试会由开发来进行），测试思维、测试方法、自动化测试等不再是测试的“独有”的能力。而对那些保留下来的少数的专职测试人员，可能会更关注：

制定整体的测试策略、落地。
测试工具或平台的支撑。
承担那些对测试技能要求非常高的测试。
测试方法的研究和改进。
测试人员也可能会同时服务于多个团队，形式可能会是服务，或者是解决方案。

Monkey：恩，首先我也认为这是一定的发展趋势，那么就问题先一个一个来谈谈吧。

测试前移是很多年前就开始讨论的了，其本质更多的是希望测试人员能够更早的介入项目，更深的层次的原因其实就是希望有一个拥有很强质量意识的人来在前期给项目更多的建议，甚至能够将质量意识带给大家，那么测试则是最佳人选。国内早几年的项目中，项目经理和研发在项目早期讨论阶段都认为不需要测试的，而只有在产品开发完毕之后才需要测试进行产品功能的验证和寻找缺陷，这当然是不对的。但这也是进步必须的一个过程，现在来看这样的情况应该已经不存在了。

无专职测试这个事情我是想在这里好好强调下的，行业说的无专职测试绝对不是大家想的那种没有测试人员，哪怕是国内的知名公司也不是这样的初衷。所谓无专职测试无非是以下几种情况：

的确没有专职的测试岗位，但有外包来做一些基本的测试工作。
的确没有专职的测试岗位，但测试工作还是继续的，验证工作也平分到了其他各个人头上。
由于团队负责产品的特殊性，比如一些中间件或者sdk，最终判断不需要专职的测试岗位。
有专职的测试人员，但测试已经不做普遍名义上的测试工作了，所以会宣称没有专职的测试人员。
某些团队或者公司由于产品的特殊性，自动化能够覆盖比较多的场景，当自动化成熟了之后，测试人员就会转到产品或者研发团队，此时就没有了专职的测试。
所以综上所述，我认为有没有专职的测试人员并不重要，重要的是选择适合自己团队的测试策略，同时行业大众看一个观点的时候一定要明白上下文，不要断章取义，弄的人心惶惶。

灰度发布在移动互联网中是使用的最多的，众测和bug bash还有A B测试也常用。灰度测试分成线下灰度和线上灰度。线下灰度其实就类似于bug bash，灰度机制本身其实就是为了让产品在真正上线之前暴露出更多的问题而存在的。而在移动互联网中由于企业中没有真正用户群那么多的Android和iOS测试机，所以灰度也就变得更加重要了。

最后来说下未来发展吧。在我看来测试未来的发展分成x,y,z三个轴：

·       x轴：横向扩展。现在无论是功能测试还是自动化测试都是普遍存在于所谓“研发过程中”的测试，但测试真正的在“项目开始之前”和“项目上线之后”这两个阶段产出的其实特别少。项目前期的时候测试可以基于场景自动生成测试用例，项目上线之后可以利用线上脱敏的数据来做一些用户行为的回放功能，同时如何利用线下线上的数据，通过不同的维度达到不同的目标等，这些都是测试可以在未来大有可为的地方。

·       y轴：深度扩展。所谓深度扩展指的就是将现有的测试活动更高效的去执行。比如上面说到的自动根据业务场景或者脑图生成测试用例就是一个案例，再比如Android与iOS上面已有的Monkey测试结合深度学习就可以出现更智能和有效的遍历。测试活动本身在深度上还有很多可挖掘的地方。

·       z轴：高度扩展。将现在的测试定位的活动扩展到质量定位的活动，那么测试会发现很多事情单纯靠自己团队是做不了的，那么这个时候我测试往往就是一个主导事情的角色，前提是测试必须很清楚的知道整个扩展高度的过程中需要什么团队参与，这些团队分别要支持什么，产出什么，然后最终满足质量的一个需求。否则只会造成反感然后被吐槽不专业

总而言之，我觉得大家根本不用担心未来，因为你只要一直保持学习，对新技术有着敏锐的嗅觉，多多保持与外界的交流，那么无无论未来怎么样，你总会有一席之地。

4.软件测试到底可以做几年？
chat主持人：两位可以聊聊，软件测试工作可以做多少年吗？

梅子：好，这其实是个很难回答的问题。我做了11年的测试，做过测试管理，最多的时候也只是一个二十多人的异地的团队，也做过现在好多人都还没有搞明白的测试架构师。我也觉得我可能会再10年测试，但在去年我转岗了。但对我自己来说，我也不介意又做回测试。测试究竟可以做多少年，我觉得是可以做很久的。

关键是，你要有你的个人价值。而且不是你自己说自己有价值，而是你的团队，你的领导都认为你有用。

Monkey：要我说吧，这个问题根本不是大家关心的，大家关心的应该是这个问题——”软件测试到底可以赚多少钱？是不是可以比开发赚的多？”。很多时候我们坚持不下去的原因有很多，但如果收入高于我们的期望的话大多数人还是会选择忍的，毕竟真的转行的话成本还是很大的。所以换句话来说，转行很大一部分原因就还是收入的问题。关于测试收入我不是很想在这里去描述了，我这里的确应该有很多大家关心的敏感信息，如果有可能我更希望大家众筹让我来写一篇专门关于测试收入的文章。

梅子：Monkey提到了收入的问题，这是个很好讨论点，也是大家很关心的内容。我所遇到的优秀的测试人员，薪水和优秀的开发的薪水是不相上下的，但是能够拿到和优秀的开发相当的薪水的优秀的测试人员，换句话说老板愿意出这个价的测试人员，真的非常少。

很多同学可能会说，看吧，测试的发展就是不如开发吧。我想，虽然我认同开发和测试的工作都是创造性的工作，但客观的说，开发工作的创造性是“开创性的”，是从0到1的，而测试工作的创造性是“探索式的”，是来确认1是否真的是1。从老板的角度来说，测试并不能直接产生价值，而是一种投资。除非老板已经不差钱了，否则他一定会把资源往开发这个方向倾斜，这是最基本的资本法则，测试要能够理解并接受这点，不要总要和开发比较，把精力消耗在自怨自艾上，真的没有意义。测试应该更多的去思考如何提高自己的价值，而且这个价值还要是老板眼中的价值，这样老板才愿意付给你相应的薪水。

其实测试可以做几年并不重要，重要的是“继续做测试”，或是“不做测试了”，是测试者自己主动的选择，而不是被动无奈的选择。