58SSP平台测试设计及实现

SSP平台有很多外部调用方，这些调用方包括58同城广告系统内部的调用（检索端、投放端等）和其他外部调用。

SSP平台的整体架构可以分为三层，第一层为web层（SSPManager），该web页面提供给业务线的产品和运营同学在页面上进行一些数据配置，包括对产品、售卖频道、售卖价格、广告位的配置等，以及对售卖频道和价格的快速调整。第二层为服务层（SSPMain），服务层经过一定的逻辑处理后将web层的数据写入底层数据库。第三层为数据层，数据存储主要分为三种，分别是MySQL、本地缓存和Redis。MySQL中主要放置产品数据、售卖节点数据等；本地缓存主要存储售卖节点数据；Redis中主要放置售卖频道数据、价格、折扣等数据。

1. SSP平台问题分析

基于以上对SSP平台架构的分析，SSP平台主要有以下三个问题：

1）因为业务需求等原因，产品和运营同学需要对SSP平台中存储的数据进行改动，SSP平台提供前端web页面供其对数据进行写入修改操作，如何保证从web页面写入的数据与最终存储到底层数据库的数据是一致的，且最终写入底层数据库的数据是正确的？

2）因为SSP平台底层数据层存储着大量的广告配置数据，因此服务层提供了大量的对外接口供外部调用方进行数据查询使用，因此当有服务层改动需求的时候，对于接口的回归工作量也很大，并且也考虑到对外接口的稳定性，需要保证业务方对接口的正常使用，因此如何对这部分接口实现快速回归是一个需要考虑的问题。

3）因为SSP平台中存储的数据并不是一成不变的，而是实时变化的，因此如何保证数据库中变更后的数据是正确的，不会影响业务的正常使用，而且要怎么保证底层MySQL、Redis和缓存中存储数据的一致性。

基于以上分析，接下来介绍一下针对以上三个问题的解决方案，即SSP平台测试质量体系建设。

2. SSP平台测试质量体系建设

根据SSP平台架构的分层，问题解决方案也可以分为三层，分别是web层的入参一致性校验、服务层的接口自动化和Redis数据层的数据质量保证。接下来分别介绍一下三种解决方案。

1）首先对于web层入参一致性校验，web页面的数据输入到底层数据存储的整个链路是经由测试上线，故可以保证从页面写入的数据与最终落入数据库层的数据是一致的。另一方面，对于保证从web层写入数据层的数据是正确的，可将该部分同数据层的解决方案合并。

2）对于服务层的接口自动化，实现SSP平台对外提供查询接口（25个）的接口自动化。该部分接口自动化已于线上稳定运行，运行频率为每30分钟运行一次，单次执行时间大约为2min/次，当有接口用例运行报错的时候会发出邮件报警通知，接口自动化实现之后可以保证SSP平台对外提供接口的稳定性。

3）对于数据层的数据监控，是SSP测试质量体系中最重要也是占比最大的部分，且对于数据层最重要的就是保证数据层数据存储的正确性，数据层的特点是数据存储量大且数据复杂度高，针对该特点将通过一个实际需求分析来举例说明对于具有该类特点的平台的测试方案设计；然后再介绍一下为了保证数据层数据正确性所产出的监控工具的具体实现。

a) SSP平台自助售卖管理需求分析

SSP平台存储数据量巨大且逻辑复杂的原因是SSP平台的数据复杂程度是和业务强关联的，因为当SSP平台只接入一种产品时，平台中只需要存储和维护一种产品的售卖数据和其他相关配置数据，当对平台能力进行升级的时候，也只需要回归这一种产品即可。但是随着各种产品不断的接入58同城广告系统，目前SSP平台已经存储了几十个产品的售卖数据，涉及业务线包括房产、二手车、招聘、黄页等，Redis中存储售卖频道和价格等数据大约13G。因此当有平台能力升级的时候，需要对上述几十种产品进行测试以保证产品功能正常，测试工作量巨大，故一个合理的测试方案设计尤为重要。

SSP自助售卖管理需求是通过对SSP平台新增售卖范围管理模块以及对价格和折扣模块进行优化，来提高产品和运营同学对售卖和价格调整的操作效率。如下图，红色虚线框中的部分为本次需求涉及到改动的地方，售卖范围管理功能是本次需求改动最大也是逻辑最复杂的部分。

售卖范围修改流程如下图：

在进行测试方案设计时，通过对修改售卖范围的业务场景进行分析，目前SSP平台已经接入的产品有31种，每种产品对应大约16种测试场景，所以测试场景大概有488种，通过分析发现测试场景非常多。

结合SSP平台的架构和代码逻辑对平台能力进行抽象化，发现平台其实只要支持三类产品的售卖类别存储就可以完全支持上面31种产品的售卖调整，具体分析过程如下图。

在测试的时候有两个痛点，一个是测试数据构造过程复杂。一个是测试case结果校验字段较多，人工校验可能存在失误。

1）如何解决测试数据构造过程复杂？

该问题指的是：本次需求对应的30种测试场景，每种测试场景都涉及到要往MySQL中地域和类别两张数据表中先写入售卖地域节点数据和售卖类别节点数据，以及将地域和类别节点叉乘的售卖频道数据写入Redis中，如果人工手动操作写入的话，操作流程较耗时，且频道叉乘操作时可能会有操作失误的情况。我们的解决方案是：通过将地域和类别节点数据保存在Excel表格中，然后通过读取Excel表格数据，然后通过调接口的方式将数据自动写入MySQL数据表；然后将Excel中节点数据当做入参，调接口自动生成频道数据写入Redis。

2）如何解决测试结果校验字段较多，人工校验失误的问题？

该问题指的是：测试结果字段根据不同的场景，每个结果数据大概有20个字段需要校验，人工校验的话耗时较长，且可能会有失误。我们的解决方案是：首先将每种测试场景预期结果数据写入Excel表格中，然后通过调用查询Redis的接口获取测试生成结果数据，并与预期结果数据进行自动对比。

根据对以上两个问题的分析产出一个辅助测试的自动化工具。该工具的处理流程如下：

通过使用该测试工具节省了测试时间并避免了人工校验可能存在的失误。以上是对数据配置类平台的测试方案设计分析，接下来看一下对于为了保证数据层数据正确性的监控工具的具体实现。

b） SSP平台数据层监控工具实现

通过分析调研发现，数据层占比最大也是变更最频繁的数据是售卖频道数据和价格数据。变更频率，频道数据大概每3个月会有一次批量频道的变更，数量在100+左右。价格数据的变更频率大概为每10天一次，为了保证该部分数据变更的正确性，实现对Redis中售卖频道和价格数据的一个质量监控。下图为频道和价格数据监控的实现架构图。

上图中红色虚线左边的部分为价格调整异常监控架构图，右边部分为频道删除监控架构图。价格部分的实现逻辑是，当在SSPManager的web页面发生价格调整操作时，会在MySQL数据库中的t_log表中记录一条数据，当该表有写入操作时，会发送一个主题的ESB操作消息，通过对这个主题消息进行监听，并分析消息中的字段，如果属于价格操作，就会获取有调整变化的产品的所有实时价格，并与上次备份的历史价格数据进行对比，对于超出正常调价范围的价格发送邮件给相关人员确认并微信报警。历史价格数据的备份频率为一天一次，且当天有价格调整的时候会进行价格的实时更新；实时价格的获取是通过售卖频道调用查询价格的接口查询Redis实时获取，上述是价格质量监控实现。

频道删除监控的实现主要分为三个模块，分别是数据中心、数据分析中心和消息中心。数据中心的作用主要是获取对比的历史数据，数据源是SSP平台线上Redis频道数据每天在云窗hive表中的备份数据，获取到数据后。数据分析中心会通过对比当天和前一天频道数据的差异找出被删除的数据。并通过消息中心发送邮件给相关人员进行确认并进行微信报警。

频道数据质量监控实现的过程，是对两个大文件的对比，如何解决大文件对比出现的内存不足和速度较慢的问题？有以下三个解决方案。

方案一：利用hash或者md5进行对比。

方案优势：操作简便，利用md5以及hash的唯一性能够快速的找到差异。

方案不足：如果利用hash或者md5对整个文件的数据进行映射对比，只能判断两个文件是否相同，但是对于不同的文件很难找出具体差异位置；其次，利用hash以及md5进行异同比较，还需要反编译，比较麻烦。

方案二：利用数据库的方式，进行对比。

具体操作是将文件数据灌到数据库的表中，然后利用sql语句进行异同判断。

方案优势：对于超大量的数据（几个亿的数据）能够快速准确的找出数据不同的具体位置，速度瓶颈在于文件的读取以及数据库的灌入上，但是仍然有其他的优化空间。

方案不足：浪费数据库资源，对于非超大数据整个操作比较复杂，不适应实际的场景。

方案三：实行分片读取。

每次读取1000行数据，且通过将每条对比数据通过字符串的方式进行变形，然后每天的数据形成一个set集合，通过计算集合的差值得到被删除的数据。

方案优势：操作简便，更适合实际的应用场景，且没有引起其他不必要的操作以及资源的浪费。

结合实际业务现状，对比三个方案的优缺点，方案三能够更加有效的解决上述问题，最终选择方案三作为两个大文件比对问题的解决方案。

该监控已于线上稳定运行，实现对频道删除和价格调整异常的监控，保证SSP平台中售卖数据的稳定性。监控频率为一天一次，监控单次执行时间为3min/次左右，因频道删除监控数据源依赖云窗每天对SSP_Redis中的频道备份数据，故若收到的单个产品的频道数量与前一日相比减少30%及以上的话会发出邮件报警通知，先确认是否云窗备份的数据有问题，若监控因报错执行失败也会发出邮件报警通知。

对于如何保证MySQL和Redis中的数据一致性，Redis中自动增加售卖频道的时候是根据MySQL中售卖地域和类别节点数据叉乘写入，该部分功能是经过测试上线，故可保证新增无问题；而对于如何保证缓存和MySQL的数据一致性，SSP平台是采用基于ZooKeeper 通知，监听主动切换加载缓存配置信息的方式。

回顾SSP平台的测试设计与实现，现有测试体系中仍有许多待完善的部分，主要包括以下两部分：

第一部分是对于监控发现的问题价格数据的自动修复。目前对于价格调整异常的监控只是实现了对于价格数据调整异常时的监控报警，并无对该部分问题数据的自动修复，为了尽量减少问题数据在线上的停留时间，后续会优化为对于发现的异常价格数据首先自动修复为合理区间范围的价格值，然后再将该部分数据按照业务分别发送给相关负责的PM和运营等同学进行确认。