PDCA理念融入软件测试   《转载》

　　摘要：软件测试作为软件质量保障的重要手段，PDCA循环是全面质量管理所应遵循的科学程序。本文结合软件测试工作的特点，通过文档规范的方式，将PDCA的理念融入软件测试，提出一套软件测试工作的流程。

　　关键字：软件测试、PDCA、测试流程

　　1、引言

　　PDCA循环又叫戴明环，是美国质量管理专家戴明博士提出的，它是全面质量管理所应遵循的科学程序。全面质量管理活动的全部过程，就是质量计划的制订和组织实现的过程，这个过程就是按照PDCA循环，不停顿地周而复始地运转的。PDCA 描述如下，PLAN：活动、控制、资源、目标；DO：按计划实施；CHECK：监控和测量一致性和有效性；ACTION：分析/回顾/改进/提高有效性。软件测试是有计划、有组织和有系统的软件质量保证活动，是软件工程的重要组成部分。本文结合PDCA循环对于质量改进的作用，依靠文档管理，将PDCA 理念融入软件测试。在软件测试流程中，结合PDCA 理念，各个阶段进行如此诠释，PLAN：编写测试计划；DO：按计划开展测试工作；DO：按计划开展测试工作；ACTION：维护测试文档。

　　2、PLAN：编写测试计划

　　软件测试组接到测试项目后，测试工程师首先编写《系统测试计划》，为本次测试工作做好安排。

　　根据研发部门提交的《项目总体需求说明书》《项目模块需求说明书》《项目概要设计说明书》《项目详细设计说明书》及《数据库设计说明书》等内容，测试工程师编写《系统测试计划》。测试计划中包含编写目的、参考资料、测试内容、测试环境、测试方案、测试通过标准、风险评估、测试组织和时间安排等内容，包括了PLAN中应该进行活动、控制、资源、目标等全部内容，实现了做测试工作的计划性。

　　3、DO：按计划开展测试工作

　　完成测试计划后，即按照计划的时间要求进行测试工作。

　　测试工程师依据《总体需求说明书》、《模块需求说明书》、《概要设计说明书》和《验收测试计划》分析测试需求，撰写该项目的《测试需求说明书》。软件测试的核心文件《系统测试需求说明书》是列出项目所有的测试点，保证了软件测试的有据可依。测试工程师根据《测试需求说明书》编写《测试用例》。

　　测试负责人依据《系统测试计划》及项目进度向测试工程师分配测试任务；测试工程师向测试负责人领取测试资料，执行测试。本轮测试结束后，测试工程师编写《系统测试报告》。

图1 测试设计工作流程

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿 

　　4、CHECK：审核和评审测试文档

　　审核和评审是PDCA方法中最重要的组成部分，在软件测试中主要是依靠对测试文档的审核和评审，来保证测试工作的质量。

　　《系统测试计划》是测试工作的纲领性文件，是对整个系统测试的工作安排。测试工程师完成后，需要由测试负责人进行审核，审核通过后由研发和测试人员组成的评审小组进行评审，保证了测试计划的合理性。

　　《测试需求说明书》是整个测试工作的核心文件，列出项目的所有测试点。首先由测试负责人进行审核，审核通过后组织评审，项目经理和评审小组参与进行评审，要求有测试记录。从研发和测试的角度保证了尽可能不遗漏测试点，也能有效减少测试组与研发部门的分歧。

　　《系统测试用例》是根据《测试需求说明书》的测试点扩展而来，测试工程师完成后，由测试负责人审核《系统测试用例》，并提出修改意见。

　　《系统测试报告》是每轮测试结束后，测试工程师编写《系统测试报告》，然后测试负责人审核《系统测试总结报告》。审核通过后，将《系统测试报告》交给测试负责人、项目经理、评审小组成员进行审批；审批不通过，则测试人员进行修改；审批通过，更新系统测试用例后，一轮测试结束。

图2 系统测试工作流程

　　5、ACTION：维护测试文档

　　文档《系统测试计划》和《测试需求说明书》都需要经过测试负责人的审核和评审小组的评审，《系统测试用例》要由测试负责人进行审核，《系统测试总结报告》由测试负责人审核外，还要进行项目经理、评审小组成员进行审批和会签，在此过程中，会有很多测试工程师要按照评审意见进行修改，达到了分析改进提高的效果，保证测试工作的质量。

　　6、总结：提高测试工作效率

　　将PDCA方法融入软件测试工作流程中，使得测试流程更加规范，提高了测试工作效率。编写测试计划，使得测试工作按部就班；规范的工作内容，在各个阶段都明确的产出物，方便领导对测试工作的检查；增加测试文档的评审机制，既降低测试组与研发部门沟通成本，减少分歧，又提高了软件测试的质量。

1、质量控制

　　软件质量控制对开发过程中的软件产品的质量特性进行连续的收集和反馈，通过质量管理和配置管理等机制，使软件开发过程向着既定的质量目标发展。质量控制是质量管理的的路标和动力，质量管理是质量控制的执行机制。

　　问题1：软件质量控制应该注意哪些方面？

　　建议：

　　（1）在整个软件生命周期中都该进行质量控制；

　　（2）不同阶段活动不同，应采用不同的技术；

　　（3）综合使用“预防性”和“检测性”技术。

　　问题2：软件质量控制技术有哪些类型？

　　建议：

　　（1）预防性技术：通过为过程、产品和资源设立标准等途径，来避免在产品开发过程中产生缺陷；

　　（2）检查性技术：用于发现和纠正缺陷，甚至分析产生缺陷的原因。

　　问题3：软件质量控制一般有哪些方法？

　　建议：

　　（1）目标问题度量法：通过确定软件质量目标并连续监视这些目标是否达到来控制软件质量；

　　（2）风险管理法：设别和控制软件开发过程中对软件质量危害最大的因素；

　　（3）PDCA质量控制法：PDCA是一个基于统计方法的迭代过程，已被作为国际标准。

　　问题4：软件质量控制的准则有哪些？

　　建议：

　　（1）制定明确的改进质量目标，满足客户需要；

　　（2）持续改进过程以提高质量和生产率，降低成本；

　　（3）消除恐惧，让员工更有效地工作；

　　（4）消除领域障碍，建立团队精神；

　　（5）不以口号要求零缺陷、高效率；

　　（6）进行培训，为所有人建立学习和自我提高机制。

　　2、质量目标

　　为了达到质量控制，测试团队不但需要明确软件的功能，还要明确软件应达到什么样的质量标准，即制定软件的质量目标。为了达到这些目标，在开发过程的各个阶段进行检查和评价。在质量评价时，需要有对质量进行度量的准则和方法，但更重要的是，需要在软件生存期中如何使用这些准则和方法的质量保证步骤及提高该项作业生产率的工具。

　　问题1：制定合理的质量目标需要从哪些方面考虑？

　　（1）适应性：必须制定能适应各种用户要求、软件类型和规模的质量标准，并能够度量；

　　（2）易学性：不需要特殊技术，软件技术人员人人都容易掌握；

　　（3）可靠性：对同一个软件的评价，评价的人或场合可能不同，但评价结果必须一致；

　　（4）针对性：不是在检查时才改进质量，而必须从设计阶段起就确立质量目标，在各个阶段实施落实；

　　（5）客观性：要从各种不同角度加以评价，并将评价结果定量地表示，使得人人都能理解；

　　（6）经济性：考虑如何才能把质量度量和保证所需要的费用控制在适当的范围内。

　　问题2：测试团队，需要重点关注哪些质量指标？

　　建议：

　　（1）测试设计覆盖率

　　（2）测试执行覆盖率

　　（3）各阶段缺陷密度

　　问题3：测试过程中，需要关注哪些测试缺陷密度？

　　建议：

　　（1）测试计划评审缺陷发现密度

　　（2）测试策略/方案评审缺陷发现密度

　　（3）测试用例评审缺陷发现密度

　　（4）系统测试缺陷发现密度

　　（5）集成测试缺陷发现密度

　　（6）验收测试缺陷密度

　　3、同行评审

　　在软件开发过程中邀请同行对工作产品进行审查，以图尽早查找出工作产品缺陷，进行质量控制的一种质量活动。需要前期准备、计划，安排好时间进度表，而且越早开展对项目越有价值。

　　问题1：常见的评审有哪些形式？

　　建议：

　　（1）审查：由公正的、接受过正式评审技术培训的组织者引导进行的同行检查；

　　（2）走查：又称走读，由产品的设计者或开发人员引导开发组成员和其它相关组成员浏览软件工作产品；

　　（3）分发：又称轮查，产品的设计者或开发人员将要评审的工作产品共享或分发，评审人员以修订标记或批注的方式将意见直接添加到工作产品或其复件上。

　　问题2：评审过程中常见的问题？

　　建议：

　　（1）项目进度紧张，开发人员没有时间进行评审；

　　（2）评审力度不够，评审发现的有效问题太少；

　　（3）评审会议中过多争论占用大量时间；

　　（4）评审专家与作者，或者多位评审专家之间的评审意见不一致；

　　（5）评审发现问题修改后，评审人员跟踪不充分。

　问题3：项目进度紧张，专家没有时间进行评审怎么办？

　　建议：

　　（1）将评审活动的时间、需要的评审专家写入项目计划；

　　（2）通过“正式渠道”协调评审专家资源，并得到承诺；

　　（3）评审开始前提前1-2天通知评审专家。

　　问题4：如何可以提高测试评审的效果，达到预期的效果？

　　建议：

　　（1）评审前可以使用Checklist、代码检视工具等进行自检活动；

　　（2）考虑知识结构、观点角度等方面，选择合理评审专家；

　　（3）必要时安排介绍会议，向相关专家介绍被评审对象；

　　（4）充分安排好足够预审时间。

　　4、漏测预防

　　漏测是指软件产品的缺陷在某一阶段未被发现而遗漏到了后续阶段、经效果评估后，将有效的预防措施纳入到流程或相关预防平台中，制定改进措施和跟进实施。

　　问题1：哪些环节容易发生漏测？

　　建议：

　　（1）需求分析，如需求分析遗漏、需求分析特性理解错误、需求变更未及时跟踪；

　　（2）策略漏测，如组网考虑不全面、继承特性考虑不全、性能稳定性考虑不全面；

　　（3）设计漏测，如用例描述不规范准确、用例观察点遗漏、功能交互遗漏、异常考虑不全面等；

　　（4）执行漏测，如用例执行构造数据不全面、没有严格按步骤执行用例、测试技能或经验不足等。

　　问题2：漏测分析需要做哪些工作？

　　建议：

　　（1）选择问题，选择有代表性的漏测问题；

　　（2）分析根因，进行漏测问题的根因分析；

　（3）改进实施，制定改进措施并跟进实施；

　　（4）补充测试设计，共性问题要跟踪多版本闭环；

　　（5）成果固化，经效果评估后，将有效的预防措施纳入到流程或相关预防平台中。

　　问题3：有哪些方法，可以进行漏测预防？

　　建议：

　　（1）测试策略和测试方案充分考虑各业务逻辑之间的交互和影响；

　　（2）测试用例设计时，充分考虑功能点与其他模块之间的交互和影响；

　　（3）充分考虑修改问题单、需求变更是否引入新的问题；

　　（4）参考优秀实践和经验案例；

　　（5）每次缺陷分析完要有总结，把容易漏测的形成测试经验checklist，并组织学习。

　　5、发散测试

　　发散测试，顾名思义就是不以某个标准或者框框作为约束的一种测试，发散测试准确来说应该叫具备发散思维的探索性测试。为了提高测试执行覆盖率，在严格按照用例测试执行后，通常需要进行发散测试，这里包括自由测试和交叉测试。

　　问题1：发散测试，需要关注哪些方面？

　　建议：

　　（1）重点模块和核心流程，需要安排多人进行交叉测试；

　　（2）根据2/8原则，对发现缺陷高的模块，需要重点安排人力交叉测试；

　　（3）了解用户场景，按照用户常常使用的实际场景进行发散测试；

　　（4）识别异常场景，模拟可能发生的各种异常场景进行发散测试；

　　（5）遵循规范原则，根据规范组织测试，如协议规范、设计规范和接口规范等。

百度测试架构师眼中的百度QA（一）  《转载》

发表于2013-04-09 15:31| 4004次阅读| 来源架构师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总监朱少明点评道：

第一篇的下半部分更精彩，谈到了百度QA的四大核心价值：全流程质量保障中心、用户体验测试技术能力中心、研发效率提升能力中心和人才中心。使大家更深刻理解全程软件测试的意义，软件测试=软件产品的测试，软件测试不是成本中心，它可以提高软件开发生产力。期待更具体的分享。

百度测试团队这几年增加比较快，希望将来能看到百度分享一些移动测试方面、专业性很强的文章。