我在百度做软件测试工作的趣味性在于可以接触到很多新IT技术的产品和把新IT技术知识应用到测试中，这些是我在百度最有趣的事。典型的代表就是如何尽可能找出不是bug但影响用户体验的设计问题，在百度被称为效果测试或产品评测。从测试目的而言这类测试不是发现软件编码的错误，而是发现产品设计的不足。应用的技术和方法有：基于大数据思想进行相关性分析自动挖掘数据bad case、众测、百度TIP中的AB testing、产品评测体系。以我所了解的信息来看目前百度很多产品已开展了产品效果评测，如网页搜索、图片搜索、地图搜索、视频搜索、商业搜索、众多的移动APP产品等。QA们在完成产品bug的挖掘后，会继续进行产品validation的工作为提升产品设计的用户体验继续贡献测试人员的价值。

今天我先分享下在百度学到的如何自动进行bad case挖掘的评测方法，因为我觉得这是我在百度遇到的最有趣的一种新测试类型，很好地解答了我内心关于算法效果测试方法的疑惑。先介绍下什么是bad case——“bad case是一个不符合用户心理预期的产品输出结果集”，例如：搜索结果中出现的“文不对图”现象，以及低质量的输出结果排在前面等现象。传统测试方法中并没有对此类问题现成的技术或方法，因此为了从数千万的输入数据中找出那些输出结果集质量不满足用户体验的问题，靠人工的方式对每个输出结果进行人眼判断显然是不行的。因此，百度的QA应用了大数据思想从数据的相关性入手，从大量的bad case中找到A现象与B结果的相关性，当我们得到一个可以达到80%以上相关性的准确率时就可得到一个靠谱的测试模型，当然这个测试模型天生就是自动化的，从而支持我们从海量的数据中自动地挖出海量bad case，而测试人员要做得就是设计这个自动挖掘bad case的测试模型。以前我们应用人工的方式进行相关性测试模型的规则抽取与验证，后来开始应用机器学习的思想和方法，实现先自动训练相关性测试模型达到一定准确性后，再应用这个测试模型自动的进行bad case挖掘。以前此类产品评测的最大困难是靠人工方式进行产品效果评估，一个PM一天能评估的输入数据也就最多几百个，而现在我们可以实现一天评估数十万的输入数据，工作效率提升上千倍。而这一切就是大数据思想和机器学习新技术应用到测试设计中的效果，自动化测试的概念又提高了一个新的层次。也许未来测试人员的工作方式会像我们的工作方式一样：先基于业务专家经验设计一个测试模型的架构和主要因子，然后通过真实数据集自动训练测试模型得到测试模型中每个变量因子合适的取值范围，最终自动得到一个测试结果高准确率的测试模型。未来是大数据时代，我认为利用大数据思想不去追求精准的因果关系，而是追求相关性的准确性，将是未来测试设计师们必须要掌握的一种IT技能。

在过去挖出足够数量的bad case是QA最大的挑战，现在的新挑战则变成了我们如何用最快的速度和最低的成本完成这些大量bad case的分析定位工作。通常第一步会自动地针对挖掘出来的bad case进行影响严重度的评级（依然是使用大数据思想和机器学习的方法），这样可自动选出影响较严重的bad case集。第二步：如果产品形态支持通过构建决策树模型自动地定位分析问题根因，那么将通过设计自动分析定位系统对bad case集进行处理。如果某些产品形态不支持通过构建决策树实现自动分析定位，则会通过百度的众测平台，引入用户资源通过一些众测活动来对bad case再次进行标注，这样也能大大降低工程师分析定位的成本与时间。对百度众测感兴趣的同行可以到平台test.baidu.com上去了解更多相关信息。在此我先简单介绍下：百度众测是国内第一个基于众包思想实现的一种“人工测试云”，它充分发挥公司产品爱好者的资源价值，不仅帮助发现产品bug还可以为产品优化设计体验提供用户数据，例如：通过百度众测用户对bad case的标注可帮助QA收集大量标注数据为改善产品效果贡献价值。目前网页搜索、地图搜索、图片搜索等产品都已通过众测的用户标注活动优化产品的效果设计质量和降低bad case的分析定位成本。

Bad case的自动挖掘和分析工作对于强算法类产品的用户体验改进帮助很大，而对于弱算法类产品如一些应用APP产品而言，百度QA则通过建立各自产品的评测体系的技术活动以量化方式对产品进行用户体验评测，产品经理和开发人员将根据评测结果输出产品改进的story和非功能质量属性的优化方向。

产品评测报告与传统测试报告的区别在于：传统测试报告是测试用例执行结果和bug数据的分析材料是用于分析软件存在的实现错误。而产品评测报告更多是产品在不同用户功能应用场景和非功能属性应用场景的评价数据（例如不同用户场景下的性能响应值和不同用户环境场景下的兼容性表现），以及与同类产品的对比数据，因此对产品设计者（PM）会更有用户体验提升的指导价值，通过更直观的产品用户体验数据支撑产品设计决策。QA则通过设计产品的评测体系对产品价值的贡献不仅在于发现bug，还扩展延伸到直接为产品设计和产品用户体验提升提供有量化数据支撑的改进方向。在百度内部移动APP的评测工作中会对APP在不同网络质量、不同机型、不同软件平台版本下进行产品基础功能、APP响应性能（业务级和系统级）、APP资源消耗性能（耗电量/流量/OS资源等）、UI流畅度等领域进行评测数据收集，QA会在评测数据基础上先进行第一轮的数据分析给出定性的结论，给出改进的建议和技术方案提供给PM或RD参考。为了最大化的提升移动APP的评测效率在内部除了各产品组独立开展的评测活动外、还有支持一键评测的百度评测平台对内部评测技术进行技术共享与重用帮助各产品QA提升评测工作效率。

测试人员要设计出一个靠谱的产品用户体验评测体系，必须先要对所负责产品的主要用户场景（功能和非功能）有充分的了解和理解，以及用户对产品体验的需求有足够完善的整理，才能对产品整体的用户体验进行科学客观地评价。然后评测体系还需要做“横向”同类产品、“纵向”历史版本的对比测试，并根据产品的“设计思想”进行评测验证是否达到预期的设计定位。最后通常一个好的评测体系一定是一个松耦合的产品测试平台，在这个测试平台上无论是自有产品还是其他公司的相似产品都能得到统一标准的测试数据评估，这样能帮助QA/PM/RD对产品用户体验数据的价值进行更好的分析，从而提升产品竞争力。从某种角度看QA要做好产品评测体系就必须拥有至少“半个产品经理”的用户需求场景知识，从这方面来看对QA的要求又提高了，不仅要懂软件技术会挖掘程序错误，还要有丰富的产品领域用户场景的知识（功能的/性能的/兼容性/稳定性等）。虽然对QA的技能要求提高了，但是无论对产品竞争力的提升还是对QA自身价值的提升都是有着很积极地作用。

另外我认为在公司内只有QA最适合做产品评测体系设计这件事，产品经理PM更擅长功能性需求的设计和创新，对如何设计严谨和完善的测试系统并不是很专业（QA出身的PM除外）。RD则更擅长产品架构的设计和实现，擅长从白盒层面来理解产品，对于用户应用行为黑盒层面的理解则相比QA有限。而QA却因为长期从事功能和非功能的黑盒测试活动的经验积累了很多产品在用户体验方面的知识，因此QA相比PM和RD更适合设计一个用户体验层面严谨的产品评测体系，而这也是QA在公司中独特价值之一的体现。

最后我的感慨是大数据思想、机器学习、众包、基于用户体验量化的产品评测这些所谓时髦的名词已不只是虚幻的理论或概念，把这些新的IT技术和理念应用到质量保障工作中为产品用户体验提升提供测试方法论，改变旧有的测试模式是已被实践证明可行的、是有价值的。希望我此次分享的百度QA在用户体验提升领域的实践经验能帮大家更好地提升产品用户体验和测试人员在公司中的产品价值。