软件测试版本管理与版本发布
阅读该文章之前，建议先了解下做产品和做项目的区别，只有理解了做项目和做产品的联系与区别后，我们才知道怎么对测试工作进行规划，更好的把控质量。
推荐阅读：“做产品VS做项目”
版本命名格式：
1.内网
项目名称_版本号格式_Qx[_标识号]
说明：
1. x表示测试轮数
2.标识号用于标识额外信息，比如“用01，表示手机端app测试时每轮测试提交的第1个包，每开启新的一轮测试，标识号重置为初始值，比如01”,标识号也可以是其它信息，比如svn标识
3. []号内容表示可选，具体以实际项目为准，以下不做赘述
4.关于对外版本号格式的更多资料，可以百度或谷歌，通常是项目经理的事了，这里就不多说了。
2.外网
项目名称_版本号格式_版本类型[_标识号]
说明：
1.版本号类型，类似Beta，Release，Final之类
特别说明：
1.内外网的“版本号”，建议保持一致，这样，当外网存在问题时，可通过内网对应版本进行验证，看是否仅外网存在的问题，是否是数据原因导致等
2.每次发布后，都对发布成功的内，外网版本及代码做一个备份，保证开发过程中任何时刻(理想的情况下)有一个可用的正式版本，测试版本
3.版本号至少保持3位数，必要时增加到4位数
举例：
背景，假设产品名为“99U校友”，包含web端和手机端(android，ios)，假设相同端的教师和学生都使用同一个web系统，或者同一个APP。
产品名称：校友
项目：99U校友
说明：一个项目或产品的开发可能涉及到多个子项目(比如软件，硬件，结构，工艺，平台，技术等)，需要多个项目密切配合完成。为了方便管理，为了追求效率，经常需要将一个大的项目划分成多个子项目。如上，我们可以将“99U校友”这个大项目，分成小项目(根据项目的定义，我们是完全有理由拆分的)。
拆分“99U校友”项目
项目：99U校友_Web；99U校友_IPhone；99U校友_Android；
备注：
1.如果有必要（比如学生和教师使用不同版本app）,还可以继续拆分，比如99U校友Iphone学生端；99U校友IPhone教师端
2.如果产品分不同平台，项目建议按平台进行分类
对外版本：
99U校友_Web：
99U校友_Web_V0.0.0_release；
……
99U校友_Android：
99U校友_Android_V0.0.0_release；
99U校友_Android_V0.0.1_release；
……
99U校友_IPhone：
99U校友_IPhone_V0.0.0_release；
……
以上看上去似乎挺完美的，没啥呀，普通人都可以想到，问题在哪里？
问题在于：
这样的版本规划主要用于对外发布，而对实际测试工作来说，还不够细粒度，还不够“方便”，特别是敏捷测试模式。
解决方案：
对内采用内部测试版本号:项目名称_版本号格式_Qx[_标识号]
例子：
对外版本，99U校友_Web_v2.2.1
1轮测试版本记为“99U校友_Web_v2.2.1_Q1”;
2轮测试版本记为“99U校友_Web_v2.2.1_Q2”;
...
3轮测试版本记为“99U校友_Web_v2.2.1_QN”;
N轮测试完成，发布外网版本：“99U校友_Web_v2.2.1_release”;
例子：
对外版本，99U校友_Android_V2.3.1一轮测试，前后一共提交了3个包，svn标识号分别为：01，02，03，那么版本号分别记为“99U校友_Android_V2.3.1_Q1_01”,“99U校友_Android_V2.3.1_Q1_02”,“99U校友_Android_V2.3.1_Q1_03”
好处在哪里？
1.每个对外版本，被分割成了多个内部小版本，加强质量管控，大大减少了发布失败的风险。
2.更能体现测试的投入，开发的投入。可以清楚的看到测试进行了多少轮的测试，开发人员打包个数(间接体现了开发人员代码质量)
3.更细粒度的管理，带来更精确的数据统计，进而便于分析存在的问题
版本发布流程：
1. App端
2. Web端
特别说明：
1. 项目名称，版本号以实际项目为准，上述仅用于流程说明
2. 版本发布外网后，重新发布时的版本号更新，一般情况下仅更新第4位版本号
3. 这里不一定要完全按这个，结合项目使用的平台，怎么样方便，怎么样更效率就咋样。
缺陷管理：
发布后外网发现的问题如何处理？
答案：在管理平台上新增和内网对应的Final版本：项目名称_平台_版本号格式_final，专门用于记录外网环境的问题，接着又是一次迭代，内网改进，外网发布
pdf版下载：
