，潜水了好几年，偶尔上来社区看看 已经很久很久没发过文章了，不知道还有人认识我吗 ，潜水了好几年，偶尔上来社区看看
最近几年主要是在 devops 方向上建树，从 0 开始到 1 再到现在，姑且为 80%？最开始接触 k8s 也是在社区看到飞哥 (孙高飞)，这里先感谢下飞哥。然后就是一发不可收拾，在质量保障体系下推动整个研发部门的效能以及规范，一路坎坷，一路踩坑过来的，到现在稳定运行了 3 年多吧。随着公司业务的不断壮大，目前支撑了 200 多个项目，几百套环境的维护，当然，只是测试环境，生产环境由别的同事负责。推动整个部门的所有环境搭建维护，从代码仓库，到镜像仓库，nexus 私仓，各类中间件及集群，如 redis mysql pgsql mq zk，以及 elk 监控 分布式存储 ceph 对象存储 minio 等等。当然测试方面工作也没落下，比如接口自动化 (核心项目的主要流程)，数据工厂服务，基于 k8s 集群的 sql 安全扫描，jmeter 分布式压测等等，还有一些其他零零散散的，一时间既然想不起来。
基于目前的工作，其实满足项目组的需要了，但是有一点还没做。这些所有的东西需要一个平台来承载，k8s 默默在后台做了那么多事情，居然没有一个数据看板，那怎么行，领导不关注这些数据就等于无用功啊。
可能有的功能。数据看板，devops 部署流水线申请，接口自动化调度 (手写编码接口，通过平台调度，只做调度不做接口自动化，业务五花八门，没法做)，jmeter 分布式压测，测试用例管理 (只做管理，不做在线编写用例，比如 xmind 转 excel 用例后存储在平台)，接口安全扫描，数据工厂服务，可能还有 mock 服务？权限控制等等。总体来说只做资源的整合，数据/文档的落库，有迹可循 (从项目管理上来说)。kpi 刷起来
有时我也一直在想，我的定位是不是偏了，我现在到底是算运维还是测试？有点模糊是吧，但是仔细一看，也挺清晰的，k8s 集群也是为了服务于测试工作，只是从更高的角度来统筹，比如刚开始测试环境的不稳定，在环境不可用占用了太多的测试时间，导致测试时间的不够。那总得解决这种痛点吧，没人搞，也就自己上了，遇到什么问题解决什么，当下团队痛点在哪就解决啥。
我一直认为，测试不只是把业务测完就够了的，拔高到项目整体上，就会有测试左移，测试右移等等，比如从需求评审上规避风险，剔除不合理需求。在用例评审上补充测试点，确定测试风险，范围。再到业务架构，数据库评审等等，可以做的事非常多，每个人可以找准自己的定位，结合公司业务实际情况去做一些事情。测试右移上的监控，预警，复盘等等。
再比如以判断一个 bug 属于前端还是后端。掌握的知识深度，可以更好的帮助开发定位问题，以及作为测试怎么去预防这些风险。
举例: 保存数据时，提示失败，怎么定位问题
又或者是各类中间件的问题，或者又不是必现的怎么缩小范围，跟服务器的网络，进程，线程池等等有关呢
了解的越多，越发现自己啥都不懂，当然，回过头来，也对自己测试的业务更有信心，知道的越多思考的方向也就多了，能从各方面来辅助测试。
再比如，某业务系统新增了一个 ip 访问黑白名单的功能，研发通过拦截器实现的，每次查询黑白名单都是读库的。如果是普通的功能测试业务上测完了，好像就没问题了。但是如果你知道研发是怎么实现这个功能的话，比如拦截器，拦截器是每个请求过来都会进一次拦截器，每次都查库这性能肯定会出问题，通过 review 了研发代码就发现了性能问题，需要研发从缓存 (如 redis) 中读取黑白名单，然后这个黑白名单在缓存中又怎么维护，以及如果业务系统并发很高，redis 也扛不住？那怎么办，这又是另外一个话题了。
说回预防风险，细心发现的话，有很多问题 (bug) 都可以归类，从规范上预防风险，从而为质量保障做更多的事情。
举例: 通过 review 研发的代码，发现很多接口的 response 有问题，比如保存数据，直接插入数据库，而没有对返回值做判断，接口直接返回保存成功。又比如一些权限的判断，默认返回了 true，依照最小权限原则，是默认返回 false，可预知的条件下才返回 true。这些都是可以通过规范来规避风险。
可以说，知道的东西越多，越是感受到自己的渺小。质量保障体系的建设远远不止这些，一个人的力量是渺小的，必须推动整个项目组或者说研发团队参与进来，质量不只是测试的事情，而是整个项目的事，测试只是从各方面来预防风险，规避风险。也希望大家找到自己的方向，做着自己感兴趣的事情，兴趣是最好的老师，不至于半途而废。
共勉
