【NCTS峰会回顾】360搜索彭兴强:360搜索质量保障体系介绍

开发 前端
2019年10月26日,由Testin主办的第二届NCTS中国云测试行业峰会在京召开,此次峰会以“AI+未来”为主题,汇聚来自国内外测试领域的知名专家学者、领先企业决策者、高层技术管理者、媒体从业者等,共同探讨高端云测试技术。

 2019年10月26日,由Testin主办的第二届NCTS中国云测试行业峰会在京召开,此次峰会以“AI+未来”为主题,汇聚来自国内外测试领域的知名专家学者、领先企业决策者、高层技术管理者、媒体从业者等,共同探讨高端云测试技术,帮助测试从业者了解最前沿行业趋势,及最新的行业实践。

[[283754]]

会上,360搜索测试总监彭兴强做《360搜索质量保障体系介绍》。彭兴强分享了360搜索业务,通过CI/CD全流程自动化、功能、性能、接口测试自动化,再加上业务监控、线上产品质量的自动化分析、AB实验以及一套完善的数据分析系统来保障线上服务质量。

以下为彭兴强演讲实录:

大家上午好!360刚刚举办了一场测试嘉年华,当时有很多同学参加并提出了一个问题,测试未来的方向在哪里?今天听了徐琨总的分享,我觉得Testin确实走在了行业的前列,对我很有启发。下面我为大家分享一下360搜索在质量保障体系建设上的一些经验。

我之前在阿里工作了四年,之后到360,在360待了七年,这期间一直负责搜索业务的测试,经过七年时间,打造出一套质量保障体系。今天主要从业务介绍、质量保障体系实践经验、问答三个环节进行介绍。

第一,业务情况。在搜索领域,大家应该都接触过360搜索。

搜索的基本流程是这样的,首先,我们会积累一批链接库,spider通过链接库中的链接获取线上网页数据进入网页库,再经过筛选、过滤,最后成为我们线上索引数据,用户通过前端搜索框查询访问索引库数据得到需要的结果。

搜索业务有什么特点呢?首先是系统庞大,整套服务需要上万台服务器、数十个在线业务模块、数亿的日PV、核心业务单例运行需要几百台服务器、多个团队开发维护;其次业务逻辑复杂,大规模的线上服务互相依赖、完整的一套业务流程需要经历十几个业务模块、结果展现需要经历数十个算法策略模块;第三,数据量大且变化快,百亿的离线数据,时刻都在更新的实时数据,特型展现的结构化数据,垂直领域的专项数据,所有数据都要能及时准确的满足用户需求;第四,测试场景复杂,系统的庞大和复杂造成几十个关联服务需要把控,众多模块由不同团队开发完成,线上query多样性造成case场景的千变万化。

征对这样的业务,我们是如何保证质量的呢?下面给大家简单讲一下。

首先,我们在流程自动化方面做了全流程的自动化体系建设。在项目管理上,我们也做了很多事情,比如把时光轴、项目时间节点都和数据关联起来。在功能自动化、前端自动化、接口自动化都有自己的一套平台。在专项测试上,有性能测试平台和DIFF平台。

最近也有人问我一个问题,人工测试能不能被替代?经过这么多年的实践,我们发现人工测试是没有办法被替代的,自动化流程只是一些固有的、已实现的流程的自动化,人工测试在新功能验证上仍然必不可少。

在整个编译打包发布流程中,由于系统复杂,核心功能单列运行就需要几百台机器,开发、测一个项目要熟悉所有模块难度很大。我们在测试之初面临过一个问题,很多同学,特别是新来的同学在不熟悉项目的时候,部署环境非常耗时,要把整个模块摸透,他至少需要一周的时间。而通过自动化的构建,实现全流程自动化之后,任何一个新同学,只要关心自己模块的变化,通过自动化系统部署自己需要的环境,这样就可以快速的切入到业务,使整体工作效率得到大幅提升。另外,很多既有功能的自动化,包括自动化发布,整个发布基本不用人工干涉,功能的自动化回归也有一套平台,另外,线上会出现一些badcase,很多并不是因为测试漏测引起的,可能是数据,或新产品类型的出现,导致结果不能满足用户需求,这些都是通过线上质量的自动化分析系统进行保障。产品质量的好坏最终衡量者是用户,通过A/B实验分流让一部分用户先用起来,快速上线,多实验版本的对比,再通过详细的数据指标分析,了解实验产品的用户使用情况,发现一些不好的版本,把优质版本推到线上。还有监控,我们的业务这么复杂,接口这么多,流程这么长,靠人去盯是不现实的,必须有一套自动化的监控模式,通过一整套的监控体系发现整个流程中存在的问题。

我们的测试开发比是比较高的,这么高的测试开发比怎么保证质量?首先是项目管理,刚才也有老师提到了测试前置,测试的极致是没有测试,完全由开发自己保证质量,但由于开发水平参差不齐,业务也很复杂,不同的开发团队,很难通过开发自己保证质量,需要测试建立整套的测试流程。在项目管理上,项目一定要规范立项,我们发现前期测试,沟通过程中会出现很多问题,比如需求不明确,低级问题不断出现,中间反复沟通,消耗了很多精力,其实大多数项目在整个项目周期里留给测试的时间并不多,如果前期规划不好,会浪费很多时间,所以项目的合规性非常重要,必须要建立规范流程、有项目说明、有项目文档。另外,全周期的平台化管理,任何一个节点,任何一个事项,在平台里可以追溯,所有的项目都有一个时光轴,可以追溯到任何一个节点,暂停,打回,bug修复,或者测试通过,我们都可以看到,可以快速定位到某一个节点,比如项目延期,为什么延期,哪个环节出了什么问题,通过平台上的记录我们都能够很清楚的知道。通过将项目管理平台和数据分析平台进行绑定,可以了解项目上线之后是什么状况,进而进一步的掌控线上产品质量。测试的极限就是没有测试,要保证质量,减少后期测试的投入,就要尽可能的加强开发自身质量建设,不能出现低级的Bug,要在前期质量建设上做好铺垫。

在流程方面,我们做了很多事情,比如编译打包自动化、环境部署自动化、基本功能测试自动化,前端的,性能的,接口的,整个体系都有自动化建设来支撑。

传统流程是开发,开发之后是自测,提测,冒烟测试,如果不通过就打回,冒烟测试通过就进入QA测试环节。我们做了一件事情,将前面的所有部分抽象出来,都放在全自动化测试流程,编译打包,提测,冒烟测试和自动化测试,所有都放到一个全自动化测试流程里。这个环节目前不需要测试来参与,现在成为开发全自动化测试,提测这两个环节,然后有两种情况,如果是性能测试QA直接确认结果,同意上线,另外一种是有新功能需要验证,测试同学完成新功能的测试,比如某版块进行了新的优化,因为我们整个流程是全自动化的,并不需要测试同学去参与,只需要走完所有的自动化验证,我们能够支持自动化上线。

全自动化的流程,一个项目提出来之后,首先会进行公共代码的检查,因为它可能会影响到其它模块,公共代码是我们必须要检查的,其次是配置文件的检查,在配制文件方面,很多开发同学有一个误区,改配制不需要测试,我们后来发现这是一个很大的误区,因为改配制导致项目出现了很多问题。因此,我们把配制的验证作为自动化建设的一个基本环节。另外是功能的回归,功能、接口、模块,离线建库,性能测试,DIFF测试,兼容性测试等,因为线上可能存在不同的版本,版本上线之后,对当前版本是支持的,对上下版本的兼容需要进行测试,所有环节都是在自动化的过程中来实现的。

接口自动化,我们对线上的数据进行收集,成为我们的测试用例,当然这些是不够的,还需要构造特定场景下自己的测试数据,公共层对常用的函数进行封装,比如抓取函数、日志分析、写数据、发邮件的基本功能,配置层进行配制项的管理,通过这个平台实现接口的自动化测试。

服务端也有一套自动化的程序,完成对测试架构及基本功能封装达到业务测试人员不用关心测试架构代码,只需要按照格式,把case输入进去运行就可以得到自动化的结果。把测试框架跟case分离,降低测试人员参与自动化测试的难度,让大众都能参与进去。

前端自动化平台,主要是通过python+shell+selenium实现。

性能测试自动化,搜索有一个特点,对性能要求特别严格,我们很多工作都是对系统性能进行测试。之前所有的性能测试都是测试同学来做的,工作量比较大,工作内容相似。我们开发了自动化性能测试平台,把测试人员释放出来,让开发同学自己去做性能测试,我们只做平台功能和数据分析和最后结果的确认和检验,降低测试人员的工作量。

通用性能测试平台的测试结果,主要是关注机器的资源消耗情况,平台使用简单,只需要提供相应的地址,选择需要的数据,平台全自动化的运行。我们还有定制化的,比如引擎,有时候会关注特定的指标,我们将基准版的数据指标集成到自动化里面去,把基本的指标标准化后和原有的数据进行对比,如果发生变化了,就需要人工去进行分析,定位看是哪里出了问题。

性能测试自动化的平台,它是数据定制化的,针对每块业务,我们可以定制化数据,开发不用关心数据,只要选择做什么业务,选择什么样的数据,点击确认就可以。平台支持数据上传,有特定的数据去验证,可以自己上传需要的数据。另外,支持多机器、多机房的发压,我们要对不同的机房发压,平台也可以支持。另外是实时日志,如果测试需要观察实时数据的状况,有些性能测试不需要把整个测试做完之后再看结果,比如10分钟,20分钟,发现问题了可以停止测试,去排查问题,我们支持秒级的数据察看。另外是历史任务管理,指标变化情况,都可以在平台里进行察看。进程监控,在特定的任务里面需要关注某些进程的情况,需要把进程名称填进去,可以通过平台察看。

结果Diff,搜索引擎的case非常多,全覆盖非常困难,每次测试,到底关注哪些query?我们只关注变化的那部分,只关注当前这一版本到底结果发生了哪些不同的变化,比如Diff不同位置的占比。

前面讲的是搜索业务线是很长的,不仅有现场的流程,还有复杂的线下流程,怎么能够保证?业务监控这块是非常重要的一个环节。我们分下面几个方面,一个是基础数据的监控,从抓取万亿级的到百亿级的网页库,这是非常复杂的过程,整个数据是什么状况,有可能中间某个环节出现了问题,数据突然停止更新了,或者突然消失了,我们需要通过监控来判断这个数据是不是存在。另外,每一个新的数据都有时间标识,我们要判断这个时间戳是不是最新的。另外,数据的大小,如果发生了明显的变化,是需要去关注的。还有,字段值是不是发生变化,都要通过监控来发现。接口的监控,接口的变化率,接口的正确性也是需要关注的。还有是查询失败率,我们控制在百分之一,甚至千分之一以内,如果超过了可能就出现了问题。还有时效性,新闻查询有最新的结果。泛时效性,比如购房新政,都会有最新的消息,我们只关注近几年的结果,你再出几年前的数据就没什么用处,所以这些信息也需要判断。还有事件查询有特型展现结果,比如国庆阅兵这样的专题,是很新的事件,需要有特型展现的,给客户更好的体验。另外是官网及高质量url,比如淘宝、京东,如果最优质的结果没有排在前面,有可能是我们的数据环节,索引环节,甚至数据筛选环境出现了问题,也是需要关注。

上面是测试基本环节应该做的事情,测试完了之后呢?效果怎么样?最终还是用户说了算,你如果觉得做的是非常好的产品,但是用户不使用,有可能说明产品质量还是有问题的,怎么验证呢?A/B实验就是很好的检验方式。

AB实验是很重要的环节,一个是分流,另外是数据。把我们整个搜索流量分成不同的桶,根据实验配置进行分流,决定某个实验到底命中哪些用户,再通过后面的数据分析,看整个效果的好坏。AB实验也是全自动化的流程,全方位、多角度的对产品数据指标进行分析。

上面都做完了可能还是不能完全保证质量,为什么?因为我们还是会收到用户反馈,使用过程中还会有各种问题,并不是测试漏测出现的,而是因为产品复杂,query千变万化,很难覆盖每一个场景,所以我们开发了线上自动化的分析系统。

从效果上来看,我们做了一些尝试,比如截图聚类,把我们的页面截取下来,去掉无关的信息进行机器学习的训练,把一些特征更好的结果筛选出来,把特征不好的结果也筛选出来,发现我们在设计方面的质量问题。

另外是sug,就是我们的智能推荐,也有可能出现badcase。我们会进行语料的处理,进行主题向量变换,相似度的计算,找出推荐的badcase。比如推荐出现了重复,比如2399小游戏,有很多重复性的数据,通过数据处理之后,发现有些很相似的去掉。整个自动化分析涉及一些比较好的技术,比如图片处理,机器学习,包括算法。

现在大家都在探讨测试左移,左移最重要的事情就是更好的去提升正式测试前版本的质量,减少测试无谓的消耗。

还有就是测试右移,左移是提升开发的质量,右移是基于用户数据去做分析,做预测,做质量的自动化建设。

这就是我今天要讲的所有内容,谢谢大家!

 

责任编辑:张燕妮 来源: 51CTO
相关推荐

2019-11-26 17:52:18

AI 数据人工智能

2023-10-26 06:43:25

2019-11-26 17:58:47

系统运维架构

2013-02-21 11:38:02

360搜索药监局

2012-09-07 14:01:22

360搜索

2014-06-03 15:57:51

移动搜索

2009-12-24 10:55:08

2012-09-24 15:39:34

2022-12-30 18:31:40

履约商家商品

2022-06-27 09:09:34

快手Flink数仓建设

2013-10-15 13:11:36

安全防护安全监控安全运维

2012-11-19 14:48:28

360手机搜索

2012-08-31 10:09:33

2014-05-30 09:15:27

移动搜索

2010-08-20 13:11:19

360百度起诉

2020-03-18 16:15:21

亿级搜索数据

2015-05-04 11:32:47

2022-12-16 09:39:43

2013-09-23 14:37:19

浏览器搜索360

2013-03-01 09:09:23

点赞
收藏

51CTO技术栈公众号