1、你不可能知道这是一条脏数据，比如，一条脏数据和正常数据，他们之间的区别只是人为修改了一个字段导致，可能这个字段在前端也不会展示出来，只有开发在 debug 状态下才能发现这个字段是错误的，所以可以确认你们研发是个撒币
2、如果不是人为修改数据库导致的脏数据，是通过其他写接口导致的，那么这一定是个系统漏洞，名正言顺的 bug

如果在系统正常操作产生脏数据，那就是有问题了，

我就一句话：你为什么还会质疑自己？你唯一显得不专业的地方就是对这事的自我怀疑

实现，脏数据，，可能是之前的接口有问题，产生的。

主要看你有没有访问数据库的权限，我们公司，测接口的时候，都会校验数据库的数据，看生成的是否正确；

其次是脏数据，测试的时候，发现的 bug，确实应该要校验一次，是不是因为脏数据导致的误报，这个跟开发无关；

其根本原因在于，接口测试的时候，发现会产生脏数据（错误数据），就应该提交 bug 了。

实际场景中，脏数据问题也是开发需要去处理的。一般过期、有字段缺失/错误或这类的比较好判断。测试权限有限，能获得的信息也是有限的，脏数据也没办法准确判断。另一方面，脏数据是否是 bug 导致的？实际场景中用户常规操作会不会产生脏数据？若产品存在脏数据，会不会有不好的影响？新的缺陷又可以提了

程序没有问题，使用程序就不会产生脏数据。这时候出现问题就应该找开发排查并且解决问题。
手动修改数据库数据，或者手动调用接口，产生的脏数据。大概率不是程序 bug。

前置一下，因为开发写的功能产生的脏数据，bug 前移一下，正常请求，服务端响应返回的数据不对，并附上正确应该返回的响应数据

脏数据哪里来的，还不是开发没做好效验，线上出了问题，也这么跟用户解释吗

功能造成脏数据，说明功能有问题，可以往这方面提交 bug；如果是因为测试伪造数据不全导致的脏数据，那就不能算 bug 了

新版本新建的数据如果脏了，那就是有 bug，直接提，至于原因，如果自己不清楚，你可以提 bug，写完整该新建数据的步骤，让开发查就行

干就完了

梳理一下你们的业务流程，从头开始来测试，那再出问题就没话说了

找出脏数据源头啊，找不出来？删掉，眼不见为净，研发测试都不头疼。

所以你为什么不按照流程造数据

如是是手工通过系统创建的数据，经由开发检查，认为是脏数据，那就是需求和代码层面有问题。
如果是通过自动化的方式创建的数据（数据格式有问题、字段缺失等），或通过直接改数据库造成的脏数据，那么就改自己的自动化脚本，再造一条正常的数据

就事论事，OK，什么叫流程？流程图设计有么？方案有么？产品对输入有限制约束么？
这些都没有，谈什么脏数据，先去解决这些问题。
如果有，测试不看，那就是测试的锅，甩得一点都不冤。
这才是解决问题的思考方式，不要总想着什么一劳永逸的规则方法去解决问题，根本就不可能存在。

然后扩大一点，从你上一篇帖子也能看出来，你们测试一没话语权，二没自己的规划。在这种情况下被喷太正常了。（大部分都是这种现状）
你要证明你重要，多少有点自己的想法吧，然后列个计划吧，然后去说服老板吧？
都没有，那不是叫你干啥你干啥，你还有意见？不喷你喷谁？

首先搞清楚脏数据的概念：

如果按流程能造出来的数据，那叫正常数据。。。
如果是开发帮你做的辅助测试工具（比如直接数据库插入的，没管前后端验证），按流程（无论正常还是异常）弄不出来的数据导致的问题，你可以说是脏数据。

其次可以看出开发对你们测试的专业能力有怀疑，正常的开发看到问题是去发现问题，解决问题，而不是纠结你们测试数据哪儿来的，哪怕是因为你们因为非正常造的数据的原因导致你们提了缺陷，也应该是给正确的建议，帮助团队规避问题，什么你啊我喷来喷去的，世界如此美妙,他却如此暴躁,这样不好~！

对所谓脏数据进行追述分析吧，确认下不可用的原因是什么，在不同的功能段，使用的同一条数据链里的数据不太一样，所以是有可能存在某段功能可用，某段功能不可用。

虽然分段测试，但出现不可用就是说明之前功能存在遗漏，这个就要具体分析，哪个环境接口数据未对应上了。

如果是通过接口造的测试数据，那就是构建的数据，不规范导致的。数据链路太长的情况下，确实会只构建当前功能可用的数据，可能当前功能所需数据没有分析清楚。