企业官网建设流程全解析

简介：这是一份由Vector Informatik GmbH发布的《Vector DOORS AddIn for vTESTstudio》官方用户手册（英文版），主要面向使用vTESTstudio进行测试开发与需求管理的测试工程师，帮助解决DOORS需求与Vector测试工具链之间的同步、追踪与验证难题。资源以单个PDF文档形式提供，压缩包大小约2.74MB。手册先介绍安装与工作流，再系统讲解六大核心功能：从DOORS导出追踪项、扩展DXL脚本导出额外属性、将追踪项导入vTESTstudio、将追踪项链接至具体测试用例实现、在CANoe中执行测试单元以及导入CANoe测试报告，并配有认证、保修、支持与商标等背景信息，内容完整。每个功能的操作步骤与界面提示清晰，读者可按图操作，快速掌握从需求导入、用例关联到测试执行、结果回传的完整协同逻辑，提升需求追溯效率与测试覆盖率。目前已有227人学习/下载，适合汽车电子测试与需求管理工程师参考。

1. Vector DOORS AddIn：先用一个场景看清它在测试链路里的位置

台架测试团队最常见的拉扯是：需求躺在 IBM Rational DOORS 里慢慢变，测试用例在 Vector vTESTstudio 里维护，执行结果散落在 CANoe 报告里，三套系统各说各话。每次版本评审要凑需求覆盖率，就得有人手动把三份数据倒一遍，倒完还得祈祷没看漏。Vector DOORS AddIn 就是官方用来把这三段接成闭环的插件：DOORS 模块里的对象导出成 trace item 进 vTESTstudio，拖拽链接到测试用例，CANoe 执行后报告再回写 DOORS。它默认只导出标题、文本、标识符、URL、模块版本五个属性，多出来的需求属性要靠改随附的 DXL 脚本自己加，这也是很多人装完发现不够用的第一个坎。适合谁？天天和覆盖率较劲，或者被 DXL、vTESTstudio、CANoe 来回倒腾数据的测试工程师和脚本开发。

2. 安装与注册：自动安装之外，两个注册表键位和一处 COM 组件

2.1 自动安装覆盖不了的两种场景

插件有独立安装包，从 Vector 官网下载后一路下一步，正常情况下 DOORS 菜单栏会出现 vTESTstudio 菜单项。但有两种场景是自动安装覆盖不了的：第一种，插件装完了你才装 DOORS，或者 DOORS 做过大版本升级，原来注册的路径已经失效；第二种，公司环境下 DOORS 装在新的机器上，旧机器上跑通的插件没有迁移过来。这两种情况不需要重装插件，只要手动在注册表里把插件路径重新登记一次。

手动注册的本质，是告诉 DOORS 去哪个目录加载 addin。DOORS 启动时会按注册表里的 Addins 值逐个加载目录下的 addin 文件，路径不对、类型不对、或者加了引号，都会直接表现为「菜单里什么都没有」。

2.2 注册表 Addins 键：HKCU、HKLM 与 64 位路径

打开 regedit，按当前 DOORS 版本找到注册表键，常见的是HKEY_CURRENT_USER\Software\Telelogic\DOORS\9.4\Config。这里的版本号要和你装的 DOORS 客户端对上，9.4 只是一个常见示例。先看 Config 键下面有没有现成的Addins值：

• 没有：新建一个 REG_SZ 类型（字符串值），名字叫Addins，值填插件安装目录，例如C:\Program Files (x86)\Vector vTESTstudio DoorsAddIn 3.0\Doors-9.3+；
• 已有：把插件路径追加到原值后面，多个路径之间用英文分号;分隔，千万别直接覆盖原来的值。

这里说下几个容易踩的细节。第一，HKEY_CURRENT_USER下的配置优先级高于HKEY_LOCAL_MACHINE，也就是说如果当前用户下配了 Addins，机器级配的 Addins 里那堆老插件可能就不加载了；想让所有用户生效，常见做法是把 HKLM 里原有的值复制一份进 HKCU，再追加新插件路径。第二，64 位 Windows 上，HKLM 路径里不是Software\Telelogic，而是Software\Wow6432Node\Telelogic，因为 DOORS 客户端是 32 位程序，注册表会被重定向到 32 位视图。很多人按文档找半天找不到键，多半是栽在这。

另有一条和注册表并行的加载方式：DOORS 启动时带-addins参数直接集成 addin。需要注意，一旦走了命令行方式，注册表里登记的 addin 就不再被读取。实际项目里不建议命令行和注册表混用，排查问题时你会分不清当前生效的是哪条路径。

2.3 RegisterCOMServer.bat：为什么必须用管理员 cmd

有些场景下，光注册 addin 还不够，COM 组件也要单独注册，典型的就是手动在注册表里登记完，DOORS 模块里打开 vTESTstudio | About 版本对话框，看不到插件带的那几个 COM 组件版本。这时要到插件安装目录下执行 RegisterCOMServer.bat。

cd "C:\Program Files (x86)\Vector vTESTstudio DoorsAddIn 3.0" RegisterCOMServer.bat

手册里有一句非常容易忽略的警告：用右键「以管理员身份运行」来执行这个 bat 是不行的，必须打开管理员权限的命令提示符（cmd.exe），再 cd 进去执行。原因在于这个脚本要注册 COM 服务器，需要写系统级的 HKCR 注册表分支和 COM 目录，双击运行 bat 时默认工作目录不一定是脚本所在目录，提权方式也不完整；管理员 cmd 能同时保证权限和工作目录都正确。

注意：验证 COM 组件是否注册成功，不用去注册表里翻。打开 DOORS 模块，进 vTESTstudio | About，版本对话框里能看到对应组件，才算真的注册上了。

安装目录下是按 DOORS 版本分子文件夹的，比如 Doors-9.3+、Doors-9.1_9.2、Doors-pre9.1，注册时路径必须指到和你 DOORS 客户端版本匹配的那个子文件夹。手册某处示例还出现过 2.2 的目录名，那是版本更新留下的旧示例，按你实际安装的 3.0 目录填。

3. 五阶段工作流：从 DOORS 导出到 CANoe 报告回写的闭环

3.1 导出 Trace Items：视图、过滤器和叶子对象

整个链路的第一步，是在 DOORS 里把需求或测试描述对象导出成 trace item 交换格式。入口是 DOORS 菜单里的 vTESTstudio | Export Trace Items…，这步之后会生成一个 XML 文件。

导出逻辑有三条规则，不搞清楚会导出得莫名其妙。第一，导出范围是「当前视图 + 当前过滤器」下所有未删除的对象，你在 DOORS 里隐藏了什么、过滤掉了什么，导出的结果就缺什么。第二，只有「没有可见子对象」的对象才会被导出为 trace item 叶子，带子对象的高层条目会被映射成 vTESTstudio 里的文件夹层级。也就是说，如果你在 DOORS 里把需求树折叠着没展开，或者过滤器把子条目滤掉了，导出来就只剩孤零零的父节点目录。第三，每个叶子对象默认带五个属性，对应关系如下：

这五个属性是 vTESTstudio 侧 trace item 的基础骨架。注意 URL 属性承担了后两跳的使命：vTESTstudio 里链接到用例、CANoe 报告里生成 reference，最终靠的都是这个 URL 指向 DOORS 里的原对象。所以导出前最好确认当前视图里 URL、Identifier 这些列是可见且有值的，否则后面报告里的 reference 会缺跳转目标。

3.2 导入 vTESTstudio，拖拽建立多对多链接

导出的 XML 不是拿来直接看的，要进 vTESTstudio。入口是 Tools | Trace Items | Import Trace Items…，选中刚才生成的文件，导入完成后，DOORS 模块的层级结构会原样出现在 Trace Items Explorer 里，父节点是文件夹，叶子节点是可链接的 trace item。

链接操作比想象中简单：直接从 Trace Items Explorer 把 trace item 拖到 test design editor 里的测试用例上。拖拽建立的是多对多关系，一个 trace item 可以挂在多个测试用例下，一个测试用例也可以挂多个 trace item——这正是一份需求对应多个验证点、一个用例验证多条需求的常态。链接做完，vTESTstudio 的 Traceability Matrix 里就能看到每个 trace item 的实现状态，哪些已覆盖、哪些还没挂用例，一屏筛得出来；下次重新导入后，有过变更的 trace item 也会被标识出来，方便你看需求改动波及了哪些用例。

3.3 CANoe 执行测试单元，报告再回写 DOORS

测试用例在 vTESTstudio 里组织成 Test Unit，执行环节交给 CANoe。在 CANoe 里跑完 Test Unit，生成的测试报告会带上一条关键信息：每个链接了 trace item 的测试用例，报告里都有对应的 reference，点进去能回到 DOORS 里的原始需求对象。这一步实现了从「测试结果」反查「需求」的链路，评审时不用再拿着报告和需求列表逐行核对了。

链路最后一步是回写。插件提供 Import CANoe Test Report 功能，把 CANoe 测试报告导入 DOORS 模块，测试结果按 trace item 的引用关系挂回 DOORS 对象上。这样 DOORS 模块里既能看需求原文，也能看这条需求对应的测试跑没跑、结果如何。整个工作流串起来就是：DOORS 导出 → vTESTstudio 导入 → 拖拽链接用例 → CANoe 执行带 reference 的报告 → 报告回写 DOORS 模块。前后两个入口都在 DOORS 的 vTESTstudio 菜单下，中间两跳在 vTESTstudio 里完成，链路封闭但两端各管一段，排查问题时先分清当前出错的是导出端还是导入端。

4. 扩展 DXL 脚本：给导出的 Trace Item 追加 Priority 这类自定义属性

4.1 为什么默认只导出五个属性，以及源码在哪里

vTESTstudio 的 trace item 交换格式核心字段就是那五件套，但 DOORS 模块里团队自己加的自定义属性千变万化——优先级、作者、评审状态、功能域、风险等级，这些字段对测试设计同样是有效输入。插件没有把导出逻辑做成黑匣子，而是把 Trace Item Export 部分直接以 DXL 源码形式放在安装目录里，想加字段就自己改。

源码文件叫 XMLExport.inc，位置在插件安装目录下按 DOORS 版本分的子文件夹里。版本与文件夹的对应关系是硬性的，DOORS 8.1 到 9.0 用 Doors-pre9.1，9.1 和 9.2 用 Doors-9.1_9.2，9.3 及以上用 Doors-9.3+。选错文件夹改出来的脚本不会生效，因为 DOORS 客户端加载的是对应版本目录里的那一份。

4.2 改造 XMLExport.inc：新增函数和插入点

改造要做两件事：加一个写属性的函数，然后在 writeObject 里调用它。下面这段是典型的扩展写法，把 DOORS 模块里一个叫 Priority 的属性追加进导出文件。

// 新增函数：把指定属性写成 XML <Property> 元素 void writeAdditionalInformation(Stream out, Object o, string attributeName) { // 先确认属性在当前模块里有定义，避免对不存在的属性取空值 if (exists attribute attributeName) { // 从对象上读取该属性的值 string attrValue = o.attributeName if (attrValue != null) { // XML 保留字符转义，防止导入解析失败 attrValue = replacePreDefinedCharacters(attrValue) // 输出一个 <Property> 块，<Name> 是属性名，<Value> 是属性值 out << sIndent << "<Property>" << "\n" increaseIndent() out << sIndent << utf8("<Name>" attributeName "</Name>") << "\n" out << sIndent << utf8("<Value>" attrValue "</Value>") << "\n" decreaseIndent() out << sIndent << "</Property>" << "\n" } } }

逐段说逻辑。exists attribute attributeName是 DXL 里判断当前模块是否定义了这个属性的标准写法，防止属性名拼错或不同模块属性不一致时取空值。o.attributeName是从对象上读属性值的写法，attributeName 是传入参数，函数被调用时它会被替换成实际属性名。null检查跳过空值对象，避免生成空的<Property>块。replacePreDefinedCharacters负责把& < >这类 XML 保留字符转成实体，属性值里一旦出现这些字符而不转义，整个 trace item 文件导入时可能直接失败，这是最容易翻车的一步。utf8()把内容转成 UTF-8，处理中文、特殊符号时必须走这一步。sIndent、increaseIndent、decreaseIndent维护 XML 层级缩进，保证<Property>块正确嵌套。

第二步是在原有函数 writeObject 里调用它。writeObject 原有逻辑会先输出 UniqueID、ReadableID、VersionIdentification、Name、Description、Reference 这些基础元素，然后在 Reference 行之后插入下面这一段：

// 插入位置：writeObject 内 <Reference> 行之后 out << sIndent << "<AdditionalInformation>" << "\n" increaseIndent() // 需要导出哪个自定义属性，就在这里为它调用一次 writeAdditionalInformation(out, o, "Priority") decreaseIndent() out << sIndent << "</AdditionalInformation>" << "\n"

参数说明：attributeName传给 writeAdditionalInformation 的字符串必须与 DOORS 模块里的属性名完全一致，大小写也敏感，模块里叫Priority，脚本里写成priority就取不到值。演示里只加了一个 Priority，实际要带 Status、Author 等更多属性，就在<AdditionalInformation>块里为每个属性加一行writeAdditionalInformation(out, o, "属性名")，互不影响。

4.3 改完怎么确认生效

保存 XMLExport.inc 后重新执行一次 vTESTstudio | Export Trace Items。注意是保存后重新导出，不是保存就完事；DOORS 执行导出时读的是磁盘上的 DXL 文件。

导出后先用文本编辑器打开生成的 XML，直接搜<AdditionalInformation>。能看到<Name>Priority</Name>和对应的<Value>，说明脚本改动已经生效，这一步只要几秒钟，比进 vTESTstudio 导完再发现没生效高效得多。确认无误后再导入 vTESTstudio，这时 Trace Items Explorer 的属性区、以及 Traceability Matrix 里都会出现 Priority 这一列。

提示：改脚本前先复制一份原始 XMLExport.inc 做备份。这个文件是内核级的导出模板，改坏了影响的是整个导出功能，有备份随时能还原，不用重装插件。

5. 常见问题与排查：注册、导出、导入三个环节的踩坑记录

5.1 安装与注册类：菜单消失和插件互相顶掉

坑一：插件装完，DOORS 菜单里没有 vTESTstudio 项。现象很直接，重启 DOORS 后菜单栏干干净净。原因通常是 DOORS 版本做过升级，注册表键还是旧版本号，或者 Addins 值指向的目录不存在。解决：按当前 DOORS 版本号找到对应注册表键，把 Addins 值指到实际存在的插件目录；64 位系统先确认走的是不是Wow6432Node路径。网上搜这个插件时还会碰到一半结果是 C++ 的 vector 容器，一半是 Vector 官网，先确认你找的是做 CANoe 的 Vector Informatik。

坑二：注册完新插件，原有 addin 失效。现象是 DOORS 里原来能用的 addin 菜单消失了一大半。原因大概率是 Addins 值被整体覆盖成了只有新路径，或者 HKCU 的优先级把 HKLM 里的老配置顶掉了。解决：追加路径时用;分隔，先把原值复制出来再追加；如果当前用户和机器级配置不一致，把 HKLM 里的原值复制进 HKCU 再追加，保证老插件路径还在。

坑三：RegisterCOMServer.bat 执行完，版本对话框还是空。现象是批处理没报错，但 vTESTstudio | About 里看不到 COM 组件。原因：不是管理员 cmd 环境，脚本写不进 COM 注册表分支。解决：重新打开管理员 cmd.exe，cd 到插件安装目录再执行一次，然后回 DOORS 里确认版本对话框。

5.2 导出与 DXL 脚本类：属性没带出来和导出数量不对

坑四：导出文件里没有自定义属性。现象是模块里明明有 Priority，导入 vTESTstudio 后矩阵里就是没这一列。原因通常是三种：改错了版本子文件夹里的 XMLExport.inc、属性名拼写或大小写和模块里不一致、脚本保存后没有重新导出。解决：先确认 DOORS 客户端版本，对照安装目录选对应子文件夹；属性名严格照抄模块里的拼写；保存脚本后重新导出，导出后用文本编辑器搜<AdditionalInformation>验证。

坑五：导出对象数量比预期少一半。现象是 DOORS 模块里几千条需求，导出的 XML 只剩下零头。原因：当前视图的过滤器和折叠状态影响了导出结果，带可见子对象的父条目不会导出为叶子 trace item，而被折叠或过滤掉的叶子也出不来。解决：导出前先调整视图和过滤器，把需要导出的对象展开到叶子可见，再执行导出。这条规则反过来利用也可以——只想导某个子集时，用过滤器圈定范围再导出。

5.3 导入与链接执行类：链接丢失和 report reference 缺失

坑六：导入 vTESTstudio 后，之前拖拽建立的链接显示丢失或矩阵标记变更。现象是重新导入 trace item 后，矩阵里一片未覆盖，或者之前挂好的用例链接断了。原因：trace item 的稳定识别靠 UniqueID 和 ReadableID，DOORS 侧如果对象标识变了，或者导出时 URL / Identifier 对应列在视图里不可见、值取空，导入后 vTESTstudio 会把它们当成新对象，旧链接自然失效。解决：导出前确认当前视图里 Identifier、URL 列有值；重新导入后先看 Traceability Matrix 的变更标识，再决定是补链接还是接受变更。

坑七：CANoe 报告里没有指向 DOORS 的 reference。现象是测试报告跑完了，用例旁边没有可跳转的需求引用。原因：trace item 的 Reference 属性在导出时就是空的，通常是 DOORS 对象没配 URL 属性值，或者导出视图里 URL 列被隐藏。解决：回 DOORS 检查对象的 URL 属性，导出前把 URL 列显示出来，重新导出导入再链接，报告里就能带出 reference。

6. 收尾技巧：用 Traceability Matrix 验证覆盖，两个能省的重复劳动

DOORS 导出、vTESTstudio 导入、拖拽链接、CANoe 执行、报告回写，五步串起来之后，大部分团队的下一步不是干活，而是被评审逼着证明「需求都被测了」。与其手工数数，不如把 Traceability Matrix 当成验证主工具：导入后先开未覆盖过滤，把所有没挂用例的 trace item 清零；执行完测试，抽查报告里的 reference 能正常跳回 DOORS 对象；报告回写后，回到 DOORS 模块按测试状态属性排序，重点看失败项对应的需求对象。

两个习惯能省下重复劳动。第一个，改 XMLExport.inc 之前永远先复制备份，并把「DOORS 客户端版本 ↔ 插件子文件夹」的对应关系写进项目交接文档。这个插件按 DOORS 版本分了三套脚本，改错文件夹是最高频的错误，换了人、换了电脑，没有记录就全靠猜。第二个，导出的 XML 在导入 vTESTstudio 前，用任意文本工具做一次 well-formed 校验，重点扫<AdditionalInformation>块里有没有没转义的& < >。replacePreDefinedCharacters 处理过的一般没问题，但自己手改脚本时漏掉这个函数的调用，导入就会翻车，而这种错误光看 XML 是看不出来的，必须靠校验工具。

有一回我改完脚本，矩阵里死活不出 Priority 那一列，排查了两个小时，最后发现改的是 Doors-9.1_9.2 那套，现场 DOORS 客户端跑的是 9.6，加载的压根不是我改的那份文件。从那以后，每次动脚本前我先看 DOORS 的版本，再决定进哪个子文件夹；导出后先搜一遍<AdditionalInformation>再进 vTESTstudio。这套验证路径多花五分钟，但再也没在需求追踪上返过工。希望帮到你。

本文还有配套的精品资源，点击获取