【问题标题】:Regression testing for schema (xsd) equivalence模式 (xsd) 等效性的回归测试
【发布时间】:2010-12-27 16:20:27
【问题描述】:

我正在考虑将其中包含许多独立复杂类型的模式重写为复杂类型更明智地扩展其他基本类型的模式。这样做的理由部分是概念性的——因为这些类型中的大多数是具有明确层次结构的域对象的特定实例——部分是实用的,因为我们使用 JAXB 生成的类来处理 XML 读取逻辑并且不可能编写无需反射或大量instanceof 和强制转换的通用功能方法。呵呵。

所以我的主要问题是,是否有人知道测试两个 XSD 模式的功能等效性的好方法?如果我正确执行此模式重构,则认为有效的文档集对于两个模式应该完全相同,尽管文件本身会非常不同。这听起来像是测试框架可以提供帮助的那种事情;我知道有一些工具可以建议 JUnit 测试的测试输入,我想知道是否有任何工具可以生成边缘案例 XML 文档来测试新旧模式的有效性?

顺便说一句 - 如果这是一个糟糕的想法(或者如果有更好的选择),那么现在阻止我。 :-)

感谢您的关注。

【问题讨论】:

  • 测试 JAXB 类是否等效会更容易吗?
  • @jon - 可能不是因为这些类不包含架构规定的全部内容。这是一个有趣的想法(即确保每种类型具有相同的 bean 属性),这对于检查某些类别的错误很有用,但我认为它并没有完全做到(事实上它实际上并没有做任何事情XML 验证让我很紧张)。

标签: xml validation xsd schema testing


【解决方案1】:

经过一番调查,我遇到了Liquid XML Sample Generator,这听起来正是我想要的那种东西(虽然我不确定相当这会有多好用于测试边缘情况)。

我还偶然发现了SUT: XML Schema Unit Test,它看起来不再被积极维护,也没有很好的文档记录,但采用了一种更加程序化的方法来定义给定模式的有效或无效 XML 文档,并对其进行测试。不幸的是,测试用例似乎是线性解释的,而不是像上面的 XML 示例生成器那样为每个不同的节点置换可能性。因此,虽然可以强制实施更好的覆盖范围,但这可能需要大量工作。

所以至少我有一个可行的后备方案——从旧模式生成一堆文档,然后根据新模式验证它们,反之亦然。这不是确定的(好吧,单元测试从来都不是),但是在每个方向上运行几百或几千个测试应该可以很好地确信模式是等效的。

我仍然很高兴能提供一个优雅的测试解决方案,但经过一个小时的谷歌搜索后,我并不抱太大希望存在类似的东西。

【讨论】:

  • 最终考虑到似乎没有任何灵丹妙药,我使用了一个 XML 文档语料库,其中包含一些从生产中捕获的文档,以及很多由 Liquid XML 生成的文档。虽然这并没有(也不能,正如 xcut 所指出的那样)给人 100% 的信心,但它确实走了很长一段路。
【解决方案2】:

这个问题没有一般的答案,因为两个上下文无关文法是否等价的问题是不确定的。见this wikipedia page

已经在这方面做了一些理论上的工作,但是没有现成的工具可以为你做这件事。

如果您对如何设计架构做出某些假设(禁止匿名类型、命名约定等),您可以解决这个问题。然后,您可以使用像 eclipse XSD 这样的库(它可以在 Eclipse 之外的独立应用程序中正常工作)来执行比较。

最后,link to a research paper 更详细地讨论了这个问题。

【讨论】:

  • 感谢您提供了一个有趣且内容丰富的答案,该答案值得我给予更多的支持。尤其有趣的是,知道这是一个无法确定的问题 - 这使得大样本的经验测试更容易接受。
猜你喜欢
  • 2018-08-02
  • 2017-04-24
  • 2021-08-06
  • 2017-01-17
  • 2017-01-02
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多