我专注于你的最后一个(和粗体的问题)......并快速浏览其他......
我不是 XMLSPY 用户...不过,我已经问过一些人,据我所知,没有开箱即用的报告可以准确地为您提供所需的内容。我确实知道 XMLSPY 有一个自动化 API,我确信可以很好地利用它来获得确切的需求。
从通用工具的角度来看,QTAssistant(我与它相关联)有一个开箱即用的报告,可为您提供依赖关系报告(可以导出到 Excel)。下面是显示 UBL 2.1.0 XSD 文件依赖项的屏幕截图。
考虑到您的要求,我相信您走在正确的道路上(将您的方法组件化)......我会提出一个更好的角度......
根据我的经验,人们在您的场景中犯的许多错误之一是在定义测试数据模型时关注 XSD 文件布局。一般来说,XSD 作者(通过 xsd:include/xsd:import)描述的 XSD 文件之间的关系并不总是与 XSD 处理器相关。事实上,一个引用可能会丢失,而不会影响 XSD 集的完整性;多余的引用可能会导致布局中不必要的开销,而 XSD 处理器会安全地“忽略”它们。这最终意味着 XSD 组件之间的关系不一定与 XSD 文件布局所描述的关系相同。
另一个常见的错误是将测试数据放在一个模型中,该模型通过名称和/或结构逐字逐句地使用 XSD 组件。至少根据我的经验,测试数据和 XSD 模型由两个不同的团队管理,它们的优先级、时间线和对一般技术的理解大不相同,尤其是 XML 和 XSD。这最终意味着 XSD 组件之间的关系不一定与项目需求文档中描述的关系相同,甚至在业务领域中也不一定相同:粒度可能不同,关系可能扁平化或超规范化等。
将测试数据建模与 XSD 耦合有一个缺点……例如,创建测试数据的人尽可能早地需要 XSD,通常情况下,不合理地(对于 XSD 设计人员)及早;更不用说对 XSD 的更改(由于新的要求、合规性和错误修复等)在测试数据方面造成了严重破坏。
如果 XSD 已经存在,或者 XSD 是“那个”模型(而不是 UML,或其他类型的建模语言)......它可以用作“灵感来源”......不过,在我的意见,应该通过一个映射层来确保两者的解耦:您的测试数据模型,与 XSD 描述的模型。
这让我想到了我们推荐的方法...... XSD 背后总是有一些东西(需求等),或者采用 XSD 描述的模型(不是它的组件),或者测试数据需求。使用它来构建“规范化”数据集......例如,它可能是一堆 Excel 工作表,或者您最喜欢/可用的数据库中的一些表。
使用一些工具组合,这些工具将使用映射信息将规范化数据集中的数据转换为 XML,最好是直接基于 XSD 或间接(例如 ORM 映射)。您必须检查哪些适合您,这取决于您运行的平台,以及您可以引入哪些技术(我们为此使用 XML Builder)。
例如,假设您使用客户、帐户、发票等对象。您的测试数据应该描述这些。虽然 XSD 也应该排列起来,但它可能会使用各种其他东西,并且出于不同的原因(替换组、类型层次结构、组等,以实现可扩展性、重用、将 XSD 适应代码绑定等)。重点是,很多东西放在 XSD 中以支持与业务领域模型无关的各种需求,这可能会给您的测试数据模型带来负担。
更不用说对您的测试数据进行建模还可以为一般的测试模型提供种子......这与(好的)XSD 应该实现的更加不同。