检测

行业背景 随着科技的不断进步和实验室治理需要的一直倒退，传统实验室治理形式面临着许多问题，如采纳纸质记录和手工操作、数据易失落和难以追溯、效率低下、流程简单以及品质治理不标准等。这些问题曾经成为制约实验室倒退和晋升运行效力的瓶颈。与此同时，测验检测行业也面临以下挑战： （1）无奈撑持大体量的数据计算和剖析：在晚期的试验数据分析计算中，数据量较少，借助简略的计算器和手工计算便可满足。然而，随着检测数据量的减少，晚期的计算形式已不能满足需要，须要引入性能更好、计算能力更强的数据分析工具。 （2）样品数据采集慢，效率低：在没有实现数字化之前，传统的数据采集须要依附手工数据信息采集的形式，纸质化的采集形式效率慢且保留性差。 （3）数据校验性能差，校验后果不精确：传统的工作模式可能会呈现数据校验不全面、校验规定过于宽松、算法存在逻辑破绽等问题，从而导致校验后果不够精确，影响数据的有效性和可信度。 （4）剖析报告后果生成慢，无奈满足用户需要：晚期的零碎无奈满足当今数据量日益增长的需要，解决大规模数据时性能不佳，导致剖析报告生成工夫较长，无奈满足用户对于疾速、实时剖析报告的需要。 （5）资源的不通明治理：在实验室工作中，样品耗材的信息都须要人工以传统形式进行记录，以纸质文件进行保留。这样就会呈现保留以及溯源不清晰，人员培训资料无奈造成体系，文件权限难以管控等问题。检测报告、检测数据传递须要依附纸质传递，不仅浪费资源且无奈保证数据的真实性和时效性。 （6）数据无奈共享（数据孤岛）：各实验室之间数据无奈互通，如品质治理部门调用各实验室检测数据难度大，数据易失落等。价值的深度开掘难度大。 如何解决这些痛点问题 为了解决这些问题和挑战，数字化零碎逐步成为实验室治理的趋势，并逐渐利用于实验室治理。实验室信息管理系统（Laboratory Information Management Systems，LIMS）应运而生，LIMS数字化零碎可能实现实验室数据的数字化采集、治理和剖析，进步数据的可靠性和准确性。同时，它可能优化实验室的工作流程、进步管理水平和品质认证程度。 实验室信息管理系统，即LIMS（Laboratory Information Management System，以下简称LIMS），它是由计算机和应用软件组成，可能实现实验室数据和信息的收集、剖析、报告和治理。 LIMS零碎以实验室为核心，将实验室的业务流程、环境、人员、仪器设备、标物标液、化学试剂、规范办法、图书资料、文件记录、客户治理等等影响剖析的数据因素有机联合起来，采纳先进的计算机网络技术，数据库技术和标准化的实验室治理思维，组成一个全面、标准的管理体系，为实现剖析数据网上调度、剖析数据主动采集、疾速散布、信息共享、剖析报告无纸化、品质保证体系顺利施行、老本严格控制、人员量化考核、实验室管理水平整体进步等各方面提供技术支持，是连贯实验室、采样现场、监管部门及客户信息的信息平台，同时引入先进的数理统计技术，如方差分析、相干和回归剖析、显著性测验、累积和管制图、抽样测验等，帮助职能部门及时发现和管制影响产品质量的关键因素。 引入LIMS数字化零碎能够极大的简化实验室治理流程。通过代替纸质记录和手工操作，LIMS零碎可能实现试验数据的电子化采集和存储，防止了数据失落和难以追溯的问题。同时，LIMS零碎的自动化性能能够减速实验室流程，进步工作效率，缩小人为谬误和重复劳动。 LIMS零碎的性能构造、测验流程与技术要点 本文仅节选计划的局部内容，更多具体内容请点击这里下载完整版理解。 性能构造 数字化LIMS利用管理系统次要蕴含数据层、撑持层、业务层及应用层。其中，数据层次要包含检测数据库、报告数据库以及采样信息云数据库；撑持层包含权限认证平台、检测后果公布平台、检测信息公布平台、业务信息平台；业务层包含：规范治理、合同治理、人员治理、品质治理、采样治理、仪器治理、绩效治理、剖析原始记录治理、试剂治理、分析方法治理、系统管理等；应用层次要包含：检测业务管理平台、检测报告公布平台、后盾治理平台。除此之外，数字化LIMS利用零碎还提供规范数据体系和对立平安规范，确保数据的准确性、一致性和规范性。 （LIMS零碎的性能构造） 测验流程 LIMS零碎的测验流程蕴含以下几个局部，客户治理、合同治理、采样治理、分包治理、资源管理、质控治理、样品治理、后果录入、后果审核、报告制作和统计分析治理。 （LIMS零碎的测验流程） 技术要点 （1）多终端跨平台利用 在晚期的LIMS零碎中，检测数据的报告填报、批改和生成都是通过Excel来实现的。进入B/S时代之后，LIMS零碎须要可能在各种终端设备上实时应用（如电脑、平板、手机等）。在这种状况下，通过Excel软件进行数据填报和批改就变得十分不便。因而，如何在浏览器上间接操作报表并实现跨平台利用是新时代下LIMS零碎的一个重要需要。 在基于浏览器/服务器（B/S）架构下的LIMS利用零碎中，与数据填报、报表剖析及展现的模块可基于前端技术来构建。借助葡萄城公司的纯前端表格控件SpreadJS可能将Excel从线下迁徙到线上，实现数据填报、剖析和生成报表的一体化流程，彻底辞别对Excel软件的依赖。通过嵌套技术计划，零碎能实现挪动端和桌面端雷同表格展现形式。 (纯前端、跨平台) （2）类Excel操作 在晚期的实验室数据管理中，大部分使用者都是借助Excel工具来进行数据的填报、统计和剖析。为了可能保持良好的用户操作体验，基于B/S架构的LIMS零碎在数据的填报、剖析和统计操作上需尽可能的与之前保持一致。而葡萄城的纯前端表格控件SpreadJS可能很好的满足这一需要。SpreadJS是一款基于HTML5规范的纯前端表格组件，具备高性能、跨平台、与Excel高度兼容等个性。该组件可能反对以原生的形式嵌入到LIMS零碎中，确保零碎操作体验的一致性。 SpreadJS不仅领有高度类Excel的交互界面，而且具备与Excel高度一致的操作体验。这一个性防止了零碎上手难、操作繁琐的问题，在保障业务人员办公效率的同时，也为企业和施行团队节俭了大量的用户培训老本。 （3）多样化文件导入导出 在测验检测行业中，晚期的大量检测报告及原始数据都是通过Excel进行记录的。为了可能实现对历史数据的传承以及对数据的高效应用，须要将晚期存储在Excel中的数据导入到LIMS零碎中；或者须要将LIMS中的数据导出至Excel等其余文件。SpreadJS基于纯前端技术研发，无需借助后盾代码和第三方插件，可间接在浏览器中实现Excel、CSV、JSON等文件的导入导出、PDF导出、打印及预览操作。 基于SpreadJS纯前端文件I/O能力的撑持，用户能够将既有的Excel报表模板间接导入到前端页面进行预览、二次设计以及进行数据填报或打印等操作。该个性不仅让用户解脱了客户客户端Excel利用的依赖，也能够轻松突破零碎与Excel的数据壁垒。 在文件打印方面，SpreadJS反对所见即所得的打印预览和导出PDF的性能，并且反对交互式设计打印参数，包含纸张、边框、分页、页眉页脚等元素，极大晋升用户的交互体验。 （文件导入导出） （4）高解决性能及响应速度 在检测零碎中，往往会波及到大量的数据加载及剖析性能。在性能方面，SpreadJS具备高性能的渲染能力，可在100毫秒内加载10万行数据，提供高效的分组、排序、筛选、行列暗藏等性能。在进行上述操作时，系统对内存的占用非常少，在满足业务需要的同时，提供更加晦涩的操作体验。 除此之外，针对文档加载及公式计算，SpreadJS同样可能提供良好的性能。SpreadJS反对纯前端导入Excel文件，针对大体量Excel文档，可能反对懒加载、增量加载等能力，晋升用户体验。在公式计算模块，SpreadJS反对纯前端百万级数据量的秒级渲染能力，并能够以靠近原生Excel的性能加载实现百万级数据和计算公式的应用。同时，还提供懒加载，异步公式等前后端联合的计划来进一步优化加载和计算性能，晋升操作体验。 （HTML5 Canvas页面绘制） 价值与劣势 LIMS零碎作为集现代化治理思维与计算机技术为一体的用于各行业实验室治理和管制的利用技术，可能把实验室的管理水平晋升到与信息时代相适应的程度。它的呈现投合了检测行业在以下四个方面的价值需要： （1）治理海量信息：LIMS零碎的呈现，能够帮忙组织保留实验室数据，辅助实验室的质量保证实际，实现与企业外部其余部门之间的信息交换。 （2）增强质量保证：质量保证（Quality Assurance，QA）被定义为：”为了提供品质牢靠的产品和服务而必须当时打算好的所有流动，它是对品质控制措施进行品质评估以及确定测定流程的有效性“。LIMS的呈现能够显著的促成整个QA过程。 通过LIMS零碎，实验室能够更好地管制和监测数据的完整性、准确性和可靠性，从而使实验室的品质管制失去进一步优化和增强。因而，LIMS零碎的利用能够被视为实验室治理的一个必要组成部分，它能够无效地进步实验室的品质和效率，同时也为实验室管理人员提供更多的数据和信息来进行决策和布局。 （3）缩小数据输出谬误：LIMS的呈现，提供了多种平安机制来缩小数据输出的谬误，例如： （a）数据输出限度：规定了数据值的输出类型和大小范畴。 （b）范畴测验：例如当输出值超出肯定限值时提供通过声音或者色彩收回正告的信息。 （c）主动计算：对于某种测试方法，LIMS将在失去足够的信息后实现主动计算得出后果，从而无效的缩小数据运算和传递过程中造成的谬误。 （4）缩短样品剖析周期：LIMS的呈现放慢了样品的周转效率，升高了样品追踪的耗费工夫。 （LIMS零碎的价值） 而在LIMS零碎中，通过嵌入西安葡萄城公司的纯前端表格控件SpreadJS，更是进一步满足零碎在表格场景下的需要，究其原因是SpreadJS为LIMS零碎带来了以下几点劣势： （1）弱小的计算引擎 SpreadJS 的计算引擎内置了513种公式函数，其中有459种与 Excel 兼容。这些函数涵盖了数组函数、动静数组、异步函数、XMATCH、LET、XLOOKUP、LAMBDA 函数等。除此之外，SpreadJS 还反对自定义个性，能够轻松进行扩大。这样的性能组合最大水平上满足了LIMS零碎中的数据分析与计算需要，并且可能显著缩小数据计算错误的产生。无论是简单的数据分析还是准确的计算，SpreadJS 提供了弱小而牢靠的工具，为LIMS零碎的数据处理提供了牢靠的反对。 ...

舆情及内容简述大家对于“舆情”应该有一个简略地概念，尤其是在当初微博、微信、知乎、抖音等平台普及化的明天，舆情的力量日渐凸显。比方最近萧敬腾的求婚、《隐没的她》的热议、ikun的翻车等等，舆情既能够让明星塌房，也会让一些光明曝光在阳光下，然而还有时候会裹挟舆论，让事件变得难以管制。 因而，对于舆论的监测和正确引导就比拟重要，尤其是对于一些明星背地的团队来说。 明天咱们就来浅浅的讲一下舆情检测和内容平安零碎。 在开始之前，咱们先对舆论因素做一个简略理解： 简略来说，网络舆情是以网络为载体，以事件为外围，是宽广网民情感、态度、意见、观点的表白，流传与互动，以及后续影响力的汇合。 带有宽广网民的主观性，未经媒体验证和包装，间接通过多种形式公布于互联网上。 而舆情的倒退阶段个别包含： 危机潜伏期： 这个阶段是危机最容易解决的期间，却最不易为人所知。 危机暴发期： 危机集中暴发的阶段，它对企业造成的冲击最为重大。 危机连续期： 危机处理过程的一个阶段，纠正危机暴发期造成的侵害。 危机痊愈期： 企业从危机影响中齐全解脱进去，然而仍要放弃高度警觉，因为危机仍会死灰复燃 因而对于舆情的监控，咱们能够从上面几个方面来进行解决。 舆情监测零碎简介个别最为简略的流程就是事先事中预先这么一个程序： 事先：口碑监测、数据分类、热点发现、主动预警事中：话题追踪、流传剖析、竞争情报、关联开掘预先：深度报告、危机解决、成果评估、名誉治理 因而，咱们舆情监测零碎应该具备的能力就包含： 数据接入与态势剖析： 反对接入与交融多源异构数据:反对对整体比例和变化趋势剖析，包含起源占比及变化趋势、地区散布、倾向性散布等:反对辨别媒体和网民剖析:可自定义工夫粒度，按天、按小时剖析专题剖析 反对基于关键词自定义创立专题反对查问历史专题:反对专题关键词剖析与主动举荐:反对对专题进行溯源、趋势、倾向性参加画像等多维度剖析和可视化出现。热点事件剖析 主动发现全网、各畛域热点反对事件影响力计算及排序反对自定义热点事件分类规定:反对对事件的要害因素、发酵趋势、重点参加媒体等进行多维分析。事件态势剖析 提供热点事件数量等统计性能:反对热点事件整体态势剖析:反对热点事件倾向性统计:提供网民参加状况统计。事件溯源剖析 反对事件溯源，辨认首发和类似文章的转载关系:反对微博流传追踪，辨认转发关系，刻画流传门路专题报告 反对报告模板的自定义和灵便治理反对多源获取和分类管理素材;反对基于素材和模板主动生成和更新报告:在反对上述能力的根底上，咱们能够画出舆情零碎一个比拟通用的技术体系架构： 并且拿到次要会用到的一些算法： 当然，还有一项没有列上去（表格不够），那就是“常识图谱”。常识图谱相比于其余一些算法会更加简单一些。 下面的一些算法设计的范畴很广，这里就不嫌丑了，还没到这个程度，如果有感兴趣的敌人能够深挖一下。 结语舆情方面的案例很多，然而真正能拿进去举例子的不多，而且会波及到相干事件，所以就不再进一步拿具体的事例来讲了。 今日份学习实现~ 以上。

上一篇曾经解了压缩表的相干概念、索引页的影响以及简略应用。这篇次要来介绍如何观测压缩表。 一、压缩表的应用场景分类1. SELECT 业务这类操作不须要对压缩页进行解压，所以非常适合应用压缩表。 2. INSERT 业务这类操作须要从新对二级索引数据页解压和以及从新压缩，不过 MySQL 对这部分操作放入 change buffer，所以频率相对来说不是很高。 3. DELETE 业务因为 MySQL 对删除的操作是间接写标记位，而后期待定期的 PURGE 线程清理，这块也适宜用压缩表。 4. UPDATE 业务因为压缩表个别都是对字符串类的数据，比方 TEXT,VARCHAR 等压缩，所以针对这块的数据做更新，很容易就把更改日志（上篇介绍过）打满，继而造成频繁的解压和压缩操作。 总的来说压缩表适宜于读密集、只读、或者极少量更新的业务场景。 二、压缩表监测对压缩表的监控，保留在 Information_schema 内以 INNODB_CMP 结尾的字典表。通过这些表能够监控到压缩表是否衰弱，是否须要调整压缩页，或者说是否适宜用压缩表等。 mysql> show tables from information_schema like '%cmp%';+--------------------------------------+| Tables_in_information_schema (%CMP%) |+--------------------------------------+| INNODB_CMP || INNODB_CMPMEM || INNODB_CMPMEM_RESET || INNODB_CMP_PER_INDEX || INNODB_CMP_PER_INDEX_RESET || INNODB_CMP_RESET |+--------------------------------------+6 rows in set (0.01 sec)这些表为内存表，也就是 memory 引擎。对这些表的检索必须具备 process 权限。依照压缩表的操作形式，分为以下三类： 1、INNODB_CMP/INNODB_CMP_RESETInnoDB 压缩表的磁盘拜访相干数据，其中 INNODB_CMP 和 INNODB_CMP_RESET 表构造雷同，不同的是 INNODB_CMP 代表压缩表历史拜访数据，INNODB_CMP_RESET 用来重置压缩表历史数据。比方要监控一小时内的压缩表拜访数据，能够执行上面的简略步骤： ...

计量检测行业业务系统如何实现信息化？SpreadJS在模板管理、证书管理模块的实践与应用 聂荣臻元帅曾指出：科技要发展，计量须先行。计量检测行业始终是具有生命力和发展前景的高科技行业。 计量检测行业看似陌生，其实它与我们的生活息息相关。小到出租车计价器、水表、燃气表，大到医院血压计、透析机、温度计，以及工厂所用的压力表等设备，都必须通过计量检测行业严格的检测标准并开具检测证书，才可投产上市。 计量检测行业历史悠久，作为一个传统行业，如何保持其旺盛的生命力和发展前景呢？除了灵活运用信息化管理手段外，更离不开现代化计量检测系统的支持。而一套先进计量检测系统的开发，需要借助开发工具的辅助，这样的开发工具有很多，纯前端表格控件SpreadJS不外乎是最适合的一个。 那么，企业如何使用SpreadJS开发一套完善、先进的计量检测系统，进而实现其信息化发展呢？本期葡萄城公开课《计量检测行业业务系统如何实现信息化》，将由吉林科图软件实施部经理——付志国先生，就此问题，与您深入交流，为您提供答案。 计量检测的历史计量在历史上称之为“度量衡”，但随着生产和科学技术的发展，现代计量已远远超出“度量衡”的范围。它涉及到工农业生产、国防建设、科学试验、国内外贸易、生活等各方面。简单地说，统一准确的测量就是计量。 我国计量检测行业现状我国目前计量检测行业处于快速发展阶段，国家对计量检测市场的整顿标准逐步规范化、流程化，其主要体现在：机构认证认可更加严格，门槛明显提高不断加大对机构的监督检查，对违规机构施以停业整顿的严厉处罚各地陆续出台规范计量检测市场的行政法规我国计量检测行业机构众多，但管理体制仍相对落后，信息化水平、技术水平参差不齐，重复建设严重。目前计量检测行业正处在由原计划体制向国际接轨的变革阶段，国有、外资、民营等不同体制和机制的机构共存，市场处于多元混战的无序竞争状态，同时具备很大的市场机遇与风险。基于此，计量检测行业亟需一款同时具备多个智能检测模块和数据分析处理能力的现代化计量检测系统。 计量检测系统的项目背景及迭代本系统的主要应用场景是：解决检测证书的智能生成及模板自动化管理需求。 传统的模板管理方式无法自定义函数，以及灵活调用表格数据，而使用本系统可以调用自己编写的函数、修改现有函数规则，并灵活运用图表表现数据。 本系统的【模板管理】模块一共历经三次升级迭代，V1.0主要通过嵌入HTML管理模板，但无法满足复杂表格的设计需求和自适应列宽行高的业务场景。基于此，我们升级为V2.0版本，通过直接嵌入Excel管理数据模板，但嵌入系统的Excel无法满足自定义宏、自定义公式的需求，因此，我们又对系统进行了全面升级：使用SpreadJS开发一套功能与Excel完全一致，但具备更高扩展性、灵活性和高度自定义能力的Web Excel系统——模板管理V3.0。 计量检测系统的功能架构PC端主要功能： 主要功能： 计量检测系统 - 模板管理模块模板管理模块主要用于：出具通过国家检测依据的客户证书以及绘制表格。 模板管理模块工作流程：绘制模板——>在模板制作完毕后，根据文件要求，完成三级审核——>获取批准——>投入使用。 下方的表格就是在 SpreadJS 中进行绘制的，除了可无损导入导出Excel外，还可直接编写函数公式及调用自定义函数。 本系统严格按照模板管理模块的工作流程设计菜单： 【模板管理】工作流截图： 1 绘制模板：科员根据文件内容、算法，编制模板，并提交审核。 2 核验阶段：核验与批准模板功能一致，选择所要核验、批准的数据，查看科员编制格式是否与文件中的格式符合。如符合选择通过，则该模板正常使用；如不符合驳回模板，科员继续修改，修改完毕重新提交审核。 计量检测系统 – 证书管理模块模板制作完成后，可以在证书管理模块中调用所做的模板： 编制证书时，科室人员输入检测数据，并生成证书，根据文件要求，编制的证书需要三级审核。 系统菜单和证书管理页面如下： 核验与批准人员检查数据是否正确，核验、批准通过即可开始打印证书。 【证书管理】工作流截图： 1 检定科室接到任务，开始检测设备。 2 选择数据，编制实际检测设备的数据添加到已经做好的模板当中，模板自动通过函数计算结果，用户不需要重复计算，可大大减少客户录入数据所耗时间。科员编制完成提交核验。 3 核验人员接到任务，对记录与证书进行核对，查看数据、计算是否填写正确，如填写正确核验人员提交到批准人员账号下，如填写有误，则返回检定人员账号下重新编制并保留修改痕迹。 注：批准同上，批准通过流程结束。 为什么使用SpreadJS？本系统使用SpreadJS开发【模板管理】和【证书管理】两大模块。在使用SpreadJS之前，主要通过HTML和Excel管理数据模板，面临以下难点： HTML：在页面上修改值需要有一定的编码基础，表格来回推拽会导致变形，无法编制图表。Excel：适用于大部分群体，但无法自定义函数及修改现有函数的规则。使用SpreadJS后，与此前使用HTML、Excel相比，优势如下： 实现了Excel 90%以上的功能用户可自定义函数调用编制表格、图表更加方便编制的文件在走流程时不会出现数据、表格改变无损导入导出至Excel中重复使用SpreadJS对最终用户和系统开发者的意义： 用户可自行编制函数、绘制表格，与Excel的使用方式几乎一致代码简洁，调用方法方便、高效售后及时，有问必答SpreadJS对本系统的价值使用 SpreadJS 设计的Excel模版，即可兼容excel的常用公式，也可自定义行业专属公式。使用 SpreadJS 的拷贝粘贴功能，可直接插入证书首页，因此首页不必在模板中维护、设计，用户可任意修改信息。使用 SpreadJS 中的条件表达式，可以使制作模版功能更加灵活。使用 SpreadJS 的富文本编辑功能，使得特殊符号设置更加灵活。使用 SpreadJS 在后端转pdf，可减轻浏览器压力，转换速度更快，方便存储备份证书文件。使用 SpreadJS 的图表功能，满足特殊客户的自动生成图表需求。使用 SpreadJS 的数据验证功能，可提醒客户输入值是否有误。使用 SpreadJS 的任意取值和任意赋值功能，实现自动化设备对接需求。以上就是本期公开课的主要内容，更多系统界面展示及功能演示，欢迎点击此处，预约葡萄城公开课，在线观看学习。 ...

概述回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他的代码出现错误。传统的自动化回归测试需要手动编写脚本获得页面元素的视图树，与原有的元素视图树进行比对。当功能进行频繁迭代时，测试同学维护这些视图元素验证点比较繁杂。因此在自动化回归测试过程中，直接比较代码修改前录制的页面和代码修改后回放的页面差异，可以快速定位代码产生的缺陷，从而提高测试同学的工作效率。以闲鱼应用举例，录制和回放页面差异检测存在的一些难点包括：图像上，闲鱼页面由顶部固定区域、中间可滚动区域、底部固定区域组成，需要对页面进行版面切割，之后分别对每一个区域进行处理。另外录制和回放页面中一些图标或者图片纹理复杂的区域往往像素值分布不同，但是语义层面又是同一个物体，因此需要从语义层面进行检测识别。业务上，两张页面中间区域因为滚动带来的差异不需要检测出来，并且一些特殊的标记差异(比如一张页面某个位置有光标，另一张页面同一位置没有光标)不需要检测出来。如上图四组录制和回放页面所示，其中每组图左边为录制页面，右边是回放页面。a)中因为中间区域的滚动带来了文字和图标的差异，b)中价格组件“¥69”右边的光标带来了差异，c)中输入框里的文字不一样，d)中“库存”那一栏的图标具有语义差别。其中a)和b)中的差异不需要检测出来，c)和d)中的差异需要检测出来。方法算法流程整个算法流程如下图所示：输入的录制和回放页面图像灰度化后进行版面切割，提取顶部区域、中间区域、底部区域两张页面的中间滚动区域进行对齐两张页面的每个区域分别进行相似度计算并排除无效的差异框两张页面中分别标记最终的差异框版面切割闲鱼大部分的页面是由顶部固定区域、中间可滚动区域、底部固定区域组成，版面切割的目的是找到中间可滚动区域的上下边界，即将页面切割为三块区域，之后对每块区域分别进行处理。版面切割只针对中间区域有滚动的情况，对于中间区域无滚动的情况即可用整张图进行后续处理。考虑到录制和回放页面在滚动区域上下边界处会产生明显的差异，因此分别从图像的第一行和最后一行开始进行比较，比较对应行的结构相似度指数(SSIM)，当对应行的结构相似度指数小于给定的阈值，则终止。结构相似度指数是一种衡量两幅图像相似度的指标，其从图像组成的角度将结构信息定义为独立于亮度、对比度的反映物体结构的属性，用均值作为亮度的估计，标准差作为对比度的估计，协方差作为结构相似程度的度量。具体公式如下：其中(x,y)分别为录制和回放图像，ux,uy,x2,y2,xy分别表示图像的均值、方差和协方差，c1,c2,c3为小的正常数，避免分母为零而出现不稳定，利用参数,,调整三个成分所占的比重。在实际工程中，一般设定===1，以及c3=c2/2，可以将SSIM简化为：SSIM为介于0到1之间的一个值，值越大表明两幅图越相似。下图a)b)为高2001像素、宽1125像素的录制和回放页面图像，选取SSIM阈值为0.95，计算得到的滚动区域的上边界为192，下边界为1832，如c)所示。滚动区域对齐对齐录制和回放图像的滚动区域后便可对比同一位置的差异，本文采用基于特征点的图像对齐方法， 即检测录制图像的一组稀疏特征点来匹配回放图像的一组稀疏特征点，通过两组特征点的匹配来计算一个转换矩阵，这个转换矩阵能变换对齐两幅图像的滚动区域。由于滚动区域只在垂直方向有位移，因此采用一般的刚性配准方法，如下式:录制图像坐标(x,y)通过一个3x3的位移矩阵转换到回放图像坐标(x’,y’)。位移转换矩阵可以通过对齐两幅图像的特征点来求取。在计算机视觉中，常见的特征点描述方法有SIFT、SURF、ORB等等，本文采用ORB方法，因为相比于SIFT和SURF方法，ORB在满足足够高的准确性前提下，速度更快并且使用不受专利约束。ORB全称是Oriented FAST and Rotated BRIEF，即是由FAST特征点检测和BRIEF特征点描述组成，并且在两者基础上加入了图像金字塔和图像重心方向等改进措施使得ORB对尺度和旋转不敏感。滚动区域对齐的具体步骤为：1. 输入录制和回放滚动区域。当上一步版面切割没有计算出滚动区域时，输入整幅图像的中间部分<br>2. 检测特征点。使用ORB检测两幅图像的角点。工程实现时可以设置每幅图像最多需检测出的特征点数<br>3. 匹配特征点。利用hamming距离来衡量两组特征点的相似性以及Brute Force暴力法尝试所有特征点来找到最佳匹配。基于匹配的特征点距离值进行排序，选取距离值较小的一部分特征点<br>4. 计算转换矩阵。输入两组特征点坐标位置通过最小二乘求解最优的转换矩阵<br>5. 对齐图像。应用转换矩阵将回放图像滚动区域映射对齐录制图像滚动区域<br>下图为匹配的两组特征点，计算出来的转换矩阵中tx=0，ty=-96相似度计算及后处理对录制和回放页面的顶部区域、底部区域和对齐的滚动区域分别计算结构相似度SSIM(如果图像不存在滚动区域，则对整图计算SSIM)，差异的地方用矩形框标识，后续通过一定的后处理排除掉无效的差异。具体步骤如下：差异检测。对顶部区域、底部区域和对齐的滚动区域每个像素在一定的领域范围内计算SSIM，得到同等尺寸的SSIM结果图；再对SSIM结果图用大津法得到二值化的SSIM结果图，其中有差异的地方为1，没有差异的地方为0；接着提取二值化SSIM差异部分的外接轮廓；之后再计算轮廓的最小外接矩形框。得到的结果如下红框所示：后处理。上图红框显示的是对齐滚动区域带来的差异，通过判断每个框是否落到特定区域范围内来进行排除，这个特定区域在垂直方向上以滚动区域上边界起始，向下移动ty行结束或者以滚动区域下边界起始，向上移动ty行结束。另外对于一些噪声点带来的差异，可以通过限制差异框包含的面积进行排除。对上图使用以上两步后处理后，红框全部被排除。其他一些录制和回放图像中的特殊标记(比如光标)差异在业务层面需要排除，或者一些纹理丰富的图标/图像虽然像素层面存在差异，但语义层面属于同一类，即使SSIM计算不相似，也需要排除。上图a)显示光标差异模式，b)显示纹理丰富的图标/图像差异模式，c)显示其他差异模式。这些差异模式是对应位置差异框绝对差得到的结果，其中a)和b)需要排除，c)需要保留。分析这几种不同模式类型，设计了一种如下图所示CNN二分类网络。图像缩放到64x64大小，然后输入到三层conv+pooling+relu的卷积结构中，后接128个节点和2个节点的全连接层，以softmax作为类别判定输出。通过分类网络便可将业务层面或像素层面的差异进行排除。结果一些差异检测的结果如下，其中红框标示的是在录制和回放页面中存在差异的部分。a)只有中间区域滚动带来的差异，业务上不需要检测出来； b)和c)能将页面中存在语义差异的部分检测出来并且没有误检和漏检； d)两张页面不存在语义差异，但底部有个文字区域出现了误检，分析原因是页面在没有滚动的情况下，误检区域没有上下严格对齐，导致计算的SSIM值偏小，认为此处存在差异。总结本文以闲鱼自动化回归测试应用举例，实现了一种版面切割、滚动区域对齐、相似度计算及后处理的录制和回放页面差异检测方法。这种方法在使用过程中达到了检出语义差异的预期，并且方法具有普适性，对其他app的自动化回归测试具有一定的参考意义。当然本方法也存在着一些不足，对于像素分布不同但语义相同的差异模式会有一部分误检，这是由于SSIM在计算相似度时对于局部像素值的变化比较敏感，未来可对页面中的文字和图片独立提取出来进行进一步的语义分析优化。本文作者：闲鱼技术-深宇阅读原文本文为云栖社区原创内容，未经允许不得转载。

背景对苹果开发者而言，由于平台审核周期较长，客户端代码导致的线上问题影响时间往往比较久。如果在开发、测试阶段能够提前暴露问题，就有助于避免线上事故的发生。代码覆盖率检测正是帮助开发、测试同学提前发现问题，保证代码质量的好帮手。对于开发者而言，代码覆盖率可以反馈两方面信息：自测的充分程度。代码设计的冗余程度。尽管代码覆盖率对代码质量有着上述好处，但在 iOS 开发中却使用的不多。我们调研了市场上常用的 iOS 覆盖率检测工具，这些工具主要存在以下四个问题：第三方工具有时生成的检测报告文件会出错甚至会失败，开发者对覆盖率生成原理不了解，遇到这类问题容易弃用工具。第三方工具每次展示全量的覆盖率报告，会分散开发者的很多精力在未修改部分。而在绝大多数情况下，开发者的关注重点在本次新增和修改的部分。Xcode 自带的覆盖率检测只适用于单元测试场景，由于需求变更频繁，业务团队开发单元测试的成本很高。已有工具很难和现有开发流程结合起来，需要额外进行测试，运行覆盖率脚本才能获取报告文件。为了解决上述问题，我们深入调研了覆盖率报告的生成逻辑，并结合团队的开发流程，开发了一套嵌入在代码提交流程中、基于单次代码提交（git commit）生成报告、对开发者透明的增量代码测试覆盖率工具。开发者只需要正常开发，通过模拟器测试开发代码，commit 本次代码（commit 和测试顺序可交换），推送（git push）到远端，就可以在本地看到这次提交代码的详细覆盖率报告了。本文分为两部分，先从介绍通用覆盖率检测的原理出发，让读者对覆盖率的收集、解析有直观的认识。之后介绍我们增量代码测试覆盖率工具的实现。覆盖率检测原理生成覆盖率报告，首先需要在 Xcode 中配置编译选项，编译后会为每个可执行文件生成对应的 .gcno 文件；之后在代码中调用覆盖率分发函数，会生成对应的 .gcda 文件。其中，.gcno 包含了代码计数器和源码的映射关系， .gcda 记录了每段代码具体的执行次数。覆盖率解析工具需要结合这两个文件给出最后的检测报表。接下来先看看 .gcno 的生成逻辑。.gcno利用 Clang 分别生成源文件的 AST 和 IR 文件，对比发现，AST 中不存在计数指令，而 IR 中存在用来记录执行次数的代码。搜索 LLVM 源码可以找到覆盖率映射关系生成源码。覆盖率映射关系生成源码是 LLVM 的一个 Pass，（下文简称 GCOVPass）用来向 IR 中插入计数代码并生成 .gcno 文件（关联计数指令和源文件）。下面分别介绍IR插桩逻辑和 .gcno 文件结构。IR 插桩逻辑代码行是否执行到，需要在运行中统计，这就需要对代码本身做一些修改，LLVM 通过修改 IR 插入了计数代码，因此我们不需要改动任何源文件，仅需在编译阶段增加编译器选项，就能实现覆盖率检测了。从编译器角度看，基本块（Basic Block，下文简称 BB）是代码执行的基本单元，LLVM 基于 BB 进行覆盖率计数指令的插入，BB 的特点是：只有一个入口。只有一个出口。只要基本块中第一条指令被执行，那么基本块内所有指令都会顺序执行一次。覆盖率计数指令的插入会进行两次循环，外层循环遍历编译单元中的函数，内层循环遍历函数的基本块。函数遍历仅用来向 .gcno 中写入函数位置信息，这里不再赘述。一个函数中基本块的插桩方法如下：统计所有 BB 的后继数 n，创建和后继数大小相同的数组 ctr[n]。以后继数编号为序号将执行次数依次记录在 ctr[i] 位置，对于多后继情况根据条件判断插入。举个例子，下面是一段猜数字的游戏代码，当玩家猜中了我们预设的数字10的时候会输出Bingo，否则输出You guessed wrong!。这段代码的控制流程图如图1所示。- (void)guessNumberGame:(NSInteger)guessNumber{ NSLog(@“Welcome to the game”); if (guessNumber == 10) { NSLog(@“Bingo!”); } else { NSLog(@“You guess is wrong!”); }}例1 猜数字游戏 这段代码如果开启了覆盖率检测，会生成一个长度为 6 的 64 位数组，对照插桩位置，方括号中标记了桩点序号，图 1 中代码前数字为所在行数。图 1 桩点位置.gcno计数符号和文件位置关联.gcno 是用来保存计数插桩位置和源文件之间关系的文件。GCOVPass 在通过两层循环插入计数指令的同时，会将文件及 BB 的信息写入 .gcno 文件。写入步骤如下：创建 .gcno 文件，写入 Magic number(oncg+version)。随着函数遍历写入文件地址、函数名和函数在源文件中的起止行数（标记文件名，函数在源文件对应行数）。随着 BB 遍历，写入 BB 编号、BB 起止范围、BB 的后继节点编号（标记基本块跳转关系）。写入函数中BB对应行号信息（标注基本块与源码行数关系）。从上面的写入步骤可以看出，.gcno 文件结构由四部分组成：文件结构函数结构BB 结构BB 行结构通过这四部分结构可以完全还原插桩代码和源码的关联，我们以 BB 结构 / BB 行结构为例，给出结构图 2 (a) BB 结构，(b) BB 行信息结构，在本章末尾覆盖率解析部分，我们利用这个结构图还原代码执行次数（每行等高格代表 64bit）：图2 BB 结构和 BB 行信息结构.gcda入口函数关于 .gcda 的生成逻辑，可参考覆盖率数据分发源码。这个文件中包含了 __gcov_flush() 函数，这个函数正是分发逻辑的入口。接下来看看 __gcov_flush() 如何生成 .gcda 文件。通过阅读代码和调试，我们发现在二进制代码加载时，调用了llvm_gcov_init(writeout_fn wfn， flush_fn ffn)函数，传入了_llvm_gcov_writeout（写 gcov 文件），_llvm_gcov_flush（gcov 节点分发）两个函数，并且根据调用顺序，分别建立了以文件为节点的链表结构。（flush_fn_node * ，writeout_fn_node * ）__gcov_flush() 代码如下所示，当我们手动调用__gcov_flush() 进行覆盖率分发时，会遍历flush_fn_node *这个链表（即遍历所有文件节点），并调用分发函数_llvm_gcov_flush（curr->fn 正是__llvm_gcov_flush函数类型）。void __gcov_flush() { struct flush_fn_node *curr = flush_fn_head; while (curr) { curr->fn(); curr = curr->next; }}具体的分发逻辑观察__llvm_gcov_flush 的 IR 代码，可以看到：图3 __llvm_gcov_flush 代码示例__llvm_gcov_flush 先调用了__llvm_gcov_writeout，来向 .gcda 写入覆盖率信息。最后将计数数组清零__llvm_gcov_ctr.xx。而__llvm_gcov_writeout逻辑为：生成对应源文件的 .gcda 文件，写入 Magic number。循环执行llvm_gcda_emit_function: 向 .gcda 文件写入函数信息。llvm_gcda_emit_arcs: 向 .gcda 文件写入BB执行信息，如果已经存在 .gcda 文件，会和之前的执行次数进行合并。调用llvm_gcda_summary_info，写入校验信息。调用llvm_gcda_end_file，写结束符。感兴趣的同学可以自己生成 IR 文件查看更多细节，这里不再赘述。.gcda 的文件/函数结构和 .gcno 基本一致，这里不再赘述，统计插桩信息结构如图 4 所示。定制化的输出也可以通过修改上述函数完成。我们的增量代码测试覆盖率工具解决代码 BB 结构变动后合并到已有 .gcda 文件不兼容的问题，也是修改上述函数实现的。图4 计数桩输出结构覆盖率解析在了解了如上所述 .gcno ，.gcda 生成逻辑与文件结构之后，我们以例 1 中的代码为例，来阐述解析算法的实现。例 1 中基本块 B0，B1 对应的 .gcno 文件结构如下图所示，从图中可以看出，BB 的主结构完全记录了基本块之间的跳转关系。图5 B0，B1 对应跳转信息B0，B1 的行信息在 .gcno 中表示如下图所示，B0 块因为是入口块，只有一行，对应行号可以从 B1 结构中获取，而 B1 有两行代码，会依次把行号写入 .gcno 文件。图6 B0，B1 对应行信息在输入数字 100 的情况下，生成的 .gcda 文件如下：图7 输入 100 得到的 .gcda 文件通过控制流程图中节点出边的执行次数可以计算出 BB 的执行次数，核心算法为计算这个 BB 的所有出边的执行次数，不存在出边的情况下计算所有入边的执行次数（具体实现可以参考 gcov 工具源码），对于 B0 来说，即看 index=0 的执行次数。而 B1 的执行次数即 index=1，2 的执行次数的和，对照上图中 .gcda 文件可以推断出，B0 的执行次数为 ctr[0]=1，B1 的执行次数是 ctr[1]+ctr[2]=1， B2 的执行次数是 ctr[3]=0，B4 的执行次数为 ctr[4]=1，B5 的执行次数为 ctr[5]=1。经过上述解析，最终生成的 HTML 如下图所示（利用 lcov）：图8 覆盖率检测报告以上是 Clang 生成覆盖率信息和解析的过程，下面介绍美团到店餐饮 iOS 团队基于以上原理做的增量代码测试覆盖率工具。增量代码覆盖率检测原理方案权衡由于 gcov 工具（和前面的 .gcov 文件区分，gcov 是覆盖率报告生成工具）生成的覆盖率检测报告可读性不佳，如图 9 所示。我们做的增量代码测试覆盖率工具是基于 lcov 的扩展，报告展示如上节末尾图 8 所示。图9 gcov 输出，行前数字代表执行次数，#### 代表没执行比 gcov 直接生成报告多了一步，lcov 的处理流程是将 .gcno 和 .gcda 文件解析成一个以 .info 结尾的中间文件（这个文件已经包含全部覆盖率信息了），之后通过覆盖率报告生成工具生成可读性比较好的 HTML 报告。结合前两章内容和覆盖率报告生成步骤，覆盖率生成流程如下图所示。考虑到增量代码覆盖率检测中代码增量部分需要通过 Git 获取，比较自然的想法是用 git diff 的信息去过滤覆盖率的内容。根据过滤点的不同，存在以下两套方案：通过 GCOVPass 过滤，只对修改的代码进行插桩，每次修改后需重新插桩。通过 .info 过滤，一次性为所有代码插桩，获取全部覆盖率信息，过滤覆盖率信息。图10 覆盖率生成流程分析这两个方案，第一个方案需要自定义 LLVM 的 Pass，进而会引入以下两个问题：只能使用开源 Clang 进行编译，不利于接入正常的开发流程。每次重新插桩会丢失之前的覆盖率信息，多次运行只能得到最后一次的结果。而第二个方案相对更加轻量，只需要过滤中间格式文件，不仅可以解决我们在文章开头提到的问题，也可以避免上述问题：可以很方便地加入到平常代码的开发流程中，甚至对开发者透明。未修改文件的覆盖率可以叠加（有修改的那些控制流程图结构可能变化，无法叠加）。因此我们实际开发选定的过滤点是在 .info 。在选定了方案 2 之后，我们对中间文件 .info 进行了一系列调研，确定了文件基本格式（函数/代码行覆盖率对应的文件的表示），这里不再赘述，具体可以参考 .info 生成文档。增量代码测试覆盖率工具的实现前一节是实现增量代码覆盖率检测的基本方案选择，为了更好地接入现有开发流程，我们做了以下几方面的优化。降低使用成本在接入方面，接入增量代码测试覆盖率工具只需一次接入配置，同步到代码仓库后，团队中成员无需配置即可使用，降低了接入成本。在使用方面，考虑到插桩在编译时进行，对全部代码进行插桩会很大程度降低编译速度，我们通过解析 Podfile（iOS 开发中较为常用的包管理工具 CocoaPods 的依赖描述文件），只对 Podfile 中使用本地代码的仓库进行插桩（可配置指定仓库），降低了团队的开发成本。对开发者透明接入增量代码测试覆盖率工具后，开发者无需特殊操作，也不需要对工程做任何其他修改，正常的 git commit 代码，git push 到远端就会自动生成并上传这次 commit 的覆盖率信息了。为了做到这一点，我们在接入 Pod 的过程中，自动部署了 Git 的 pre-push 脚本。熟悉 Git 的同学知道，Git 的 hooks 是开发者的本地脚本，不会被纳入版本控制，如何通过一次配置就让这个仓库的所有使用成员都能开启，是做好这件事的一个难点。我们考虑到 Pod 本身会被纳入版本控制，因此利用了 CocoaPods 的一个属性 script_phase，增加了 Pod 编译后脚本，来帮助我们把 pre-push 插入到本地仓库。利用 script_phase 插入还带来了另外一个好处，我们可以直接获取到工程的缓存文件，也避免了 .gcno / .gcda 文件获取的不确定性。整个流程如下：图11 pre-push 分发流程覆盖率累计在实现了覆盖率的过滤后，我们在实际开发中遇到了另外一个问题：修改分支/循环结构后生成的 .gcda 文件无法和之前的合并。 在这种情况下，__gcov_flush会直接返回，不再写入 .gcda 文件了导致覆盖率检测失败，这也是市面上已有工具的通用问题。而这个问题在开发过程中很常见，比如我们给例 1 中的游戏增加一些提示，当输入比预设数字大时，我们就提示出来，反之亦然。- (void)guessNumberGame:(NSInteger)guessNumber{ NSInteger targetNumber = 10; NSLog(@“Welcome to the game”); if (guessNumber == targetNumber) { NSLog(@“Bingo!”); } else if (guessNumber > targetNumber) { NSLog(@“Input number is larger than the given target!”); } else { NSLog(@“Input number is smaller than the given target!”); }}这个问题困扰了我们很久，也推动了对覆盖率检测原理的调研。结合前面覆盖率检测的原理可以知道，不能合并的原因是生成的控制流程图比原来多了两条边（ .gcno 和旧的 .gcda 也不能匹配了），反映在 .gcda 上就是数组多了两个数据。考虑到代码变动后，原有的覆盖率信息已经没有意义了，当发生边数不一致的时候，我们会删除掉旧的 .gcda 文件，只保留最新 .gcda 文件（有变动情况下 .gcno 会重新生成）。如下图所示：图12 覆盖率冲突解决算法整体流程图结合上述流程，我们的增量代码测试覆盖率工具的整体流程如图 13 所示。开发者只需进行接入配置，再次运行时，工程中那些作为本地仓库进行开发的代码库会被自动插桩，并在 .git 目录插入 hooks 信息；当开发者使用模拟器进行需求自测时，插桩统计结果会被自动分发出去；在代码被推到远端前，会根据插桩统计结果，生成仅包含本次代码修改的详细增量代码测试覆盖率报告，以及向远端推送覆盖率信息；同时如果测试覆盖率小于 80% 会强制拒绝提交（可配置关闭，百分比可自定义），保证只有经过充分自测的代码才能提交到远端。图13 增量代码测试覆盖率生成流程图总结以上是我们在代码开发质量方面做的一些积累和探索。通过对覆盖率生成、解析逻辑的探究，我们揭开了覆盖率检测的神秘面纱。开发阶段的增量代码覆盖率检测，可以帮助开发者聚焦变动代码的逻辑缺陷，从而更好地避免线上问题。作者介绍丁京，iOS 高级开发工程师。2015 年 2 月校招加入美团到店餐饮事业群，目前负责大众点评 App 美食频道的开发维护。王颖，iOS 开发工程师。2017 年 3 月校招加入美团到店餐饮事业群，目前参与大众点评 App 美食频道的开发维护。招聘信息到店餐饮技术部交易与信息技术中心，负责点评美食用户端业务，服务于数以亿计用户，通过更好的榜单、真实的评价和完善的信息为用户提供更好的决策支持，致力于提升用户体验；同时承载所有餐饮商户端线上流量，为餐饮商户提供多种营销工具，提升餐饮商户营销效率，最终达到让用户“Eat Better、Live Better”的美好愿景！我们的团队包含且不限于 Android、iOS、FE、Java、PHP 等技术方向，已完备覆盖前后端技术栈。只要你来，就能点亮全栈开发技能树。诚挚欢迎投递简历至 wangkang@meituan.com。参考资料覆盖率数据分发源码覆盖率映射关系生成源码基本块介绍gcov 工具源码覆盖率报告生成工具 .info 生成文档 ...

摘要： 本文介绍了异常值检测的常见四种方法，分别为Numeric Outlier、Z-Score、DBSCAN以及Isolation Forest在训练机器学习算法或应用统计技术时，错误值或异常值可能是一个严重的问题，它们通常会造成测量误差或异常系统条件的结果，因此不具有描述底层系统的特征。实际上，最佳做法是在进行下一步分析之前，就应该进行异常值去除处理。在某些情况下，异常值可以提供有关整个系统中局部异常的信息；因此，检测异常值是一个有价值的过程，因为在这个工程中，可以提供有关数据集的附加信息。目前有许多技术可以检测异常值，并且可以自主选择是否从数据集中删除。在这篇博文中，将展示KNIME分析平台中四种最常用的异常值检测的技术。数据集和异常值检测问题本文用于测试和比较建议的离群值检测技术的数据集来源于航空公司数据集，该数据集包括2007年至2012年间美国国内航班的信息，例如出发时间、到达时间、起飞机场、目的地机场、播出时间、出发延误、航班延误、航班号等。其中一些列可能包含异常值。从原始数据集中，随机提取了2007年和2008年从芝加哥奥黑尔机场（ORD）出发的1500次航班样本。为了展示所选择的离群值检测技术是如何工作的，将专注于找出机场平均到达延误的异常值，这些异常值是在给定机场降落的所有航班上计算的。我们正在寻找那些显示不寻常的平均到达延迟时间的机场。四种异常值检测技术数字异常值|Numeric Outlier数字异常值方法是一维特征空间中最简单的非参数异常值检测方法，异常值是通过IQR（InterQuartile Range）计算得的。计算第一和第三四分位数（Q1、Q3），异常值是位于四分位数范围之外的数据点x i：使用四分位数乘数值k=1.5，范围限制是典型的上下晶须的盒子图。这种技术是使用KNIME Analytics Platform内置的工作流程中的Numeric Outliers节点实现的（见图1）。Z-scoreZ-score是一维或低维特征空间中的参数异常检测方法。该技术假定数据是高斯分布，异常值是分布尾部的数据点，因此远离数据的平均值。距离的远近取决于使用公式计算的归一化数据点z i的设定阈值Zthr：其中xi是一个数据点，是所有点xi的平均值，是所有点xi的标准偏差。然后经过标准化处理后，异常值也进行标准化处理，其绝对值大于Zthr：Zthr值一般设置为2.5、3.0和3.5。该技术是使用KNIME工作流中的行过滤器节点实现的（见图1）。DBSCAN该技术基于DBSCAN聚类方法，DBSCAN是一维或多维特征空间中的非参数，基于密度的离群值检测方法。在DBSCAN聚类技术中，所有数据点都被定义为核心点（Core Points）、边界点（Border Points）或噪声点（Noise Points）。核心点是在距离ℇ内至少具有最小包含点数（minPTs）的数据点；边界点是核心点的距离ℇ内邻近点，但包含的点数小于最小包含点数（minPTs）；所有的其他数据点都是噪声点，也被标识为异常值；从而，异常检测取决于所要求的最小包含点数、距离ℇ和所选择的距离度量，比如欧几里得或曼哈顿距离。该技术是使用图1中KNIME工作流中的DBSCAN节点实现的。孤立森林|Isolation Forest该方法是一维或多维特征空间中大数据集的非参数方法，其中的一个重要概念是孤立数。孤立数是孤立数据点所需的拆分数。通过以下步骤确定此分割数：随机选择要分离的点“a”；选择在最小值和最大值之间的随机数据点“b”，并且与“a”不同；如果“b”的值低于“a”的值，则“b”的值变为新的下限；如果“b”的值大于“a”的值，则“b”的值变为新的上限；只要在上限和下限之间存在除“a”之外的数据点，就重复该过程；与孤立非异常值相比，它需要更少的分裂来孤立异常值，即异常值与非异常点相比具有更低的孤立数。因此，如果数据点的孤立数低于阈值，则将数据点定义为异常值。阈值是基于数据中异常值的估计百分比来定义的，这是异常值检测算法的起点。有关孤立森林技术图像的解释，可以在此找到详细资料。通过在Python Script中使用几行Python代码就可以实现该技术。from sklearn.ensemble import IsolationForestimport pandas as pdclf = IsolationForest(max_samples=100, random_state=42)table = pd.concat([input_table[‘Mean(ArrDelay)’]], axis=1)clf.fit(table)output_table = pd.DataFrame(clf.predict(table))```pythonPython Script节点是KNIME Python Integration的一部分，它允许我们将Python代码编写/导入到KNIME工作流程。在KNIME工作流程中实施KNIME Analytics Platform是一个用于数据科学的开源软件，涵盖从数据摄取和数据混合、数据可视化的所有数据需求，从机器学习算法到数据应用，从报告到部署等等。它基于用于可视化编程的图形用户界面，使其非常直观且易于使用，大大减少了学习时间。此外，它被设计为对不同的数据格式、数据类型、数据源、数据平台以及外部工具（例如R和Python）开放，还包括许多用于分析非结构化数据的扩展，如文本、图像或图形。KNIME Analytics Platform中的计算单元是小彩色块，名为“节点”。一个接一个地组装管道中的节点，实现数据处理应用程序。管道也被称为“工作流程”。鉴于所有这些特性，本文选择它来实现上述的四种异常值检测技术。图1中展示了异常值检测技术的工作流程。工作流程：1.读取Read data metanode中的数据样本；2.进行数据预处理并计算Preproc元节点内每个机场的平均到达延迟；3.在下一个名为密度延迟的元节点中，对数据进行标准化，并将标准化平均到达延迟的密度与标准正态分布的密度进行对比；4.使用四种选定的技术检测异常值；5.使用KNIME与Open Street Maps的集成，在MapViz元节点中显示美国地图中的异常值机场。检测到的异常值在图2-5中，可以看到通过不同技术检测到的异常值机场。其中。蓝色圆圈表示没有异常行为的机场，而红色方块表示具有异常行为的机场。平均到达延迟时间定义的大小了记。一些机场一直被四种技术确定为异常值：斯波坎国际机场（GEG）、伊利诺伊大学威拉德机场（CMI）和哥伦比亚大都会机场（CAE）。斯波坎国际机场（GEG）具有最大的异常值，平均到达时间非常长（180分钟）。然而，其他一些机场仅能通过一些技术来识别、例如路易斯阿姆斯特朗新奥尔良国际机场（MSY）仅被孤立森林和DBSCAN技术所发现。对于此特定问题，Z-Score技术仅能识别最少数量的异常值，而DBSCAN技术能够识别最大数量的异常值机场。且只有DBSCAN方法（MinPts = 3/ℇ= 1.5，欧几里德距离测量）和孤立森林技术（异常值的估计百分比为10％）在早期到达方向发现异常值。总结本文在一维空间中描述并实施了四种不同的离群值检测技术：2007年至2008年间所有美国机场的平均到达延迟。研究的四种技术分别是Numeric Outlier、Z-Score、DBSCAN和Isolation Forest方法。其中一些用于一维特征空间、一些用于低维空间、一些用于高维空间、一些技术需要标准化和检查维度的高斯分布。而有些需要距离测量，有些需要计算平均值和标准偏差。有三个机场，所有异常值检测技术都能将其识别为异常值。但是，只有部分技术（比如，DBSCAN和孤立森林）可以识别分布左尾的异常值，即平均航班早于预定到达时间到达的那些机场。因此，应该根据具体问题选择合适的检测技术。参考Santoyo, Sergio. (2017, September 12). A Brief Overview of Outlier Detection Techniques；本文作者：【方向】阅读原文本文为云栖社区原创内容，未经允许不得转载。

引言Apache Flink是面向数据流处理和批处理的分布式开源计算框架，2016年阿里巴巴引入Flink框架，改造为Blink。2017年，阿里整合了所有流计算产品，决定以Blink引擎为基础，打造一款全球领先的实时计算引擎。当年双11，Blink支持了二十多个事业部／群，同时运行了上千个实时计算job，每秒处理的日志数峰值达到惊人的4.7亿。因此Blink的可靠性和稳定性保障变得极其重要，搜索事业部的质量团队为此专门成立了Blink测试小组，通过一年多的努力，建立了从代码质量到持续集成再到预发测试的全面的测试体系，帮助Blink的质量取得大幅提高。Blink测试平台介绍Blink测试团队为Blink质量量身打造Blink测试平台，内容如下图所示：Blink测试平台包含了三个测试阶段： 代码质量校验阶段，主要进行静态代码扫描、单元测试和基于minicluster的测试；集成测试阶段，主要是进行功能测试、性能测试和带有破坏性的稳定性测试；而预发测试阶段，主要是利用用户的job进行仿真测试，并在版本发布之前做最后的版本兼容性测试。平台选取部分测试集合纳入到precommit的验证中，可尽早发现代码中问题，而大规模的功能、性能、稳定性测试，通常作为dailybuild的集合。另外，Blink测试平台建立了较为完善的质量度量体系，除去对代码覆盖率的统计及变化的分析，还可一键生成测试报告，并对不同版本的质量进行横向对比。代码质量校验阶段代码质量校验阶段是整个Blink质量保障的基础。主要包含单元测试，利用aone提供的"集团代码规约扫描"工具对代码进行规范扫描，单机运行的基于minicluster的集成测试，只有这三个阶段都测试通过后才允许Blink代码提交到项目git。功能测试Blink功能测试框架使用defender，该框架是由pytest[1]改造而来，很好地支持了BlinkSql测试的特性，并支持第三方插件的引入。在测试集群中可以端到端的对某一场景进行精准测试。具体流程如下图所示，支持IDE和Jenkins两种触发模式，yarn_job、yarn_session和local三种case运行调度模式。执行结束后通过web页面或邮件的形式对结果进行展示，并对运行结果进行持久化。具有如下优势：1、case的统一调度与精细化管理：现在Blink在defender上有12个场景4000多个case，可以每天定时进行dailyrun，如果某一类别的case出现问题可单独执行，并可在页面上显示详情。2、case的三种运行模式满足了不同场景的测试需求：其中yarn_session模式对一个模块中存在sqlCase的场景较为适用，可大大减少与Yarn交互的时间。3、case灵活配置：不仅可以支持系统配置，对每个case集所需资源（slot，memory等）或集群其他配置的不同进行单独配置。4、一个case可同时支持批和流两种运行类型。5、client类型灵活扩展：可对现有数据存储和服务进行集成和扩展。现已支持多类型data store读写服务，yarn_session的启动，Blink job交互等。性能测试Blink作为实时大数据处理引擎，其对单位时间内的数据处理能力和数据处理的实时性提出了非常严苛的要求。因此，性能测试是整个Blink测试中非常重要的一环，是衡量Blink新版本能否发布的核心标准之一。Blink的性能测试主要包含Operator性能测试、SQL性能测试和runtime性能测试：Operator指构成SQL语义的一个原子操作，例如Sum，Aggregate等，是一个不能再分割的算子。Operator的性能测试主要用于监控单个算子在整个开发过程中的性能变化，以保证局部处理的优化和提高。目前，Operator的测试分成两个部分：单个算子的性能测试和算子组合的性能测试。Operator测试以Daily Run的方式反馈性能的变化。SQL性能测试主要用于监控版本开发过程中单个SQL的性能变化。TPCH和TPCDS是业界SQL标准性能测试集，分别有22和103个测试用例。测试平台将其引入到Blink性能测试中，以更全面地衡量Blink的性能变化。Runtime性能测试主要为了保障runtime层面性能不回退，主要包含端到端性能测试和模块性能测试。端到端性能测试首先根据梳理出测试场景，关注各场景job在指定数据量下的job运行时间，模块性能测试主要包含网络层性能测试，调度层性能测试，failover性能测试等，更关注在特定场景下job的处理时间。性能测试未来规划是将E2E性能测试、模块级别性能测试和参数调整整体联动起来，使其能够更好协助开发定位性能问题root cause和查看参数调优效果。稳定性测试对于支持高并发、多节点，集群物理环境复杂的分布式系统来说，类似磁盘打满、网络延迟等物理节点的异常很难避免。Blink作为一个高可用的分布式系统，必然要做到在异常情况下也能保证系统的稳定运行及数据的正常产出。“避免失败的最好方法就是不断地失败”，因此，在Blink任务运行期间将可能发生的异常模拟出来，就能够验证Blink的稳定性。我们把异常场景分为两类：一类是"黑猴子"，该类场景与运行环境相关，包括机器重启、网络异常、磁盘异常、cpu异常等，这部分异常主要用shell命令来模拟；另一类异常是"白猴子"，此类场景与Blink job相关，包括rpc消息超时，task异常，heart beat消息超时等，主要通过byteman[2]软件注入的方式来实现。在稳定性测试中，monkey作为调度会随机选取上述异常场景进行组合，以模拟线上可能出现的所有异常场景。考虑到Blink支持任务failover的特性和稳定性测试的自动运行，我们把稳定性测试设定为一轮轮的迭代循环，每一轮迭代都包含释放出monkey，提交任务，等待job恢复，校验四个阶段，校验主要包含checkpoint，container及slot资源等是否符合预期，校验失败就报警，校验成功后通过后进入下一轮迭代，以验证任务在长时间运行下的任务稳定性。稳定性测试架构分为四层：组件层主要包含测试Blink job，monkeys和dumper；action层包含job启动，状态校验，输出校验等；执行层包含service，monkey操作等，monkey操作时会根据ssh到具体机器，执行monkey操作；最上层是WebUI。详情如下图所示：预发测试Blink预发测试阶段主要通过克隆线上的真实任务和数据来进行复杂业务逻辑和大数据量的测试。因此，Blink 预发测试是对代码质量校验和集成测试的补充以及整个测试流程的完善，是Blink版本发布的最后一道关卡。Blink预发测试主要分为两个部分：仿真测试和兼容性测试。仿真测试仿真测试对Blink的功能、性能和稳定性等基础测试指标进行进一步地衡量，并将开发中的版本与当前的线上版本进行横向比较。因此，仿真测试能够尽早发现各种功能、性能退化和稳定性问题，从而提高上线版本的质量。仿真测试主要分为环境克隆，环境适配和测试运行三个阶段：环境克隆环境克隆是实现整个仿真测试的基础，包括线上任务的挑选、克隆和测试数据的采样。Blink的线上任务分散在多个不同的工程中，数量较多。虽然，每一个线上任务都有其内在的业务逻辑，但是，不同的任务可以根据其主要的处理逻辑进行归类，例如，以Agg操作为主的任务集合，以Sum操作为主的任务集合等，因此，Blink仿真测试需要对线上任务进行甄别，挑选出其中最具有代表性的任务。仿真测试的测试数据集是当前线上任务输入数据的采样，仅在数据规模上有差异，并且，可以根据测试需求的不同进行动态地调节，从而实现对测试目标的精确衡量。环境适配环境适配是仿真测试过程中的初始化阶段，主要进行测试用例的修改，使其能够正常运行。该过程主要包括两个步骤：更改测试数据输入源和测试结果输出地址和更新任务的资源配置。测试运行测试运行是仿真测试流程中的实际执行模块，包括测试用例的运行和结果反馈两个部分。Blink仿真测试包括功能测试、性能测试和稳定性测试等模块，不同的测试模块具有不同的衡量标准和反馈方式。这些测试模块的测试结果与代码质量校验和集成测试的结果一起构成Blink测试的结果集。性能测试和功能测试以仿真任务和采样数据作为输入，对比和分析任务在不同执行引擎上的执行过程和产出。其中，性能测试重点考察执行过程中不同执行引擎对资源的利用率、吞吐量等性能指标。功能测试则将执行的最终结果进行对比。需要特别指出的是，在功能测试中，线上版本的运行结果被假定为真，即当线上版本的执行结果与开发版本的执行结果不同时，认为开发版本的执行存在错误，需要修复开发中引入的错误。稳定性测试重点关注仿真测试任务在线上克隆环境、大数据量和长时间运行条件下的稳定性。其以Blink开发版本作为唯一的执行引擎，通过收集执行过程中的资源利用情况、吞吐量、failover等指标来进行度量。兼容性测试Blink兼容性测试主要用于发现Blink新、旧版本之间的兼容性问题，从而为线上任务升级Blink执行引擎的版本提供依据。目前，兼容性测试主要分为静态检查和动态运行两个阶段，其中，静态检查是整个兼容性测试的基础。静态检查静态检查主要用于分析线上任务在不同执行引擎下生成执行计划的不同，包括两个方面的内容：新的执行引擎生成执行计划的正确性及生成执行计划的时间长短。新、旧版本的执行引擎生成的执行计划是否兼容。在静态检查中，若新的执行引擎不能正确地生成执行计划，或者生成执行计划的时间超出预期，都可以认为静态检查失败，Blink新版本中存在异常或者缺陷，需要查找原因。当新版本能够正确地生成执行计划时，若新、旧版本的执行引擎生成的执行计划不兼容，那么，需要将对比结果反馈给开发人员以判断该执行计划的更改是否符合预期；若执行计划兼容或者执行计划的更改符合预期，则可以直接进行运行时测试。动态运行测试Blink动态运行测试利用仿真测试中的功能测试模块来进行任务的运行，是升级Blink新版本之前的最后一轮测试。若任务能够正常启动且测试结果符合预期，则认为该任务可以自动升级，反之，则需要人工介入进行手动升级。展望通过一年多的努力，Blink整体质量已经有很大幅度的提高，Blink的测试方法和工具也越来越成熟，Blink回馈社区之际，我们会逐步将测试工具一起输出，回馈更多的社区开发测试者，与此同时，随着Blink用户群的壮大，Blink业务开发者对于业务任务的质量保证需要日渐高涨，Blink测试团队未来会提供更多质量保证和开发效率工具，进一步提升Blink开发者工程效率。本文作者：溶月阅读原文本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。