认识达内从这里开始

数据测试是程序员在做软件测试的时候经常用到的一个测试方法，而今天我们就一起来了解一下，数据测试常见问题与改进措施都有哪些。

我们认为数据测试失败的根因来源于以下几类：

数据实际上正确，但是我们测试需要兼容。比如，有一些不寻常但正确的异常值。

数据实际是错误的，但可以被修复。直观的例子，格式错误的日期或者电话号码。

数据崩溃了，并且不可以修复。比如，数据缺失。

一个非常普遍的数据问题，发生在数据加载或者数据获取阶段，数据发生了变化，数据的团队就无法控制。在我做三方医疗数据时，我看到无处不在的各种各样的数据问题。一些普遍的例子，包含数据不被更新(数据发布延迟导致)，表属性的变化(比如列名和类型)，或者值和范围与预期偏离(生成数据方法变化)。另一个主要的原因在数据获取时的问题是在实际的数据获取或链路中，经常会出现(标记为)旧数据。这种经常经常发生在处理hang、crash或者获取备份时，因为长时间的运行。

现在，你怎样去定位数据获取问题的根因?关键且有条理的步骤：

确认实际发生的、精确的问题

确认是什么引起了这个问题

考虑到模板，我的建议不要把问题归咎于表面的数据。例如，对NULL值的测试可能会失败，因为有些行实际上就是NULL，或者因为那一列不存在。确保你看到了所有的失败，然后定位问题的所在。一旦问题清晰了，那么你就可以开始定位是什么原因导致的。当然，我们不能罗列所有潜在的原因，但是一些普遍的原因如下：

代码的变化(可以问一下团队的人或者看下版本控制记录)

处理崩溃或者连接中断(日志文件)

数据发布延迟(确认你的数据源是否及时发布)

上游的数据变化(检查源数据，与数据生产者确认)。后，当数据经常获取失败，测试失败经常是由于代码的变化。一种消除非预期值的影响的办法是使数据流水线作为发布过程和CI/CD过程的一部分。让工程师和数据科学家自动化的测试他们的代码，例如，对于thegoldendataset，如果实际结果与期望不符，那么将不会发布到生产环境。

问题解决

现在，如何修复问题呢?当然，没有一个统一的方法去修复数据问题，修复问题极度依赖他的实际原因。回头看一下我们对于测试失败的三种根因，我们可以使用下述三种方式来使我们的测试能够通过：

如果你确定数据绝对正确，但是测试却失败了，你需要调整你的用例。

如果数据可修复，一些已知的解决方案是，重新执行你的流水线，可以在遇到连接超时或者资源限制等问题上提高鲁棒性，或者修复你的流水线代码，理论上可以加一些机制，让工程师测试代码来避免相同的问题再次发生。

如果数据崩溃了，你可能要去联系数据生产者来确认。无论如何，直到这个问题被解决，一定有需要你去剔除掉的记录，数据集或者分区。尤其是当你要处理三方数据时，有时候数据被删了、被改了，不再更新了，也没法在你的测试用例中使用了。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。