5) cycle(i)=cycle(j)+1, j=argmax(j: unit_id(j)=unit_id(i), j<i)
6) 6 Hours< task_end_time(i)- task_start_time(i)<5 Days.
根据这些规则，TestTask有几百条异常记录(1%左右)。根据每条记录的单独分析，除了
1) TestTask中存在测试周期缺失；2) TestTask有些记录的起止时间不对之外，还发现3) TestTask部分记录的unit_id是错的。
针对分析课题的关键字段，列出隐性的约束和假设，无论对于数据质量问题识别，还是应用的边界条件检查都有很大帮助。
很多数据异常可能是我们没有意识到的业务场景，但业务场景通常没有完善的记录，也很难靠访谈方式获得全面的了解。一个有效的获取方式就是拿具体案例，和业务专家深入探讨。
针对上面约束检查中发现的task_end_time(i)- task_start_time(i)过短或过长的记录，做深入的个例分析。可以发现：1)部分是正常的例外业务场景造成的。例如，测试台出现故障长时间处于待修状态；测试中也时常采用一些新工艺；测试台之间存在交叉影响等；2)部分记录是周期划分不正确导致的，例如，在安装阶段出现了异常，短暂停留后成功进行二次安装，从业务逻辑上还是同一条TestTask记录，但被录成了2条记录。
《工业大数据分析实践》中，我们呼吁业务理解阶段需要进行业务上下文理解。理想情形下，如果之前的数据库系统或应用开发时有一个业务语义层面的领域模型（请参阅Eric Evans《领域驱动设计:软件核心复杂性应对之道》），这些问题就变得简单。
但这种跨领域协同实际执行起来有难度，造成绝大多数数据库和应用设计都不会积累下来领域模型。通常业务专家会做一定业务概念介绍，但通常不完备。跨领域交流时，业务专家不知道你不知道什么，数据分析师不知道自己不知道什么。图书、文档、业务专家介绍的大多是正常情形(甚至理想情形)，而不是在日常使用中的各种实际情形。对于数据分析师而言，我们的优势是有实际数据，可以采用两边夹击的方式，基于当前的领域理解，整理出一个当前认知水平下的“领域模型”，再结合实际数据集中个别案例的理解，补充完善这个“领域模式”。
考虑跨领域交流的信息损失，全面展开的工作量太大，时间太长，且很难见效。这里推荐：针对数据分析中的关键字段，通过个例探讨获取对业务场景的深入认知。更深入的探讨，可以参阅Eric Evans一书中关于集装箱海运领域建模的案例。
