微信号:Top100Case

介绍:TOP 100软件案例研究峰会是科技界一年一度案例研究盛会,每年甄选有代表的100个技术创新/研发管理案例,旨在揭幕100件案例背后的思考、长尾价值,为听众提炼最佳学习路径,帮助他人的项目或团队获得启示、成长,...

百度大数据质量保障体系(案例分析)

2015-06-01 17:01 壹佰案例

IEEE的标准中,将测试定义为“对系统或系统原件在特定条件下的运行结果进行观察或记录,并对系统和原件进行某些方面特性的评价”。传统的测试验证手段专注于构建特定的输入、上下文场景、系统执行路径,并通过对系统输出的检测,来验证系统的正确性。

随着行业中大数据话题的逐渐兴起,我们实践发现,传统的测试设计方法无法完全满足这一新领域的质量保障目的。例如,地图导航系统将用户带到一家已休业的店铺,这一结果明显违背用户意图,是一个典型的产品问题。但由于软件系统的功能是符合预期的,数据的错误无法用传统测试验证手段来提前发现。

随着百度关键领域的工程架构日益成熟,大规模的工程重构性项目逐步趋于收敛,业务的突破口逐渐倾斜至算法与策略,例如贯通更多更全面的数据、例如利用深度机器学习技术带来的广告变现的增益,等等。

在这样的大背景下,如果测试团队的角色定位仍停留在工程代码验证与回归支持的层面,恐将有被边缘化的风险。越来越多的数据类的场景与项目,促使部门开始这一新技术领域的探索。

百度每日新增的数据量高达几个PB的级别,这些数据将用于搜索、广告等核心业务系统。这一规模下,数据与系统的质量保障会遭遇到新的问题与挑战。

限于篇幅,这将是一篇综述性质的文案,介绍一个系列的案例,逐一介绍在大数据测试方向取得的经验与教训,抛砖引玉,以为更多企业提供该领域的质量保障体系建设的思路。

大数据带来的质量挑战

大数据类项目与传统工程性质的项目相比,系统庞大复杂,场景难以构建,输入无法穷举,因此传统的系统验证方法难以满足质量保障诉求。

实践过程中主要遇到以下几类较为困难与特殊的场景,罗列如下,并在后文附有解决思路供参考。

  1. 大数据领域涉及多类目的基础算法,例如挖掘、推荐、预测、机器学 习,算法本身的测试是一个专业性很强的方向。例如基于时间序列的预测模型,可用于库存管理,帮助全国连锁便利店更合理有效地补充货源。这个预测模型的有效性验收,是一类典型的大数据测试挑战。

  2. 大数据领域常常会涉及无明确验收标准的场景,是一种典型的Test-Oracle缺失问题。例如电商推荐,这类系统输出结果是否正确是存在灰度与模糊的,系统总是在持续优化与逼近理想状态。这类项目的行进过程中,对测试过程有着不同的诉求。

  3. 大数据往往涉及“长数据流”,数据的源头到数据的消费往往横跨整 个公司,介入多个部门,体系架构复杂,信息量远超出个人能掌握的 范畴。例如百度搜索系统,从获取整个互联网的页面内容信息,到最终将搜索结果展现在终端,途径页面内容提取、页面权重计算、去重与反作弊、建立索引、用户搜索点击分析等一系列动作,要求测试团队积累体系化的工具与能力,方能有效追踪和覆盖跨多业务团队的问题。

  4. 大数据往往涉及超大数据量的验证,每日千亿级别的数据,抽样无以 穷举,而在线的持续监控会导致大量资源损耗。当数据量极大时,会 遇到一些问题与瓶颈,须有相应解决方案。

  5. 大数据系统往往涉及平台与应用共存的复杂测试场景。典型的场景可 描述为:苹果的IOS操作系统是平台,基于平台有一系列应用,如何 保障平台升级后应用的兼容?同样的, Hadoop平台与Map-Reduce程序,数据库与基于数据库的存储过程,都是这样的场景。在自主研发的平台持续迭代的过程中,应用也在保持着快速的迭代与升级,需有相应的研发流程对这类项目模式进行回归支持。

  6. 支持大数据量的基础架构体系,涉及分布式系统、容灾容错、运 维、拉伸扩展、性能、异常,须有相应的技术积累。

解决方案综述

第一类问题:基础算法的测试的常用手段


  1. 功能测试:算法的功能性测试仍能复用传统的测试设计方法,依据对算法的理解构建输入输出,验证算法的基本功能正确性。

  2. 蜕变测试:由于边界常常无法穷举,为补充算法的功能验证,蜕变测试是一种常用的手段,在不确定输出预期的前提下,对已知的输入进行渐进变化,并由输出变化的关系来判断测试结论。不对该方法展开详述,可翻查相关文献。

  3. 性能测试:1)关注算法的基本指标,包含但不限于并发、吞吐、时延,确保算法能应对给定场景的压力;2)算法的伸缩性,空间、时间复杂度是否吻合算法设计预期,性能拐点在什么条件下会出现;3)算法本身的资源消耗,是计算密集型还是存储密集型,随输入压力变化对CPU、IO、Memory的损耗如何变化。

  4. 健壮性测试:各种异常输入,异常注入。

  5. 算法特性测试:例如算法设计时理论满足线性特性,在数值型输入递增整数倍率时,输出也应当预期同倍数递增。部分算法有典型、明显的特性,不展开详述。

  6. 同类算法交叉验证:大多主流算法均有开源实现,可寻找相近算法,借助开源实现处理同一数据样本,来观察输出结果与待测算法输出结果的差异,并对较大差异点进行分析。

  7. 引入真实数据场景:在测试预测模型的过程中,我们获取了百度文具中心的领用记录作为样本数据库,来观察预测算法是否吻合真实数据波动。一些真实数据样本往往对特定算法验收有很大帮助。

  8. 获取大数据样本:百度在调整语音识别模型时,需要收集大量的用户语音样本。众测、众包、向第三方公司购买,都是获取算法验证所需的大数据样本的传统手段。

第二类问题:大数据应用场景的质量保障体系


这类场景往往基于大数据常见的基础算法,例如推荐、预测、挖掘等。典型的应用例如电商的推荐系统,工程与算法的有效性不代表最终推荐能获得成功,作为测试团队,还可以在以下几个方面来支持这类系统的迭代。

  1. 确定质量标准:对于验收标准不明确的系统,首先需要明确判断正面或负面的结果的标准。例如一个电商推荐,推荐商品的重复(例如来自不同售卖者的同一款商品)是负面结果,推荐内容不相干是负面结果,推荐了配套设备(例如买了手机推荐同品牌的手机配件)是正面结果。需要有约定的质量标准,才能建立有效评估体系。

  2. 体系:基于质量标准,可人工对每一迭代进行评估与打分,人工标注可由己方人员、也可由“众包”等形式提供,见上一章节“获取大数据样本”。评估可针对全量数据的抽样,也可针对差异部分的数据。如何有效地从大数据中抽取样本,是一个需关注的问题。

  3. 数据分析:数据分析是了解和改善这类系统质量的重要手段。例如电商推荐,可根据用户实际购买的情况来判断推荐的有效性,若某一品类的推荐远低于均值,可能需要尝试不同的模型或手段来辅助提升测试效果。也可针对每一高人气商品的推荐商品数量、丰富度等,来宏观了解整个推荐系统的现状,帮助找到最有价值的改进点。

  4. 小流量实验支持:通过灰度分级上线,来渐进验证算法或策略的有效性。好的小流量实验框架,是较高并发的、发布成本低的、支持特定场景与用户群的、能快速协助判断的。小流量对于大数据应用类场景的迭代效率有很大帮助。

  5. 工具链建设与研发过程改进:在一些初步尝试此类项目的团队,研发过程往往遇到一个问题,工程、数据准备、算法、策略调优、上线运维、结果判断等诸多任务,是由同一个工程师肩负的,这会导致效率降低,且新人上手与培养的周期变长,核心人员流失对项目影响变大。需要构建工具与流程,尽可能切割任务类型,并将整个过程有效衔接,以支撑更快速有效的迭代。

第三类问题:复杂数据流质量保障


这类场景常跨多个技术团队,上下游复杂,数据量大以至难以穷举验证,问题的发现和排查较为困难,并非线下体系能覆盖。通常会涉及以下技术手段:

  1. 线下验证:传统的单测、功能测试之外,需抽样引入线上数据流,或给予模型生成更大量的样本,来验证系统的稳定性、时效性。

  2. 一致性验证:对于升级系统,获取相邻版本差异,自动或人工查验差异部分。

  3. 线上监控:复杂数据流的在线监控重要度高于线下测试,关键点在于规则库的梳理,一般流程参考大数据常见的子产品“Data Quality”,在数据流运作时,判断数据是否符合特定规则,并将结论同步到数据收集系统。对于大数据量,额外的性能开支是需要考虑的因素。

  4. 数据闭环:需构建机制确保问题收敛,使得数据质量得以提升。对于千亿级别的数据,监控的略微波动会引起超大规模的报警,需有机制对报警聚合,并使得报警阈值动态浮动以提升准确率。一些大数据异点分析的技术会对此有帮助。

  5. 问题定位:需构建机制,对报警问题自动排查,或构建工具辅助排查,降低维护成本。

  6. 性能与延迟:大数据环境的性能测试与调优,有诸多相关文献,不展开。

第四类问题:大数据测试流程相关


  1. Test After Release:发布后的测试分为两类。一类是前文描述的发布过程管理,例如预算线环境、小流量实验框架等。一类是由于场景与测试集合无法穷举,除线下测试环境外,往往将测试引入线上,作为持续监控过程。

  2. 平台与应用的迭代支持:尽量给每个开发者提供独立隔离环境,必要时模拟一些周边组件,以避免快速迭代时的集成成本。要求平台对前兼容,主流应用测试失败时不允许平台新版本并入,有自动的持续集成验证,失败时有“回滚”机制。对于Hadoop 类的复杂平台,须有长时运行的稳定性环境,线上拷贝少量任务或直接对应用测试开放,以期待暴露更多问题。

第五类问题:复杂系统的测试技术积累


处理大数据的系统往往是大规模的分布式系统,如果相关系统为自助研发,有额外需注意的测试点,罗列如下:

  1. 健壮性:“Monkey Test”与“Fuzz Test”是复杂系统常用的测试手段,建议按项目需求,构建相应的基于模型的、数据驱动类的测试工具,以增加测试集的丰富度。

  2. 时序敏感:对于分布式系统,需尝试有条件地控制系统在特定时序条件下稳定执行,以确保更完整的路径覆盖。这类工具对定位那些非稳定复现的线上问题也很有帮助。

  3. 扩展性:性能的线性及拐点,常限于测试资源无法全量验证,需在线验证或设计场景模拟。

  4. 伸缩性:集群处于各种状态时,节点加入和退出集群,验证可靠性。

  5. 测试资源:大型系统往往线上物理节点数过千,测试资源会有局限,需要做好多轮降维。

  6. 异常:磁盘磨损或坏道、文件系统局部损毁、内存过载网络拥塞、通讯丢包、包重复、网络分割,须有工具在分布式系统级环境下完成简单模拟。分布式系统设计时应当容错,可以对系统级测试回归过程中注入异常,撞击测试,来进一步验证系统健壮性。

  7. 一致性:带有状态的分布式系统(例如分布式存储),应定期检测线上数据一致性。

总结

大数据类的项目往往无法通过传统测试手段保障质量,是一个挑战更是一个机会,测试团队在该领域大有可为。让我们勇于开拓积极创新,打造坚实的技术基础,为迎接新时代到来做好准备。



分享嘉宾钱承君

嘉宾简介:测试架构师兼管理



感谢关注top100case微信公共账号,我们致力于分享、解读有代表的技术创新/研发管理案例,帮助他人的项目或团队获得启示、成长。用案例启发思维,用案例激发行动,正如"他山之石,可以攻玉"。成为所有研发中心可用的案例智库!


 
壹佰案例 更多文章 一分钟了解负载均衡的一切 【本文有福利】“数据时代,技术为王”T11 2016 智能数据峰会技术会场介绍 数据驱动变革:顶级大数据专家齐聚深圳 Facebook、Google等公司测试人员占比下降,是否代表测试将逐渐消失? 和百度当当的数据分析师聊聊大数据那些事儿
猜您喜欢 乱拳打死老师傅:大爆炸式创新,你会吗? 【重大喜讯】猿族再次崛起 Cocos2d-js中的简易MVC框架(一)框架简介 亲历亚马逊早期岁月 | Early Amazon: BookMatcher DDD领域驱动设计初探(4):WCF搭建