天猫技术专家：测试十二年，六道轮回后的初心可否找回

本期做者简介：高翔，天猫技术部测试开发专家。

好久没写文章了，以前测试十年，也是在本身有变化的时候 ，强迫本身写了一篇文章，说了本身的困惑和痛苦和思考，也获得一些共鸣。如今测试十二年了，至关于一个轮回，也有一些新的痛苦和感悟，趁还在这个圈子里面，记念一下，固然了，YY比较多，干货也很少，反正记念下，或许我是真的不太可能写测试15年的文章了。你们有任何问题，欢迎讨论，欢迎吐槽。

其实写这篇文章以前，我一直是犹豫的，感受写不出啥花样来，一是由于水平有限，另外就是由于测试这个圈子里面说不出啥新花样出来，仍是老生常谈的那些，并且不一样水平的读者想看的内容也不同，很难写的深刻人心，反正真的差点放弃了；可是我心里是渴望的，想说些那些不同的，了解个人人都知道，我是不甘平庸的，是有本身的思考和底线的，不少时候可能被现实战胜，可是我还会站起来，继续战斗。

12年 / 这两年我干了啥

我是一个很怀旧的人，简单说说这2年干啥了，这两年作天猫新零售的业务，这是一个新业务，你们应该理解新业务的背后的意义吧，我这里就不赘述了，团队成员都很是给力，拿到了不错的结果；其实你们都知道，测试在一个业务的发展过程当中，本身能起到了哪些做用，无论这个业务是发展了多长时间，咱们都是会通过三步走，不少时候咱们就是在平衡这三步的比例和深度。

【质量】

测试人员核心的产出，发现bug，提高产品质量和用户体验，尽可能少的把bug遗漏到线上去，让用户或者监控发现；是的，这两年来，对于一个新业务来讲，咱们在这么多、这么变、这么复杂的需求和迭代项目中，咱们拼劲了全力，新业务的质量有了稳步的提高，线下bug的数量、线上bug的数量和趋势、系统的稳定性等各个角度来看结果，都说明了咱们真的不错，是的，这是咱们的基本工做，也就那样吧。

【效率】

对于一个新业务，对测试效率的要求也是更加考验，新零售是连接线上和线下、商家和消费者之间的桥梁，咱们在测试效率上也是面对很大的考验；是的，这两年来，对于一个新业务来讲，咱们在这么多、这么变、这么复杂的需求和迭代项目中，咱们继续拼劲了全力，新业务的研发效率有了稳步的提高，开发自测质量提高、初级bug、ISV对接效率、全网回归效率、10+测试数据工具等各个角度来看结果，都说明了咱们真的不错，是的，这好像也是咱们的基本工做，有了一些进步，还不错的，不过也就那样吧。

【技术驱动业务】

你是开玩笑吧，是的，我没有开玩笑，对于测试来讲，驱动业务简直是难如登天，开发是天生的，测试是后天养的；天猫智慧门店在线下业务的拓展过程当中，咱们对每个商家、每个线下门店都会有质量的责任，咱们经历过双11，经历了痛点。是的，这两年来，对于一个新业务来讲，咱们在这么多、这么变、这么复杂的需求和迭代项目中，咱们再次拼劲了全力，咱们在商家业务配置检查、商家ISV验收、线下门店预演等一系列的结果上来驱动天猫新零售商家和门店的规模化发展，我以为咱们是技术驱动业务了，为业务高速发展提供了保护伞，都说明了咱们真的不错，是的，这好像也多是咱们的基本工做，有了更多进步，还不错的，不过好像技术含量比较低，扩展性通常，其实也就那样吧。

好吧，刚刚都是自诩，看不下去了吧；其实我想说的是，这两年，咱们作的还不错，各个层面都有结果，特别是第三个层面的，有的时候是可遇不可求的，整体上团队能力和技术都有提高，可是在某些结果上的确不让人满意，咱们的一些测试大佬们既要、也要、还要、反正什么都要，你要是哪一个没有，很差意思，只能这样了。说实话，我有时候也能理解他们，真的理解。

12年 / 国内测试都在关注啥？

这个话题有点大，其实真的不敢写，可是无知者无畏，虽然在阿里干测试9年多了，自我感受蛮了解的，比起”阿里测试都在关注什么”，我以为我更敢写这个，其实也有点心虚的。这些年，我一直专一在咱们本身的业务和系统、测试问题，这些细节很是多，咱们的目标和规划都围绕这个来，很是接地气；是的，说这个就说明我对国内测试在发生什么，在追求什么，其实对细节了解很少，可是在微博、在大会的主题、在相关的ppt和群讨论中，仍是能感知到一些的，接下来就说说，不少理解不必定对和全面的，欢迎你们补充讨论。

在正式的说以前，你们回想我以前说的一句话，咱们干测试的，不少时候就是在平衡这三步的比例和深度，在质量、效率、驱动业务上不断的调整策略和战术，根据不一样的业务阶段、根据不一样的目标、根据当前的大事件驱动等。

咱们最怕干的是就是平衡，由于平衡的好，前途光明，平衡的很差，万丈深渊。你们都知道咱们干测试的，杂活特别多，不少事情都须要投入一点，不少事情作起来不少人看来也没有亮点，那咱们不少时候就是在不断的平衡一些事情，可是无论怎么样，咱们的目标仍是比较聚焦的，就是对应本身的业务和开发技术，以及将来的业务发展，在质量和效率上如何作的更好，成本上愈来愈低，解决方案也愈来愈有技术含量。

你们都知道，不一样行业对应测试的要求是不同的，那么测试技术和要解决的问题也是不同的，可是有几个套路实际上是差很少的，大致上分这几个方向。

1. 基于模型的测试：这块领域不少人不太熟悉，并且在不一样的行业的实践和效果是差别比较大的，可是不可否定这个方向带来的价值，在通信、IOT、嵌入式等领域都有很是多的实践，效果也不错，我认为是测试前移比较重要的一块；可是不少人对于这块只是基本的了解，不少时候都有可能直接放弃；最后的结果，多是咱们的开发同窗先开始业务建模，先开始各类模型抽象，提高开发效率，而后再到测试的模型和效率提高，很显然，咱们是被动的，并且不少时候咱们错过了一些风景，可能感知不到呢。
2. 可测试性：这块话题，实际上是你们聊的比较少的，由于不少方面是偏理论的，真正落到实践到项目过程当中，和业务项目的技术架构、技术能力、技术人员思惟都有比较大的关系；而这块对于大公司是比较看重的，特别是微软、google级别的重视技术体现的公司，咱们做为测试开发工程师的重点是从开发角度去作测试工做，会把主要精力投入在系统设计和编码阶段。开发人员关注某个功能最优实现方案，而咱们测试要有总体产品的视野。因此测试在设计阶段，帮助开发人员完成代码复用和模块交互方面的设计，在设计review的时候，保持目的性：完整性、正确性、一致性、设计、接口与协议、测试（可测试性）。还有一个明显的，就是作这块，须要沉下心来，慢慢积累和思考，对于不少急功近利的公司来看，绩效和沉淀方面难说了，并且这块的确是咱们测试的短板，接下来我以为仍是有可能会从新重视起来。
3. 自动化测试：这个是很明显的提高测试效率的手段，这里面不一样的行业的自动化测试策略和框架也可能不同，可是的确是互联网企业发扬光大的，包括分层自动化测试实践，其效果也是很是显著的，无论是什么行业领域，都是逃不掉的；无论你是采用流量录制和回放、页面录制和回放、关键字驱动、数据驱动的自动化脚本运行，这些经验和沉淀目前也是国内的公司强烈关注的，为何非要关注这块，说实话，这些能带来XX平台的沉淀，XX平台的开发和技术品牌、XX平台的能力透出；若是咱们加上功能依赖分析、系统依赖分析、代码覆盖率等各个因素的影响，咱们能够加上精准测试的方向，进一步提高自动化测试效率，这块上国内有一些公司都在沉淀和探索，也有一些不错的结果。
4. 灰度&监控：这块话题，是测试右移的核心思路，基本上也是互联网和移动互联网企业的测试策略的标配，测试和开发一块儿共建，来增强灰度的落地，监控覆盖率和提高；可是测试在其中的体现到底多少，价值多少，这个就很难说了，咱们的沉淀的方向究竟是什么呢？咱们开发有没有加上这块的监控、开发为何没有加上这块的监控、咱们测试是否是要监控开发是否加上了某块的监控、咱们测试是否是要来Review开发是否加了某些监控、监控的方法和策略的沉淀开发和测试的关系在哪里。这也是测试本身没办法的策略，不少时候咱们不怕出现线上bug，咱们就怕不能快速fix bug；咱们就怕咱们的系统监控没有发现这样的线上bug，反而让客户主动报了相关线上bug；可是这个策略是否是惟一的，依赖它的程度究竟是多少，咱们测试线下须要作到什么样的程度，又是一个平衡的问题了，这块上，咱们能够再思考多一点，想一想测试在这里面的定位是什么，是和开发绑在一块儿，分享系统稳定性的结果，仍是思考它对于测试体系的位置到底什么样的。
5. 大数据测试：有两种状况，一种是大数据产品的自己的测试体系的建设，包括常态化的测试策略和大数据的数据监控策略，这里面的监控多是测试工程师的重点产出；另一个状况是利用大数据的手段来提高测试效率，来监控线上质量，反过来驱动线下测试覆盖率和效率。第一个应该有比较成熟的体系了；第二个也是在探索阶段，对于产品特色、体系架构有必定关联，同时配合多个手段来提高，若是加上某些机器学习、和算法、精准测试策略、可能会包装成AI智能化测试，解决大数据量状况下的功能测试问题。可是这方面可能不只仅是测试这个领域，包括运维和体系化架构设计等一个闭环的打造，测试其中启到什么关键的做用，仍是值得期待的。
6. 探索式测试：4-5年前比较火，目前基本上是冷却了一大半了，如今是邰晓梅老师一我的独立坚守着，在国内各个公司和线下活动不断的布道和实践，目前来看，国内的不少公司都有了解和参与，在测试的自己价值上，测试自己的能力建设上仍是有不少的进步的，这些对于持续在测试能力上有特定思考(包括和敏捷测试的结合)的同窗，他们的体感会很是强，可是对于一些开发技术为核心套路的可能以为偏理论，不够技术含量，很难继续深挖，很难造成平台化效应，是的，我本人也是最近几年都没有在这方面进行学习和探索，非常愧疚和遗憾，但这就是现实。

整体上来看，国内测试技术和方向也是解决部分的问题，还有些多是大趋势中找到本身的位置，到底有几分是本身独立思考的，有几分是在真正的研究和探索的，目前看到的很少，不少都是在围城里面走套路，你们一块儿走，反正现实有不少的问题须要解决。另外就是不少行业领域里面的测试技术探索，好比游戏测试领域、IOT领域、AI领域、区块链领域、三方生态领域等。

12年 / 国外测试在走什么方向？

好了，咱们的全部测试技术和方向的探索，国外基本上前几年都已经开搞了，有些领域可能领先十几年，有些你们都在同步探索阶段。咱们须要更大视野去看国外测试技术和体系的发展，不只仅是某个框架或工具的角度去看，甚至不是某个行业的测试解决方案来看。咱们知道某一个技术的开始和发展，不只仅是和企业的工程领域有关系，不少时候和学术领域有关；国外测试领域里面包括不少学派，它们分别表明了不一样的测试领域的思考和沉淀，不只仅是不一样的测试类型，还包括不少测试理论上的思考，包括自动化测试学派、质量保障和规范学派、上下文驱动学派、开发测试学派等，每一个学派都有本身主张的观点、方法、实践方案、工具体系等，并且每一年都是有序的讨论和发展（有那种百家争鸣的感受，在工程和学术领域同步开花结果）；在这里，咱们在看看一个很明显的区别点，国外的测试大会上和国内的测试大会上的topci就能够看到一些区别了。

这里面有一些共性的topic包括敏捷测试、Test in ops、性能测试、监控、安全测试、自动化测试、国际化本地化测试；可是国外的不少topic是强调测试自己的思考的，包括测试信息输入论、探索式测试、基于风险的测试、测试管理、测试策略和计划、某领域的测试设计方法。这里，不少人其实都看到了不一样点，国内这方面的沉淀相对来讲少不少，不少人都不感兴趣的，以为都是理论的多，对个人技术没有帮助。

另一个层面来看国外测试就是测试大师们，国内从事一线测试工做的工程师基本上10年如下的，10年以上的基本上都是管理的、或者走其余路线了；持续在某个领域进行测试技术体现的研究在国内很难找到，可是也是有的（陈能技、朱老师、领测贺老师、CSATQB周老师、阿尔卡特郑老师、顾问邰老师等等，这些老师颇有可能和其余些人观点很是冲突，互相不被承认），总体上来看仍是缺乏不少的，大部分人对于测试生涯、测试价值、测试发展、测试方向都有一种悲观的预感。反看国外测试工做10-20几年的测试大师们很是多，他们在测试自己价值上进行了很是多的思考和沉淀，一点点造成本身的思考和理论，一点点去实践本身想要的测试方式和思路，感兴趣的同窗能够去多看看国外的测试论坛，你确定会看到不同的测试理解的，好了，我也很久没看了，赶忙补课去（对绩效啥好处都没有，我真的要看？）。

12年 / 测试生涯还剩多少？

咱们先讨论一个热门词语“测试开发工程师”，你们能够思考下为何不叫"开发测试工程师"呢？你们都知道的是将来开发测试是融为一体的，不少一些外企也作到了，开发测试的融合，互相backup，互相对产品质量和稳定性负责，其乐融融的感受。说实话，最近几年我对外企里面测试的理解很少，这里不敢多说，怕说错了；可是国内的测试里面，你们其实都能感受到，那就是咱们更多的在关注咱们是否是会写自动化测试脚本，会写java代码，懂不少开发技术，作过不少平台或工具等。这里面的技能重要不重要，固然重要了，可是不是咱们考察一个测试开发工程师惟一的思考点呢；咱们的批判性思惟、咱们的打破砂锅问到底的精神、咱们的错误猜想的思路、咱们的细心专注的用心、咱们的异常逻辑判断的方法、咱们的流程优化的意识等等，这些咱们到底有多关心呢，很差意思，不怎么关心，由于干了这么久，干了这么多，看不到产出、说不清投入、显不出能力。

咱们再分析下，咱们测试开发工程师要干的事情到底哪些呢，以前就是说过了，保障产品质量和提高研发效率，这两块咱们的投入的比重呢，这两块咱们看结果的思路呢，这两块咱们要沉淀的方向和方法的抽象呢？这些说实话，你们看到的都不多，我本身也是同样。说直白了，将来测试工程师会愈来愈少，质量不少时候都是开发去负责、或者其余灰度监控手段去避免，那意味着咱们在质量上的投入会愈来愈少，在效率上投入会愈来愈多，其中的道理你们都应该理解的吧。

当咱们第一眼要追求的是效率问题时，咱们更多的关心开发技术的提高，以及开发技术在解决效率问题时的应用，由于这些价值是显而易见的，是被高度承认的（对于无线适配测试平台，阿里每一个大BU都有，起码6-7个平台，可是80%的功能是同样的）；咱们打着效率提高的口号，彷佛也能解决质量的问题，可是扪心自问，真的能解决吗？你们知道本身产品的用户是怎么用咱们的产品的吗，咱们的用户遇到了哪些问题吗，天天都暴了哪些线上bug给你吗，其实不少时候，咱们都是不敢正视这些问题的，由于咱们会被完全战胜，太丢人了啦。好了，我知道了，测试不可能测试全面的，那样成本也是很是高的，咱们仍是快速发布第一位的。由于咱们不能真正的去面对这些线上bug，因此你们有真正的去思考线上bug遗漏的真正缘由吗，有多少是从测试设计角度去思考的，更可能是从监控、fix效率等角度来增强和避免。

当咱们去增强测试工具的开发、测试平台的建设、监控平台的建设时，咱们测试开发工程师还剩下什么？咱们只能作这些事情吗？难道就由于这些能拿到好的绩效、能体现你的技术能力、能快速晋升？好了，不能说太多了，这里有可能会带来吐槽。其实我不反对这些事情的价值所在，我只是想一想咱们在干这些事情的时候，有没有去思考测试自己的核心定位，测试自己的经验教训究竟是什么？

12年 / 六道轮回后的初心是什么？

你猜对了，前面一大堆都是废话，如今才到正题，测试的目的和初心究竟是什么，咱们为何要干这件事情，是用户须要咱们干，是系统须要咱们干，那咱们干到什么程度呢，咱们究竟是作测试，仍是作校验，仍是作验证，仍是作探索；每一个人心中都有本身的理解，可能不同，不要紧，有一点你确定没法否定，无论你是谁，你确定是某个产品的用户，你都确定遇到这些产品的bug，你均可能是傻笑、生气、发飙、投诉、卸载、放弃等，而后没有了，没有了。

前面也是谈了很是多了，关于测试核心工做产出上，有不得没必要需要干的、有可干可不干的、有很是想去干的、有老大们逼着去干的、有你们都在干的我也想干的；在这里，我想谈谈我我的认为的咱们可能忽略的一些问题，你们听到测试技术或测试方法时，第一能想到的是什么呢？若是说到测试设计方法时，你第一能想到的又是什么呢？若是说到测试架构师，你第一能想到的又是什么呢？若是说到项目测试负责人，你第一能想到的又是什么呢？

建议你们先看看《google测试分享-SET和TE》咱们是测试开发工程师的title，可是咱们干的什么活呢，基本上把SET的工做和TE的工做合二为一，放在一我的的身上，你们其实也看到了SET和TE的技术和要求是不同的，咱们测试团队的测试开发工程师都能很好的具有SET和TE的能力吗，咱们真正的测试工做的初心究竟是什么呢？咱们的测试开发工程师都能在产品的测试过程当中发挥这么多的做用吗？在技术突飞猛进的时代里面，开发都在全栈了，测试也是该全栈了，不只仅测试类型上，在不一样的领域测试上也有这样的要求，可是这里面有一个基本的基石，那就是如何更好的去测试，去想到测试什么地方，去抓到那些隐藏的bug，去识别到那些隐藏的风险。

好了，言归正传，通用的基石有那么几块，最核心的固然是使用什么方法去测试了，知道测试哪里了，因此测试设计是一切测试活动和技术的基础及前提; 同时，咱们须要考虑需求文档不足下的测试设计怎么作? 咱们还须要思考测试模型该怎么创建，并且测试模型分为测试方法模型和业务测试模型，全部设计都是基于模型的，咱们也知道好的测试设计能提升测试执行效率，可是咱们如何有一个好的测试设计呢。咱们先从你们最熟悉的黑盒测试方法来讲，你们都熟悉的等价类划分、边界值分析等测试方法，不少人都说一个正常的工程师 都能在一个下午学会和理解大部分的黑盒测试方法。 对此观点，我是不敢苟同的，这就讨论到这些黑盒测试方法的深度的问题了（这个话题以前就是打架无数了，好像最后咱们没输，可是也没赢）。

（1）学会和理解测试方法的使用步骤是很简单的，可是真正的在项目需求中应用起来可不是一朝一夕的。这就比如给你一张扑克同样，高手就能拿它杀人，通常的人能作到什么程度呢。 这个也很像有些人能发现你不能发现的bug同样。至于缘由有不少，具体看在淘两年的blog。

（2）谈谈我本身的感想吧，我本身在工做前两年也是认为这个黑盒测试方法一下午就能够学会的，找几个例子试着使用下，感受本身掌握到这些黑盒测试方法，可是后来我看过不少这些测试方法的背景以及应用的注意点后。我发现本身真的是了解了一些皮毛，没有深刻的了解。对于个项目需求，如何快速且完整的应用这些黑盒测试方法设计出很少很多的测试用例，这个须要的经验的积累，也就是你测试价值的核心体现。

（3）屡次和其余公司的测试同窗交流，发现不少同窗说本身都说本身是工做2-3年的人，已经遇到瓶颈了，感受测试很单调和无味。我给的建议其实很简单，那就是真正的理解和掌握全部的黑盒测试方法。怎么来验证呢，我本身就是这样：给你一个白板，你能把全部测试方法的5W2H(What、Why、When、Where、Who、How、How Much)都能很是清晰明了的演讲出来，记住是不须要参考ppt或其余资料的状况下。

就像火影里面的鸣人同样，他只会螺旋丸这个核心的攻击忍术，可是在扩展其余忍术以前，他会把这个忍术的深度发挥到机制，从而研究出威力更强的超大螺旋丸、超大玉螺旋丸、风遁螺旋丸等等。

你们再想一想，这些黑盒测试方法都是20年前国外的测试大师们发明的了，然而20年后的今天咱们在学习测试方法的理论时仍是这些，这是为何呢？这里面有几方面的缘由，一方面咱们的测试同窗不少是非科班毕业的，自己技术能力和逻辑能力相对来讲薄弱，这样在测试生涯过程当中更加没法变幻出更多的测试方法，另外一方面，咱们在各个行业领域内更多的关注效率问题，更多的关注如何快速的测试，而不是如何更正确的测试，因此咱们都很难沉下心来来思考改领域内的一些通用的测试方法，从而能分享和传承给全部测试同仁；说咱们不肯意去作，或者说咱们没有意识去作，多是乐观了，其实这个很是有难度，这个方法的抽象和建模很是的难（以前作过一些测试模型的抽象，感兴趣的能够了解下），不是在某个领域扎根多年的测试大师们没法作到的，前提仍是这个大师在这块上有更多的思考和沉淀和总结。

这里强调我可没说初心就是黑盒测试，我的见解，初心是从本质上去想和思考怎么去测试，什么方法和策略，测试哪里，说到黑盒测试方法只是其中举了一个例子而已，想一想你如何回答你是经过什么方法来测试”它“的，你不可能说我用自动化测试来测试它，我开发了一个平台来测试它，须要你想一想你的回答有没有传承性。这里是有一套方法的思路的；至于技术原本就是解决问题的思路；怎么去作的方法，这个可能比较虚，就像道同样，这些思惟方式的思考，咱们平时作的太少了，而是更多的去作开发自动化测试框架，不是说很差，去想一想为何，是体现你的技术，仍是以为这个是潮流，你们都干，仍是以为这个是某一个价值的；等等。而这些是否是符合最初你的本心。

12年 / 咱们还能找回初心吗？

好了，前面说了蛮多了，你们在现实面前仍是须要现实一点，随着开发测试比例的提高，测试人员会更加专一在效率上，而不是质量上，咱们都有一个美好的愿望，就是咱们先把问题解决了，先把效率提高了，咱们就有时间好好研究如何正确的测试SUT了，如何创新出新的测试方法了。理想很丰满，现实很骨感，就像需求列表里面同样，都是P0的需求，咱们都在想P0需求作完了，下一期咱们作P1P2的需求，而后你会发现P0的需求永远作不完，同理，咱们的效率和问题解决也是作不完的，那咱们的重心和目标规划仍是在这上面，这有错吗？没有错，对SUT来讲、对质量和效率来讲、对业务发展来讲、都没错。

固然不少人会说我测试效率提高了，质量也会同步的提高，这个仔细想一想还真不必定哦；前面其实也提到了，咱们在平衡质量和效率上的投入，到底平衡到什么程度，咱们本身也不知道，不少时候为了功利、为了本身、为了将来、为了测试行业自己，咱们作的选择可能有所不一样，最关键是你作出了什么选择，你是如何平衡这些的，在这个平衡中，你学到了什么，你知道了测试这个产品有什么样的坑，你的测试经验教训到底有几条，哪些是对他人是有价值的，你有没有总结和抽象出。

回答问题，在这个现实世界里面，咱们工做10几年的测试工程师们，咱们还能找回初心吗，还能静下心来思考咱们真的是正确的作测试吗？真的只有这样的一条路吗？咱们还能有其余的路吗，对于绝大部分测试同仁来讲，咱们都没法找回初心，咱们只能在这现实世界里面随波逐流，固然，颇有可能包括我本身。

12年 / 忘记我所写的

感谢你能看到这里，看到了那么多的废话，那么从如今开始，忘记我所写的，继续写代码，继续开发测试平台，继续解决问题，你会成长的很快不少的。以上全部的观点都只是个人我的见解，不少地方说的容易被人挑战，被人骂SB，是的，可是又有什么关系呢。

我思故我在，在此记念测试十二年的酸甜苦辣。

下一个轮回，又是12年，很漫长，若是我不干测试了，我也会关注大家的。青山不改，绿水长流。

本文做者：云效鼓励师

阅读原文

本文为云栖社区原创内容，未经容许不得转载。