前言
- 最近不断地回顾总结自己这些年作为测试工程师的经历，作为一名在测试岗位上工作快5年的老兔，基本上已经历完从新手到熟练的阶段，做过各终端，供应链平台、业务中台，内容分发等质量保障的工作以及带过团队，朋友问过我在这些业务是干什么的，最初我可能会介绍说版本测试、自动化测试、测试工具开发和流程规范，到后面总结为质量保证和效能提升，直到现在我认为简练但又精粹的总结-测试能力建设，我们看很多招聘信息里面对测试工程师的职责要求，列了很多项，包括了技术的要求和项目管理的要求等，最后都是能够用测试能力建设来概括，对于测试能力建设，我们作为测试工程师需要做些什么，接下来结合我个人的经历来讲一下怎么做测试能力建设
关于测试工作
- 测试工作，换在4年前我第一反应可能也会认为是帮这个业务在每个版本中找bug，让版本顺利发布，但是作为工程师，我们的工作方式是否已经是以工程的形式开展，或许你看到研发同学敲代码开发一个业务系统称谓工程，把系统的各种能力各种服务规划设计好称谓架构，回到测试的性质，不是开发一个测试工具就叫测试工程，不是把持续集成自动化测试设计好落地好，把流程规划好就叫做测试架构，测试工作其实是要求测试工程师能够把一个业务或者一整块的业务的质量保障体系给建立起来，质量保障体系需要我们做的就是通过测试能力建设
- 测试能力建设，还是围绕质量保障和工程效能的两个核心，说通俗一些就是业务在质量和效率这两块缺什么，作为测试工程师就需要做什么，这一点在很多企业中已经作为考核测试工程师的指标
- 在工作中我们往往遇到接手别人的业务或接手新业务的测试工作，或许你对这种业务有经验，但也会遇到从来没接触过的业务，这样我们如何开展测试工作，不管是你做工程效能还是业务质量，开展任何工作的第一步都是熟悉，熟悉业务，熟悉技术，熟悉团队协作，对于如何熟悉这一点，我会从这几点出发
业务理解 - 要入手一个业务首先是要了解前世今生，要知道这个业务存在的原因，定位是什么，发展至今现在又是怎么样的形态，什么样的地位，将来的发展方向是什么，这好比需要先认清自己
- 我们的业务如何交付给用户使用，可以从发布流程入手，其实业务团队里面的流程，不管是测试流程还是研发流程，最终结果都会表现在发布流程，发布流程可以推导出业务团队用的是什么研发流程，用什么测试流程，同时通过发布流程我们可以了解到系统的部署，从而推导出系统架构，依赖调用关系等，再深入推导出业务使用的技术栈，发布策略，人员水平等，所以我每加入一个新团队或接手新业务，我习惯性的会看版本如何发布，发布流程是怎么样的，以此为线索，很容易就可以把业务团队的协作能力和技术能力了解清楚，这个就是了解业务内部
- 用户怎么使用我们的业务，其实就是了解我们业务的外部情况，我们的目标用户是谁，表现形态如何，我们的业务为用户产出了什么，解决了什么，大家可以试一下通过上面的一些方法是否会更容易了解一个业务甚至一整块业务
- 对于业务了解完之后，那接下来才是测试工程师的主菜，我们怎么去做测试能力建设
测试能力建设
测试能力建设有一个关键点，就是如何把测试肉身投入转换成测试能力投入，我们是人，但我们也是能力的一种，但能力未必是人，他可以是技术，可以是流程，简单地说就是怎么把人力转换成技术能力和流程化
-
在测试能力建设的工作投入中，直白的目标就是业务需要什么我们就做什么，所以我们还是需要找到适合业务和团队的方式，传统的IT公司习惯走V模型或是双V模型，到了互联网行业，大家都开始强调要研测一体，devops，测试左移右移等，在我的经历中大部分在互联网行业，所以习惯性从方向上会考虑当前业务和团队要如何左右移，如图中所示
测试能力建设 测试左移强调的是尽早介入测试，提前发现问题
这时候还是从工程化和流程优化那两个点去打，我之前所在的业务，我投入测试时一般会先规范代码的管理分支，在多位研发并行开发的时候我们需要怎么规避一些由于切分支带来的问题，我们明确好开发分支，提测分支，发布分支和主干，测试只接受提测分支的版本测试，发布的版本只能用发布分支等，同时接入静态代码扫描等代码精准测试的能力，研发每次提交代码后基本上都经历了一层代码扫描的质量保障过程，同时在接口和端功能层面，作为测试我会去建立自动化回归测试的能力，我们可以用接口测试框架或UI测试框架等自己手打自动化测试用例，把持续集成的流程建设起来，也可以通过更成熟的工具或平台如线上流量引流回归等等，其实就是通过大规模的自动化等能力来从最根本的代码层面，接口层面等保障起来，为了就是尽可能不带bug提测，所以这个过程就是要做如何把这些自动化的能力建设起来，缺乏工具和平台的时候，我们就得去找合适的工具和平台，找不到就得自己设计开发，这也是作为测试开发乃至所有的测试工程师都需要具备的能力，有了工具和平台之后就结合业务的特征进行相应能力的建设，做到懂得用，懂得做，懂得落地
-
在流程上，左移的方式是通过提前交付测试用例或测试方案实行研发自测，为了还是不要把bug带到测试阶段这个目标，或许研发会质疑说研发来测试，要测试来干嘛，我们从ROI的角度去思考，研发自测花大概0.5到1个人天，但如果出现bug导致版本阻塞，可能影响的就不是0.5到1个人天，测试包来来回回几次，测试找bug，定位bug原因等，一不小心几天就过去了，这时候就会出现版本延期的风险，所以我们要把问题扼杀在摇篮之中，这需要代价，但这也给我们带来了更好的结果，研发自测和产品验收很大程度就是依赖了测试用例或测试方案，所以这个时候我们就不仅仅是把当前的需求要点或技术改动点给覆盖，当然不是说所有的用例产品研发都要过完，测试工程师是测试执行的兜底，研发基本上都是把核心链路和功能过完后就提测，这时我们更多的是实践探索性的测试，测试执行和研发分工，节省的时间做更有深度的测试工作，包括把版本的一些测试需求自动化，或者考究安全性性能等，我在写测试用例或方案的时候基本上会使用这个大纲
测试大纲 每个版本的测试，不是简简单单把测试用例执行完，功能执行完就完成的，每做一件事情，必须明确这件事情的目标或背景，因为接下来所做的一切都会围绕着这个目标去开展，对于目标不清晰的，设计出来的方案或用例，存在偏差的概率就会增大，也就会存在漏测的风险，二来我们需要明确版本的改动范围，尤其是多组件多服务组成的业务，在加上相关依赖关系，这个是可以用来明确我们的测试范围，测试成本永远都是有限的，要做到即充分又低成本的那就需要明确测试范围，目标和范围都明确之后我们就可以进行相关的用例设计，需求的用例，技术性的用例，都需要在测试用例中体现，具体的如接口的逻辑是如何的，缓存的逻辑如何，如遇到数据迁移等情况，我们也需要把对应的数据验证和数据同步用例等设计好，
把测试阶段的验证都设计好之后，那就是发布阶段和运营阶段的一些质量保障手段，大家都了解有灰度发布，流量隔离，线上监控，线上验收等一些测试能力，这些就是在测试右移中采取的一些质量保障策略，所以在设计阶段我们就要把作为线上验收能力的一些打点和日志输出设计好，监控项给明确好，甚至设计好质量相关的数据报表，通过这些采集监控数据进行分析和配置告警，来观察版本发布的情况，从而建立了一个线上的业务健康度模型
-
有些情况确实是通过测试右移的方式来执行，我在做中台业务的时候，经常遇到业务方由于环境等原因，功能必须在线上验收，所以这个时候我们就需要有线上验证的能力，线上验证的原则是尽可能的不要影响到原有功能和使用业务的用户，这个就需要做好很好的隔离，所以从研发一开始的设计就从线上可测性角度就需要考虑到这一点，功能做好隔离，数据做好隔离，一旦出现问题，我们有相对应的风险预案，如何清除脏数据，如何将功能降级等，前期的设计都要考虑好，发布完成以后我们还需要考虑运营层面的事情，运营事故在各大互联网公司中也是屡见不鲜，比如暴露了一些敏感数据等，对于这方面作为业务的测试我们也是需要建立其相关的防范机制，不管是流程上和从技术上去杜绝，这往往也会在我们的风险预案中体现，当然故障都没有是最好的，但一旦出现故障的时候我们就要能够快速的发现和解决，这也是我们作为测试能力建设中的一个重要环节，下面就是我根据上面的一些方法论所建立的项目流程
研发流程
小结
- 是否会发现，一旦把这些能力都建立起来，测试人员的投入就会变成测试能力的投入，测试工程师就是测试能力的体现，测试能力的建设者，只要安排人员去执行使用测试能力即可，就不一定需要测试工程师的肉身投入，让业务都具备自我质量保障的能力，从根本上的提效和降低投入成本
- 纵观我上文所说，其实我作为测试工程师大部分的时间都是在做测试设计，测试设计体现一名测试工程师的产出，测试执行不一定需要测试工程师来做，但需要你做好的是在测试能力方面的建设，质量是整个团队的目标和责任，测试工程师就是专门为这个目标出谋划策的，我们认清出自己的职责，把自己的思维转换过来，把肉身转化成能力，把人力成本变成技术成本，这是作为测试工程师价值的体现，希望通过此文，能够对大家在测试工作上有一点点帮助，谢谢
