我对版本的理解

起因很简单，因为要在节前上线一个版本，而且是必须上线（无论如何、死都要的那种 ），为此研发同学从下午 5 点开始部署，直到晚上 8：30 还没搞定，其中缘由有网络、服务器等问题，这里就不细细的吐槽了。此时此刻的我真的想吟诗一首表达我内心的愤懑与感慨（在部署上线的过程中还因为多次的催促受到了研发大佬的批评和教育 ），闲话不多说下面谈谈我对版本的理解，希望能看到此文的同行各抒己见，小弟不才愿抛砖引玉。

首先来谈谈版本

我理解的版本就是在固定的时间节点，会解决哪些问题，需要测试研发评估版本的影响范围，从而创建一个版本节点并发布上线，最终会给用户带来什么样的影响。

很遗憾自从我进公司到现在，这里从始至终都没有版本这个概念。不对应该是没有子版本的概念，一味的都是以项目来命名的版本，而不是如在某某分支解决了几个问题而发布一个版本。

难道这种处理方式对研发没有影响吗？至少觉得对测试是有影响的吧？比如线上出现了生产问题，在测试环境复现的时候我们不应该是首先从一个大版本开始入手，然后再从大版本中的小版本开始一个个复现最终找出这个 bug 的源头，最终定位这个 bug 是出自研发改出来的 bug、测试漏测的 bug、测试未执行的 bug？？？（黑人问号）,这只是一方面。

另一方面版本的管理带来的好处就是，研发、测试、项目经理都能知道哪个版本的 bug 少、稳定性高，在我们测试需要做回归测试的时候不仅仅是功能性的回归，更需要针对性的回归。

接下来再讲讲上线

1. 不是为了上线而上线

为什么要说这句话？因为发现我们有项目经理这个角色，这个角色真的是让我头疼啊（这里不是吐槽项目经理，请轻拍）。

恕我头脑简单、四肢发达，难道我们测试对测试的工作量评估、研发对需求的拆分实现排期都要按照项目经理的要求而压缩吗？

oh fuck！! 你说上线上线就上线

oh shit！！解决不了的问题你说下个版本就下个版本，难道我们测试、研发对需求的理解、实现、难度会不了解？？

大家都说测试是产品质量最后的一道防线，在以前待过的公司中只要测试、研发发话上线有风险并给出风险评估则不上线。其实不然，我觉得做一个产品至少每一个参与者都是一道防线。任何一位参与产品建设的都可以提出自己疑问、建议，不只是简单的理解产品就是研发实现、测试来保证质量、运营和客服的需求反馈、产品经理对需求的升级改造等等，就好比自己的孩子（当然谁都希望自己的孩子自己管）自己管不好的时候当然就会有别人（亲戚朋友、老师、甚至陌生人）来替你管，只要你能虚心接受我相信你的孩子会越来越优秀。

1. 上线的原则

这个话题有点大了，相信互联网公司都有一套自己的上线原则，比如节假日不上线、周末不上线等等。为什么要给出上线原则？

一个是上线后万一出现了生产上的大问题公司就需要投入人力去复现、定位、解决问题，这样给用户的体验是不是极大的打击呢？万一是地推的过程中发现我靠，他娘的注册都不行怎么办，是不是啪啪的打脸了（当然这种几率非常低）。

还一个就是有原则就可以规避很多不必要的问题。比如像楼主这种不想加班的狗

1. 上线的环境预估

这应该是最难的一种吧，虽然现在有预生产环境，因为我们不知道环境究竟会发生什么。除非遇到电缆被挖断了之类的，这就尴尬了，楼主在这一块经历的比较少就不多说了。

最后

好了，吐槽到此为止，能说到这个份上我的心情也平静了。另外插一句公司（平安某子公司）组织架构调整，遗憾的是我被划分到其他的测试团队，我敢保证不是因为技术能力原因（话不多说。。），还是希望能找到一份稳定的（毕竟快要当爹的人了），最好还是平安的子公司（要求太高了 ）。多谢多谢