软件测试职业发展的 二个面你知道多少？

海鸥一飞

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

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

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

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

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

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

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

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

第一阶段：我认为测试思维就是测试如何去分析被测对象的视角，可以概括为测试类型（性能测试、可靠性测试、兼容性测试这种）和功能交互分析（就是把很多功能放在一起考虑）。这个测试思维能够帮我系统的分析被测对象，让我可以很容易的就比别人发现更多产品的问题，而且问题还蛮有价值的。

第二阶段：慢慢的我发现我真的没有必要对所有被测对象都进行那么全面的分析，有的功能特性好像不怎么测试也可以，有些功能测试却真的需要非常深入细致的测试，并且哪些需要详细测试，哪些不需要详细测试是动态变化的，我认为测试的核心，就是要在项目中把握这种动态性，有策略的进行测试。我开始注意项目的成本，思考如何用最小的成本来获得最好的测试效果。我觉得测试思维也许并不应该只是狭义的理解为测试中才需要考虑的思维，测试思维是一种探索式的思路，它不仅适合于测试，也适合于产品的其他角色。

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

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

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

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

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

Monkey：这个的确是个好问题，但我觉得很多会问这个问题的主要问题在于自己根本就没有怎么做过测试，跟风问题，对测试策略的理解太浅。在我看来测试策略其实已经是一个很高等级的词汇了，能做到这个根本就是屈指可数，其根本就和所谓的开发技能不在一个水平面上，所以不能去做一定的对比。行业中很多次拿出来对比在我看来就是大家的理解太过浅层次。

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

最后来谈下测试策略吧，在我理解的测试策略并不是你掌握了一个很厉害的用例设计方法或者看看几个PRD，会写几行代码就能够制定出来的，测试人员制定一个真正的测试策略应该至少满足以下几点：
拥有不错的代码能力和架构思维
经历过大项目复杂业务，对业务有深入的理解
深入正确的理解PRD和项目架构
了解项目在企业中的定位
了解项目需要哪些团队来合作
测试团队目前资源分配的现状
等等
只有一个测试人员同时了解这些的情况才可能真正的去制定所谓的测试策略，所以无论我们说的研发技能还是测试用例设计方法还是沟通交流能力等等这一切都是制定测试策略的基础。对测试人员真正重要的就现在而言真的就是一个综合的能力，而不是单独的某一个技能。

3.测试前移，无专职测试，内测，灰度发布，测试开发等会是测试未来的发展趋势么？

梅子：我认为这些活动一定会是测试未来发展的一个趋势。
其实“质量活动提前”、以“内测、灰度发布等手段来替代传统测试”等这些新的测试实践，最后都会导致“无专职测试人员”，“无专职测试人员”或者说“专职测试人员”会变少，会是未来测试的一个发展趋势，但这并不等于未来就“没有测试活动”了，相反，测试活动会分散到产品开发活动的各个阶段，产品经理，开发，运维都要进行各自层面的测试（例如验收测试由产品经理来进行，功能测试会由开发来进行），测试思维、测试方法、自动化测试等不再是测试的“独有”的能力。而对那些保留下来的少数的专职测试人员，可能会更关注：
制定整体的测试策略、落地。
测试工具或平台的支撑。
承担那些对测试技能要求非常高的测试。
测试方法的研究和改进。
测试人员也可能会同时服务于多个团队，形式可能会是服务，或者是解决方案。

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

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

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

4.软件测试到底可以做几年？

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

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

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

梅子：Monkey提到了收入的问题，这是个很好讨论点，也是大家很关心的内容。我所遇到的优秀的测试人员，薪水和优秀的开发的薪水是不相上下的，但是能够拿到和优秀的开发相当的薪水的优秀的测试人员，换句话说老板愿意出这个价的测试人员，真的非常少。
很多同学可能会说，看吧，测试的发展就是不如开发吧。我想，虽然我认同开发和测试的工作都是创造性的工作，但客观的说，开发工作的创造性是“开创性的”，是从0到1的，而测试工作的创造性是“探索式的”，是来确认1是否真的是1。从老板的角度来说，测试并不能直接产生价值，而是一种投资。除非老板已经不差钱了，否则他一定会把资源往开发这个方向倾斜，这是最基本的资本法则，测试要能够理解并接受这点，不要总要和开发比较，把精力消耗在自怨自艾上，真的没有意义。测试应该更多的去思考如何提高自己的价值，而且这个价值还要是老板眼中的价值，这样老板才愿意付给你相应的薪水。
其实测试可以做几年并不重要，重要的是“继续做测试”，或是“不做测试了”，是测试者自己主动的选择，而不是被动无奈的选择。