一、用户体验数据分析

作为一款O2O产品，所有的线上服务最终都会体现到线下服务中。即使我们线上服务质量做到十分完美，也无法保证从ONLINE到OFFLINE的服务和体验是完美的。所以，在质量保障方面，百度医生还有诸多与传统服务类互联网不同之处，主要体现在以下方面：

1. 对来源数据充分信任

对于第三方的号源、医生信息，充分信任数据的有效性。但是在测试中发现，有些数据会周期性或不定期地更新，测试阶段因无法做到实时同步而造成数据失效，产生Badcase。这部分数据只能从线上实时获取。对于这种情形，我们采取数据监控策略，挖掘数据Badcase。数据监控方案如下图所示。

2. 线上真实用户体验数据的收集与分析

为了更好地保障用户体验，我们展开了线上监控，监控体系功能逻辑如下图所示：

从业务功能角度划分，线上监控主要包括：

a) 基本页面元素监控：主要针对一个HTML页面的各个元素进行监控，包括：图片、链接、文案、数据等等；

b) 核心数据接口监控：web服务前后端交互的途径是http数据接口，通常这部分数据又是页面的核心数据，所以针对这部分数据，添加数据格式、大小、文本校验的监控，保证数据返回正常，并页面展示正常；

c) 第三方API监控：当业务以来第三方接口或者第三方资源的时候，很多不可控因素可能会影响到业务本身，所以针对这个问题，对第三方进行监控，目的在于：第一时间发现异常，同时在第三方异常情况下保证本身服务不受影响；

d) 机器硬件可用性监控：其实这部分是最基本的监控，服务器硬件异常，必然会影响到业务的服务，监控无法避免问题，却可以在出现问题的时候及时止损。

其中，数据接口监控方案如下图所示：

图3接口自动化监控方案

上图所述的接口监控方案详述如下：

1）  自动采集线上日志

2）  对日志分析，符合规范的自动生成监控case

3）  开展监控，异常报警

该方案最大的优势在于：自动根据线上接口的返回生成监控case，并自动添加监控；从而节省了大量的人力维护成本。

另一方面，为了获取线上真实数据，我们收集了所有的用户服务请求日志，建立起日志监控，通过日志分析产品缺陷和用户行为，指导产品改进。日志监控示警方案如下图所示，主要是通过分析日志中高频率出现的问题，进行分析报警。

图4日志监控方案

二、检索端测试与评测

检索端是百度医生WEB端和APP端的后端，为后两者提供数据支撑，其重要性不言而喻。百度医生检索端，负责提供医生/医院/疾病/科室/症状的类型搜索，并提供APP/PC/WISE前端sug和筛选等其他服务接口。百度医生检索端测试，从线下质量和线上质量两方面进行全面质量保证，线下评测和线上评测全面覆盖效果评估。检索端质量保证的整体方案，概要如下图所示：

图5检索端质量保证方案脑图

1. 产品线特殊性

针对医疗产品线的以下几个特殊点，在各项质量保证措施中，需要特别处理。

1.1 医疗数据的专业性

需要在功能测试和异常测试中，全面覆盖到医疗类query类型，并考虑到用户搜索习惯。除一般的超长、特殊字符、空、超出边界范围等异常值，要考虑录入医院和医生信息数据的异常，和用户输入数据的异常。

    a) 专业术语覆盖

疾病/症状/科室搜索的测试，需要覆盖专业术语query，测试中会使用线上log提取出的用户真实query，以及大搜医学类query，进行补充。

    b) 用户搜索习惯

相对于医院标准名，用户更习惯于用医院别名进行检索；根据用户医院名称记不全，科室名称输入不准确等特性，测试时需要关注sug提示列表的功能和效果测试。

    c) query实体识别结果易产生歧义

部分query可以识别为科室，也可识别为疾病，对此类实体识别可能产生歧义的query，测试时需覆盖验证。

1.2 用户医疗行为的隐私性

用户对医疗产品的体验数据，倾向于非公开和非分享，因此不方便开展直接的用户满意度调查、用户问卷、用户体验反馈类活动。在专家小组内开展的专家体验评测，也无法覆盖到真实用户的真实就诊体验。因此，我们会通过最基础的用户日志数据，分析用户跳转和流失模型，指导产品改进和优化。

1.3 医疗检索结果的满意度指标，从用户的角度看，更广泛

除了一般的搜索系统评价指标『准确率』和『召回率』，还要考虑医疗类的其他特点，如：

   a) 结果中三甲医院、主任医生的比例会影响搜索结果的权威性；

   b) 医院距离排序影响用户对搜索结果的满意度。

1.4 医疗资源对用户体验的影响

平台接入的医生、医院等资源的数量和质量，会首当其冲的影响用户体验。鉴于此，我们从地域、医院级别、医生级别等多个维度开展了对百度医生和竞品的评测。

2. 检索端测试与评测

结合医疗产品线的特点，百度医生检索端质量保证的重点工作逐一介绍如下。

2.1 自测采用QA+RD配合模式

检索端模块送测前，RD完成自测并保证自测case覆盖率达到约定值。检索端模块的自测，采取QA开发提供基础lib库，RD完成自测case的配合模式。其中使用了xts 后端自动化测试框架， xts lib库、自测case和RD送测源码，同源管理。

新模块需求评审后，RD开发代码的同时，QA开发模块的自测基础lib库，方便在RD送测前的自测中，可以调用使用。后续，对于已有模块的版本迭代，QA根据升级需求点补充并持续维护基础lib库。

2.2 测试自动化

医疗检索端模块测试，从代码拉取、环境部署、daily构建，到模块上线阶段，通过QA在jenkins上配置各自动化job，都做到了一键自动化执行。

2.3  检索评测

在基础测试保证功能测试、异常测试和性能测试通过的基础上，对于检索的效果，通过检索评测完成。每月产出一期检索评测报告，对优化前后整体的检索效果进行对比评测。

检索端评测模型，包括评测方案、评测指标和评测打分策略，各部分详述如下：

评测方案：

l  评测的query，来自大搜query中的医学类query，和百度医生线上log中的真实query。

l  相同query对百度医生和竞品发送请求，对百度医生和竞品的检索结果进行爬取、解析、对比和打分。根据评测指标的得分情况，对比百度医生与竞品的优劣。

l  每月进行一次评测，除竞品评测横向对比外，评测还包括百度医生自身前后两个版本的纵向对比。

评测指标：

医疗的检索评测，与泛搜索的评测指标和指标的定义有所不同。

准确度：指检索医院、医生、科室、疾病和症状时，检索结果的准确度。

召回率：指检索医院、医生、科室、疾病和症状时，检索结果的召回率。

权威值：指检索医院、医生、科室、疾病和症状时，检索结果中，三甲医院、主任医师的排名，和在返回结果中的数量。

评测打分策略：

每个评测指标中的评测子指标，按优先级不同，按照不同的权重加权后求和，作为各评测指标的得分。

2.4 检索端Badcase挖掘

Badcase挖掘，是针对在评测中发现的问题，归类总结并梳理出普遍规则，然后按照此规则进行针对性的Badcase挖掘。检索端以周为周期定期进行，并生成Badcase报告，覆盖医生、医院、疾病、科室不同实体类型的检索badcase。目前的医院检索Badcase，可自动定位到模块粒度，辅助更快速地修复问题。

Badcase自动定位的整体流程图，如下所示：

医院检索Badcase自动定位，对于检索无召回的场景，需确认是因资源未覆盖导致，或检索策略处理问题。定位的基本过程，先经实体识别DA模块，确认搜索query是否识别为『医院』实体。如识别正确，在医院实体库中查询，确认接入资源中有无覆盖此查询医院。如资源库中未覆盖，定位为资源缺失导致的未召回。否则，需要继续在检索策略BS模块中，确定检索策略问题发生在哪个具体环节。流程如下图所示：

图7医院检索Badcase自动定位流程

2.5 用户真实检索习惯分析

我们对用户的搜索习惯进行分析，主要包括：

l  在各类型的搜索页面，用户跳转和流失情况

l  用户对首次搜索结果不满意时，能容忍的反复搜索次数

分析过程使用的源数据，是用户原始log日志。处理过程如下：

数据预处理：原始log日志，按照用户id进行聚类，每个类簇内提取操作序列并按时间排序。

数据建模：各类簇内的有序操作序列，统一映射后，将跳转关系存储到矩阵中。

数据统计：按产品线需求，在矩阵中统计任意两个节点直接的跳转比例并绘图输出。

用户搜索习惯分析过程如下图所示：

图8 用户搜索习惯分析过程简图