热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

测试工程师的转型探索:如何让产品质量变得更好?

__编者按:本文作者为孙高飞(ycwdaaaa),霍格沃兹测试学院特邀嘉宾,某人工智能企业资深测试开发工程师。原文标题《测试开发之路--让我们把产品质量变得更好(测试人的转型探索)

__


编者按: 本文作者为孙高飞(ycwdaaaa),霍格沃兹测试学院特邀嘉宾,某人工智能企业资深测试开发工程师。 原文标题《测试开发之路--

让我们把产品质量变得更好 (测试人的转型探索)》h
ttps://testerhome.com/topics/6557



前言

测试工程师应该都会面对或者经历过这么一段迷茫期:

不论我们设计多少测试用例,编写多少自动化测试脚本,执行多少测试计划,产品质量依然没有按照设想的那样发展。原来开发延期的依然会延期,原来提测 Bug

多的照旧不变,线上漏测的仍然会漏测。我们貌似都已经习惯了这些场景:延期、压缩测试时间、需求不对、部署事故、漏测等。

直到后来我们知道了 Google 的工程生产力团队,知道了 CI、CD、DevOps,知道了光靠 QA

来保证质量是不行的...。越来越多的新概念冲击着原有的质量保障理念,而随着很多公司的 QA

大部门被裁撤,测试工程师必须思考如何不被淘汰?所以我们要改变,要进化,要去做以前没想过的事。


以质量为中心,发散式工作

之前我也说过这种理念,我希望自己能不仅仅局限于测试行为这一条路。任何能提升质量的途径我都要尝试。之前的文章也写过这样一句话:


我开始了各种各样的,无所不用极其的野路子来提升质量,提升生产力。


提升产品质量有两种路子,一种是测试行为,这是最直接的方式。这一点我们研究了很久我不多说了。只是在此之外,我们仍然能发现很多问题,列几个常见的:

1.如果 RD 开发延期了,压缩了测试时间。我们有足够的时间去做测试么?2.如果 RD 提测的质量不好,全是bug。我们有足够的时间把 bug

都修完再重新测试么?3.如果系统过于复杂,过于高科技,有些东西我们测不了。RD

能够自测么?4.如果都开发完了,产品经理才发现与需求不符,我们有足够的时间重新来过么?5.如果团队每个人都因为这些原因疲于加班。我们还有时间创新么?

测试工程师总会面临一些我们自己控制不了的风险,例如开发延期,提测质量差。也许以前我会说那是 RD 的事,我不

Care。但是最后加班加成狗,质量还上不去的状况就会找上我。 所以,我想测试工程师得做点什么,把技术能力转变为生产力,提升团队所有人的效率

我们需要探寻第二条路子去解决这些问题。它是软性的,是间接的,是以提升生产力和效率的方式,间接的解决上面我们遇到的风险。


技术能力转变为生产力

我以前写过 CI

的文章,详细到每个分支的策略是怎么制定的;也写过环境管理的文章,详细到开发,测试,预演,预上线环境每一个都怎么做的;还写过单元测试架构,详细到

Jenkins 上每个配置如何设置。我还做过一些别的零散的,运维相关的事务。

通过这些综合的努力实践,我发现 测试工程师要想让其他人对质量负责,就得给他们提供更简单的方式 。例如:

1.我们希望 RD 能够自测,那我们就得有简单的方式让 RD 自测,太麻烦太耗费时间是不行的。2.我们希望 RD

不拖延进度,那就别让琐碎的环境问题拖延他们,别让需求不明造成他们返工。3.我们希望产品人员更好的预演产品,设计需求。那就给他们提供一个保持代码更新并稳定的环境。4.我们希望运维人员更好更快的部署产品,别在部署时期出问题。那就严格的按运维的标准去编译,出包,部署,测试。保证到了运维手里的东西,一定是可靠的。5.我们希望运维和

RD

有更多的时间提升架构,监控,运维自动化。那就让他们从琐事中解放出来。例如我承担了除生产环境之外的一切环境部署自动化管理、所有模块的自动化编译出包的工作。

举个详细点的真实例子。

也许对大部分团队来说,自测和联调一般不是什么问题,搭建个环境还不是分分钟的事。但我们团队不是:不仅业务复杂、架构复杂、配置复杂,还是多语言构建。每个模块的编译和部署方式可能都不一样。靠各自模快的

RD 一起拼是拼不出几个环境的。最终大家在一个环境上互相踩踏,互相影响。

我们期望 RD 能从整个产品的角度来设计,来自测。希望除了单元测试以外他们能从 UI

上从产品的角度测试。但如果没有一个专属的、他个人的环境让他随意破坏,那是绝对不靠谱的。所以我们才提供了一套以 Docker

为基础的自动化部署开发环境的机制。注意这里是开发环境,不是测试环境。

有什么区别呢?区别是:测试不需要编译环境,不需要源代码,测试要模拟真实环境所以测试是按产品环境的结构部署的,所以测试只需要部署包。但开发不是,它希望这个环境能供他随意折腾。可以随意编译源代码,可以随意在环境中开发。那是他的实验室,怎么搞他说了算。

所以,我们给开发人员的环境都是完整的编译环境+部署环境,有源代码、ssh、MySQL Client、Git Client、Hadoop

Client、Spark Client,定制了各种方便的脚本拉代码,重启单个服务,重启所有服务等等。

同样,为了让 RD 能自己触发回归测试。我们在 Jenkins 上配置了相应的

job,一个按键就能让我们的自动化测试项目跑到他的环境上测试。测试报告里有每一步骤的日志,失败截图,环境信息。后来 case

越来越多,运行越来越慢,一套测试下来2个小时,RD 等不起。我们就分布式处理,从 2 小时降到了 20 几分钟。后来用这个 job 的 RD

越来越多,排队时间越来越长,所以我们计划着加资源,加机器。不让 RD 排队等待。

于是我们的提测质量越来越好,因为 RD 自测的越来越好。


与人方便就是与己方便

也许以前我会觉得这些事让他们自己操心去好了。但后来我发现,只有让研发能开心的自测了,我自己才能开心的测试。否则一定是到提测阶段,我就痛苦的像条狗。恩,与人方便就是与己方便。

•我们提升了 RD 的开发效率就能让他们更快的完成产品开发,我们也有更多的时间测试-- 与开发方便就是与己方便 •我们让 RD

自测的更快更方便就能提升了提测质量,减少我们的工作量-- 与开发方便就是与己方便

•我们给产品人员的预演环境做蓝绿部署,永远有最新的稳定产品给他们用。让他们及时纠正需求,更好的设计产品,减少返工-- 与产品方便就是与己方便

•我们按运维标准承担了所有模块的编译出包的自动化,让运维在何时何地都能一键拿到他们想要的包,让他们更快更好的部署-- 与运维方便就是与己方便

•我们承担了除产品环境外所有环境的部署和维护自动化,让所有人都从这些破事中解放出来,专注自己的事情让产品变得更好-- 与人方便就是与己方便


总结

恩,这是我想到的方式,它没什么名字,没什么固定的套路。它就是一个思路,一个用自己的技术去解决团队中一个一个痛点的思路。也许在你的团队中,我碰见的这些问题都不是问题。但总有属于你自己团队的问题。找到它,解决它,别让他们成为影响你产品质量的根源。

我受谷歌影响颇深,所以路子十分像他们的工程生产力团队,但略有不同,我期望能由我们来辅佐甚至打通 DevOps

的路径,说不定以后会有一个新的职位诞生,例如叫什么 DevOps 工程师,团队工程化工程师等等。
产品质量已经不是单打独斗的天下了。 _

(end)_ **** ****

**

**

- 能力进阶 -

全面提升软件工程质量和研发效能,已经是很多互联网巨头企业如华为、阿里巴巴、腾讯、小米、京东等产品技术团队的重要目标。

从人才招聘纬度可以看出, 当前 BAT、TMD 等大厂测试社招,已经几乎不再招募传统测试工程师,而基本 只招测试开发工程师。

随着敏捷开发、DevOps、持续交付的流行,软件测试人员必须成长进阶为测试开发工程师,同时具备一定的开发和运维能力。

测试开发工程师会通过 测试左移

,更深入介入开发工作,提前与开发人员一起制定测试计划,推动代码评审、代码审计、单元测试、自动化冒烟测试、测试精准化分析以及研发自测等来保证研发阶段的质量。

测试开发工程师会也通过 测试右移 ,参与配置部署,将自动化测试用例配置到持续交付链中,并全流程监控发布后的应用质量。

总之,作为 DevOps 关键角色,测试人员将推动开发和运维共同实现高效交付高质量产品的目标。

为了帮助传统测试工程师以及在职测试开发工程师成长进阶,同时也为了解决互联网企业的测试开发人才困境,霍格沃兹测试学院与 TesterHome 社区联合发起了「

中高级测试开发工程师名企定向培养计划 」项目。

资深测试架构师用 4 个月项目实战,带你快速提升测试开发实战能力,挑战 BAT 高薪 Offer!

报名方式 :扫码加小助手微信,回复「 名企定向 」入群咨询。

报名方式 :扫码加小助手微信,回复「 名企定向 」入群咨询。

点击“ 阅读原文 ”,了解更多详情。

- 利 ** ** -

关于测试工程师的进阶和成长痛点, 请在评论区留下你的感言,关注霍格沃兹测试学院公众号,并转发文章到微信朋友圈

。小编会挑选一位精彩回复者,赠送定制版好礼( 五选一, 截图证明)。

在霍格沃兹测试学院

与优秀的测试开发工程师并肩

来霍格沃兹测试开发学社,学习更多软件测试与测试开发的进阶技术,知识点涵盖web自动化测试 app自动化测试、接口自动化测试、测试框架、性能测试、安全测试、持续集成/持续交付/DevOps,测试左移、测试右移、精准测试、测试平台开发、测试管理等内容,课程技术涵盖bash、pytest、junit、selenium、appium、postman、requests、httprunner、jmeter、jenkins、docker、k8s、elk、sonarqube、jacoco、jvm-sandbox等相关技术,全面提升测试开发工程师的技术实力

QQ交流群:484590337

公众号 TestingStudio

点击获取更多信息



推荐阅读
  • 从0到1搭建大数据平台
    从0到1搭建大数据平台 ... [详细]
  • 服务器部署中的安全策略实践与优化
    服务器部署中的安全策略实践与优化 ... [详细]
  • 本文介绍了如何利用Shell脚本高效地部署MHA(MySQL High Availability)高可用集群。通过详细的脚本编写和配置示例,展示了自动化部署过程中的关键步骤和注意事项。该方法不仅简化了集群的部署流程,还提高了系统的稳定性和可用性。 ... [详细]
  • 技术日志:Ansible的安装及模块管理详解 ... [详细]
  • HBase在金融大数据迁移中的应用与挑战
    随着最后一台设备的下线,标志着超过10PB的HBase数据迁移项目顺利完成。目前,新的集群已在新机房稳定运行超过两个月,监控数据显示,新集群的查询响应时间显著降低,系统稳定性大幅提升。此外,数据消费的波动也变得更加平滑,整体性能得到了显著优化。 ... [详细]
  • 本文详细介绍了如何在Linux系统(以CentOS为例)上彻底卸载Zimbra邮件系统,包括停止服务、删除文件和用户等步骤。 ... [详细]
  • Python 数据可视化实战指南
    本文详细介绍如何使用 Python 进行数据可视化,涵盖从环境搭建到具体实例的全过程。 ... [详细]
  • Hadoop平台警告解决:无法加载本机Hadoop库的全面应对方案
    本文探讨了在Hadoop平台上遇到“无法加载本机Hadoop库”警告的多种解决方案。首先,通过修改日志配置文件来忽略该警告,这一方法被证明是有效的。其次,尝试指定本地库的路径,但未能解决问题。接着,尝试不使用Hadoop本地库,同样没有效果。然后,通过替换现有的Hadoop本地库,成功解决了问题。最后,根据Hadoop的源代码自行编译本地库,也达到了预期的效果。以上方法适用于macOS系统。 ... [详细]
  • 本文深入探讨了NoSQL数据库的四大主要类型:键值对存储、文档存储、列式存储和图数据库。NoSQL(Not Only SQL)是指一系列非关系型数据库系统,它们不依赖于固定模式的数据存储方式,能够灵活处理大规模、高并发的数据需求。键值对存储适用于简单的数据结构;文档存储支持复杂的数据对象;列式存储优化了大数据量的读写性能;而图数据库则擅长处理复杂的关系网络。每种类型的NoSQL数据库都有其独特的优势和应用场景,本文将详细分析它们的特点及应用实例。 ... [详细]
  • Presto:高效即席查询引擎的深度解析与应用
    本文深入解析了Presto这一高效的即席查询引擎,详细探讨了其架构设计及其优缺点。Presto通过内存到内存的数据处理方式,显著提升了查询性能,相比传统的MapReduce查询,不仅减少了数据传输的延迟,还提高了查询的准确性和效率。然而,Presto在大规模数据处理和容错机制方面仍存在一定的局限性。本文还介绍了Presto在实际应用中的多种场景,展示了其在大数据分析领域的强大潜力。 ... [详细]
  • 本文探讨了 Kafka 集群的高效部署与优化策略。首先介绍了 Kafka 的下载与安装步骤,包括从官方网站获取最新版本的压缩包并进行解压。随后详细讨论了集群配置的最佳实践,涵盖节点选择、网络优化和性能调优等方面,旨在提升系统的稳定性和处理能力。此外,还提供了常见的故障排查方法和监控方案,帮助运维人员更好地管理和维护 Kafka 集群。 ... [详细]
  • 在搭建Hadoop集群以处理大规模数据存储和频繁读取需求的过程中,经常会遇到各种配置难题。本文总结了作者在实际部署中遇到的典型问题,并提供了详细的解决方案,帮助读者避免常见的配置陷阱。通过这些经验分享,希望读者能够更加顺利地完成Hadoop集群的搭建和配置。 ... [详细]
  • 在项目开发过程中,掌握一些关键的Linux命令至关重要。例如,使用 `Ctrl+C` 可以立即终止当前正在执行的命令;通过 `ps -ef | grep ias` 可以查看特定服务的进程信息,包括进程ID(PID)和JVM参数(如内存分配和远程连接端口);而 `netstat -apn | more` 则用于显示网络连接状态,帮助开发者监控和调试网络服务。这些命令不仅提高了开发效率,还能有效解决运行时的各种问题。 ... [详细]
  • 构建高可用性Spark分布式集群:大数据环境下的最佳实践
    在构建高可用性的Spark分布式集群过程中,确保所有节点之间的无密码登录是至关重要的一步。通过在每个节点上生成SSH密钥对(使用 `ssh-keygen -t rsa` 命令并保持默认设置),可以实现这一目标。此外,还需将生成的公钥分发到所有节点的 `~/.ssh/authorized_keys` 文件中,以确保节点间的无缝通信。为了进一步提升集群的稳定性和性能,建议采用负载均衡和故障恢复机制,并定期进行系统监控和维护。 ... [详细]
  • 在Hive中合理配置Map和Reduce任务的数量对于优化不同场景下的性能至关重要。本文探讨了如何控制Hive任务中的Map数量,分析了当输入数据超过128MB时是否会自动拆分,以及Map数量是否越多越好的问题。通过实际案例和实验数据,本文提供了具体的配置建议,帮助用户在不同场景下实现最佳性能。 ... [详细]
author-avatar
半夏✔
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有