前言

我们应该都有过这么一段迷茫期，不论我们设计多少测试用例，编写多少自动化测试脚本，执行多少测试计划，产品质量依然没有按照我们想的那样发展。原来开发延期的依然延期，原来提测 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 工程师，团队工程化工程师等等。产品质量已经不是单打独斗的天下了