软件版本管理规范测试-调查问卷模板-问卷网

您的姓名

____________

关于”燃管信息化系统 v1.2.3-231.3344.beta“描述正确的有(多选)

数字1表示主版本号

数字2表示特性版本号

数字3表示修正版本号

beta表示该版本正处于外部验收阶段

数字3344表示该版本的源代码在svn上的记录号为3344

下列关于版本号描述正确的有(多选)

主版本号：当做了不兼容的API修改。此版本号仅限产品部有权更改，起始号为1。

特性版本号：当做了向下兼容的功能性新增。此版本号由软件专业技术负责人更改，起始号为0

修正版本号：当做了向下兼容的问题修正。此版本号由软件专业技术负责人更改，起始号为0

当前svn记录号：表示编译时的svn记录号，由编译工具从svn获取记录号后自动填写

版本号中包含当前svn记录号，关于此记录号描述正确的有

当前svn记录号的存在目的是将程序与源代码对应起来，方便后期溯源

当前svn记录号可由脚本自动获取

登记当前svn记录号最佳方法是每次编译前由脚本自动填写

当前svn记录号应当取自代表所有代码更改的文件夹

版本号变更时应当注意

主版本号变更后意味着不会向下兼容，所以仅限产品部有权更改

新版本规范中，不允许在版本号前面加0

研发人员能够查看SVN中的”已发布“文件夹

研发人员可在”已发布“文件夹下提交代码

软件发布到现场时，以下描述正确的是

阶段版本号应当由dev更改为alpha

阶段版本号应当由alpha更改为beta

发布到现场前，研发人员需要填写“版本管理登记表”

发布到现场前，需要检测人员核查所有变更记录

研发人员提交代码到SVN时，以下描述正确的是

可提交IDE生成的obj、bin目录、debug目录、release目录

一旦修改代码，需要及时提交，每天至少提交一次

每天提交次数不宜太多

不应提交自己未作修改的文档

因修复禅道bug而作的提交，应当

在提交日志中写明类似格式”修正BUG#221“的文字，以便追溯

同属一个bug的多次提交，也应当按照格式”修正BUG#221“书写日志

提交的文字不应少于5个字符

需要描述本次提交的解决思路

因解决QM上的问题而提交代码时

须在svn注释中写明QM的质量通知号，格式为“修正QM#200021”，其中#后面为QM的质量通知号

不需要关联QM上的问题

日志信息包含5个字符以上

日志信息可为空

为现场的程序进行数字签名，目的是

数字签名的exe、dll在更改后，签名会自动丢失。根据此特性，可查证发布到现场的程序是否经过管理员审核过的

通过管理员的数字签名，可有效避免现场软件版本的混乱

避免研发人员修改现场程序后没有备案，后期无法找到源代码的问题

规避我司程序因病毒感染造成损失的风险

以下关于发布流程的描述，正确的是

阶段版本从alpha变更到beta时，需要检测组和管理员审核

阶段版本从beta变更到release时，需要检测组和管理员审核

发布前由管理员记录软件增加了什么功能、修复了什么问题

发布前需要管理员对exe、dll进行数字签名

alpha表示该版本处于公司内部检测阶段，beta表示该版本处于外部验收阶段。这两个阶段都允许研发人员修改代码，但是每次修改代码后要做的工作不一样，以下描述正确的是

beta阶段的产品运行于客户现场，直接影响客户体验，所以需要严格管控发布流程

beta阶段的产品一旦出现更改，需要在10天内进行数字签名

release阶段的产品出现更改，需要重新定义版本号

alpha阶段的产品需要数字签名

以下关于SVN目录规范的描述正确的是

“已发布”文件夹是通过建立分支建成的

“开发中”下应当包含“源代码”、“文档资料”、“安装包”三个文件夹

“开发中”下的文件夹不应该随意更改

“已发布”文件夹下内容研发人员不能读取

订单项目引用通用版本的代码时，以下操作正确的是

从SVN下载通用版本的代码，然后复制到订单项目目录下，最后提交到SVN

通过建分支的方式，将通用版本代码分支到订单项目中

引用的通用版本号需要软件专业负责人审核通过

只要涉及到引用其他代码，都需要使用分支的方式引用，这样可以很好的保留svn的修改日志，便于溯源

数字签名有什么好处？

能够确保软件经由管理员发布

防止杀毒软件误杀

提升公司知名度

能够检测到他人对软件的篡改

请选择以下选项 (多选)

查看exe文件属性，可以看到数字签名栏

以管理员身份运行时，会提示该程序的发布者

使用我司数字证书数字签名后的exe可以证明是由我司发布的

病毒篡改或者研发人员更改程序后，数字签名将自动丢失

beta阶段的软件需要不断完善才能完全适应现场环境，放心交付给客户使用。安排检测人员定期审查现场程序是否已经数字签名的目的是

督促研发人员及时将代码存档，避免时间过久遗忘存档，导致代码与现场程序不一致

培养研发人员及时存档的良好习惯

跟进现场软件完善进度

避免未经审核就发布的事情发生

关于SVN中的“已发布”文件夹，以下描述正确的是

订单下存储的内容相当于现场软件的当前版本和历史版本

专用版的软件代码将取自“已发布”下的代码

已发布下的代码表示经过检测组检测与管理员审核过的

研发人员不仅能下载此文件夹内容，还能提交修改此文件夹

关于SVN提交的描述正确的是

可提交zip、rar等压缩文件

“源代码”文件夹下允许提交hex、exe、dll等类型文件

“安装包”文件夹下允许提交exe、dll等文件

obj、log、bin等类型文件不应该提交到svn中

当技服在QM上提交问题后，研发人员应当

及时处理QM上的问题，并在QM上及时回复进度

当自测或和技服一起确定问题已解决时，督促技服及时在QM上写明已验证解决

将问题彻底解决，避免问题重现

解决问题后在QM上回复即可，不需通知技服验证

检测人员提交BUG到禅道之后

研发人员应当在48小时内确认，并在15天内给出解决方案

研发人员超过48小时未确认将记违规事件

研发人员应当在15天给出解决方案

检测人员需要及时验证研发人员标记已解决的问题

提交代码到SVN时需要注意

不要把加密过的代码提交到SVN上

每次提交前先更新（update），再提交（commit）

无论在公司还是在客户现场，一旦修改代码，每天至少提交一次代码

建立的文件夹不应该包含“最新版”字样

软件版本管理规范测试

相关模板