本篇为【从零开始学产品】系列课第1章第4节
欢迎到公众号菜单栏，获取产品经理课程更多资料

上节课我们说到了，Bug的生命周期，而只有在测试环境和线上环境发现的Bug，才会被称之为Bug。

倒底什么是测试环境，什么是线上环境，开发环境又是什么，三者之间的关系怎么样？

一 从【开发环境】说起

这是蛮荒之地，惟有力量和自然法则永存。

研发领域

开发环境是研发团队的领地，你可以把开发环境当成是蛮荒之地。

在这里，惟有力量和自然法则才是统治者：

野蛮的研发团队成群结队的出现，频繁的发布版本，经常爆发小规模的资源冲突。

荒草重生，各种奇异和鬼怪的现象都会在开发环境出现，就像是一个还未完全成形的小世界。

你看到的一切都有可能是假像，昨天发生的事情，到了今天就可能是完全不一样的结果。

为什么会这样？

第一，研发团队需要提供假数据来保证前后端并发开发。

第二，研发团队经常会出现思维漏洞。

第三，不少研发团队的成员没有持续集成的习惯，总是在自己本地环境中做研发。

第四，开发环境没有版本管理，所有的依赖关系都不够稳定。

第五，开发环境是思想从诞生到落地的重要过程，产品经理的意志最终被研发团队执行并展现在世人面前，研发团队和产品经理的理解偏差也会随之浮现。

破局

在开发环境中，产品经理或者是测试人员需要提前介入么？

按照我们之后描述的敏捷开发来看，产品经理和测试人员不需要在开发环境正式的介入：

特别是当出现开发人员说来不及测试了，所以请测试团队在开发环境先进行测试的时候。

这样会导致更混乱，合理的解决办法是，在明确优先级的情况下，分出迭代，先保证重要的功能进入测试环境。

那么，产品人员和测试人员需要做的是什么？

需要是每天在晨会之后，或者是任意一个时间段，到开发环境去看一下，关键的逻辑有没有错误，有没有重大的偏差，而不是做严谨的测试。

Demo

开发环境对于产品人员和测试人员而言，最重要的环节还在于是Demo。

关于Demo，我们陆续发现有一些误区，特此声明。

第一，Demo是开发团队向产品团队交付，所以Demo的主角是研发团队。

第二，Demo应该依照Story去演示功能，防止有遗漏。

第三，Demo之后就会打Tag（固定代码版本），所以Demo应该是非常严谨的。

从来都没存在所谓的主流程跑通，而是应该一行代码都不需要改动，直接发布到测试环境。

第四，Demo过程中，有一个Demo通过的基本原则：

就是但凡是肉眼能够发现的错误，都应该记为不通过。

而不是说，有几个Minor级别的小问题，可以通过。

第五，下次Demo的时候，可以只演示Demo中出现的问题，以节省时间。

第六，产品人员和测试人员应该参加Demo。

Demo的时候不仅是要看一下研发团队的操作，还应该自己亲自在PC或者是手机上操作。

第七，Demo的数据应该使用仿真数据 ，（而不是随意填写的测试一，测试王八蛋之类的）。

第八，在Demo之前，应该先进行性能测试，UI自检规范和CodeReview，三者通过之后才允许Demo。

第九，如果有Bug的修复，也应该在开发环境先向测试人员演示通过，才允许发布到测试环境，以减少反复发布测试的次数。

第十，Demo过程中发现的问题，应该记录下来责任人和预计修复时间。

好了，从混沌无序的开发环境，到发布到测试环境，必须有序且稳定：

随着开发人员的深入，冲突的规则越来越少，我们通常认为在测试环境，应该检测出来的Major级别以上的Bug为0，不多于4个的Normal Bug。

从开发环境通过了Demo，升级到测试环境，就进入了我们的秩序山谷-测试环境

（是的，我改了名字，秩序山谷更适应测试环境的名字~）

二  秩序的力量-【测试环境】

我们更新一下图，如下所示。

测试领域

测试环境，是测试人员所掌控的世界。

在这里，所有的Bug的发现，流转，验收和版本的管理，必须摆脱开发环境的野蛮和无序。

测试环境的秩序体现在以下几个环节：

第一，发布到测试环境需要登记。

我们通常使用Wiki来管理测试环境的发布，在测试环境中，只有两种情况下才允许被发布：

一种是新的迭代开发，一种是Bug的修复。

这是指，每一次的发布，要么是对一个迭代开发的需求，要么是对一个Bug的修复。

不允许说，我这次发布的功能改了什么什么东西，而我们在需求和Bug管理工具上根本看不到。

第二，发布到测试环境，必须要指定版本号。

第三，发布到测试环境，必须要指定回滚版本。

第四，测试环境发布之后，必须由运维，开发依次验证是否发布成功。

第五，测试环境的发布，原则上只允许每天发布一次。

运维人员依据每天的测试登记，不能无脑发布。

所有的操作步骤应该写在Wiki上，所有的脚本和Sql都应该在测试环境的Wiki中登记。

严格执行流程，严禁开发人员和运维人员脱离Wiki单独发布。

第六，测试环境中，开发人员应该只有读日志的权限，不应该重启和发布的权限。

测试到发布

测试环境并不是单纯意义上的找Bug，更是对线上环境发布的演练。

所以测试环境其实是包含了“演练发布脚本”+“寻找系统Bug”两个环节。

而我们往往会忽视掉第一点，等到线上环境发布的时候出现问题，再怎么甩锅都没用了。

你可以理解为测试环境是试婚，又或者是婚前同居，但其实测试环境远远比试婚或者是同居更复杂和严谨。

在测试环境中，找出来的问题越多，心里会越踏实，如果你一个Bug没找到，太完美反而会有不真实的感觉。

在测试环境中，遇到被卡住流程，无法进行操作验证是非常头疼的一件事，所以倒推而来，Demo的重要性。

测试环境中，还应该做出一个很重要的判断，就是发布计划：

这应该由测试，产品和研发共同决定发布的排期。

发布到正式环境，同样应该是需要在Wiki登记，我们接下来看一看，穿越秩序山谷，是怎么样到达真实界元的。

三  【线上环境】-爱我，就用这把刀插进我心里

我想看看，我自己的心里倒底喜欢谁，听说只要刀够快，就可以让我在死之前，看到一个真实的自己。
不，你看不到，你只能看到她在心里，留下了什么。

上线

上线永远都是一件恐怖又期待的事情，像少女等情人，怕他不来，又怕他乱来。

上线的严肃程度远超开发环境，历经开发和测试的层层把关，倒底系统上线之后是什么样子，答案即将揭晓。

但无论如何，对线上的操作应该谨记的重要原则如下：

1.如有问题，五分钟之内无法解决，立刻回滚，严禁在线上调试和解决问题。

2.发布必须选择每天活跃用户最少的时候。

3.视发布版本的重要度来决定是否要对用户公告停机或者是不停机维护。

4.视发布版本的重要度来决定是否对新功能做运营推广。

5.线上发布必须所有团队在线 （不要求在场，毕竟通常都是深夜发布，或者是凌晨5点发布）

6.发布之后，运维，研发，测试和产品必须依次验证。

7.发布之后，重点观察用户的反馈和系统日志，有很多种异常情况，是你无论在测试环境测试的多严谨，都可能预料不到的。

（就好像无论你认识一个人多久，都不可能完全了解他一样）。

8.正常来讲，一周只允许两个时间点来发布，周二或者是周四，不选择周末之前的一天，这样，如果真的发布失败，还有一个白天的时间用以解决问题。

9.准备好要祭天的程序员。

10.发布应该分成正常发布和紧急发布。

严谨的流程

线上的Bug，一旦是Major级别，可以定性成是事故了，对事故：

往往需要摆脱正常发布的限制，可以走紧急发布流程：

通常是在单独的Wiki页面登记，由产品总监和技术总监签字画押。

流程可以后补，但是不能不补，特别是对于没有打版本发布的场景，手工修改的一些页面，或者是字段：

往往有可能会被开发人员忘记，又被覆盖掉。

对于App的，有审核时间的限制，所以向前兼容性，是产品经理要提前重点告知开发团队，并在测试环境严谨测试的。

版本更新通常是分成强制更新和非强制更新，也由产品人员和研发人员共同决定。

四 小结

规范

这次讲的三个环境，开发，测试和线上，每一个环境都有他自己不同的特点。

测试人员的正常工作环境，就是测试环境，但是不可避免的和开发环境/线上环境都有接触。

不知道哪里有一些遗漏，欢迎在评论中指出～～

另外，文中举的例子，和一些约定，可以结合自己公司的实际情况做一些变动。

但是希望大家能够理解：

每一条，其实都是踩着由无数Bug和程序员、产品经理的尸体形成的规范~

这其实是属于敏捷开发中的内容，在我们的另一个专栏里,从零开始学敏捷开发，会有一些内容和这里的有部分重复,也可以用来互相印证。

小编注：

【从零开始学敏捷开发】致力于将一套可落地执行的敏捷开发流程分享给大家

该流程面向项目团队全体成员，定位了每个职业在敏捷开发流程中扮演的角色，以及在项目研发不同阶段的流程规范。

无论是对团队协作开发一无所知的项目新手，还是想要提高团队开发效率，减少BUG数量的技术总监，都能从自己的角度有所收获。

欢迎扫码关注

第一章第四节的内容就到此结束

下节预告：

【更强大的测试：自动化测试和性能测试】，敬请期待