当前位置：文档库 › 程序代码版本管理规范

程序代码版本管理规范

软件版本管理规范

Software

Revision List

一、目的 ......................................................................................................................................................................... - 4 -

二、适用范围.................................................................................................................................................................. - 4 -

三、版本定义规范.......................................................................................................................................................... - 4 -

四、版本代码设计规范.................................................................................................................................................. - 4 -

五、版本进阶规范.......................................................................................................................................................... - 5 -

六、软件备份要求规范.................................................................................................................................................. - 5 -

七、软件版本发布规范.................................................................................................................................................. - 5 -

八、软件发布流程规范.................................................................................................................................................. - 7 -

九、量产中软件管理规范.............................................................................................................................................. - 8 -

一、目的

1.1本规范规定了公司软件发布及版本管理规范，为工程师发布软件提供版本管理标准和流程。

1.2提高本公司软件版本的可识别性，为工程，生产，售后服务提供便利性。

二、适用范围

本规范适用于研发部软件人员发布软件、程序时制定版本参考。

本规范中所涉及软件为泛指一切以计算机代码形式存在的软件，包括以下(但不限于)几类：

1、Windows 软件、程序

2、Linux 软件、程序

3、经过裁剪后Linux 内核

4、单片机，DSP，ARM 固件代码及烧录FW

5、FPGA 代码及烧录FW

6、本公司自己开发的驱动程序

7、第三方提供的驱动程序

8、第三方提供的烧录FW

三、版本定义规范

3.1本规范规定：除第三方提供的软件以外，本公司开发的软件正式版本号采用如下格式，

3.1.1 三位版本编码格式，即x.xx,由三位数字和一位小数点组成。

第一版正式版即1.00；

在1.00正式版之前研发内部测试和验证版本以0.xx.xx 表示。

3.2 选用哪种版本号格式由软件自身情况决定；同一软件版本号格式不得随意更改,一旦选用三位或五位版本编码格式，在没有必要和充分的理由的前提下不能对版本号格式进行变更。

3.3 第三方公司提供的软件继续沿用第三方公司的版本号编码格式。

四、版本代码设计规范

为便于检查和查看软件版本，固件、软件版本通过工具可以被查看，因此在软件代码设计阶段，

对版本查看应实现如下要求：

4.1固件：量产后烧录的F/W版本可通过以下两种方式之一进行查看

(1) 可以通过LCD显示。

(2) 可用通过串口或其他通信接口通过电脑上位机软件（命令方式）获取

4.2上位机程序或软件版本可以通过以下方式之一进行查看

(1) 显示在标题栏、状态栏，或界面中；

(2) 通过“关于…”或“About…”菜单查看；

(3) 通过命令行查看。例： xxxx –h 或 xxxx –ver；

五、版本进阶规范

5.1正式版版本迭代更新。软件为修正bug，完善功能，增加功能的情况下，需要对软件版本进行更新和升级，本规范规定如下：

5.1.1三位版本编码格式

正式版本迭代升级可进行两部分变更，小数位之前或小数位之后。

例：1.00 版本可以升级为 1.01，也可以升级为2.00；

较大的软件变动建议升级小数位之前数字，较小的软件修正和变动建议升级小数位之后

的数字。

5.2 测试版和试用版版本迭代更新。

产品量产后若需要修改部分功能或针对客户进行定制的F/W和Program在测试验证阶段均采用5位数字和2个小数点构成，且只能修改最后两位数字版本号，如：

1.01.00- 1.01.01,1.01.02。只有当测试版本经过测试和验证，或客户认可后，才能发

表正式版，进阶前3位数字。例： 1.01.02的测试版解决了某些bug或增加功能，并经过测试验证解决了实际的问题，则将1.01.02测试版重新编译，变更测试版本变更为正式版格式。如 1.01.02-->1.02.00。

六、软件备份要求规范

软件代码变更后均要将变更更新至服务器Git版本库进行管理，未备份至Git版本库的软件版本不允许发布。

具体备份步骤参考《研发部Git版本库服务器使用指南》。

七、软件版本发布规范

7.1正式版FW，软件需要经过工程测试部门验证后在进行发布。测试版软件发布由工程师根据实际情况而定。

7.2正式版软件发布时要除软件本身外，需要附更新说明release notes。

Release notes 采用追加方式记录，即保留之前的更新日志。且采用倒序方式，最新版本更新日志在最前端。测试版更新一样要记录入更新日志文件。

Release notes 格式如下：

当前版本：1.01

日期：xx-xx-xx

Author：

更新原因及内容：

(1)Xxxxx

(2)Xxxxx

---------（分隔线）--------

前一版本：1.00.08(T测试版)

日期：xx-xx-xx

Author：

更新原因及内容：

(1)Xxxxx

(2)Xxxxx

……………………

八、软件发布流程规范

软件工程师代码编写、修改

设计工程师

调试

测试版本发布

Git 代码库

测试工程师测

试验证

调试通过？

验证通过？反馈给软件工程师更新

软件工程师发布

正式版客户验证（Option ）

验证通过？

Yes Yes

Yes

发布ECN 通知工程、生产，

计划做相应变更

九、量产中软件管理规范

9.1 已发布的软件程序，安装包，Bin，Hex等文件需要在FTP中进行备份。备份管理工作由工程部负责。

9.2 生产部生产带有软件下载的PCBA或成品时，F/W(bin,hex)文件下载后须在相应芯片上贴上“机种、版本”标签。

9.3当软件版本有更新时，软件工程师和研发主管根据更新内容评估，对在产品，产成品，及已出货产品中的软件是否更新，其他部门应根据ECN要求执行更新动作。

9.4对已更新软件版本的产品，需要更换正确的，与之对应的标签；已出货的产品视具体情况而定。

9.5 QA应对出货及入库产品的软件版本进行检查。检查方法由工程部或研发部提供。

公司软件管理规范

XXXXXX有限公司文件制订（修订、作废）申请单NO.: 表格编码：

1. 目的为规范公司软件、程序的管理，确保开发、使用、变更等过程得以受控，根据本公司实际情况，特制定本规范。 2. 适用范围本规范适用于公司所有自主开发、外购、客供软件、程序的管理。（如无特别说明,本规范内“软件”包含软件、程序） 3. 软件分类: 3.1产品源程序: 由研发部软件开发工程师编写，实现产品功能的烧录文件。 3.2 ATE测试软件及测试程序：是指由信息技术部负责编写的配套ATE硬件使用的产品测试软件平台,及在此平台下针对不同型号产品编写的测试程序。 3.3 设备应用程序: 是指工程部在设备操作系统下针对不同产品型号编写的对应程序（ATE除外）。如：打码程序、贴片程序、SPI检测程序、AOI检测程序、分板程序、回流焊程序、X-Ray 测试程序等。 3.4管理应用软件: 是指企业使用的电子化管理工具或系统平台。如:ERP系统、品质管理系统、SPC系统、生产报表系统、电子看板系统、绩效管理系统、项目管理系统等 3.5办公软件：Windows、office、Coremail、PDM、AutoCAD、杀毒软件等。 4、职责定义: 原则上公司各部门均可依据自身需求提出软件申请，由技术部门进行开发，交由使用部门进行管理，异常无法解决时,可向技术部门寻求技术支援。具体定义如下： 4.1 需求提出部门:依据公司或者部门的实际情况,提出软件需求申请。软件需求多由软

件使用部门提出，但也可以由其它部门提出。 4.2使用/管理部门:对提出的申请进行评估,确定需求后向开发部门发起正式申请;在软件验收合格后负责日常的管理、维护等；当异常时且无法解决时，及时向开发部门反馈,并要求协助处理。 4.3开发部门:对于使用/管理部门提出的申请进行评估,确定执行方案,并最终完成软件开发；开发部门也负责后期的技术支援。 4.4监控部门:负责对软件验收完成后的使用过程进行监控，确保不出现使用错误,维规操作,使用非法软件及机密软件外流等。 4.4软件管理职责对照见下表：分类开发部门使用/管理部门监控部门产品源程序研发部工程部品质部 ATE测试软件及测试程序信息技术部工程部品质部设备应用程序工程部工程部品质部管理应用软件信息技术部使用部门信息技术部办公软件信息技术部使用部门信息技术部 5.软件管理规范： 5.1软件申请、开发、使用管理流程图：（如下图）

软件版本管理规范标准[详]

软件版本管理规第一章目的本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象包括但不限于：项目总体计划可行性研究报告开发计划需求说明书需求设计原型设计说明书系统开发变更申请单系统管理手册用户操作手册培训计划培训记录源程序支持系统运行的配置文件存储过程脚本测试计划测试用例测试脚本测试报告上线计划

上线申请版本维护日志 4.2. 配置库的目录结构每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目部的目录结构： |–projectA |–src （保存该项目的源程序） |–doc （保存项目相关文档） |–000.项目管理（保存项目过程管理相关文档） |–010.项目计划（保存项目计划相关文档） |–020.项目需求（保存项目需求相关文档） |–030.系统设计（保存项目设计相关文档） |–030.系统测试（保存项目代码测试相关文档） |–040.系统实施（保存项目部署实施相关文档） |–050.系统运维（保存项目运维文档，包括培训、用户手册等） |–060.技术资料（保存项目技术文档，包括第三方技术资料等）

研发中心产品版本管理规范

××××网络产品版本管理规范[草稿]

目录 1.引言 (1) 1.1.目的 (1) 1.2.范围 (1) 1.3.术语定义 (1) 1.4.参考资料 (2) 1.5.版本控制记录 (2) 1.6.版本更新记录 (2) 2.版本管理 (4) 2.1.版本标示方法 (4) 2.1.1.正式版本 (4) 2.2.目录结构 (5) 2.3.文档的存放 (6) 2.3.1.开发文档的存放 (6) 2.3.2.源代码的存放 (6) 2.3.3.SQL的语句存放 (7) 2.3.4.发行文档的存放 (7) 2.4.配置管理流程 (7) 2.5.权限控制的管理 (8) 3.更新管理 (9) 3.1.源程序的修改 (9) 3.2.版本升级 (10) 3.2.1.版本升级原则 (10) 3.2.2.新版本发布 (11) 3.3.文档的变更 (11) 4.备份管理 (12)

1.引言版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。 1.1. 目的本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。 1.2. 范围本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括： ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3. 术语定义 SCM 软件配置管理（Software Configuration Management）缩写 SVM 软件版本管理（Software Version Management）缩写 SVN 一个开源的版本控制系统Subversion. 文档一种数据媒体和其上所记录的数据。

软件项目代码编码规范

变更履历

目录 1总则 (4) 2源代码完整性保障 (4) 3源代码的授权访问 (4) 4代码版本管理 (5) 4.1系统初验 (6) 4.2试运行 (6) 4.3系统终验 (7) 4.4系统验收标准 (7)

1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小

源代码管理规范

1源代码管理 (1) 总则 (1) 源代码完整性保障 (1) 源代码的授权访问 (2) 代码版本管理 (2) 源代码复制和传播 (5) 系统测试验收流程 (5) 系统初验 (6) 试运行 (6) 系统终验 (6) 应用系统验收标准 (8) 文档评审通过标准 (9) 确认测试通过标准 (9) 系统试运行通过标准 (10)

1代码管理总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。

软件版本管理规定

上海精佑通信技术有限公司企业标准（管理标准） Q/HT 0001–2005 软件版本管理规定 V1.04 2005-04-11 发布 2005-04-11实施

上海精佑通信技术有限公司目录 1范围 (4) 2术语和定义 (4) 2.1软件 (4) 2.2产品软件 (4) 2.3生产支持软件 (4) 3软件版本命名规则 (5) 3.1软件版本命名组成 (5) 3.2手机软件版本命名 (5) 3.3模块软件版本命名 (5) 3.4手机PC侧软件版本命名 (6) 3.5模块PC侧软件版本命名 (7) 3.6手机生产支持软件版本命名 (7) 3.7模块生产支持软件版本命名 (8) 3.8公用于所有手机和模块的软件版本命名 (9) 3.9无线上网卡相关软件版本命名 (9) 3.10无线上网卡驱动软件版本命名 (10) 3.11正式版本号的升级规则 (10) 3.12版本的电子文件命名规则 (11) 4软件版本发布流程 (11) 5禁止条例 (14) 6管理条例 (14) 7附录 (14)

上海精佑通信技术有限公司文档版本变更记录：版本号拟制日期拟制人版本描述存档编号 V1.00 2005-4-11 郝军初始版本 V1.01 2005-4-27 郝军1．版本号前增加“V”,用以明显标识版本号 2．版本号和时间之间以下划线分隔 3．增加生产支持软件种类 4．增加无线上网卡生产支持软件、管理器软件和驱动软件命名 5．增加版本发布流程的文字说明 V1.02 2005-7-1 郝军增加手机和模块生产支持软件的类型：射频补丁软件（RFP） V1.03 2005-7-15 郝军更改版本号升级规则，更改资料外发申请表 V1.04 2005-7-26 郝军增加机卡合一版本的命名规则注：1）拟制、审核、会签、批准不走电子流程时，必须用钢笔或签字笔填写，不得用铅笔、圆珠笔填写。

测试管理规范流程_V1.0

测试工作流程规范版本记录：北京天诚信安科技有限公司

目录 1编写目的 (2) 2测试团队构成 (2) 2.1组织结构 (2) 2.2测试组职能 (2) 2.3职责划分 (3) 3测试流程及规范 (4) 3.1测试流程图 (4) 3.1.1 完整开发流程 (4) 3.1.2 测试流程 (5) 3.2计划与设计阶段 (6) 3.2.1 立项会议 (6) 3.2.2 需求评审 (7) 3.2.3 测试工作启动 (7) 3.2.4测试设计阶段 (8) 3.2.5设计内容评审 (9) 3.3实施测试阶段 (10) 3.3.1 测试交接 (10) 3.3.2 实施测试 (10) 3.3.3 回归测试 (11) 3.3.4 同行审查 (12) 3.4总结阶段 (12) 3.4.1测试总结报告 (12) 3.4.2测试归档 (13) 3.4.3测试工作总结 (14) 3.5缺陷跟踪 (14) 4发布标准 (15) 5争议处理 (15) 6标准文档 (15)

1编写目的本文档是测试团队的日常工作规范，主要侧重测试工作流程的实施和控制，明确软件工程各阶段测试团队应参与和完成的工作。并且对于测试团队中关于测试组架构、职能及成员职责进行必要的说明。通过建立规范的测试流程、测试团队组织架构，同时明确测试小组任务、目标和各小组成员的具体职责，对部门测试工作的正常开展起到规范的指导作用。 2测试团队构成图 1 2.2测试组职能软件测试是软件开发过程中的重要组成部分，测试团队主要肩负着如下责任：在项目的前期、需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。针对测试需求进行相关测试技术的研究。根据项目的实际需求，编写合理的测试计划，并与项目整体计划有机地整合在一起。编写高效、覆盖率高的测试用例。

Git源代码管理规范

Git源代码管理规范一、分支管理使用git进行源代码管理，一般将某个项目的所有分支分为以下几条主线： 1.Master 顾名思义，既然名字叫Master，那么该分支就是主分支的意思。master分支永远是production-ready的状态，即稳定可产品化发布的状态。 2.Develop 这个分支就是我们平常开发的一个主要分支了，不管是要做新的feature还是需要做bug fix，都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本，即完成了某个feature或者修复了某个bug后的开发稳定版本。 3.Feature branches 这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当功能点开发测试完毕之后，就会合并到develop 分支去。 4.release branches 这个分支系列从develop分支出来，也就是预发分支。在预发状态下，我们往往会进行预发环境下的测试，如果出现缺陷，那么就在该release分支下进行修复，修复完毕测试通过后，即分别并入master分支后develop分支，随后master分支做正常发布。

5.Hotfix branches 这个分支系列也就是我们常说的紧急线上修复，当线上出现bug且特别紧急的时候，就可以从master拉出分支到这里进行修复，修复完成后分别并入master和develop 分支。下面这张图将完整展示这一个流程

二、工作原理 Git的工作方式：也就是说，每次提交版本变动的时候，git会保存一个快照(snapshot)。如果文件没有被更改，git也不会再次保存，而是提供一个到原来文件的链接。这样一来，git更像是一个小型的文件系统。此外，git的所有操作都可以是本地的，仅仅在将新版本的内容上传到服务器上时才需要连接网络。

源代码管理规范

代码管理制度 1总则 (2) 2源代码完整性保障 (2) 3源代码的授权访问 (2) 4代码版本管理 (3) 5源代码复制和传播 (4) 6系统测试验收流程 (5) 6.1 系统初验 (5) 6.2 试运行 (5) 6.3 系统终验 (5) 6.4 系统验收标准 (6) 6.5 文档评审通过标准 (7) 6.6 确认测试通过标准 (7) 6.7 系统试运行通过标准 (7)

测试流程版本管理规范标准[详]

测试流程、版本管理规编制：审核: 批准：文件历史记录

目录测试流程、版本管理规 (1) 1.目的 (3) 2.适用围 (3) 3.测试流程规 (3) 3.1搭建环境 (3) 3.2冒烟测试 (3) 3.3禅道版本管理规 (3) 3.4系统测试流程规 (4) 3.6 缺陷管理流程 (8) 3.4上线版本 (9) 4.系统版本管理规 (9) 1.目的为了规项目组的测试流程、版本规，减少人为影响上线版本的质量 2.适用围项目组所有系统以及流程的版本 3.测试流程规 3.1搭建环境缺失本次版本变更说明或者部署文档不完整，需向开发人员说明，并要求提供齐全，保证文档有效性。

3.2冒烟测试 ?环境搭建完后，进行冒烟测试，如果冒烟测试不通过，需打回版本 ?如果未实现需求涉及的功能，打回版本（除非开发人员有说明按模块提交测试）3.3禅道版本管理规产品 ?接到新的系统时，首先在产品模块新建产品名称，命名规则直接以系统名称为准，比如“移动OA” ?产品新建成功后，需要把需求关联至产品，可以直接把文档或者git地址关联进来项目 ?新项目或者目前版本的变更时，需要新建项目，项目需要关联产品，命名规则直接以版本名称为准，比如“移动OA3.0” ?项目新建成功后，开发提交一次版本，需要把版本号进行维护，版本号命名规则。如“移动OA3.0_rc1”，以此类推，每一轮测试时，如果仍存在BUG,需要把下个版本号提前维护进来，方便开发变更BUG状态时，选择正确的版本号测试 ?项目的模块需要分类维护，测试用例对应到模块下，每一轮测试完毕后，需要变更测试用例状态，并把测试用例与BUG进行关联 ?在测试过程中，如果测试用例有遗漏，需要补写 ?每一轮测试结束后，需要出测试报告

代码版本管理规范_v1.1

XXXXXXXX 代码版本管理规范

历史版本

目录历史版本 (2) 1引言 (4) 1.1目的 (4) 1.2管理工具 (4) 2现状概述 (5) 3现状分析 (5) 3.1现状详述 (5) 3.2目标细化 (6) 3.3SVN版本管理 (6) 3.3.1概述 (6) 3.3.2使用对比 (7) 4完整的实施方案 (9) 4.1开发阶段 (9) 4.2预发布测试阶段 (9)

1引言 1.1目的为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，同时明确开发源代码的控制管理流程，特此制定此规范。 1.2管理工具沿用SVN管理工具来进行开发的版本管理，源代码管理和开发资料归档。

2现状概述目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。这样会造成如下两点影响： ●会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。 ●一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部分问题是由于其他项目代码引起的。因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。 3现状分析 3.1现状详述当前代码版本管理现状如下： 1.所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。 2.提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。 3.测试出bug以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此bug再做测试。这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布bug数量。总体来说，当前工作流程是：预发布出bug，研发修改，再提交测试，然后预发布测试

项目软件版本号管理规范

历史修改记录一. 目的

1.1软件版本按照一定的规则保存所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确的查找到任何版本。 1.2软件版本规范有利于公司各部门之间的对接工作，有利于公司内部资料统一管理。 1.3本文档是为规范研发部软件版本管理而制定的。二. 范围 2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容，包括：2.2版本标识方法及管理 2.3版本升级 2.4文档及源码的备份制度 2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作，公司内部使用按照文档及源码存放备份制度。三. 版本管理 3.1版本号规则 3.1.1每个归档版本都有两个版本号：内部版本号和外部版本号。版本号使用 VP规则，V(Version)是指外部版本号（研发测试版本），P(Patch)是指补丁版本号（可选）。 3.1.2版本号命名：V/B+主版本号+次版本号+修订版本号+日期版本号

3.2版本号修改规则 3.2.1主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化。此版本号由项目决定是否修改。 3.2.2次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目决定是否修改。 3.2.3修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩充，要经常发布修订版，修复一个严重Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 3.2.4日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。如： V8.1.0.XXX (上一级版本号有变动时，下级要归零) 3.3版本号修改举例说明如此时版本号为：V8.1.0.XXX ，此时为内部测试阶段 3.3.1 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为： V8.1.1.XXXX ，如当前日期跟上一个版本号的日期不一样，版本号可改为： V8.1.1.XXX。

源代码管理规范

1源代码管理 (1) 1.1总则 (1) 1.2源代码完整性保障 (1) 1.3源代码的授权访问 (2) 1.4代码版本管理 (2) 1.5源代码复制和传播 (5) 1.6系统测试验收流程 (5) 1.6.1系统初验 (6) 1.6.2试运行 (6) 1.6.3系统终验 (6) 1.6.4应用系统验收标准 (8) 1.6.5文档评审通过标准 (9) 1.6.6确认测试通过标准 (9) 1.6.7系统试运行通过标准 (10)

1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。

软件版本管理规范19726

软件版本管理规范第一章目的本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用范围所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。此岗位可由开发或测试人员兼任。 3.第四章内容 4.1. 版本管理对象包括但不限于：项目总体计划可行性研究报告开发计划需求说明书

需求设计原型设计说明书系统开发变更申请单系统管理手册用户操作手册培训计划培训记录源程序支持系统运行的配置文件存储过程脚本测试计划测试用例测试脚本测试报告上线计划上线申请版本维护日志 4.2. 配置库的目录结构每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。

配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目内部的目录结构： |–projectA

软件版本管理规范标准

软件版本管理规 V1.0.0 文档版本变更记录：

目录前言 (3) 1 围 (4) 2 术语和定义 (4) 2.1 软件 (4) 2.2 产品软件 (4) 2.3 演示软件 (4) 3 软件版本命名规则 (4) 3.1 软件版本命名组成 (4) 3.2 产品软件版本命名 (4) 3.3 演示软件版本命名 (5) 3.4 正式版本号的升级规则 (6) 3.4.1 软件版本升级规则 (6) 3.4.2 演示版本升级规则 (6) 3.5 版本的安装文件命名规则及存放路径 (6) 4 软件版本发布流程 (7) 5 管理条例 (7) 6 附录 (7)

前言为规部门产品软件版本的管理与控制，保证产品版本的有效与质量，制定本标准。本标准由移动金融事业部拟制。本标准于2015年6月首次发布。

软件版本管理规定 1围本标准规定了移动银行事业部产品软件版本的控制与管理。本标准适用于移动银行事业部产品软件版本的控制与管理。 2术语和定义下列定义适用于本标准。 2.1软件指与产品相关的所有软件，可以分为产品软件和演示软件。 2.2产品软件已签订合同，有明确交付日期的产品。 2.3演示软件处于研发阶段，并未正式投入生产的应用。 3软件版本命名规则 3.1软件版本命名组成产品的正式软件版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。产品的演示版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 3.2产品软件版本命名产品软件版本的命名规则如下所示：

测试管理规范流程

测试管理规范流程 SANY标准化小组 #QS8QHH-HHGX8Q8-GNHHJ8-HHMHGN#

测试工作流程规范版本记录：目录

1编写目的本文档是测试团队的日常工作规范，主要侧重测试工作流程的实施和控制，明确软件工程各阶段测试团队应参与和完成的工作。并且对于测试团队中关于测试组架构、职能及成员职责进行必要的说明。通过建立规范的测试流程、测试团队组织架构，同时明确测试小组任务、目标和各小组成员的具体职责，对部门测试工作的正常开展起到规范的指导作用。 2测试团队构成 2.1组织结构图1 2.2测试组职能软件测试是软件开发过程中的重要组成部分，测试团队主要肩负着如下责任：在项目的前期、需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。针对测试需求进行相关测试技术的研究。根据项目的实际需求，编写合理的测试计划，并与项目整体计划有机地整合在一起。编写高效、覆盖率高的测试用例，充分保证测试的完整性和可执行性。部门经理（或项目经理）测试小组测试小组测试组长测试实施工程师测试组长测试实施工程师

认真仔细地实施测试工作，内容包括功能性测试，文档测试，兼容性测试，性能测试，安全测试等，并提交各阶段测试报告供项目组参考。进行缺陷跟踪与分析。对测试整个过程进行总结，完善和优化测试流程，提高和改进测试方法和技术。 2.3职责划分在人力资源有限的情况下，一个团队成员可能会同时承担多个角色。角色名称相关主要责任部门经理（或项目经理）确定测试组长，分配测试任务给测试组。同其他部门协调，提供测试组所需的内、外部资源。了解项目进度，对测试组的工作进行指导、监督。

(完整版)技术部软件版本管理规范

技术部软件版本规范文档建立/修改记录：版本管理规范【新建项目版本管理部分】 1，项目组接到项目需求， 1.1，开发组出项目设计和开发计划； 1.2，测试在Git中建立空项目(项目名称开会时候会有，没有需要问)，形成master版本，版本设定为V0.0.0。 2，组长发邮件给技术总监，并且抄送给项目经理和测试。邮件内容：开发计划文档url和开发版本号(V0.1.0)，请批准第一阶段(开发计划中会包含)开发。 3，得到批准开发回复后，测试从master(V0.0.0)建立分支版本(V0.1.0)，打开版本参与人员的更新权限，并且将url给组长。 4，组长download项目，上传项目可运行框架，并且更新GIT中的readme文档并通知开发；5，开发者必须按时按功能点来提交(提交时需写相应描述)项目到GIT中，并且push前必须测试，保证代码不能有运行异常，导致无法测试 5.1，Push结束后，开发者继续开发下一个功能点。 5.2，push结束会自动化构建，自动化构建完成后系统会自动通知测试人员进行测试，测试人员需先关闭版本参与人员的更新权限，再按功能点来测试bug，然后更新bug文档和测试用例文档的内容(有无bug都需要更新)，随即打开更新权限并通知组长。 6，开发者下一个功能点提交时，同上要求。 7，第一阶段最后一个功能点提交完毕后，测试者关闭此版本参与者更新权限，然后将此版本(V0.1.0)建分支版本(V0.1.1)并且给出版本url给组长，继续进行测试最后一个功能点bug。8，组长通知组员进行bug（bug一般会比较少，bug很多只能说明开发者开发质量有问题）修改，给出修改版本地址。 9，修改完毕后提交，测试人员再次关权限且测试，如仍然有bug存在，更新相应文档并在相关修改支版本(这里是V0.1.1)中再次建立修改版本(此时是V0.1.2)，随即给出版本url给组长。ps：提交版本如有冲突找组长调节。 10，第一阶段开发完全完成后开始开发第二阶段任务，重复2~9步骤，相应的版本号会变为从V0.2.0开始，同里修改版本号则是V0.2.1/V0.2.2/V0.2.3...... 11，当全部阶段任务完成(指的是开发完成并测试无bug)，测试将最新的修改完成的版本(应该是V0.x.x，x为任意数字)合并到master版本中，此时版本号设定为V1.0.0。测试发邮件给

版本测试管理规范

版本测试管理规范编制：审核：批准：编号: W TH-SP-0768 版本/状态：A/2

文件编号MSD-SP-0768 版本/状态A/2 版本测试管理规范生效日期2015-10-27 目录 1、目的/方针 (2) 2、范围 (2) 3、原则 (2) 4、角色与职责 (2) 5、入口准则 (3) 6、输入 (3) 7、流程图 (3) 8、“在研”项目的版本管理的主要活动 (4) 9、已结案软件维护测试流程......................................................................................................................... (6) 10、已结案软件维护测试主要活动 (6) 11、版本测试管理规定.......................................................................................................................................... ..7 12、输出 (8) 13、出口准则 (8) 14、软件版本发布流程 (9)

态生效日期2015-10-27 1、目的/方针制定版本管理过程的目的：有效指导版本转测试的相关工作活动，使得工作过程更加的规范，避免版本的混乱，有效地进行版本控制。 2、范围适用于公司所有“在研”项目或者 “已结案”的维护类项目测试。 3、原则 “在研”的研发样机与试产后的样机送测试部进行系统测试。已结案的维护类项目需要维护测试，送质量管理部进行测试，是否结案以质量管理部的结案公告为判定准则。 4、角色与职责角色职责项目经理1、发起“测试通知”工作流； 2、工作流处理情况监控； 3、BUG 评审及决策会议的组织等管理相关工作；技术负责人 1、工作流审核及任务下发； 2、协助工程师进行BUG 的修复； 3、督导及审核软件工程师提供《自测报告》及《版本发布说明》；硬件工程师 1、工作流任务下发，附件提供《自测报告》； 2、测试机器的提供及硬件BUG的修复；软件工程师 1、按照需求，处理工作流，除软件代码上的修改外，也包括《版本发布说明》及《自测报告》的写作； 2、BUG的修复；配置管理员1、负责版本代码集中编译、版本基线标识； 2、负责规范命名测试版本号； 3、版本的统一管理，将“待定稿”的版本，移入“正式软件”，并做好相应的记录，方便后续版本的取用；测试工程师 1、测试用例写作； 2、测试执行; 3、测试报告的输出；测试主管（测试经理）中心领导测试任务下发和测试报告的审核对正式版本和临时版本发布审核

产品版本管理规范

基于Tortoise SVN的软件产品版本管理规范[草稿]

目录 1. 引言 (1) 1.1. 目的 (1) 1.2. 范围 (1) 1.3. 术语定义 (1) 1.4. 参考资料 (2) 1.5. 版本控制记录 (2) 1.6. 版本更新记录 (2) 2. 版本管理 (4) 2.1. 版本标示方法 (4) 2.1.1. 正式版本 (4) 2.2. 目录结构 (5) 2.3. 文档的存放 (6) 2.3.1. 开发文档的存放 (6) 2.3.2. 源代码的存放 (6) 2.3.3. SQL的语句存放 (7) 2.3.4. 发行文档的存放 (7) 2.4. 配置管理流程 (7) 2.5. 权限控制的管理 (8) 3. 更新管理 (9) 3.1. 源程序的修改 (9) 3.2. 版本升级 (10) 3.2.1. 版本升级原则 (10) 3.2.2. 新版本发布 (11) 3.3. 文档的变更 (11) 4. 备份管理 (12) 5. 版本工具Tortoise SVN的使用 (13)

测试流程规范

测试流程规范版本： 1.0 上海锐至信息技术有限公司二〇二〇年五月

修订历史记录

一、概论：根据我们公司的情况，测试分为2种模式，一种是根据新需求进行的测试，以下文档以NEW表示该模式；第二种对于已发布版本升级的测试，以下文档以UPDATE表示该模式。二、NEW的测试规范 ●需求阶段：测试工程师需要在参与需求讨论之后，或者对需求说明书（SRS）进行需求分析后，整理对应的疑问录入到需求问题列表，汇总后邮件发送项目负责人（PM）或者与其当面沟通后，将沟通结果邮件发送给测试小组成员抄送给开发小组、项目负责人需求问题列表.xls （PM）。具体的参见附件所示的需求问题列表模板。 ●设计阶段：测试工程师根据开发计划、概要设计后，设计整理出项目整体测试计划。根据项目情况需要实时更新计划。具体的参见附件所示的需求问题列表模板。

测试计划模板.doc ● 准备阶段： 1）测试工程师根据详细设计，设计编写测试详细用例。优先级为1的用例为正面基础流程用例，优先级为2的用例为正面详细用例（实施可以用该用例进行现场实施验证），优先级为3的用例为反面用例或错误用例。 2）测试工程师收到leader 转发的测试申请邮件后，针对申请内容进行评估，将相应的结果录入到测试申请反馈上传到PMS ，在测试申请反馈文档中，需要写明接受那些部分的测试申请，不接受那些部分的申请，并发送邮件告之申请人反馈内容以及反馈上传的对应PMS 链接。具体的参见附件所示的测试申请模板、测试申请反馈模板测试申请模板V1.0. xls 测试申请反馈模板V 1.0.xls ● 执行阶段：测试工程师根据详细用例执行操作，执行完操作后需要记录对应结果，如果未通过该用例需要将bug 情况录入到PMS ，并在测试记录上填写对应的bugID 。在与开发沟通bug 情况后，需要询问修复时间，安排对应的回归测试。具体的参见附件所示的测试记录模板测试记录模板.xls ● 测试结束阶段：测试工程师根据测试记录、BUG 管理填写测试报告，并且编写对应的用户手册。具体的参见附件所示的测试报告模板测试报告模板.xls 三、UPDATE 的测试规范

源代码管理规范

源代码管理规范标准化文件发布号：（9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-

代码管理制度 1总则.................................................................................................. 错误!未定义书签。2源代码完整性保障............................................................................ 错误!未定义书签。3源代码的授权访问............................................................................ 错误!未定义书签。4代码版本管理 ................................................................................... 错误!未定义书签。5源代码复制和传播............................................................................ 错误!未定义书签。6系统测试验收流程............................................................................ 错误!未定义书签。系统初验........................................................................................... 错误!未定义书签。试运行............................................................................................... 错误!未定义书签。系统终验........................................................................................... 错误!未定义书签。系统验收标准................................................................................... 错误!未定义书签。文档评审通过标准........................................................................... 错误!未定义书签。确认测试通过标准........................................................................... 错误!未定义书签。系统试运行通过标准....................................................................... 错误!未定义书签。