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

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

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

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

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

3.1 从流程上谈质量
file
上图描述的是我们一个需求的生命周期,黄色部分是我作为团队里的一个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 从效率上谈质量
file
上图是我们接口自动化平台的主要功能,QA在平台中编写接口自动化用例后,即可用于日常监控和版本回归,从而尽可能减轻一部分重复工作。编写的用例要求尽可能适用于4个环境,且需要随着产品迭代不断增加新功能的用例,保证覆盖足够多的场景。

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

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

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

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

第一点,从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等等。

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

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

分类: 测试

发表评论

电子邮件地址不会被公开。