软件产品上线的基础知识

产品上线知识
1 .产品上线的定义
产品上线在软件行业通常指的是软件新版本的发布，按照发布先后通常会有多种类型的版本，主要有测试版、试用版、正式版。 》》 产品上线就是发布版本的意思
（产品上线之前修改好的bug，一点要谨慎，把风险说明清楚，让leader去决定）
2. 产品上线前后版本的分类
α(Alpha)版–阿尔法版： // 还没有正式的在对外使用
此版本表示该软件仅仅是一个初步完成品，通常只在软件开发者内部交流，也有很少一部分发布给专业测试人员。一般而言，该版本软件的bug(漏洞)较多，普通用户最好不要安装。主要是开发者自己对产品进行测试，检查产品是否存在缺陷、错误，验证产品功能与说明书、用户手册是否一致。

β(beta) 版–贝它版：// 给一些用户先试用
该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过大规模的发布测试来进一步消除。这一版本通常由软件公司免费发布，用户可从相关的站点下载。通过一些专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性的修改。该版本也不适合一般用户安装。

trial版–试用版：// 例如Xmind,还有开发工具中的一些如功能可以让你使用一段时间
试用版软件在最近的几年里颇为流行，主要是得益于互联网的迅速发展。该版本软件通常都有时间限制，过期之后用户如果希望继续使用，一般得交纳一定的费用进行注册或购买。有些试用版软件还在功能上做了一定的限制。

unregistered版–未注册版：// 经常性的提示你注册的那类应用
　　未注册版与试用版极其类似，只是未注册版通常没有时间限制，在功能上相对于正式版做了一定的限制，例如绝大多数网络电话软件的注册版和未注册版，两者之间在通话质量上有很大差距。还有些虽然在使用上与正式版毫无二致，但是动不动就会弹出一个恼人的消息框来提醒你注册，如看图软件acdsee、智能陈桥汉字输入软件等。

demo版–演示版： // 在一些企业的产品发布会上出现的一些
　　也称为演示版，主要是演示正式软件的部分功能，用户可以从中得知软件的基本操作，为正式产品的发售扩大影响。如果是游戏的话，则只有一两个关卡可以玩。该版本也可以从Internet上免费下载。demo版仅仅集成了正式版中的几个功能，颇有点像unregistered(未登记的;未注册的)。不同的是，demo版一般不能通过升级或注册的方法变为正式版。
以上是软件正式版本推出之前的几个版本，α、β可以称为测试版，大凡成熟软件总会有多个测试版，如windows 98的β版，前前后后将近有10个。这么多的测试版一方面为了最终产品尽可能地满足用户的需要，另一方面也尽量减少了软件中的bug。而trial、unregistered、demo有时统称为演示版，这一类版本的广告色彩较浓，颇有点先尝后买的味道，对于普通用户而言自然是可以免费尝鲜了。

release版–正式版本 >>& ®标志
该版本意味"最终释放版"，在出了一系列的测试版之后，终归会有一个正式版本，对于用户而言，购买该版本的软件绝对不会错。该版本有时也称为标准版。一般情况下，release不会以单词形式出现在软件封面上，取而代之的是符号®，如windows nt® 4.0、ms-dos® 6.22等。

补丁版本（紧急修复版本）（web网页，js项目）
版本投入使用后，出现的必须立马修复的问题或者必须新增的功能，不在正常版本发布的计划周期内，需要紧急发布的版本。

3. 产品上线参与的人员
   1.第一版或者重大版本
   项目组全体人员：>> 参与的人相对比较全面 ？？
   项目经理、产品、开发、测试、版本管理员、运维和相关部门领导所有人员

2.功能模块迭代版本 >> 不需要全部参与 ？？
项目组参与模块迭代的相关人员和重要功能模块人员：
项目经理、产品、开发、测试中参与过本期项目迭代和重要功能的人员和版本管理员、运维还有相关部门领导

4. 产品上线时间
   上线时间：》》一般是夜里上线
   上线时间尽量选择用户使用不频繁的时候，减少对用户的影响。日期根据自身应用情况选择，发布时间点一般在凌晨。（产品发布的时候，很多人就得加班，每个部门得有人员盯着上线情况）
   上线审核：
   对于要向应用商店发布的，因为有审核机制，需要提前预算好时间。
   比如苹果，首次上架七天，更新四天，被拒如果能很快再次提交的话，大概两天。保守估计的话，为应用上架留出2周比较稳妥。
   安卓，不同应用市场时间不同，华为应用市场（第一个版本一周，版本更新2天），应用宝（1天）

5. 产品上线流程和规范
   1.发布计划制定
   产品：确定需求范围，需求评审后提供PRD及原型。
   研发、测试：评估工作量，整理研发、测试计划。
   产品、研发、测试：沟通协定封版（在公司一般封版后，就不会做修改）时间以及发布日期。

2.发布前的准备
需求整理确认：确保前期明确的需求均包含在版本中。
相关制品整理：主要升级包和安装包。
测试环境准备：分为安装环境和升级环境。
版本发布测试计划整理，明确具体事项，明确负责人，明确相应的日期，便于跟踪监控。

3.发布测试阶段
安装测试
使用安装包，在全新的测试环境上进行安装操作，验证全新安装是否正常。
升级测试
使用升级包，由上一个版本升级到最新版本，验证版本升级过程是否正常。
自动化测试
如有自动化测试(API或者UI)，可在搭建好的安装环境和升级环境先执行一遍，验证安装、升级制品及环境是否OK，自动化部分功能是否正常。
功能测试
包含界面功能，业务功能，验证自动化未覆盖部分功能是否正常，另外，针对版本重点需求和改造部分，以及核心业务流程需要重点测试。
性能测试
针对产品或项目提出的诉求有针对性场景，进行性能测试，验证性能指标是否满足要求。
安全测试
针对产品及特定业务场景，进行安全测试，验证安全指标是否正常。
回归测试
针对上述阶段发现的问题，做BUG回测，确保等级较高的BUG均为修复。
当然，不是每个版本发布都要完全按照上述流程，部分流程可根据产品特性、投入情况等情况做适当的取舍。

4.版本发布阶段
制品整理
安装、升级制品（可能还有脚本或者定制内容）。
文档整理
PRD、功能手册、配置说明、升级文档、安装文档、API文档、数据字典、需求列表、BUG列表、测试用例、测试报告等。
发布报告整理
包含注意事项、新增配置项说明、新增表OR字段说明、接口改动说明、BUG修复情况说明、版本兼容性说明、测试环境，配置说明、制品获取地址、升级OR安装注意事项等。

5.版本发布总结
从版本计划开始至版本发布期间，针对过程中产品、开发、测试暴露的一些问题进行针对性的总结解决，可能是流程协作类的问题，也可以是开发质量、产品设计质量上的问题。

6.版本发布跟踪
一般跟踪发布后三个月的情况，为了便于统计可以使用在线文档或禅道、JIRA等项目管理平台，建立统一汇总跟踪任务单。
如果使用在线文档或者Excel统计，可以参考下述格式：

如果是禅道或者JIRA平台，可以建一个总任务单，后需有项目或客户反馈问题在对应版本的总任务单下建子任务进行记录即可。
目的是方便跟踪汇总，具体使用什么工具，没有限制。