职业经验 如何体现测试工程师的价值

归云乡 · 2021年01月17日 · 最后由 goodpassion 回复于 2021年01月28日 · 20109 次阅读
本帖已被设为精华帖!

​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 这玩意儿。

共收到 15 条回复 时间 点赞
恒温 将本帖设为了精华贴 01月18日 00:15
仅楼主可见

都是实践出的真知。

确实,深有体会

跟我这这边的状态很相似呢,目前自动化有一定规模了,在考虑测试左移右移的事,但是很尴尬的一点是左移单元测试搞不过开发,右移线上监控搞不过运维😅

小酷 回复

搞不过就加入他们

小酷 回复

单元测试没那么难,只不过需要跟开发统一技术栈。不过单元测试开发写 ROI 更好

张狂天 回复

就是把自己日常的工作内容和一些问题写下来了哈

😜 经历过体会才更深刻

小酷 回复

😅 哈哈,我目前也这样,而且公司里很多事其实也轮不到 QA 来做,线上监控都给运维了

抛去一些术语定义不同,这个流程和参与项目的工作流程相似度 90%,握个小手
这有几个小问题点:
3.2 中对于失败用例解决是否有更好的解决方案?这块目前需要投入比较多的人工去维护(这里涉及到底层误报,网络抖动误报,依赖方问题误报等),误报一多,没有及时维护,对于监控麻木,不及时跟进,也就体现不出对应的价值
3.3 接口自动化可以做为服务端的准入测试的前置条件之一,这块会有个问题,旧功能的回归有脚本,新的特性接口人员来不急编写脚本输出给开发作为自动化自测,那么这块是否有好的实践解决方案?以及开发自测过程,出现失败用例问题的跟进判断等?

Qiang 回复

第一个问题:我们目前失败的用例只做了一遍自动重试,在 3.2 最后也提到了目前这套监控体系也确实没有起到改善情况的作用,当前对于监控任务的结果实际上也没人关心,更多的作用还是用在 Staging 阶段的版本回归,所以没法提供解决方案给您。
第二个问题:新的 feature,在 3.1 中提到了会给到开发 P0 用例自测,并没有录入接口平台中,提测标准仍旧是旧的功能回归用例通过率;开发自测过程中,出现失败用例在 3.3 中也提到了,目前没有想好如何跟进,如果 QA 来做,那其实又加重了 QA 的负担,在提测准入之前就需要做工作,并没有达到提高提测质量的目的,反而流程又变长了,所以目前这一项也没有放到准入流程里面。

Qiang 回复

确实很像,你遇到的问题,我目前也没有很好的方式解决😅

总结的挺好,我公司的现状是项目经理说很多加密算法对测试都不能公开,所以接口测试没有条件,连接口请求 URL 都是加密的。UI 自动化在项目初期做过探索,后面没有继续做下去,基于现状,可能还是要继续弄 UI 自动化,至少做到稳定功能的 UI 自动化。关于监控,基本都是开发弄的,测试能力不足,但是确实测试可以多方面去多学习,提升。

liuau86 回复

接口测试开展不了那感觉处境挺难的,老哥加油

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册