如何测试处理以不可预测格式存储的大量数据的程序

如果没有数据格式的规范,那么任何东西都是可以接受的。

如果不是,则存在数据的显式或隐式规范。我现在就想把这件事弄清楚。如果您无法获得足够明确的数据定义来编写程序,从而使程序能够正常运行,那么我会说,根据这些数据的使用方式,您将冒很大的风险造成严重的损害。

您应该编写程序,以便在运行不符合规范的数据时抛出异常或记录错误。然后,在部分可用数据上运行该程序,直到它正常运行。这可以看作是一个培训集,用于开发您的课程。然后,使用一些保存的数据作为测试集。这将为您提供程序将在生产中生成的异常/错误数量的估计。

如果您不愿意执行所有这些步骤(即,在基本上所有数据上运行代码——因为测试集也在使用这些数据),那么我会说任务太大,无法完成。

另一方面,与其创建一个解释当前数据中所有“错误”的非常奇怪和特殊的格式定义,不如为数据创建一个新的规范化(从某种意义上说,这些东西被简化了)规范,然后编写一个“错误的文档修补程序”可以在有故障的文档上运行以修复数据。

如果生成数据的应用程序仍在生产中,那么您可能需要去找该应用程序的开发人员,以获得对新规范的认可。一旦您有了新规范,您就可以开始记录其应用程序的错误,因此希望有故障的文档修补程序可以退役。

更有可能的是,我猜软件开发人员早已离开,没有人再理解代码了,即使代码还在运行。

在这种情况下,如何测试程序的正确性?或者更确切地说,如何在不运行整个可用数据的情况下获得相当稳定的产品版本?

对于每一种数据类型,我都会对允许的值设置合理的约束。 如果单元格违反了这些约束,则抛出一个异常,该异常包含它失败的数据段及其数据类型。如果某个数据段违反了其约束,则可以修改源以包含该数据段所需的其他约束,并修改转换方法以使其统一。

举一个你给出的日期的例子,最初的日期会有一个限制,它只能是四位数。当程序遇到“20”时,会抛出异常。 然后,您可以允许使用两位数的日期,以及一种将两位数的日期转换为四位数的方法,以允许进一步处理。

在这种情况下,您可以非常防御性地在出现意外数据时抛出异常。在越来越大的数据集上重复运行程序。首先,通过修改代码来解决任何异常,因为首先发现的异常将是常见的,这是一条很好的经验法则。您可能希望在两次运行之间清空输出数据库。

对于这类事情,我通常按照@MarkJ的建议来做,并在单元测试中对整个事情进行编码。

因此,我编写了一个小数据文件,起初只包含几行普通数据。这是单元测试1。

然后我对一些数据进行快速的视觉扫描,以发现任何明显的异常。单元测试2到n。

最后,我编写解析器代码,直到它通过所有单元测试,并抛出和记录所有未管理数据的异常。

虽然有时容纳一些非常奇怪的数据会增加解析器的复杂性,但这是不值得的,我将记录异常,转储它,然后继续。这是一个专业判断的问题。

这将隔离未处理的数据以供用户更正,并防止您处理相同的数据两次(或更多)。