转：测试十年-我难以逾越的困惑和痛苦和思考

Posted 2020-10-13 赖荣生

原文： http://blog.sina.com.cn/s/blog_6cf812be0102wo6d.html

很久没写blog了，之前的测试三年，测试六年都写了blog来记录自己的测试生涯和思考，这次测试10年肯定不会错过了，当然了，YY比较多，干货也不多，反正纪念下，或许我很难写测试15年的blog了。大家有任何问题，欢迎讨论，欢迎吐槽。

 

--- 10年测试的困惑和痛苦

转眼间参加工作10年了，也就是意味着干软件测试10年了，经历过3家公司，都有一些感悟，也难以相信我能在淘宝坚持了这么久，7年了，人家都说七年一痒，我的确是有一点痒了，但是没那么大，不管怎么样，还是会做一些改变吧，7月份初我会离开淘宝BU，这个我奋斗了7年的测试团队，每一年BU和团队和测试都在变化，我都坚持在淘宝BU做测试，一点点的落地我的想法和思考，看着淘宝业务的起起落落和变化；之后我会加入商家BU，跟随第一任boss齐哥做一些自己想做的事情，去探索一些未知，包括业务和技术和心中的那个测试。

 

回顾这测试十年，我走了很多的弯路，也走了很多经典的路，前五年主要经历在测试技术和开发技术的提升上，那个时候看了很多的书，读了国外很多关于测试的paper，很开心；后五年带团队后，花在测试技术和开发开发的投入上大幅降低，很多时候很迷惘，需要处理一些小的琐事，无法在管理和技术上找到比较好的平衡点，所以这几年技术的提升相当不满足期望，不开心；但是这个世界就是这样，有得必有失，有失必有得，这是经典的老路，在国内做测试的大部分人都会走这条路，但是很多时候，看着测试技术的发展（特别是移动测试技术、大数据测试技术、云计算测试技术），包括国外技术的发展，不禁感慨我真的有点跟不上这个变化，这个时代了，必须做出改变，到底改变什么呢？

 

改变业务：让自己接触不同的业务，不同的产品，运气好的话，就会有不同的开发技术和测试技术等着呢，这样你还可以多充实一会，多学点东西，让自己的测试经验更加丰满，这样熬过1-2年后，又会回到原点，路还是那么窄，而我已经老了。

 

改变测试：做业务的测试的确是个很烦人的东西，很多杂七杂八的事情麻烦，需求变化，需求合理性，用户体验，测试数据，bug管理等等，偶尔会有一些自动化测试、看代码，分析开发设计实现 作为开胃菜，其他的都是痛苦的，无味的。那我不想做业务测试了，也不想带业务测试团队了，我们怎么办；测试的未来是很明显的，我们肯定要在保障基础质量的、提高效率的情况下减少测试的，这样业务测试的人员会越来越少，带领这样的精英测试团队？去做基础的测试服务化的体系和平台（支撑那些不能缺少的测试活动的高效执行）？能做到什么程度，能得到什么样的结果？

 

改变工作：竟然看到了测试的未来，包括职业发展，包括方向和国内的现状，是不是可以考虑不干测试了，脱离测试这个很小的圈子，包括脱离测试平台开发的圈子；在阿里，我知道一些测试高P成功的脱离测试圈子，进入到开发这个更有发展更有前途的圈子，未来肯定更好，这个是毋庸置疑的；我也是思考过几十次说服自己必须要脱离测试这个圈子，长痛不如短痛，丢掉那些我自认为很擅长的东西，一次次的自卑懒惰犹豫打败了自己，有时候很难相信自己是这样没有魄力的人。当然不一定非要进入开发这个圈子，PD也不错啊，实在不行，做HR也很好啊，做Staffing也行啊，反正别干测试的就好了呀；再看看创业的parter，有需要测试的吗，都是开发啊、PD、运营才是核心班子呀，这样下去，自己都没法创业了，也就是没法成为创业公司的核心成员了，这一辈子只能当个测试经理，测试总监？这些有意思吗，这些当真不需要知道先进技术吗？那样会分分钟被取代的，都这么大年纪了，还没有追求，等到猴年马月啊；有家庭了，不能太折腾了，安稳点好哦；尼玛，好了，我受不了我自己了，我要改变工作，还是改变生活，还是两个都要改变？好了，不说了，我更加痛苦了。

 

哎呀呀，说到这里，就说到国内测试届的偶像了，段总，人家在测试领域最早是google测试经理，几年前（2010？）很快就跳出测试圈子到豆瓣当然技术VP，然后到各个公司的VP，CTO，现在是CEO了，看看吧，这人生才充满了挑战和不确定性，路越走越大越宽了，当然了，行业也是越来越潮流，从互联网、到互联网游戏、到互联网金融；再次膜拜下段总，毕竟国内只有一个段总，却有千千万万的测试经理和测试总监。

 

好吧，再次承认这两年我是真的很困惑，目标和方向都不清晰，产出和得到的东西较少，这样下去，那是没救了，但是我还在测试领域做什么呢，还要学习什么呢，哪些东西是真的有用的，哪些东西是真的对公司有用的，对部门有用的，长期的还是短期的，好吧，再次迷惘。

 

--- 10年测试的思考

当然了，在阿里巴巴的测试的相关技术的突破和创新，我是一直在关注的，的确有很多自动化测试、线上监控、测试服务化、线上线下数据对比等相关的突破性的结果产出，都是或多或少的改变了原来的工作模式。但是我们一直不能忘记的是 上下文驱动派的 原则之一，那就是 根本就没有最佳实践，只有某个上下文背景下存在好的实践。

 

大家有没有想过，开发的核心产出是代码，是的可以永恒的保存在代码仓库的，而且这个仓库的权限和重要性不言而喻。测试的核心产出是什么呢？测试代码？Bug？测试场景设计？当然，如果我们的自动化测试做的非常好，那么我们的test code 也可以有它非常大的价值，但是如果没有呢？我们对应的测试场景描述、bug 就没有得到足够的重视和价值透出。大家都知道，测试对于业务逻辑的理解和整理应该是在开发之上的，我们往往忽略业务沉淀和技术沉淀的融合产出的价值的重要性，同时忽略了这个产出的可持续性、迭代性、可跟踪性（代码其实都具有这样的特征）。

 

所以我们可以发挥想象，我们是不是可以将系统服务能力地图、测试场景、相应代码在git上统一管理和映射起来，TC 的 可持续性的版本控制、review的流程化机制、主干TC和分支TC的管理、TC的组件化和对外提供服务。我们把测试设计场景真正作为一个资产来管理和共享出来。注意这种动态管理测试场景的好处很多，这里就不描述了，当然其实我们还可以包括测试数据服务的关联关系，真正的打通系统的各个环节（产品逻辑、开发代码、测试场景、机器、线上环境、数据），且能够清晰的知道和如何完善系统的点点滴滴，这是个大图，我一直很想看到这个，好吧，我可能在YY。

 

那继续YY下，开发人员的质量意识到底怎么来提高，如果我们要做10：1的开发测试比，测试人员做的事情和开发人员做的事情在现在的项目流程中是有很大的不同的，我自己都看过Google的开发人员写的单测代码和方法，那是相当赞的，一个普通的sort排序能写20几个单元测试的testcese，比很多测试人员都思考的全面，这样的测试sense在，系统的单元测试、接口测试、甚至集成的自动化测试都很有可能都是开发来完成的，那是相当赞的，国内公司的开发编码时间都没有，更不用说写单元测试代码的时间了，那到底是时间问题还是开发人员的质量意识和责任问题呢。另外，我还发现一个现象，大家都很BS UI自动化测试，都会认为UI自动化测试的维护成本高，都去做接口测试，我们是不是有点走极端了（现在已经很难看到有UI自动化脚本在持续集成了，估计大家都不写UI自动化脚本了吧），UI自动化测试的作用不仅仅在测试环境，包括在线上环节的功能监控都是能起到关键的作用，而我们基本上都是摈弃了这个作用，我们自己没法找到分层自动化测试的平衡点，就一味的选择放弃，再想想，后端开发能做单元测试、接口测试，那我们的前端开发是不是也可以做UI自动化测试呢，他们也是比测试更加擅长去写自动化测试脚本，我们可以不可以去尝试。

 

其实，不管测试如何发展，测试效率如何提升，系统质量谁来把控，这些都是永恒的话题，谁做不是做呢。我们要做的就是不断变革，变革自己，变革开发，变革整个研发流程。如果测试人员还守着自己的一亩三分田，进步和收获都是相当少的，测试需要去做很多开发需要做的事情，比如非功能的专项上，性能、稳定性、安全，不一定是专项测试上，整个解决方案上都要有比较不错的结果，注意这里不是说业务上的开发能力的体现。

 

不管怎样，当你测试干了10年的时候，我觉得是不是可以思考更大的问题，因为这些问题是不可避免的，无法逃避的。当然，这里不是说我们不能做一线测试工作，但是如果我们的重心是不停的去测试执行，去提bug，去写自动化测试脚本，这是不可取的；我们还是需要了解一线测试人员的痛苦，郁闷，难受，问题的地方；而这些抽象放大的问题，就是我们需要去解决的。测试架构师们需要解决的问题就是在平衡质量的前提下（无P1P2级线上故障），快速发布，提高测试效率，提高开发测试比。我们到底要做什么，做哪些具体的action，我们做的事情的目标和规划是不是围绕着这个核心？

 

好吧，其实我一直有一些自己的乱七八糟的想法，了解了很多测试团队的做法，了解很多测试相关的创新工具和流程，但是我之前一直没有想到的是，我心中的测试到底是什么样的，我为了这种测试，我做了哪些事情，我没有做到很好的抽象，总结、规划自己心中的测试。不管这个测试是美好的，还是现实的；不管这个测试是不可能落地实现的，还是可以做到的，我都没有很好的思考这个测试的整体。这10年来，我经历的点很多，但是我没有把它串成一条线，没有把它连成一个面。

 

-- 我心中的测试

 

好吧，前面太啰嗦了，现在回到正题了，这两个月我确实思考了很多，包括看了自己之前写的一些blog，从中选取一些很好的想法，加上自己看到的一些变化。最后，我思考了一个六道网质量防控体系，肯定会存在一些问题，后续一些想法和思考都会围着这个体系来建设，从而完善它，真正的把它做好，真正的服务到整个项目团队成员。

 

why-六道网质量防控体系

首先说下，为什么会有这样的一个六道网质量防控体系呢，因为我们想：

全方位多角度的测试活动来保障系统质量

改变传统模式下的开发测试工作方式

 提升研发团队的测试成熟度，助力组织升级

 质量可控情况下，提升开发测试比

 更显性化的展现系统质量控制过程和结果

 

六道网质量防控体系大图 

六道网质量防控体系实施策略  （去掉了怎么做、工具、结果）

 

当然了，这里面每道网都有自己的独立的实施流程和策略，我这也思考的一些，但是现在不方便拿出来，所以这里就先不讨论了，后续有机会再详细描述一下，这里就是要注意的是，不同的产品特点会对应不同的实施策略，纯后端的、标准web的、H5的、native的，SDK的，ISV的，大数据的，算法的等等都有自己合适的实施策略，我们要的就是配置不同的项目，自动化配置不同的实施策略，包括实施的进度，状态，风险控制等等。

 

六道网质量防控体系的机制&标准问题：

 

六道网系统的项目接入标准是什么？

 如何知道某一道网防控的进度情况？

 如何知道某一道网防控的效果和问题？

 六道网的具体action如何保证落地执行？

 六道网防控的质量风险无法提前暴露？

 六道网无法综合各道网的防控结果做出决策？

 六道网如何获取防控过程中出现的内部和外部数据？

 

上述这些问题我很多都没有想好，想透，而且我一直在思考的是六道网系统的核心竞争力到底是什么？对外提供的服务能力到底是什么？系统和功能架构到底是什么样的？我得承认，我做测试工作10年了，平时对系统设计方案、架构设计、业务抽象设计做的其实不多，对平台设计、架构抽象的能力实在不行，这个问题很大的限制了我的发展，我无法体系化的思考一个平台是什么样的，无法准确的设计一个平台的配置性、可扩展性、稳定性、多样性等。

 

大家都看过军事题材的电影或电视剧吧，我们经常看到的是军事演习或对战的时候，指挥部的大屏显示的内容，那TMD的太帅了，我就是想要那样的系统，那样的六道网防控体系，那样的给指挥部所有成员作出决策提供信息的支撑。但是不得不承认的是，目前阿里巴巴还没有这样的大屏，没有这样的让我非常清楚一个项目、一个系统该有的实施信息和控制决策，不仅仅是自动化的问题，还包括我们做项目的标准输入、标准输出的问题，我们一直做互联网产品，一直要的快速，一直要的是随心所欲，一直要的自己方便就好，最后就只能这样了。

 

平台和想法规划的再好，也需要落地执行能力，对于平台和产品来说，有些人说的是从上而下的支持和鼓励，有些人说的是平台带来的解决的问题，有些人说两个缺一不可；大家都害怕改变，改变意味着带来了新的不可避免的成本，带来不熟悉的工作方式，带来了可能是自己工作量的加大。我们的目标是确定的，我们不希望靠增加测试人员来提升和保障系统质量，我们就是要减少测试人员，去探索那肯定会来到的测试未来。

 

不管怎么样，最早我就提到了，如今我离开原先的淘宝测试团队，独自一个人去商家BU，会面临很多问题，但是我找到了六道网体系，我会为了它，献出我长时间的思考和总结，包括学习（最近经常看这些架构设计，技术思考等），我相信我能找到合适、心中的那个测试。下一个测试十年，道路肯定不平坦，肯定会有很多的挑战，唯有 雄关漫道真如铁，而今迈步从头越！