前言
- 最近不断地回顾总结自己这些年作为测试工程师的经历，作为一名在测试岗位上工作快 5 年的老兔，基本上已经历完从新手到熟练的阶段，做过各终端，供应链平台、业务中台，内容分发等质量保障的工作以及带过团队，朋友问过我在这些业务是干什么的，最初我可能会介绍说版本测试、自动化测试、测试工具开发和流程规范，到后面总结为质量保证和效能提升，直到现在我认为简练但又精粹的总结-测试能力建设，我们看很多招聘信息里面对测试工程师的职责要求，列了很多项，包括了技术的要求和项目管理的要求等，最后都是能够用测试能力建设来概括，对于测试能力建设，我们作为测试工程师需要做些什么，接下来结合我个人的经历来讲一下怎么做测试能力建设
关于测试工作
- 测试工作，换在 4 年前我第一反应可能也会认为是帮这个业务在每个版本中找 bug，让版本顺利发布，但是作为工程师，我们的工作方式是否已经是以工程的形式开展，或许你看到研发同学敲代码开发一个业务系统称谓工程，把系统的各种能力各种服务规划设计好称谓架构，回到测试的性质，不是开发一个测试工具就叫测试工程，不是把持续集成自动化测试设计好落地好，把流程规划好就叫做测试架构，测试工作其实是要求测试工程师能够把一个业务或者一整块的业务的质量保障体系给建立起来，质量保障体系需要我们做的就是通过测试能力建设
- 测试能力建设，还是围绕质量保障和工程效能的两个核心，说通俗一些就是业务在质量和效率这两块缺什么，作为测试工程师就需要做什么，这一点在很多企业中已经作为考核测试工程师的指标
在工作中我们往往遇到接手别人的业务或接手新业务的测试工作，或许你对这种业务有经验，但也会遇到从来没接触过的业务，这样我们如何开展测试工作，不管是你做工程效能还是业务质量，开展任何工作的第一步都是熟悉，熟悉业务，熟悉技术，熟悉团队协作，对于如何熟悉这一点，我会从这几点出发
要入手一个业务首先是要了解前世今生，要知道这个业务存在的原因，定位是什么，发展至今现在又是怎么样的形态，什么样的地位，将来的发展方向是什么，这好比需要先认清自己
我们的业务如何交付给用户使用，可以从发布流程入手，其实业务团队里面的流程，不管是测试流程还是研发流程，最终结果都会表现在发布流程，发布流程可以推导出业务团队用的是什么研发流程，用什么测试流程，同时通过发布流程我们可以了解到系统的部署，从而推导出系统架构，依赖调用关系等，再深入推导出业务使用的技术栈，发布策略，人员水平等，所以我每加入一个新团队或接手新业务，我习惯性的会看版本如何发布，发布流程是怎么样的，以此为线索，很容易就可以把业务团队的协作能力和技术能力了解清楚，这个就是了解业务内部
用户怎么使用我们的业务，其实就是了解我们业务的外部情况，我们的目标用户是谁，表现形态如何，我们的业务为用户产出了什么，解决了什么，大家可以试一下通过上面的一些方法是否会更容易了解一个业务甚至一整块业务
对于业务了解完之后，那接下来才是测试工程师的主菜，我们怎么去做测试能力建设
测试能力建设
- 测试能力建设有一个关键点，就是如何把测试肉身投入转换成测试能力投入，我们是人，但我们也是能力的一种，但能力未必是人，他可以是技术，可以是流程，简单地说就是怎么把人力转换成技术能力和流程化
在测试能力建设的工作投入中，直白的目标就是业务需要什么我们就做什么，所以我们还是需要找到适合业务和团队的方式，传统的 IT 公司习惯走 V 模型或是双 V 模型，到了互联网行业，大家都开始强调要研测一体，devops，测试左移右移等，在我的经历中大部分在互联网行业，所以习惯性从方向上会考虑当前业务和团队要如何左右移，如图中所示
测试左移强调的是尽早介入测试，提前发现问题
这时候还是从工程化和流程优化那两个点去打，我之前所在的业务，我投入测试时一般会先规范代码的管理分支，在多位研发并行开发的时候我们需要怎么规避一些由于切分支带来的问题，我们明确好开发分支，提测分支，发布分支和主干，测试只接受提测分支的版本测试，发布的版本只能用发布分支等，同时接入静态代码扫描等代码精准测试的能力，研发每次提交代码后基本上都经历了一层代码扫描的质量保障过程，同时在接口和端功能层面，作为测试我会去建立自动化回归测试的能力，我们可以用接口测试框架或 UI 测试框架等自己手打自动化测试用例，把持续集成的流程建设起来，也可以通过更成熟的工具或平台如线上流量引流回归等等，其实就是通过大规模的自动化等能力来从最根本的代码层面，接口层面等保障起来，为了就是尽可能不带 bug 提测，所以这个过程就是要做如何把这些自动化的能力建设起来，缺乏工具和平台的时候，我们就得去找合适的工具和平台，找不到就得自己设计开发，这也是作为测试开发乃至所有的测试工程师都需要具备的能力，有了工具和平台之后就结合业务的特征进行相应能力的建设，做到懂得用，懂得做，懂得落地
在流程上，左移的方式是通过提前交付测试用例或测试方案实行研发自测，为了还是不要把 bug 带到测试阶段这个目标，或许研发会质疑说研发来测试，要测试来干嘛，我们从 ROI 的角度去思考，研发自测花大概 0.5 到 1 个人天，但如果出现 bug 导致版本阻塞，可能影响的就不是 0.5 到 1 个人天，测试包来来回回几次，测试找 bug，定位 bug 原因等，一不小心几天就过去了，这时候就会出现版本延期的风险，所以我们要把问题扼杀在摇篮之中，这需要代价，但这也给我们带来了更好的结果，研发自测和产品验收很大程度就是依赖了测试用例或测试方案，所以这个时候我们就不仅仅是把当前的需求要点或技术改动点给覆盖，当然不是说所有的用例产品研发都要过完，测试工程师是测试执行的兜底，研发基本上都是把核心链路和功能过完后就提测，这时我们更多的是实践探索性的测试，测试执行和研发分工，节省的时间做更有深度的测试工作，包括把版本的一些测试需求自动化，或者考究安全性性能等，我在写测试用例或方案的时候基本上会使用这个大纲
每个版本的测试，不是简简单单把测试用例执行完，功能执行完就完成的，每做一件事情，必须明确这件事情的目标或背景，因为接下来所做的一切都会围绕着这个目标去开展，对于目标不清晰的，设计出来的方案或用例，存在偏差的概率就会增大，也就会存在漏测的风险，二来我们需要明确版本的改动范围，尤其是多组件多服务组成的业务，在加上相关依赖关系，这个是可以用来明确我们的测试范围，测试成本永远都是有限的，要做到即充分又低成本的那就需要明确测试范围，目标和范围都明确之后我们就可以进行相关的用例设计，需求的用例，技术性的用例，都需要在测试用例中体现，具体的如接口的逻辑是如何的，缓存的逻辑如何，如遇到数据迁移等情况，我们也需要把对应的数据验证和数据同步用例等设计好，
把测试阶段的验证都设计好之后，那就是发布阶段和运营阶段的一些质量保障手段，大家都了解有灰度发布，流量隔离，线上监控，线上验收等一些测试能力，这些就是在测试右移中采取的一些质量保障策略，所以在设计阶段我们就要把作为线上验收能力的一些打点和日志输出设计好，监控项给明确好，甚至设计好质量相关的数据报表，通过这些采集监控数据进行分析和配置告警，来观察版本发布的情况，从而建立了一个线上的业务健康度模型
有些情况确实是通过测试右移的方式来执行，我在做中台业务的时候，经常遇到业务方由于环境等原因，功能必须在线上验收，所以这个时候我们就需要有线上验证的能力，线上验证的原则是尽可能的不要影响到原有功能和使用业务的用户，这个就需要做好很好的隔离，所以从研发一开始的设计就从线上可测性角度就需要考虑到这一点，功能做好隔离，数据做好隔离，一旦出现问题，我们有相对应的风险预案，如何清除脏数据，如何将功能降级等，前期的设计都要考虑好，发布完成以后我们还需要考虑运营层面的事情，运营事故在各大互联网公司中也是屡见不鲜，比如暴露了一些敏感数据等，对于这方面作为业务的测试我们也是需要建立其相关的防范机制，不管是流程上和从技术上去杜绝，这往往也会在我们的风险预案中体现，当然故障都没有是最好的，但一旦出现故障的时候我们就要能够快速的发现和解决，这也是我们作为测试能力建设中的一个重要环节，下面就是我根据上面的一些方法论所建立的项目流程
小结
- 是否会发现，一旦把这些能力都建立起来，测试人员的投入就会变成测试能力的投入，测试工程师就是测试能力的体现，测试能力的建设者，只要安排人员去执行使用测试能力即可，就不一定需要测试工程师的肉身投入，让业务都具备自我质量保障的能力，从根本上的提效和降低投入成本
- 纵观我上文所说，其实我作为测试工程师大部分的时间都是在做测试设计，测试设计体现一名测试工程师的产出，测试执行不一定需要测试工程师来做，但需要你做好的是在测试能力方面的建设，质量是整个团队的目标和责任，测试工程师就是专门为这个目标出谋划策的，我们认清出自己的职责，把自己的思维转换过来，把肉身转化成能力，把人力成本变成技术成本，这是作为测试工程师价值的体现，希望通过此文，能够对大家在测试工作上有一点点帮助，谢谢
深有感悟
不明觉厉
别论了,点九完事
很不错，赞一个。
nice~
定期总结，盘点自己的认知，以后回头看可以清晰的看到自己的成长轨迹
槽神
回复
谢谢，定期总结真的很有必要，如大佬您所说，看清自己的过去，把控好未来的方向，对于总结来说，最容易得到的是经验，而我更想得到的是思维，经历比较容易转换为经验，但思维需要沉淀
收藏了
还是需要技术 没技术 还是不行 感谢分享
思路很清晰，结合自己的工作实践，阐述了测试的航向与价值：根据项目实际情况持续不断的建设转换实际测试能力去保证质量和提升效能。很好！就是文名感觉没内容美丽
理论很重要，它给你了方向和思路，但是更重要的是如何在工作中落地执行
内容很多，其实 少说了 一个，那就是 你能左右项目 向左 向右么，太高估自己了
Jwong
回复
是的，落地才是最后产生实际价值，其实我在做这些项目的测试工作以前，我也没有思考过所谓的测试能力建设，就是一味通过流程化和工程化去推送业务，但后续项目组协调起来渐渐就形成了左右移动等思维理论，有了成功的经验，后面在换业务的时候按照这套方案都能够很好的把业务的质量保障体系建立起来
YangPower海盐
回复
我从几个点来回答你的问题
1、测试向左和向右首先是没有对立的，我们需要具备向左的能力，提高研测的协作能力，我们需要具备向右的能力，来支撑业务可以在真实环境的模拟下得到验证，所以向左向右本质上不冲突，这里说的是左移这个方向上需要什么样的测试能力，右移的方向上又需要什么能力
2、对于落地的问题，我首先用我的经历来说，我的理论基本上建立在我的实践经验，当然具体项目具体讨论，这是实际情况，我不大说怎么落地，因为我不了解的你业务，我说出来大家也会觉得虚，下层经济决定上层建筑，如果不熟悉业务和团队，做什么都是空谈，所以为什么前文我强调了要熟悉业务，熟悉技术，熟悉团队，质量是整个团队的目标，向左和向右是建立在团队当前所拥有的测试能力和团队协作能力相结合的结果，作为测试工程师，我们要做的就是根据这个方向去落地工程化方案，包括你所做的自动化测试，工具开发，监控工具等等，都是为了产出能力，对于流程化，前面提到这是一个团队协作能力的产出，测试要做好的就是要提升这个能力，也就是大家一直在说的提效，提什么效，就是协作能力
3、最后回答一个对于是不是高估自己的问题，我觉得做人就是要高估一下自己，不然做什么事都会畏手畏脚，机会都被别人抢走，这不禁让我想起我当初是如何工作一年就开始带团队的经历，你觉得自己能做到，就有可能做到，觉得自己做不到，就绝对不可能做到，我们在业务当中，必须把自己定位成业务 owner，业务的大管家，在业务和团队面临问题的时候，怕自己由于能力不足而不敢挺身而出的话，还是那句，机会就送给别人了，人都是逼出来的，高估一下自己，尝试去做，不行再论
这几张图值得存下来
赞!
大佬 5 年能摸索和时间这些出来很强了!
我现在也是在努力实践这些方向
本来业务定调质量保障体系
可惜后面 boss 走了
现在离大佬目前的体系建设还有很长的路!
感谢输出 算是给了我一个启明灯
希望下次大佬能出一个更加详细的落地实践
fungaegis
回复
谢谢您的认可，其实落地的方案是有的，包括我以前写的线上监控体系那些，但涉及到里面的技术栈和具体的实现细节，因为有风控，所以很多东西都不能说，所以普遍还是想通过思维和理论去推导要落地的事情
测试右移 现在最大的困惑是版本都上线了，测试在测，体现不出测试价值。本身测试的价值就很难体现，更何况现在测试右移。
最近也看到很多关于测试左移和测试右移的帖子，但还是有困惑。
张
回复
这里有个界限，首先你这边版本上线的定义是在生产环境发布，还是说已经交付到真实用户使用，这是不一样的场景，测试右移更多是指利用生产环境的资源来进行验证，毕竟有些场景只能在生产环境模拟，所以也就会存在所谓的线上联调的情况，这里强调的是如何在不影响正常用户的情况下利用生产环境的资源进行测试，所以测试的价值就体现在如何落实在一点，以致于可以产出预发布环境，流量隔离，线上监控等一系列测试能力建设的工作
同样作为一个快 5 年的 tester，深感赞同
收藏了，正是我需要的。
从事测试行业两年，一直在做 做普通的点点点，偶然学了一些自动化测试。
但是，没有了解 测试整体的内容，含义
对测试没有一个真正的了解
就像一个没有感情的机器，偶尔码一码代码，偶尔手动测试
————
现在明白了，测试要注重对整体的含义，而不是只学了一点自动化技术就飘了
面进一个大场，才明白跟前辈们的差距
现在只能慢慢跟前辈们学习
还好前辈们愿意接纳
萌新一个，自学过程中，听到很多概念性的东西，goole 搜索结果越来越迷，在这里学到了感谢大佬
楼主写的很好，感觉现在很难在 testhome 的 top 热帖中看到这类文章了。
从文中让我想起了另外一篇文章，聊一聊职业发展（https://testerhome.com/topics/16354）这里写的例子，我认为也是测试工程师的职责，能力方面的
才 5 年经验，善于总结，理论很丰富，楼主是个不错的领导管理者
楼主很优秀，同快 5 年经验自愧不如，如果公司需求多，迭代快，人员少，单纯的业务测试就基本占据了基本所有的时间，自动化测试需要投入时间成本，在人员少的情况下，如何安排测试左右移
挺赞同测试输出自测工具，实现左移，可以避免低质量的 bug，更何况可以留更多时间给测试同学挖掘更深度问题
讲的是真的很好，受教了
楼主讲的很好，这套流程可以说很全面了，只是小公司没有这么完善的流程
xiaoxiaoxue
回复
确实，很多项目都这样，包括我现在所在的项目也是，招我来就是做自动化的，结果去年业务大爆发 ，人却没多招几个，只能靠业余时间搭了框架，用例还没实现多少，还不能真正起到作用。
讲得很好，大部分小公司流程都被砍断了，因为小公司考虑的更多是成本，怎么最小代价创造跟多价值
不错不错。
虽然没能像楼主一样 站在整个项目的质量维度去看待。 但我自己前段时间也在自动化这一细分层面有了些新的思考。
即不能仅仅局限于测试自动化的实现，还应该关心环境治理、数据治理、团队技能整体水平提高（体现在组内多分享，解决协作低效，沟通障碍等问题）等等既基础又有高成效的地方上。总的来说，用一个 “自动化体系” 来概括，不仅是 “自动化测试”。
点赞收藏就完了，感谢楼主
先点赞，学习了。
学习了，感谢分享！
分析的很好
楼主的见解很独特，值得学习，现在测试人员普遍太浮躁
左移，右移要搞；但是左移势必和开发的工作产生重叠，很多测试左移工作实际上是 “帮助开发完成自测”，所以哪些要左移哪些要让开发做好自测，就要定义清楚。 糟糕的是目前这个没有业界统一标准，甚至同一个公司不同部门也相互差别巨大。
于是会出现一个人，适应 A 部门的分工，但到了 B 部门就适应不了的现象，因为两个部门测试 和 开发 两个角色分工差异较大。
同时也给招聘工作带来巨大麻烦，需要去验证候选人能够适应当前团队的分工，而如果当前团队的分工不合理，往往也会加剧人员流失，造成招聘工作频繁发生，更加剧了招聘工作量。。。。 再加上 测试工作频繁交接带来的风险和低效率。。。
左移，怎样左移，移到什么程度，真是个大问题。
右移反而清晰一些，大多数情况是，测试想找运维要线上数据，运维不给，不配合，基本以运维配合的程度为界限，界限分明一些，比较好做，能做到哪做到哪，大佬想推就往运维那边甩，有大佬压力，运维配合给拷贝数据，导流量就做，而且右移对质量保障和提升效率的效果比左移明显。 如果遇到线上风险大，测试不用说话，运维直接把方案拍死，大佬一般也不会强推毕竟大佬也不想出事故。
黄弟庄
回复
非常认同您的观点，我之前在大公司里面工作，左移右移这个过程，其实建立在高度工程化和标准化的基础上，通俗说就是有好的基础设施和标准化的技术栈，这个是整个公司在技术的意识形态上高度统一的结果，所以才能有我们可以很好落地左移右移的前提，所以说到适应这个问题，大公司或者说已高度标准化的公司，问题不大，然而现状是很多互联网或软件公司就是没有这种前提，左移右移的难点涉及到本身测试人员的能力，团队对质量的需求等等，虽然是这种情况，但也不妨碍一名测试工程师怎么在一个项目或业务当中做好因地制宜的质量布局，质量规划，我现在也在一些基建不太好的新业务当中，这点非常有感触，怎么做好一个项目的质量布局，才会有后续的测试能力建设:
测试左移的理解：
1、关于需求，最好在产品论证阶段就能参与讨论
2、一定要将 90% 问题在需求评审时暴露出来，这一点非常重要，不要开发做一半或者送测了产品改需求，这样对整个团队伤害都很大（待过的公司很多时候需求评审都是鸡肋，开发做的时候还是啥都不清楚）
3、参与开发的架构设计，且不论开发用什么框架、什么插件、什么中间件等，至少要搞清楚开发的实现逻辑、增加了哪些接口、哪些表、哪些字段，如果涉及到老数据怎么兼容等等
4、测试用例的编写，时间充足的情况下能细则细。在写用例的时候其实会发现很多细节问题，这个时候就要和产品、开发一起讨论给出解决方案
5、给开发同学提供冒烟测试用例，自行冒烟通过才能送测
我觉得做好以上 5 点，能很大程度的保障送测质量。欢迎交流
测试是为了质量和速度。质量自然是少 bug。速度，是提交的代码到实际发布中间的距离。如果测试足够快，覆盖率够高，而且我们对测试的覆盖率有信心，发布就会很方便和快，甚至可以做自动化发布。比如最开始没有测试的时候，开发要自己跑手动测试，手动发布，而且因为是手动，其实很容易错。所以每个星期能发一版。而且开发要自测某个新写的 feature 会不会把其他 feature 炸掉也很麻烦。但如果有足够的自动化测试，自测就会很简单，一个命令，出去喝杯茶什么的，回来就可以了。发布也可以自动化，然后就能做到每天，甚至不断发版。
感觉这样同时是测试的宏观方法论，测试能力建设、测试执行方法等这些都属于方法论中的具体体现。
YangPower海盐
回复
测试管理人员/测试项目负责人在项目前期写测试方案的时候，要体现出来，并且测试方案是要经过产、研、测都评审同意的
接口测试工具可以试用一下国产的接口测试和接口文档生产工具 apipost：https://www.apipost.cn/?dt=2020
每个版本的测试，不是简简单单把测试用例执行完，功能执行完就完成的，每做一件事情，必须明确这件事情的目标或背景，因为接下来所做的一切都会围绕着这个目标去开展，对于目标不清晰的，设计出来的方案或用例，存在偏差的概率就会增大，也就会存在漏测的风险，二来我们需要明确版本的改动范围，尤其是多组件多服务组成的业务，在加上相关依赖关系，这个是可以用来明确我们的测试范围，测试成本永远都是有限的，要做到即充分又低成本的那就需要明确测试范围，目标和范围都明确之后我们就可以进行相关的用例设计，需求的用例，技术性的用例，都需要在测试用例中体现，具体的如接口的逻辑是如何的，缓存的逻辑如何，如遇到数据迁移等情况，我们也需要把对应的数据验证和数据同步用例等设计好，
can't agree more
nark
学习了