__
编者按： 本文作者为孙高飞（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
点击获取更多信息
标签：工程师,环境,RD,开发,测试,产品质量,我们 来源： https://www.cnblogs.com/hogwarts/p/15820926.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。