​2020 年过的很快，眨眼间就到了 2021 年。最近看了几篇行业同僚的年终总结，想着自己也要回顾过往，总结得失，看看能否指明自己接下来一年前进的方向，于是有了这篇文章。

前段时间参加了公司的培训《如何做好一场分享》，今天就直接拿其中部分理论来试试手吧。直接从主题开始说起，要讲清楚 “如何体现测试工程师的价值” 这件事，我们分三个层面来谈，即 Why、What、How。

1. Why
   为什么要谈论这件事，因为工作中会面临很多棘手的情况，无法直接体现测试工作的价值。比如，发现的 Bug 越多是不是代表隐藏的 Bug 越少，产品质量越好，不一定；发现的 Bug 很少是不是代表隐藏的 Bug 越多，产品质量不好，也不一定。拿这个例子举例是因为测试工程师日常的绝大多数工作都在于此，如果平时工作很努力，但是产品质量却不是很理想，会让人产生挫败感，从而自我怀疑，我到底有没有价值。

2. What
   那么测试工程师的价值是什么，最重要的是保证产品质量。但是这里又有一个问题，把整个产品质量抛给测试团队来兜底是不可取的，测试团队只能保证产品质量的下限，产品质量的上限是整个团队共同努力的结果。撇开质量这一点，另一点则是效率，也是老生常谈的测试开发比了，如何做得既快又好，是体现自身价值的关键。

3. How
   围绕着既快又好这一关键点，接下来我会结合过去这一年的工作经验，来谈谈我们的工作是如何开展的，哪些做得好的需要继续保持，哪些做得不好的需要改进。

3.1 从流程上谈质量

上图描述的是我们一个需求的生命周期，黄色部分是我作为团队里的一个 Member 日常需要负责的工作。解释下 “PFB” 即 Preview Feature Branch，因为同时会有很多个需求在进行开发，所以会有很多个分支在测试，最后将一个版本内的所有需求合进版本分支。

在需求终审结束后，测试需要及时输出测试用例，以及提供 P0 用例用于开发自测，保证提测后主流程畅通，至于如何制定提测标准暂且不表。

Test PFB 环境测试结束后，会有一个 QA UAT PFB 验收环节，该流程主要是为了保证交付的 UAT 版本质量，此前因为 UAT 分支无人管理而频遭投诉，无奈之下只能投入部分人力进行质量控制。

接下来到了发版阶段，需要进行 Staging 回归测试，Liveish 环境验证，再部署到 Live 环境，则该版本需求生命周期结束。

为了保证迭代速度，每个版本之间都是间隔并行的。什么意思呢，假设有 A B C 三个版本，C 版本的需求本周处于测试阶段，而上一版本 B 的需求本周处于 UAT 阶段，上上版本 A 的需求则本周需要发版。

细心的同学可能会发现，一个需求要在多个环境中重复测试，即使质量有所提升，但对 QA 来说是非常痛苦的，且没有太多人力可以投入，所以目前在 UAT 和 Staging 阶段对于新需求只保证主流程，旧功能则依靠自动化保证质量。

3.2 从效率上谈质量

上图是我们接口自动化平台的主要功能，QA 在平台中编写接口自动化用例后，即可用于日常监控和版本回归，从而尽可能减轻一部分重复工作。编写的用例要求尽可能适用于 4 个环境，且需要随着产品迭代不断增加新功能的用例，保证覆盖足够多的场景。

自动定位系统的作用是如果有用例失败，根据请求的全局唯一 Trace-ID，去对应容器中将日志搜索出来，写入用例的结果中，以便于 QA 定位问题，减少查日志的工作耗时。

PIC(Person In Charge) 系统则是配置了各个模块对应的 DEV PIC，如果有用例失败，则会自动发送邮件提醒 DEV 处理。为了避免打扰，以及误报的情况发生，此处增加了人工确认环节，目前并没有开启自动发送邮件功能。

整个平台的初衷是想结合接口自动化打造一套监控体系，一是保证各环境的稳定性，二是可以避免日常测试工作因为依赖方的各种问题造成的阻塞。但实际情况却并没有因此改善，首先对于监控任务中失败的用例，QA 完全没时间去处理其为何失败，其次依赖方的问题目前仍旧要靠私下解决。所以目前平台最大的价值还是在于 Staging 阶段的自动化回归。

3.3 从创新上谈质量

如今测试左移右移概念提及的比较多，核心思想有两点，一是尽可能早的发现问题，二是时刻监控产品质量。

第一点，从 3.1 的流程图中，参与需求终审和组织用例评审都是为了确保产品，开发，测试对需求的理解达成一致，尽可能避免产品设计和功能实现不一致的情况发生。

上图中，黄色部分是我们当前已开展的工作。静态代码扫描其实是有做的，结合 GitLab 的扫描插件在 Commit & Merge 时进行扫描，但目前形同虚设，并没有人关注扫描结果。

单元测试，实际上完全依赖于开发对于自己的代码是否有 Ownership，我认为依靠 QA 去做单元测试是不现实的，且效率非常低。除非说实现 TDD(测试驱动开发) 模式，抛开 TDD 不谈，光推行单元测试就是一个非常难的事情。

接口测试，由于目前已经有比较完善的用例集，想把接口测试结果作为条件之一放进提测标准中。但是目前接口测试没有集成到 Jenkins 中，且提测标准应该达到多少通过率，如果达不到，失败的用例又该谁来处理，想来想去发现这些事还是落到了 QA 身上，实在是分身乏术。

代码覆盖率，曾经有尝试过，结合 Coverage.py 做了一个 Demo，也算是实现了想要的功能。但是不太了解 Python 项目的构建方式，如何融入 Gunicorn 中，如何接入项目代码中也没搞清楚，且后来团队技术栈由 Python 切换到 Golang，由此被搁置。

线上日志监控，当前主流的做法是 ELK，即 Elasticsearch、Logstash、Kibana 三者结合，分别负责日志的搜索、存储和展示。但实际上这些仍旧是不够的，ELK 只是提供了一个日志搜索平台，真正要做到监控，还需要 Node Exporter、Prometheus、Grafana 三者合作，收集日志中的数据进行展示，如接口 Latency、QPS、200、400、500 等等。

总结

对自己的工作进行了一番梳理和回顾，能改进的地方还有很多，能做的事情也还有很多。一方面因为自身能力不足，另一方面也因为时间有限，许多地方仍旧没有做好，希望新的一年能够有所进步。

彩蛋：可能有小伙伴疑惑没有提及到性能测试、兼容性测试、UI 自动化这些。UI 自动化有在实践，但还没有真正派上用场，是一个做不好可能会有负收益的活；由于我就职于电商公司，每次大促前会有性能测试；兼容性测试由于 UI 自动化没开展，自然无法结合 UI 自动化做兼容性测试，处于放弃状态，虽然我也捣鼓过 STF 这玩意儿。