很多开发同学对开发环境、测试环境和线上环境傻傻分不清楚，这篇文章或许能让你将它们区分开来。
一、开发环境
简述：就是与测试环境分开的独立客户机、服务器、配置管理工具等。
国内很多公司将测试环境和开发环境混用，在开发环境做测试，其实这样是不可取的，开发环境因为代码可能会有BUG，而且需要和后端联调，状态会反复。
PS：这里的开发环境不是指的开发的时候使用的IDE等这些工具。
使用阶段：
1.开发人员每日上传代码到开发环境进行自测。
2.demo会议时，PM同学和开发同学一起测试。（项目开发流程）
发布频率：每天发布1-2次，做持续集成，改完code立马提交。
测试：QA同学不能在开发环境做测试，因为开发环境因为需要与后端联调，状态会反复。
备注：持续集成
在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，然后等所有的代码都开发完成之后再集成到一起进行测试，随着软件技术的发展，各种软件方法百花齐放，软件规模也在扩大，软件需求越来越复杂，软件已经不能简单地通过划分模块的方式来开发，需要项目内部互相合作，划分模块这种传统的模式的弊端也越来越明显，由于很多 bug在项目的早期就存在，到最后集成的时候才发现问题，开发者需要在集成阶段花费大量的时间来寻找 bug 的根源，加上软件的复杂性，问题的根源很难定位，甚至出现不得不调整底层架构的情况，在这个阶段的除虫会议（bug meetings）特别多，会议的内容基本上都是讨论 bug 是怎么产生的，最后往往发展成为不同模块的负责人互相推诿责任。
持续集成最大的优点是可以避免这种传统模式在集成阶段的除虫会议。持续集成主张项目的开发人员频繁的将他们对源码的修改提交(check in)到一个单一的源码库，并验证这些改变是否对项目带来了破坏。
二、测试环境
简述：测试环境是指测试人员利用一些工具及数据所模拟出的、接近真实用户使用环境的环境，测试环境的目的是为了使测试结果更加真实有效。测试环境应该与开发环境分隔开，使用独立的客户机、服务器和配置管理工具。
原则上开发人员是不能碰测试环境和线上环境的，只能看不能动，如果随便哪个人发布了一个包或者修改了代码，那就乱了，因此测试环境涉及到权限管理，对于开发人员来说应该是只读权限。
有些公司还会仿真环境，用于模拟线上用户的使用，一般不对外开放。
使用阶段：demo通过后由开发人员将代码部署到测试环境，并写好域名发送邮件通知QA同学进行测试。
发布频率：一天发布一次，保持测试环境稳定。
测试：3-5天测试时间，主要测边际条件，主流浏览器的兼容性。难走的流程走组合测试，录入多组数据，所有的功能点都要走一遍。
备注：组合测试
组合测试法：有n个输入参数，每个输入参数可取若干个值，将n个输入参数取值的所有组合进行穷举测试，由于爆炸性，所以是不行的。退一步：对n个输入参数中的任意m个输入参数的所有取值组合要覆盖到，是可行的，称之为强度m的组合测试。由此引出了组合测试的一系列理论研究。
三、线上环境
简述：即发布环境，真实用户访问的环境，要求不能有任何BUG，且不能频繁发布，这样对用户体验性不好。
使用阶段：QA同学测试通过后，由OP将代码发布到线上环境，发布的时候相关人员必须全部在场。
发布频率：现在的公司一般周二或者周四，发布时间为用户在线数最少的时候。再就是固定时间进行的BUG修改完发布。最后就是紧急发布。
测试：
1.关注用户的反馈。
2.灰度发布的话，测试要做梯度测试。
备注：灰度发布
简单理解就是给一部分用户发个测试版本，其他用户继续用以前的版本，然后观察测试版本的情况。
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
