代码之家  ›  专栏  ›  技术社区  ›  lavinio

如何测试需要复杂输入数据的程序?

  •  1
  • lavinio  · 技术社区  · 15 年前

    我们有一套转换器,可以获取复杂的数据并对其进行转换。大多数输入是EDI和输出XML,反之亦然,尽管还有其他格式。

    数据中存在许多相互依赖关系。什么 方法 软件 是否可以生成这样复杂的输入数据?

    现在,我们使用两种方法:(1)我们多年来构建的一套示例文件,主要来自文档中的文件bug和示例;(2)生成伪随机测试数据。但是前者只覆盖了一小部分案例,后者有很多折衷之处,并且只测试了字段的一个子集。

    在深入实施(再创新)之前复杂的表驱动数据生成器,有哪些选项 找到成功了吗?

    2 回复  |  直到 15 年前
        1
  •  2
  •   FWH    15 年前

    答案就在你的问题上。除非您实现了一个复杂的表驱动的数据生成器,否则您可以用(1)和(2)来做正确的事情。

    (1)包含“1个bug已验证,1个新测试用例”的规则。 如果(2)的伪随机测试数据的结构与现实生活中的任何情况都相符,那就很好了。

    (2)在考虑新的边缘案例时,总是可以改进的,而且主要会随着时间的推移而改进。用于测试的随机数据的问题是,它只能是随机的,以至于很难从测试用例中的随机数据计算出预期的输出,所以您必须在测试用例中基本重写测试的算法。

    所以(2)总是匹配部分案例。如果有一天它匹配了所有的情况,它实际上将是您的算法的新版本。

        2
  •  0
  •   Mark Roddy    15 年前
    1. 我建议不要使用随机数据,因为如果不可能重现所报告的错误,可能会很困难(我知道你说的是“伪随机”,只是不确定你说的是什么意思)。

    2. 对整个数据文件进行操作可能会考虑功能或集成测试。我建议您将带有已知bug的文件集转换成单元测试,或者至少对您将来遇到的任何bug这样做。然后,您还可以扩展这些单元测试,以涵盖您没有任何“样本数据”的其他错误条件。当您每次想到要检查的条件/规则冲突时,这很可能比使用一个全新的数据文件更容易。

    3. 确保数据格式的解析是从格式中的数据解释中封装出来的。这将使如上所述的单元测试更加容易。

    4. 如果您确实需要驱动您的测试,您可能需要考虑获取文件格式的机器可读描述,并编写一个测试数据生成器,该生成器将分析该格式并基于该格式生成有效/无效的文件。这也将允许您的测试数据随着文件格式的发展而发展。