软件测试版本管理
说明：很早之前写过一篇文章“软件测试版本管理与版本发布”，之前作者也按文章中所述执行过，但是随着工作经历的增加，对代码管理认识的加深，发现还是有不足的地方，特别是敏捷模式下，因为缺乏“自动化版本管理”，执行时难免力不从心，所以呢，结合工作经历，重新整理
阅读该文章之前，建议先了解下做产品和做项目的区别，只有理解了做项目和做产品的联系与区别后，我们才知道怎么对测试工作进行规划，更好的把控质量。
推荐阅读：“做产品VS做项目”
版本号格式：
1.版本号格式：
常见格式为：主版本号.次版本号.修订版本号.源码版本号.时间_版本类型
主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化
次版本号：在项目功能做较大调整时增加，增量为1,
修订版本号：通常在解决缺陷或者细微功能变化时增加，增量为1或者2。通常，该版本号分奇数和偶数两种，奇数表示测试版本，偶数表示稳定版本
源码版本号：自动化生成的，比如svn中的Revision
时间：自动生成的时间
每个公司都有自己的规定，可能只是其中的部分，比如主版本号.次版本号.修订版本号
版本命名格式
这里的版本，主要是针对我们测试来说的，因为我们提交缺陷，需要填写测试版本，方便缺陷管理、分析统计，我们需要在缺陷管理上新建测试版本。而开发通常有代码管理工具比如svn，管理组织他们的代码
说明：
版本号格式：通常，主版本号.次版本号.修订版本号
Tx：表示测试轮数，比如T1表示第一轮，T2表示第二轮，在敏捷模式下，开发可能动不动就提交代码，这种情况下，轮次界定就没多大意义了，还有就是碎片化问题，比如你测完一轮，还有2个bug，测第二轮如果新建一个T2版本，如果测完还有1个没修复，还得再新建一个T3版本，所以建议在开发代码质量比较高，代码管理比较规范的情况使用
[]号内容表示可选，具体以实际项目为准，以下不做赘述
版本号类型：类似beta, Release，final
结合上述，通常我们用的格式可能是：项目名称_版本号格式[_版本类型]
测试：项目名称_版本号格式，供内网测试提交缺陷使用
线上：项目名称_版本号格式_版本类型,记录线上走查提交缺陷使用，方便后期缺陷分析统计。
举例：
背景，假设产品名为“99U校友”，包含web端和手机端(android，ios)，假设相同端的教师和学生都使用同一个web系统，或者同一个APP。
备注：通常，所谓的教师端，学生端仅是同一个站点下，相同目录下的不同web页面，所以，一般来说，web端不会针对这两个端编写两套代码，即代码层面是不分学生端和web端的，用同一套代码满足两个端的需求。针对这种情况，咋办？
答案：
分工不分家，即项目上分成两个项目，比如99U校友_Web_学生端，99U校友_Web_教师端，版本上则使用同一个代码版本，比如99U校友_Web_V1.0.0_release
产品名称：校友
项目：99U校友
说明：一个项目或产品的开发可能涉及到多个子项目(比如软件，硬件，结构，工艺，平台，技术等)，需要多个项目密切配合完成。为了方便管理，为了追求效率，经常需要将一个大的项目划分成多个子项目。如上，我们可以将“99U校友”这个大项目，分成小项目(根据项目的定义，我们是完全有理由拆分的)。
拆分“99U校友”项目
项目：99U校友_Web；99U校友_IPhone；99U校友_Android；
备注：
1.如果有必要（比如学生和教师使用不同版本app）,还可以继续拆分，比如99U校友Iphone学生端；99U校友IPhone教师端
2.如果产品分不同平台，项目建议按平台进行分类
测试版本：
99U校友_Web：
99U校友_Web_V1.0.0；
……
99U校友_Android：
99U校友_Android_V1.0.0；
99U校友_Android_V1.0.1；
……
线上版本：
99U校友_Web_V1.0.0_release；
……
99U校友_Android：
99U校友_Android_V1.0.0_release；
99U校友_Android_V1.0.1_release；
……
特别说明：
如果是app测试，建议每次发布后，都对发布成功的内，外网APP做一个备份，保证开发过程中任何时刻(理想的情况下)有一个可用的正式版本，测试版本
缺陷管理：
发布后外网发现的问题如何处理？
答案：在管理平台上新增和内网对应的外网final版本：项目名称_平台_版本号格式_final，专门用于记录外网环境的问题，接着又是一次迭代，内网改进，外网发布
