WOT讲师钱承君：大数据带给百度测试团队的发展新探索

　　大数据时代已经来临，百度的测试团队在这个时代遇到了很多挑战和难题，他们是如何解决并进行发展新探索的呢?目前测试团队的构成情况是怎样的，对于新入行者又有哪些指导建议?带着这些问题，记者采访了百度测试经理钱承君老师，他将为大家深入解析这些问题。　　

　　钱承君，具有多年互联网研发、测试、管理经验，在基础架构与大数据方向有着丰富的实战经验。曾任职大众点评研发，参与了点评团队最初始的设计。目前负责百度大数据测试部门的技术管理工作，下属团队规模百人左右。

　　大数据给百度测试团队带来哪些挑战

　　大数据相关的测试其实已超出传统的测试范畴，按IEEE对软件测试的定义，软件测试是验证(verify)软件系统吻合需求定义(requirement and specification)的行为过程，更多地偏向传统的工程类软件项目。常用手段是构建系统的输入与预期的输出，来确保系统符合预期。

　　但是，从大数据的角度来看，整个测试理念和测试方法已经出现非常大的变革。我们拿百度搜索来举例。首先，测试输入无法穷举，可以输入的内容千变万化，按传统测试的方法论，覆盖工程实现的逻辑分支远无法确保结果的质量。其次，输出内容怎样算是正确的，没有一个定论，奇差的结果，完全不相干的结果， 用户能直接说这个返回不行，但可能就有一个更好更贴近搜索的结果没有被返回啊!这个系统的输出，一直在“理想中的好”和“极致的差”之间游移，传统的测试方法论未必能给出解答。这就是一类典型的“non-test-oracle”问题，这类问题非常常见，例如电商的结果推荐。对于大数据类的场景，除了做好传统的、工程上的、代码准确性的验证，还需要对产品本身的质量进行“验收(validation)”，这些是我们要探索的内容。

　　测试团队工作中遇到的最大难题

　　从工程实现的角度，相对于一个小型网站或手机应用，做大数据或者底层的基础架构是更困难的。百度涉及的数据规模超出了一般开源系统能承载的范畴，例如需要跨机房，需要混用计算密集与存储密集型设备。当自行改动一些复杂的基础架构，例如改造Hadoop，或索性自研发大型分布式文件系统等，由于技术的复杂度，对质量保障的要求是非常高的。

　　从数据的测试方法论的角度，针对算法、针对大数据挖掘的结果，判断这些产出是否吻合用户需求，以及帮助业务持续提升数据质量，是一个持续探索的话题。百度搜索每一段时间都要更新策略与搜索内容，或许某一次发布对用户的搜索体验有了坏的影响，质量团队需要评估、预判、防卫这些问题的发生，也需要在发生问题的第一时间捕获、定位、止损。这是一项很困难的工作。

　　从团队建设的角度，由于当前整个行业的低技术含量工作更多，较难培养和吸引更多优秀的人才加入我们，来从事这些复杂的工作。团队对人员的要求在持续上升，但从业人员的素质没有及时跟上，对于团队的组建会非常困难。

　　测试组织的具体架构介绍

　　这里介绍几种常见的测试组织结构。从汇报关系角度看，常见的测试团队有两类，一类是测试团队隶属产品线与特定业务，属于业务的一部分；一类是整个企业共享质量团队，属于企业的基础技术服务。在百度，测试团队的组织架构属于后者，是一个近两千人的大部门，直接汇报给技术高管，下属子团队与业务一一对应，但没有汇报关系。值得一提的是，也有各种知名的例外，例如谷歌模式中，测试资源是流动的，测试人员具备某种专业能力，可以是某种工具的使用，可以是提升可测性的经验。这些流动的资源进驻到产品线，把相应能力带给产品线，离开后相应的能力会在产品线留存。

　　测试团队内部，曾经比较流行的是细分工，在一些传统的大型企业还有留存，有专门管流程实施的，有专门做工具平台的，有专门负责发布的，有专门负责管理外包的，有专职做测试设计与测试执行的。每个人所做的工作是整个研发闭环中的一个小部分。这种模式在快速变化的互联网团队中不能很好适应，逐渐演化成百度目前的做法，百度的测试工程师更偏全栈和综合，每个人既需要懂业务，也需要能从代码中定位问题，还需要能开发工具。这种做法对工程师能力要求很高， 对个人发展很有好处，但是对公司来而言，是需要付出额外的培养成本的。到目前为止，百度仍坚持高技术标准，是一家秉持技术信仰的公司。

　　百度目前的测试团队，鼓励测试人员做一些横向的流动，期望人员有更全面的视野，曾经也有不少测试人员在经验丰富后转岗产品经理或者研发，因为培养的路径比较好的补足了各种短板，是很受欢迎的复合型人才。

　　百度测试团队人员构成

　　百度各个测试团队情况不同，我所在团队由于需要涉及基础架构与大数据，比较特殊，行业中没有太多对口的人力资源。团队成员主要包含几类