我们有一套转换器,可以获取复杂的数据并对其进行转换。大多数情况下,输入是 EDI,输出是 XML,反之亦然,尽管还有其他格式。
数据中存在许多相互依赖关系。有哪些方法或软件可以生成这样的复杂输入数据?
现在我们使用两种方法:(1)我们多年来构建的一组示例文件,主要来自文档中的文件错误和示例,以及(2)生成伪随机测试数据。但是前者只涵盖了一小部分案例,而后者有很多妥协,只测试了一部分领域。
在进一步实施(重新发明?)复杂的表驱动数据生成器之前,您发现哪些选项是成功的?
我们有一套转换器,可以获取复杂的数据并对其进行转换。大多数情况下,输入是 EDI,输出是 XML,反之亦然,尽管还有其他格式。
数据中存在许多相互依赖关系。有哪些方法或软件可以生成这样的复杂输入数据?
现在我们使用两种方法:(1)我们多年来构建的一组示例文件,主要来自文档中的文件错误和示例,以及(2)生成伪随机测试数据。但是前者只涵盖了一小部分案例,而后者有很多妥协,只测试了一部分领域。
在进一步实施(重新发明?)复杂的表驱动数据生成器之前,您发现哪些选项是成功的?
嗯,答案就在你的问题中。除非您实现复杂的表驱动数据生成器,否则您使用 (1) 和 (2) 做的事情是正确的。
(1) 涵盖“1 个错误已验证,1 个新测试用例”的规则。如果 (2) 的伪随机测试数据的结构与现实生活中的任何情况相符,那就没问题了。
(2) 总是可以改进的,当考虑新的边缘情况时,它会随着时间的推移而改进。用于测试的随机数据的问题在于,它只能是随机的,以至于很难从测试用例中的随机数据计算预期输出,以至于您必须基本上重写测试用例中的测试算法。
所以(2)总是匹配一小部分情况。如果有一天它匹配所有情况,它实际上将是您算法的新版本。
我建议不要使用随机数据,因为即使不是不可能,也很难重现报告的错误(我知道你说的是“伪随机”,只是不确定你的意思是什么)。
对整个数据文件进行操作可能会考虑功能或集成测试。我建议将您的一组包含已知错误的文件转换为单元测试,或者至少为您将来遇到的任何错误这样做。然后,您还可以扩展这些单元测试,以涵盖您没有任何“样本数据”的其他错误条件。每当您想到要检查的条件/规则违规时,这可能会比提出一个全新的数据文件更容易。
确保您对数据格式的解析是从格式中数据的解释中封装的。这将使如上所述的单元测试更加容易。
如果您确实需要进行测试,您可能需要考虑获取文件格式的机器可读描述,并编写一个测试数据生成器,该生成器将分析格式并基于它生成有效/无效文件。这也将允许您的测试数据随着文件格式的发展而发展。