测试思想-测试流程 软件测试版本管理

说明：很早之前写过一篇文章“软件测试版本管理与版本发布”，之前作者也按文章中所述执行过，但是随着工作经历的增加，对代码管理认识的加深，发现还是有不足的地方，特别是敏捷模式下，因为缺乏“自动化版本管理”，执行时难免力不从心，所以呢，结合工作经历，重新整理

阅读该文章之前，建议先了解下做产品和做项目的区别，只有理解了做项目和做产品的联系与区别后，我们才知道怎么对测试工作进行规划，更好的把控质量。

推荐阅读：“做产品VS做项目”

版本号格式：

1. 版本号格式：

常见格式为：主版本号.次版本号.修订版本号.源码版本号.时间_版本类型

主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化

次版本号：在项目功能做较大调整时增加，增量为1,

修订版本号：通常在解决缺陷或者细微功能变化时增加，增量为1或者2。通常，该版本号分奇数和偶数两种，奇数表示测试版本，偶数表示稳定版本

源码版本号：自动化生成的，比如svn中的Revision

时间：自动生成的时间

版本号类型：类似beta, Release，final之类

每个公司都有自己的规定，可能只是其中的部分，比如 主版本号.次版本号.修订版本号

版本命名格式

这里的版本，主要是针对我们测试来说的，因为我们提交缺陷，需要填写测试版本，方便缺陷管理、分析统计，我们需要在缺陷管理上新建测试版本。而开发通常有代码管理工具比如svn，管理组织他们的代码

项目名称_版本号格式[_Tx][_版本类型]

说明：

版本号格式：通常，主版本号.次版本号.修订版本号

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：

99U校友_Web_V1.0.0_release；

……

99U校友_Android：

99U校友_Android_V1.0.0_release；

99U校友_Android_V1.0.1_release；

……

特别说明：

如果是app测试，建议每次发布后，都对发布成功的内，外网APP做一个备份，保证开发过程中任何时刻(理想的情况下)有一个可用的正式版本，测试版本

缺陷管理：

发布后外网发现的问题如何处理？

答案：在管理平台上新增和内网对应的外网final版本：项目名称_平台_版本号格式_final，专门用于记录外网环境的问题，接着又是一次迭代，内网改进，外网发布