很多公司，由于开发对测试的能力不太相信，让测试介入的环节非常少 。什么都帮测试搞定了，测试只需在那等着版本放到测试环境，调试通了，去执行测试即可 。
对一个测试从业者的技能要求 ，以及一位测试工程师的职业发展来说，了解整个研发流程 & 具体执行细节，是必备技能 。特别是这些与测试职业强相关的提测流程 。
<< Git
开始之前，先了解下Git
俗称「代码管理」，研发过程的所有代码，都会提交到Git，可以方便的管理分支、版本、打标签，且能整个团队，多人协作（如果你不知道Git ，同类的SVN你应该知道）。关于Git的分支、标签、版本如下：
玩Git ，你应该知道的几个分支「Master / Hotfix / Release / Develop / Feature」
Master ：一般来说，线上的发布分支，稳定版本 。
Hotfix ：紧急修复分支 。
Feature ：功能特性分支 （一般来说，一个团队会同时存在多个功能特性分支；比如Feature/A Feature/B Feature/C ... ）
注，此处简单待过，对这块感兴趣的，网上检索下文章，非常多 。
<< 拉取提测分支代码
知道分支概念，接下来聊聊如何获取提测的分支代码 。
一般来说，团队内部会约定好，某个版本提测，代码在哪些仓库、哪个分支，需要在提测时，写清楚 。
测试这块，可以直接通过Jenkins，拉取对应仓库、对应分支代码，编辑、打包、部署、发布到测试环境，然后调用一些自动化手动测试，冒烟通过，就可直接进行测试 。
如果测试通过，打算发布到生产时（此文，中间省去了一些步骤；应该还有回归环境、预生产环境 等），先把代码合并到发布分支，Jenkins配置好发布脚本（一般来说，除非是新项目，否则发布脚本，不需要调整），团队内容，协商一个发布时间，Jenkins一键发布到生产即可（发布后的一些流程，此文省略）。
<< 同时开发了多个Feature，如何只发布某个 ？
这里涉及到Git分支规范、版本管理 ，一般来说，独立的Feature，独立分支开发，代码别混淆，方便后续独立发布 。
而且，实际研发过程中，某些Feature，研发过程，暂停或者终止，都是很正常的事 。
注，分支管理，很重要，团队内容，一定要约定一个规范 。
來源：简书
作者：IDO老徐