首先提个问题：你觉得在测试工作中，最让你抓狂的一件事情是什么？如果问我的话，我会毫不犹豫的说：最难的应该就是每一次测试都需要开发协助部署环境了吧~

尤其是遇到那种时间紧、任务重、质量要求高的工作，开发本身都自顾不暇时，这个时候测试人员只能追在运维和开发的身后让他们帮忙部署测试环境。

看起来很『清闲』的测试

一般公司测试环境的部署程序一般是这样的。等待开发完成之后提交代码，然后打成war包传给运维，由运维统一在服务器上部署（有的公司开发也负责部署环境）。部署完成后，再由测试人员来进行测试。

那么问题就来了，开发在努力写码的过程中，原本预估3天能完成的工作，结果花了5天完成。在这多余的2天时间测试人员看起来就很『清闲』。

等到测试环境部署完成之后，由于之前开发不小心的多用了几天时间进行开发，而上线时间迫在眉睫。这个时候就只能辛苦测试人员加班加点并且保质保量的完成测试工作。

这悲伤逆流成河

测试人员去催开发打war包的时候，开发会说：『你别急，我总得写好再给你吧！现在给你，你也没法测啊~ 而且你到时候随便点点点就好了。』完全不给测试反驳的机会。

你要和开发聊一聊测试的重要性吧，开发说：你工作再重要，也得等我写好吧~现在给你你也没办法测啊~等拿到war包之后，距离上线的时间已所剩无几了。于是只能针对重要地方进行突破性测试。

急匆匆上线之后，客户不管反馈了任何问题，产品经理一定第一个来找测试，很愤怒的说：你是怎么测的？一堆bug。

当你一本正经的解释，是因为无法保证测试时间时，得到的答案总是尽量保证测试时间。但是悲伤的是，下一次悲伤仍在继续。测试完全陷入死循环中。

测试和开发之间的矛盾

出了问题吧，测试来背锅。没出问题吧，是开发代码能力强。这年头，做一个点点点的测试，真的是太难了。

一边是测试时间的极大压缩，一边是需要保质保量的完成工作任务，这是两个非常矛盾的点。而这两个矛盾也一度让测试和开发之间的关系不那么融洽。

其实开发小哥哥也是很委屈的。我们也不想占用测试人员的时间啊，但有的时候遇到新的问题，解决起来也是需要时间的。

解决问题是根本

那有没有一种方法，让开发人员这边写出了一部分可测代码后，交由测试人员进行测试。那这样搭配，相处就会很融洽啦，再也不需要因为测试环境的问题而有争执啦！

你别说，还真有这项神奇的技能。学会jenkins之后，自己搞定测试环境。开发只需共享源码，其他的事情测试人员自己搞定。再也不用苦哈哈的等测试环境了！

“学会 Jenkins 自己部署测试环境”不仅仅是一项技术技能，更是测试人员实现职业转型、掌握工作主动权、迈向“测试开发”或“质量保障工程师”角色的重要里程碑。

测试开发快速提升技能水平的路径只有一个：找到领域专家，学习过来人的踏坑经验，并结合业务实践落地，内化成自己的能力并持续优化。站在巨人的肩膀上前行，自然可避免走很多不必要的弯路。