qa食品范文

2022-05-15

第一篇：qa食品范文

QA是什么职位_QA工程师岗位职责

QA是什么职位，QA工程师岗位职责是什么?想必想就职此职位的人肯定会有此疑虑，乔布简历的小编就给大家来解释一下。

QA，QUALITY ASSURANCE 的简称，品质保证的意思，是为了实体满足品质的要求而提供足够的信任，并在品质管理体系中能够进行针对性的证实全部有计划和有系统的活动。

QA工程师岗位职责为：

1.负责组织质量管理体系文件的编制、修改、实施与管理;

2.按照规定程序完成对产品的现场验货，包括数量、结构、外观、包装等;

3.出具现场验货报告;

4.协助客户对产品质量进行分析、解决、改善及跟进;

5.对各品类产品所执行的标准进行修改、归档和管理。收集外来最新技术文件、国家标准、行业标准，根据市场的流行趋势及顾客的需求更改新的工艺指令和技术文件，并传达各相关部门。

6.QA工程师配合好与业主及监理公司进行的各种质保监督检查活动，及时组织对检查出的质量问题进行整改，并采取纠正或预防措施。

7.QA工程师与各专业工程师、单项工程师密切配合，抓好不合格品的控制。出现不合格品，要及时进行原因分析并做好统计记录工作，采取有效的纠正预防措施，杜绝类似质量问题再发生。

以上就是乔布简历的小编为大家整理的QA是什么职位以及QA工程师岗位职责，希望能够对找工作的小伙伴有所帮助。

本文来源

找工作 http://cv.qiaobutang.com/knowledge/articles/563319a70cf235ea8cb0e678

第二篇：百度QA

百度QA 经验分享：百度测试架构师眼中的百度QA

(一)

发表于2013-04-09 15:31| 5060次阅读| 来源架构师Jack的个人空间| 13 条评论| 作者董杰

百度测试QA 摘要：一直以来百度质量部在业界都比较低调，外部同行鲜能了解百度QA的工作流程，以及如何应对互联网研发节奏和质量的平衡。为此，百度测试架构师董杰在博客中分享了百度QA的四大核心价值，帮助理解全程软件测试的意义。

从组织结构上百度所有的QA都归属于一个大部门百度质量部统一管理，在一个大部门下的好处是很容易一起跨产品线的协同作战，各种测试技术和测试工具能以最快的速度得到传播，避免重复造轮子的浪费。同时QA们能有一种更强的组织归属感、有着专业的发展通道与空间、关键能交到更多在QA领域与自己志同道合的朋友，扩展视野，所有QA都能从这种大资源池中获益。这一点对所有做测试的人而言更有利于测试专业技能的持续提升。从我工作所见和感受来看，百度QA有四个主要的工作挑战：职责范围广(覆盖完整的产品生命周期全流程)、面对产品技术新(如移动互联网、WebOS、推荐引擎)、研发速度快(互联网的节奏)、大数据系统的复杂(百度本质是一个分析处理数据的公司)。这些挑战长期影响着QA日常的工作方式，使得与传统的tester有着工作模式的不同。

百度QA的工作范围覆盖了百度所有形态的产品从基础架构的分布式系统、搜索架构系统、到搜索算法、Web前端、Windows客户端、手机客户端，以及最新的多媒体技术、机器学习等这些前沿的IT业务，因此在这里我能最广泛的接触到各领域测试的QA同行，听听他们的分享，扩展我的测试视野。当然我也有机会到各领域进行测试实战，从我到百度算起，我已在web前端、windows客户端、手机客户端、搜索架构系统、搜索算法、图片搜索领域进行了各种测试实践工作，大大丰富和完善了我的测试技术知识体系，受益不少。另外百度QA会更完整参与到产品研发流程的周期，从最早的MRD，到设计评审、到产品发布后的效果评测是端到端的参与完整的产品生命周期。与我过去经历最大的区别在于，QA与PM(产品经理)打交道的时间非常多，在整个产品生命周期中几乎是同步一起从头到尾密切配合，同时QA还会为PM设计并开发用于产品评测的平台对产品设计的影响会更多。对于QA与RD的关系，QA不仅只是响应RD提交代码的测试，还会主动去帮助RD如何更好地做好UT(单元测试)、如何做好code review。

基于百度QA职责范围的扩大，在百度QA工程师的职责和发展路线上目前来看已大致分为QAD和QAT，至少我在进行职称评定的评审时，已会有意识的区别评估。QAD就是QA中的软件开发者更多侧重测试工具和测试系统的软件开发，我在参加QAD任职评审1对2活动时，基本是以一个对软件开发者和软件产品设计者的角度来进行review，关注其代码质量、软件架构设计思路和产品设计思路的能力。QAT则是标准的Tester，偏重如何尽早的发现更多软件质量问题，要求精通产品的应用场景以及各种测试类型。

因此各种风格和兴趣的QA都可以在百度找到自己希望和喜欢的角色，当然有时QAT和QAD也会互换，我个人而言，认为相对而言QAT转QAD容易，QAD转QAT要难些，因为百度的QAT大多具备一定的软件开发能力，平时也会根据工作需求自己做一些自动化测试开发和工具开发的工作。而QAD要转QAT则还需要补充多种测试类型的知识技能，以及产品的业务知识。

我在这里目前算是QAT路线，大多时间在思考如何设计更完整的测试避免问题遗漏，以及如何让测试人员在短时间内发现更多的深层次问题，当没有QAD资源来帮助你时，也会自己设计与实现一些小规模的测试系统或测试工具。如果未来某天我的兴趣转换到了QAD的工作内容了也是比较容易获得机会转换的。所以当QA工作的平台足够大时，个人的兴趣也会得到最大化的满足。

在日常的工作中，很多百度QA常常还会面对很多新产品技术的挑战，这里的“新”是指新形态的互联网产品(机器学习、推荐系统、多媒体搜索)以及新的软件应用场景(移动互联网和Webos)，这些新的被测对象所带来的直接挑战主要是业界很难有现成的完整的测试方案及测试技术，于是不得不逼迫百度的QA比传统软件测试的Tester更加持续地进行测试技术的创新才能满足“新”产品的质保需求。例如：我今年参加的整个百度质量部层面的移动互联网测试技术专项topic组的工作，就不得不去填补诸多业界在移动APP稳定性测试领域、性能测试领域、自动化测试领域技术的空白，否则无法达到真正对高质量用户体验的追求。

当业界大多数APP的稳定性测试只依赖Monkey测试工具时，Monkey测试已只占百度最新APP稳定性测试用例类型不到10%的覆盖面，其他90%的稳定性测试方法大多是业界还未知但APP应用又必须要考虑的，否则就会出现“为什么用户会碰到而我无法重现的问题”。

当业界还靠移动机型穷尽进行兼容性crash问题的覆盖时，百度的QA已设计实现了基于静态代码自动扫描的兼容性crash问题的快速测试。当很多QA还在为如何在不稳定的2G网络下得到稳定的测试结果而苦恼时，百度QA已靠不到1000元的低成本技术方案很好地解决该问题。同时在完善移动APP测试方案的过程中QA内部还设计开发了不少APP测试工具填补了业界在移动APP测试领域的很多空白。经过我对内部信息的了解，之前官方对外宣传较多的移动云测试MTC只代表了百度QA在移动互联网领域测试技术积累的一部分而不是全部。所以我希望下一步有机会百度质量部能逐渐给业界分享出来，让大家都能受益从而减少移动互联网测试的烦恼和困难。据我在百度的观察我个人总结了一个规律：中国人并不缺创新能力，而是缺逼迫自己去持续创新的压力和平台。正是由于百度QA所处的工作环境和测试对象的特点，逼迫他们不得不去创新，结果QA个人的创新能力在不断提升并形成了创新的习惯。我在这样的环境下，一年下来自己的创新效率感觉比以前也提升了一倍以上，发现原来测试很多领域都有着创新的可能与空间。有朋友问我在百度累吗?我说相比过去身体不累但脑子累因为经常都在思考如何创新地解决所遇到的各种没有现成方案的测试问题。

曾有多位互联网的测试友人网上问我：“百度是如何进行面向互联网的快速测试的?”对于这个问题，我最大的感受是互联网研发速度与质量的平衡让百度的QA必须持续通过测试技术的改进来实现该目标，靠智慧的测试而不是加班来同时满足进度与质量的需求。为了满足这些需求百度质量部有大型测试平台如百度TIP(Test in production)系统、百度众测平台、百度MTC、分布式并行自动化测试等支持大多数产品组同时获得研发速度加快和研发质量提升的收益。

我个人认为百度TIP应该是国内在beta测试领域做得非常智能和系统的beta测试系统，可大大提升beta测试的效率和质量。而百度众测平台则是国内第一个也是规模最大的众测社区，依靠互联网上的热心用户资源帮助产品尽早发现更多用户场景特有的问题，减少了百度QA测试时间资源和测试物料的投入，值得国内各公司借鉴。如何更好地把用户吸引进来参与beta测试，花点钱是必须的，空手套白狼是不可能的，但是投入产出比是值得的。百度移动云测试MTC平台则通过对已有测试物料和测试资源的共享管理及自动化应用帮助各产品APP测试缩短了在兼容性测试领域和性能测试领域的测试时间，并且让各产品APP获得更广的测试覆盖从而获得更高质量的APP。

除了这些公司级的测试平台帮助各产品QA加快测试速度外，在日常的测试工作中一线百度QA还会主动积极学习和广泛地应用业界优秀的测试技术：持续集成、code review实践、静态代码自动测试工具、环境一键搭建、监控系统、分布式并行测试、探索测试等都在大多数产品组普及落地，希望靠先进的技术手段生产力来提升测试效率，缩短研发测试周期。据我所知百度质量部的探索测试在国内应该是应用产品范围最广的，从windows客户端、移动APP、web产品都在例行应用，探索测试几乎覆盖百度所有产品线，应用和实施探索测试的QA数达到上百人以上，涌现出不少内部探索测试教练，实施了探索测试的产品在没有增加测试周期和测试人力的前提下能提前发现更多问题减少漏测，部分产品探索测试发现的问题数所占比例已达30%以上，提升了发现单个缺陷的测试效率。

我个人认为对比靠延长工作时间和减少必做测试类型来加快研发速度的做法，靠主动持续应用各种新测试技术实践和成果是一种更可持久更科学更人性化的做法。关于百度如何进行“快测试”的咨询，我想这里已给出了一个已验证的解决方案了，希望值得各位同行借鉴和思考。对于当前很热门的“大数据”及大数据如何测试?我觉得百度有些实践值得大家了解，给大家一些大数据测试的启发思路。

因为百度天生就是一个大数据公司，百度大数据系统的复杂度很高导致一直要求百度的QA既要保证高负载数据处理系统的稳定性、还要挖掘大数据中的badcase，尤其要擅长算法的测试。在保障高负载数据处理系统的稳定性领域，既有“线下百度”这样集系统化的稳定性测试方案与监控系统为一体的专项测试系统，也有不少申请了专利的可靠性测试工具来解决稳定性测试中异常构造和测试流量构造的问题。同时几乎所有产品线都通过百度的大型后台系统的稳定性测试实战培养起了该领域的测试高手。

当然我也受益于百度的稳定性测试工作，通过为某百度第二大流量的产品进行稳定性测试方案的改进，在这里真正地把我过去在可靠性测试、压力测试、长时间测试领域的经验系统地结合起来形成了我自己完善的稳定性测试模型，并通过大数据处理系统的测试应用检验了我的稳定性测试模型的完整性，确保有各种测试方法可提前发现所有可产生稳定性问题的风险。另外为了更好地对大数据时代的数据挖掘和推荐效果算法进行效果评估，而不仅仅只是进行新算法程序正确性验证，百度的QA们还积极应用机器学习的思想、算法和工具对诸多产品的推荐效果算法进行产品算法集有效性的自动化评测，各产品线QA们设计的badcasse自动化挖掘系统在很多产品都能达到85%-95%的准确性，提供大量的量化数据帮助产品的算法设计者重新优化算法，而不只是修改算法的程序bug。

同时为了更早更快更准地体现算法效果测试的价值，有的QA还积极进行该领域的其他创新，诸如：网页搜索的QA把badcase自动化挖掘系统与百度众测结合后大大减少了研发人员大规模分析与定位badcase的成本。图片搜索的QA甚至实现了线下badcase自动挖掘的算法，突破了搜索业界传统依靠线上用户数据进行用户体验测试的限制，能在大数据产品上线前未获得用户数据前就提前自动发现大量的badcase数据，为用户提供更好的推荐结果。大数据领域的测试涉及很多，由于我个人所见有限，就先给大家分享到这里。如果非要我用一句话来总结百度QA的特点那就是：“持续技术创新与积极学习”。平时在微博上测试同行们常讨论QA的核心价值是什么，甚至常有开发领域的老兵也来参与辩论。当然在百度内部也会有关于QA核心价值的讨论，从我了解的情况来看百度QA的核心价值在内部已得到了一些共识和不可替代性的证明。

百度QA的第一个核心价值是：全流程质量保障中心

全流程质量保证确保所有百度产品的程序质量。从需求/设计/编码/产品发布的全流程都会有QA介入并提供各类质量保障手段。从尽早发现问题，到缺陷预防，到减少发布后遗漏问题的影响都是百度QA投入和支撑的目标。百度产品的全生命周期的质量保障是百度QA的首要工作目标，也是在百度不可或缺的核心价值，大部分的QA都一直为将漏测率降低到千分之几，甚至是零漏测长期进行着持续的测试创新和技术改进工作。

百度QA的第二个核心价值是：公司用户体验测试技术能力中心

前面所介绍的百度QA的工作范围和工作目标不只是传统tester所涉及的内容，他们被要求不仅要发现程序的错误，还要发现产品效果的问题，要求对用户体验质量全面负责。所以，百度QA除了广泛应用各种软件测试技术帮RD找bug还会积极进行产品的应用效果评测工作为PM提供用户体验方面的缺陷，badcase自动化挖掘系统、百度众测平台等都是这方面的典型代表。我觉得从这点来看百度QA的用户体验定义的覆盖含义远超过了很多人所认知的易用性感受。

百度QA不只关心程序错误这一点突破了许多公司目前对tester的限定，因此我建议各公司的tester们应该更积极主动的行动起来，在公司内部开展对产品业务有效性的评测而不仅是正确性的评测，因为只有这样才是真正的产品测试，而不仅是软件测试，测试者的价值能够获得更多的体现。

百度QA的第三个核心价值是：公司研发效率提升能力中心

百度QA们从最开始关注如何提升测试过程的效率，到现在考虑如何通过提供研发辅助工具和流程改造，提升公司整体的研发效率。我看到的是除了百度质量部层面的质量工程中心、还有产品线层面的EP专职团队、以及分布在各产品组的QA们都在积极贡献各种提升测试效率和开发效率的工具及系统。百度TIP系统、持续集成等是研发流程层面的典型代表，分布式并行测试系统、各种代码自动扫描工具等是测试效率提升的典型代表，提供给UE的单测工具FIS、提供给RD的UT技术支持服务则是研发效率能力提升的另一种形式。我认为在研发效率提升方面，百度的QA们担负起了最大的职责和贡献了最大的价值。因此各公司的tester们如果要跳出测试价值的狭义定义，可以考虑参考百度QA的工作模式，积极担负起公司研发效率提升的担子。

百度QA的第四个核心价值是：百度技术部的人才“黄埔军校" 在很多公司测试部或质量部都是向各部门培养人才的输送部门，这是因为测试工作的综合性让很多测试者获了全面的锻炼。成为一个懂技术的产品经理，成为一个懂质量的研发人员都是测试人员转岗的优势。

不过在百度我看到这里的QA在质量部内部得到了更多综合性的锻炼，不依靠转岗也能在质量部内部专注做产品研发、做产品经理。因为有的QA团队本身就在做产品，承受着做产品的质量标准压力，如百度移动云MTC本身就是百度移动云战略产品的一部分，百度众测也是一个完整的互联网产品，QA们在其中担任起了互联网产品经理，互联网产品运营，互联网产品研发角色，能参与这些项目的QA是比较幸运的，这些经历对他们未来的发展都是一次很全面的锻炼。同时前面谈到QA从MRD到产品发布后的全程介入工作，也使得QA能掌握大多数PM的技能和更深入的了解产品的完整生命周期成为“半个PM”。

因此QA的发展空间和路径是很广阔的，关键看自己在公司内部如何去推动，如何去影响周边团队，让自己的工作范围扩大的更多。没有人说“你不能做什么?”只有自己内心限制了自己“不能做什么”。从这点来看，百度的QA玩得还挺“风生水起”的，希望国内其他公司的测试人员们能跳出原有思路，扩大自己的影响范围。

经验分享：百度测试架构师眼中的百度QA

(二)

发表于2013-05-13 10:12| 4103次阅读| 来源51testing.com| 9 条评论| 作者Jack 产品测试QA百度用户体验

摘要：作者在测试工作中，遇到很多新IT技术的产品并将其应用到测试中。典型的代表是被百度称为的产品评测。这类测试主要是发现产品设计的不足。基于大数据思想进行相关性分析自动挖掘数据、产品评测体系等技术方法。

本文由百度测试架构师Jack所作，在第一篇里( 百度测试架构师眼中的百度QA(一))主要谈到百度QA的特点与核心价值，在第二篇里，他谈到了百度用户体验提升的产品评测。以下是第二篇的内容： badcase挖掘的评测方法

百度的QA应用了大数据思想从数据的相关性入手，从大量的badcase中找到A现象与B结果的相关性，当我们得到一个可以达到80%以上相关性的准确率时就可得到一个靠谱的测试模型，当然这个测试模型天生就是自动化的，从而支持我们从海量的数据中自动地挖出海量badcase，而测试人员要做得就是设计这个自动挖掘badcase的测试模型。以前我们应用人工的方式进行相关性测试模型的规则抽取与验证，后来开始应用机器学习的思想和方法，实现先自动训练相关性测试模型达到一定准确性后，再应用这个测试模型自动的进行badcase挖掘。以前此类产品评测的最大困难是靠人工方式进行产品效果评估，一个PM一天能评估的输入数据也就最多几百个，而现在我们可以实现一天评估数十万的输入数据，工作效率提升上千倍。而这一切就是大数据思想和机器学习新技术应用到测试设计中的效果，自动化测试的概念又提高了一个新的层次。也许未来测试人员的工作方式会像我们的工作方式一样：先基于业务专家经验设计一个测试模型的架构和主要因子，然后通过真实数据集自动训练测试模型得到测试模型中每个变量因子合适的取值范围，最终自动得到一个测试结果高准确率的测试模型。未来是大数据时代，我认为利用大数据思想不去追求精准的因果关系，而是追求相关性的准确性，将是未来测试设计师们必须要掌握的一种IT技能。在过去挖出足够数量的badcase是QA最大的挑战，现在的新挑战则变成了我们如何用最快的速度和最低的成本完成这些大量badcase的分析定位工作。通常第一步会自动地针对挖掘出来的badcase进行影响严重度的评级(依然是使用大数据思想和机器学习的方法)，这样可自动选出影响较严重的badcase集。第二步：如果产品形态支持通过构建决策树模型自动地定位分析问题根因，那么将通过设计自动分析定位系统对badcase集进行处理。如果某些产品形态不支持通过构建决策树实现自动分析定位，则会通过百度的众测平台，引入用户资源通过一些众测活动来对badcase再次进行标注，这样也能大大降低工程师分析定位的成本与时间。

我先简单介绍下：百度众测是国内第一个基于众包思想实现的一种“人工测试云”，它充分发挥公司产品爱好者的资源价值，不仅帮助发现产品bug还可以为产品优化设计体验提供用户数据，例如：通过百度众测用户对badcase的标注可帮助QA收集大量标注数据为改善产品效果贡献价值。目前网页搜索、地图搜索、图片搜索等产品都已通过众测的用户标注活动优化产品的效果设计质量和降低badcase的分析定位成本。

Badcase的自动挖掘和分析工作对于强算法类产品的用户体验改进帮助很大，而对于弱算法类产品如一些应用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在用户体验提升领域的实践经验能帮大家更好地提升产品用户体验和测试人员在公司中的产品价值。

转载：我眼中的百度QA(第二篇)----百度用户体验提升的产品评测

分类：软件测试2014-03-29 20:2549人阅读评论(0)收藏举报

转载地址：http://qa.baidu.com/blog/?p=1129 作者：百度质量部测试架构师董杰

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

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

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

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

转载：我眼中的百度QA(第三篇)----版本发布阶段百度QA的EP职责提升研发效率

分类：软件测试2014-03-30 10:4738人阅读评论(0)收藏举报

转载地址：http://qa.baidu.com/blog/?p=1150 作者:百度质量部测试架构师董杰

上一篇关于通过EP职责提升研发效率的文章提到了百度QA在开发阶段和测试阶段提升研发效率的主要EP工作实践。本篇给大家最后分享百度QA在版本发布阶段是如何支持研发效率提升的。

首先：谈谈持续集成在百度的应用。无论在哪个产品组工作每天早上都会收到最新产品代码持续集成的测试报告。持续集成作为一个每天都进行的例行工作，最大化的保障了产品每天能都有一个可交付的可用版本，节省了很多开发自验和入口测试的时间，尽早发现产品缺陷。在百度持续集成平台的建设和维护是由QA来负责，各产品都有QA在默默地支撑着整个产品的持续集成，维护着持续集成中运行的测试脚本和测试程序。

其次：为了保证上线质量和覆盖一些免测的项目，有些重点产品还会有高仿真的线下系统进行预上线测试评估，这能帮助我们有效覆盖上线单、系统错误以及跨子系统的接口问题，使得上线效率和质量大幅提升，此外线下高仿真系统还对外提供各种系统环境的需求，其中包括重点产品在重点版本发布前QA还会进行故障演习(自动化或半自动化)，减少版本发布后回滚的发生，减少版本发布的返工就是提升版本发布效率。

最后：QA设计和开发的产品分级发布系统Test in Production (TIP)，是百度目前QA对整个研发流程影响最大的一个EP工程成果，它直接改变了公司传统的产品发布习惯和模式，不是直接全流量发布，而是从小流量开始逐渐发布，深刻地影响了公司的产品发布阶段。通过TIP平台的分级发布功能、流量控制功能、流量测试分析功能、线上监控功能等不但能尽早发现产品问题、而且还能帮助RD和QA简化裁剪部分发布前的测试流程，不但能很好的减少版本回滚数，还能端到端的缩短测试周期，是一个提升版本发布效率的优秀工程手段。

另外在版本发布早期阶段，为了帮助产品经理PM尽早的分析和评估产品的用户体验效果，QA通过开发A/B testing系统、应用机器学习进行badcase自动挖掘、以及其他线上数据监控的系统自动地帮助PM完成产品效果从量化分析到定性决策的过程，相比传统PM靠人工收集和分析数据的方式，提升了PM在版本发布后工作效率，使得PM可以更快地完成下一个版本的产品设计改进，加快产品效率迭代速度。

第三篇：现场QA感受

现场QA工作感受

担任现场QA有半年的时间了，感受颇丰。

常说“药物的质量不是检验出来的，而是生产出来的。”为什么呢?原因也简单，因为检验样品是抽取所得，具有随机性，存在一个抽样是否均匀，是否可靠, 是否有代表性的问题。所以说检验具有缺限性。

药品质量源于设计，过程决定质量，检验揭示品质。在药品生产企业中，现场QA作为生产过程的质量体系维护者，有三点是我认为极为重要而自身仍欠缺的。

第一，全方位的知识，包括GMP知识、微生物知识、现场操作知识、工艺知识以及检验知识。

GMP是药品生产和质量管理的基本准则，所谓基本准则，也就是最低要求，而亿邦制药无论在硬件还是软件都远高于此，值得自豪。GMP三大目标要素中，防止污染是当中的重要环节，污染分为交叉污染和微生物污染。只有具备丰富的微生物知识，了解微生物的特性，才能指导现场操作人员、外来辅助人员进行良好预防。同理，丰富的现场操作知识和工艺知识的具备，能准确地评价现场人员的操作是否规范，保证生产过程被正确执行，继而保证过程质量来保证质量。至于对检验知识的要求，有人可能会问，现场QA干嘛要懂检验呢?其实不难理解，一方面，现场QA的基本职能就是评审过程的质量，而检验则是最直观的评价方法，检验结果可以为纠正偏差提供依据;另一方面，丰富的检验知识可帮助现场QA对检验数据作出更为准确可靠的判断。

第二，良好的沟通协调能力。

现场QA担任的是现场质量管理的工作，涉及到管理，就少不了沟通。可以这样说，沟通能力的高低直接决定管理水平的高低。值得高兴的是，我的进步空间很大。

第三，良好的自我调节能力。

正所谓，在其位，谋其政，各位其主。这时候，问题就来了，车间的主人是产量，而现场QA的主人则是质量。日常生产中，质量与产量难免发生矛盾时(现场QA与现场人员发生摩擦)，现场QA往往难免成为众矢之的，导致情绪上容易产生多少波动，不及时调整就会影响工作质量，这时候就需要有良好的自我调节能力，好尽快回复积极状态，投入工作。

对于如何在保证工作质量的前提下减少与现场人员的摩擦，我认为可以从以下数个方面入手：

首先，保证公平，对事不对人。这是现场QA工作的最根本原则，不可以带有个人情绪在工作中发泄。

其次，要换位思考问题，不应不分情况单纯拿文件规定去硬性要求车间，而应在全面了解情况后根据不同的情况去处理问题。对于实在无法一步到位解决的问题，要学会分解问题，分步到位，而不是强求一步到位或者放任不管。对于现场人员提出的问题，给予的答案应该是能够帮助提高质量和产量，能够赢得尊重的，而不是一句冷冰冰的“文件就这样规定，你照着执行就行了!”，令人厌恶的回复。

最后，全面提高全体员工的质量意识，无疑使减少摩擦的最好办法。QA是质量管理体系的主要建立者和维护者，对于全体员工的质量意识的提高，责无旁贷。现场QA只有在工作中展现出所具备的精益求精的质量意识的言行，才能在工作中感染他人，使清楚深刻地认识到质量的重要性。

第四篇：QA的定义

QA(Quality Assurance，中文意思是“品质保证”，其在ISO8402：1994中的定义是“为了提供足够的信任表明实体能够满足品质要求，而在品质管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。有些推行ISO9000的组织会设置这样的部门或岗位，负责ISO9000标准所要求的有关品质保证的职能，担任这类工作的人员就叫做QA人员 .

基本简介

无论是ISO9000还是CMMI，都是以过程为中心。也就是说，通过过程的持续改进来提高产品质量。而过程质量与产品质量如何正向关联呢?就需要质量保证(QA)。这也是ISO9000和CMMI都很推崇的方法。但从国内软件企业的现状来看，很多企业的过程体系都相差无几，而开发出来的产品质量却千差万别。导致这种差别的原因有很多，过程及其执行方式的生搬硬套就是其中很重要的原因之一。

在建立QA组织的时候，多数企业也这样实行“拿来主义”。就像看着别人穿着一双非常漂亮的鞋，就想拿过来自己穿，一般都不会适合自己。其结果要么是打肿脚穿大鞋，要么是削足适履，效果可想而知。我们应该做的是“量脚买鞋”、“量体裁衣”。QA组织的建立也一样，应先了解企业的文化、可获得的资源以及过程成熟度水平等，再据此选择适宜的QA组织。下面我们就从一个动态的视角来探讨QA组织的建立。

建立组织结构

建立一个组织，首先需要考虑的是它的组织结构。组织结构不仅在很大程度上决定了岗位的职责，而且还决定了资源如何配置。按照国内多数企业的做法，QA组织结构可划分为三类：职能结构、矩阵结构以及两者结合而成的柔性结构。

职能结构

在职能结构中，各个职能部门设立自己的QA岗位，位于高级经理之下，独立于项目组。QA直接对高级经理负责，但业务上需要向项目经理汇报，属于项目成薄H缤?所示。这种组织结构的优点是QA容易融入项目组，易于发现实质性的问题，解决问题也很快捷。缺点是各职能部门相对独立，部门之间的经验缺乏交流和共享，还可能出现对过程、方法和工具研究的重复性投资。在这种组织结构下，由于高级经理专注于业务的发展，QA的职业发展容易受到忽视，难于接受到应有的培训和提升。

矩阵结构

在矩阵结构中，设立了专门的QA部门，与各业务职能部门平级。QA隶属于QA部，行政上向QA经理负责，业务上向业务部门的高级经理和项目经理汇报。如图2所示。在这种组织结构中，由QA部经理对QA考评和授权，有利于保证QA的独立性和评价的客观性，也有利于确保组织的长期利益与项目(或个人)的短期利益之间的平衡。QA资源为所有项目所共享，可按照项目优先级动态调配，资源利用更充分，但也可能出现资源竞争冲突。此外，QA部门对QA流程的改进、QA知识的管理、QA人员的发展负责，并可集中资源进行QA平台的建设，以防止重复性的投资。但另一方面，在矩阵结构中，QA难于融入项目组，发现的问题也很少能得到及时有效的解决。

柔性结构

柔性结构是职能结构和矩阵结构的混合形态，在职能结构的基础上建立了QA组。

QA组是一个专业组

QA组是一个专业组，不是一个行政机构。QAG Leader可由质量管理部委派人员担任或由某业务部门的QA兼任。与职能机构一样，QA直接对高层经理负责，但在业务上向项目经理和QAG Leader汇报。柔性结构吸收了职能结构和矩阵结构的许多优点，既便于QA融入项目组，又便于部门之间经验的分享，还利于QA能力的提高。QAG Leader可以从各部门QA汇报中提取出各项目的共性问题，用于组织级过程的改进。企业还可以通过授予QAG Leader不同的权利，比如按照20/80原则与高级经理分配QA的管理，来促进QA专业研究与应用的结合。

确定岗位职责

在CMMI中，QA的主要工作是过程评审和产品审计。从实践经验来看，QA只完成这两项工作很难体现出QA的价值。为了让QA组织的产出大于组织的投入，实现增值，就应该根据企业需要适当增加QA的职责，比如过程指导、过程度量和过程改进等。过程指导主要是项目前期辅助项目经理制定项目计划(包括辅助定义或修改项目过程和过程模型、协助项目估计、建立项目验收准则、设置质量目标等)，对项目成员进行过程和规范的培训以及在过程中进行指导等。过程度量(包括产品度量)在CMMI中已经成为CMMI ML2级中一个单独的过程域，但却是对所有过程的一个共性要求。特别是成熟度越高，对度量的要求也越高，难度也越大。这就要求有专业的人员来负责，QA就是一个很好的选择。主要职责包括收集、统计、分析度量数据，以支持管理信息需求。过程改进在CMMI中主要是EPG的职责。但事实上，QA更接近于过程实施的环境，更了解过程运行的情况，也就更容易发现“木桶中最短的那块”。同时，QA也是改进过程试施的重要推动力量。

在了解了QA的这些工作以后，是否认为每个企业的QA职责应该都一样或者差不多呢?目前国内不少企业的现状确实是这样，这也是QA整体效果低下的一个很重要的因素。我们在确定QA职责的时候应该考虑自身的需要和环境，主要包括业务需求、过程成熟度水平和企业文化。

业务需求主要是确定了QA需要完成哪些方面的工作，比如执行同行评审过程中，QA可以协助评审和组织会议;在存在外包的情况下，可能需要QA在监控外包方方面发挥作用。 QA职责分配很重要的因素

过程成熟度是影响QA职责分配很重要的因素，不同的成熟度等级所要求的QA工作分布是不同的，如图4所示。在低成熟度等级下，需要抽取各项目最佳实践来定义过程，并指导过程的试施，QA在这方面的工作最多。随着过程的完善、制度化和实施，QA的工作重点逐渐转向了过程评审和产品审计。当企业的过程成熟度达到4级或5级以后，对过程的遵守已经成为员工的一种习惯，过程和产品的审查需求减少，而度量和过程能力的优化又成为QA的工作重点。

企业文化对QA来说就像空气一样，看不见它，但却深深地被它影响。比如说，在一个氛围活跃、高技术、创新能力强的企业，QA应该倾向于服务职责;而在一个强纪律、低技术、规章制度成熟的企业，QA就应该倾向于监督职责。

配置岗位人员

在建立组织结构过程中设立了QA工作岗位，现在就需要为岗位配备足够的资源，特别是分派岗位人员。从大体上说，QA人员的配备可根据企业特点分为两类：全职和兼职。

全职就是设置专门的QA人员，QA的主要职责就是质量保证工作。在设置这类人员时，最重要的是考虑他的知识、技能和素质是否符合组织和岗位的规定和要求。这些要求是依据企业文化和成熟度的不同而有所侧重。比如说，对于一个协作意识较弱、官僚主义较浓的企业，沟通对QA来说可能是一个重要的素质要求;对于成熟度较低，还没有制度化标准过程的企业，对业务的了解和QA专业知识的精通可能是选择QA最重要的标准。

兼职就是将工程师分派到其它职能部门或项目中去兼任QA工作，每一位工程师都作为一名潜在的QA。这也是QA人员配置的一个可选方案，一般适宜于开放的、以质量为向导的文化，反过来也能对质量文化的建设起到很大的促进作用。但这种方案应小心地与组织制度结合，比如奖惩制度、成本制度等，否则容易引起利益冲突。

由于QA的概念引入国内不久，QA人才相当缺乏。为了获得足够的资源来完成QA工作，也可以采取岗位轮换的方式。比如，允许项目经理在项目管理岗位和QA岗位上轮换，把一定的QA工作经历作为项目经理上岗的必备条件。采取岗位轮换的方式，一方面解决了QA资源的不足，另一方面还促进了轮岗人员把QA的思想和方法融会到开发和项目管理工作中，更大程度上提高产品质量。

从以上的分析我们可以知道，建立QA组织需要动态地考虑企业的文化、可获得的资源以及过程成熟度水平等因素，做到“因地制宜”，而不是生搬硬套。首先要建立一个适宜的组织结构，组织结构中确立了QA岗位和汇报渠道。接下来就是确定岗位职责，并根据岗位职责的要求配置合适的QA人员。只有在组织结构、岗位职责、岗位人员都设置和整合好以后，才能充分发挥QA的价值，确保通过过程的持续改进来带动产品质量的不断提高。