大数据时代已经来临，百度的测试团队在这个时代遇到了很多挑战和难题，他们是如何解决并进行发展新探索的呢?目前测试团队的构成情况是怎样的，对于新入行者又有哪些指导建议?带着这些问题，51CTO记者采访了百度测试经理钱承君老师，他将为大家深入解析这些问题。
钱承君，具有多年互联网研发、测试、管理经验，在基础架构与大数据方向有着丰富的实战经验。曾任职大众点评研发，参与了点评团队最初始的设计。目前负责百度大数据测试部门的技术管理工作，下属团队规模百人左右。
大数据给百度测试团队带来哪些挑战
大数据相关的测试其实已超出传统的测试范畴，按IEEE对软件测试的定义，软件测试是验证(verify)软件系统吻合需求定义(requirement and specification)的行为过程，更多地偏向传统的工程类软件项目。常用手段是构建系统的输入与预期的输出，来确保系统符合预期。
但是，从大数据的角度来看，整个测试理念和测试方法已经出现非常大的变革。我们拿百度搜索来举例。首先，测试输入无法穷举，可以输入的内容千变万化，按传统测试的方法论，覆盖工程实现的逻辑分支远无法确保结果的质量。其次，输出内容怎样算是正确的，没有一个定论，奇差的结果，完全不相干的结果， 用户能直接说这个返回不行，但可能就有一个更好更贴近搜索的结果没有被返回啊!这个系统的输出，一直在“理想中的好”和“极致的差”之间游移，传统的测试方法论未必能给出解答。这就是一类典型的“non-test-oracle”问题，这类问题非常常见，例如电商的结果推荐。对于大数据类的场景，除了做好传统的、工程上的、代码准确性的验证，还需要对产品本身的质量进行“验收(validation)”，这些是我们要探索的内容。
测试团队工作中遇到的最大难题
从工程实现的角度，相对于一个小型网站或手机应用，做大数据或者底层的基础架构是更困难的。百度涉及的数据规模超出了一般开源系统能承载的范畴，例如需要跨机房，需要混用计算密集与存储密集型设备。当自行改动一些复杂的基础架构，例如改造Hadoop，或索性自研发大型分布式文件系统等，由于技术的复杂度，对质量保障的要求是非常高的。
从数据的测试方法论的角度，针对算法、针对大数据挖掘的结果，判断这些产出是否吻合用户需求，以及帮助业务持续提升数据质量，是一个持续探索的话题。百度搜索每一段时间都要更新策略与搜索内容，或许某一次发布对用户的搜索体验有了坏的影响，质量团队需要评估、预判、防卫这些问题的发生，也需要在发生问题的第一时间捕获、定位、止损。这是一项很困难的工作。
从团队建设的角度，由于当前整个行业的低技术含量工作更多，较难培养和吸引更多优秀的人才加入我们，来从事这些复杂的工作。团队对人员的要求在持续上升，但从业人员的素质没有及时跟上，对于团队的组建会非常困难。
测试组织的具体架构介绍
这里介绍几种常见的测试组织结构。从汇报关系角度看，常见的测试团队有两类，一类是测试团队隶属产品线与特定业务，属于业务的一部分；一类是整个企业共享质量团队，属于企业的基础技术服务。在百度，测试团队的组织架构属于后者，是一个近两千人的大部门，直接汇报给技术高管，下属子团队与业务一一对应，但没有汇报关系。值得一提的是，也有各种知名的例外，例如谷歌模式中，测试资源是流动的，测试人员具备某种专业能力，可以是某种工具的使用，可以是提升可测性的经验。这些流动的资源进驻到产品线，把相应能力带给产品线，离开后相应的能力会在产品线留存。
测试团队内部，曾经比较流行的是细分工，在一些传统的大型企业还有留存，有专门管流程实施的，有专门做工具平台的，有专门负责发布的，有专门负责管理外包的，有专职做测试设计与测试执行的。每个人所做的工作是整个研发闭环中的一个小部分。这种模式在快速变化的互联网团队中不能很好适应，逐渐演化成百度目前的做法，百度的测试工程师更偏全栈和综合，每个人既需要懂业务，也需要能从代码中定位问题，还需要能开发工具。这种做法对工程师能力要求很高， 对个人发展很有好处，但是对公司来而言，是需要付出额外的培养成本的。到目前为止，百度仍坚持高技术标准，是一家秉持技术信仰的公司。
百度目前的测试团队，鼓励测试人员做一些横向的流动，期望人员有更全面的视野，曾经也有不少测试人员在经验丰富后转岗产品经理或者研发，因为培养的路径比较好的补足了各种短板，是很受欢迎的复合型人才。
百度测试团队人员构成
百度各个测试团队情况不同，我所在团队由于需要涉及基础架构与大数据，比较特殊，行业中没有太多对口的人力资源。团队成员主要包含几类来源：第一类是工作时间不太长还有持续培养潜力的社会招聘，比如我们招到过来自一线公司从事分布系统开发的工程师。第二类是高级别的架构师，匹配的人才非常少。第三类也是最大的团队人员构成，吸引优秀毕业生，并给更大的空间，持续培养。有些学校的实验室有非常对口的背景，比如从事大数据方向 data quality 研究的，比如做分布式系统中调度算法的，比如一些有机器学习与挖掘背景的。团队主要构成是一线院校的硕士研究生。我们的团队一直在持续寻找优秀人才的加盟。
研发、测试和运维三块工作是一个密不可分的整体
从研发到测试到运维，很难去切割那块是谁的工作，很多已经走向融合。现在很流行说的词是全栈工程师，一个人从开发做到测试做到运维。通常情况下，测试团队在这些场景与运维会比较密切地合作：
1.项目发布后的风险与预案，一般由开发、测试、运维多方联合演练。很多系统未自动恢复的容错场景是需要人工介入的，这时候需要测试人员评估这些风险和模拟场景，并促成预演。这样的演练可以在线上，在预上线环节，也可能是在线下环境。
2.很流行的一个概念叫“test after release”。现在越来越多的场景过于复杂或资源消耗过多，尤其是谈到大数据，动辄几千台机器，线上环境很难保证与生产环境的一致性。所以主张在上线 之后，在运维监管和看护下，对线上注入一些异常，注入一些抖动，加一加压，来查看系统在极端环境下的表现，这是运维跟测试比较好的结合点。
给年轻入行者的成长建议
真正好的工程师不论先进入哪一个行业，或者进入哪一个角色，从事测试、研发还是运维，你真正关注的应该是这个角色之外的东西，注重培养和修炼在某一个领域上的强积累，这个积累是别人很难通过看几篇文章，做一个小APP那么容易获得的，这里的重点是需要找到能够持续积累的领域。我们看到很多年轻人随着行业浮躁，不愿意深耕和积累，频繁跳槽来获取现金回报的增长。其实最终一个人才的价值在于稀缺性与不可替代性，需要找到这样的一个能持续积累的领域，在深入之后别人很难在数年时间内超过你，这才是专业人员的修炼正途。
预期在11月深圳WOT峰会上分享哪些内容
在51CTO WOT 2015峰会上，钱老师会介绍三方面内容。首先是大数据带给测试的挑战以及我们目前探索到的一些应对方案。其次是大数据能力对质量保障乃至研发的过程带来哪些新的可能性。最后，相信也是更多人感兴趣的部分，会聊聊百度大数据在做什么，未来的走向如何。敬请期待！
