编者按：测试、QA一直是大家关注的话题，只要有软件开发，就离不开QA和软件测试。本次特别邀请到一淘网测试架构师 @公直_黄利 ，诺基亚敏捷及精益教练 @徐毅-Kaveri 和百度高级测试工程师杨进，请他们谈下各自对QA和测试的理解，内容涉及如何衡量软件测试的有效性，探索式测试，敏捷测试，开源对测试的影响，测试的开放性以及测试框架推荐等。
请先做下自我介绍。
徐毅：我叫徐毅，现在在诺基亚北京担任敏捷及精益教练的工作。我是从05年在杭州诺基亚网络的时候开始转做专职测试的，同期也加入公司刚成立的测试自动化小组，这对我的理念有很大的影响，基本上我认为所有的测试都应该自动化。06年初加入当时的第一个Scrum试点项目，体会了一把敏捷测试，当时还根据我们的经验总结出了一套轻量化的测试流程。后来我们在公司内推广使用robotframework这个工具，作为培训师指导大家学会使用这个工具来进行测试自动化。后来还担任了一段时间的测试自动化教练的工作。
公直：阿里巴巴一淘网测试架构师。
杨进：百度高级测试工程师，06年加入百度，之前有过4年的测试开发工作，加入百度以来，主要从事自动化开发、测试方法改进以及系统测试相关的工作。
最近主要在从事哪方面的工作？
徐毅：最近主要是在敏捷及精益教练这个方面做得比较多，辅助组织和个人进行敏捷转型，由于有很强的测试背景，所以同时也做敏捷测试相关的工作。
公直：最近半年一直在做代码质量的相关工作。在一淘业务线测试团队支持之下，与测试、产品架构师、PE等合作，从系统层面出发，优化目前的测试策略和方法，提升系统的可测试性和可部署性。
杨进：近1年主要focus在系统测试和效果监控等系统层面的工作，目前是线下百度和大搜索效果监控的负责人，线下百度是一个基础的系统测试平台，对外提供预上线、故障预演、数据测试等系统层面的服务，而效果监控目标是快速发现产品严重影响用户体验的效果问题，它和线下百度相互相成，共同提升百度对外服务的质量。
国内外一直有很多人把测试与质量保证混为一谈，其实测试属于质量控制（QC），而QA还有更多内容，请谈谈您对QA和测试的理解。
徐毅：其实不管是保证还是控制，都很难达到名副其实的效果。测试做得再充分、再彻底、再快速，也无法把质量给控制起来，最多只能够更频繁地展现出质量的现状。关于QA么，我曾经在微博上发起过一个讨论，还是比较热闹的，大家可以去看看，What is the value of Quality Manager。至于“质量保证”这个词，大家可以想一想，如果我跟你拍胸脯说某件事情包在我身上，我保证办到，但实际情况是，回过头去我得催着一拨人做这个做那个才能保证你的事情办妥，你觉得这是你理解中的“保证”吗？ 更重要的问题在于，“质量是什么”。如今，我们可以说质量的外延发生了变化，已经涵盖了许多方面；也可以说，质量已经不再重要，用户体验才是最重要的。温伯格在他的《质量 软件 管理》书中说到“quality is value to some person”，对于不同的人来说，同一件东西的价值可以是不同的。
公直：其实一直以来个人不太喜欢把测试工程师称呼为QA，QA一般是指质量保证，范畴更大一些，在一淘，像过程改进工程师、配置管理工程师都在做质量控制的事情。单纯地靠测试工程师本身也是没有办法控制质量的，因为对决定软件质量的还是开发工程师。这个在博客中的《Google如何测试》系列文章中提及，对于质量来说，预防问题比发现问题本身更重要。质量更多是开发人员的问题，而不是测试人员的。通过把测试工作融入到开发过程中，我们能降低那些富产Bug的人的出错机会，不仅可以避免了大量最终用户的使用问题，而且还可以极大地降低测试人员报无效Bug的数量。测试的未来在于发现设计和编程人员解决问题方法上的局限、思路中的狭隘和技能方面的不足，这是我对测试的理解，也认为是以后测试发展的一个方向。
杨进：我理解测试关注的更多是被测对象上线前的质量，而QA关注的是宏观意义上的质量，包括开发环节的质量控制（如何提高代码本身质量）、测试环节、上线环节以及运维环节（如线上出现问题后如何快速止损），甚至还包括用那种开发模式能更有效的提升项目开发质量和效率，因而是一个更宽泛的领域。
如何衡量软件测试的有效性？
徐毅：衡量一个东西的有效性，对我来说就看比较有无之间的区别，也就是说比较“有软件测试”和“无软件测试”在“效果”上面的差异，那就是有效性啦，也即是有效的程度。那么，你所期望的“效果”又是什么呢？
公直：从90年代末开始，测试进入所谓的“Prevention oriented period ”（参见wiki）阶段，强调2点，第一个缺陷预防，第二就是软件度量。就是这个问题本身（如何衡量软件测试的有效性），如何度量你做的测试有什么收益，如何判断你的测试活动的有效性，无论是学术界还是工业界，好像也还没有什么比较好的方法，特别是在国内目前的现状（人治，部门经理或者项目经理决定太多东西），度量系统（例如sonar）计算出的测试ROI本身可能也不一定准确，人的因素变化太多。我就简单说下我们这边判断测试有效性做法好了，基本上还是还是从结果来看，上线失败次数、线上故障、线上Bug几个维度来评估测试的有效性。
杨进：要想全面评判测试的有效性是比较困难的，目前比较通用的手段是在产品发布以后，利用用户报告bug的数量和趋势来判断测试的有效性，然后这种判断方法需要上线后才能进行因而显得价值有限，上线前也有一些可参考的手段，比如UT完成后的代码覆盖率，测试用例完后的评审，测试报告的评审等。我自己比较喜欢手段是代码覆盖率，因为代码覆盖率是一个利用客观标准进行判定的方法。此外基于测试需求覆盖率也是一个好方法。
请谈下您对探索式测试的理解，请分享下这方面的实践经验？
徐毅：其实探索式测试是什么，Cem Kaner和James Bach的一些文章、PPT都已经写得非常清楚。
首先探索式测试是一种测试的“方式”（Way，或Approach），而不是测试“技术”（Technique），方式也即是指完成整体测试工作所选择的办法，而技术则是指对于局部测试工作进行操作的方法。
其次，ET的目的在于“探索”，也即有一个明确的测试目标，但是目标的细节或是达成目标的步骤尚不清晰，所以需要边走边看，同时间地进行学习、设计、执行、解析的结果，与PDCA循环颇有相似之处。
第三要区分开ET和手工测试的关系。“手工测试”所强调的是执行的手段，也即“手工”。而ET主要强调目的，也即“探索”，当然还有就是，执行只不过是ET中的一部分而已，而这一部分，可以借助自动化。例如，修改某个已有自动化测试脚本中的部分测试数据，借助于脚本快速地执行某些操作，而去掉或暂停分析部分的脚本执行，因为此时测试的结果未知，需要依赖人工来判断、分析测试结果。
公直：探索式测试最近2年异常火爆，很多人以为是最新出的一个测试技术或者方法。Cem Kaner 在1983年（都快30年了）就提出了。这是一种强调个人自由与责任的测试方法，让独立测试人员可以借由不断的学习来改善测试的规划与测试的执行，而在测试的过程中也会同时改善测试用例从而达到相辅相成的效果。在一淘这边，其实很早就开始使用这种实践方法了，但很多一线的测试人员并不知道自己的做法就是探索式测试，在互联网研发模式下，一般都或多或少地使用敏捷模式，或者其他的土方法，但迭代周期都很短，一个月就要上线。在这样的环境下，文档少，在测试计划制定设计上都不可能完善，一般在测试过程中是用freemind等脑图工具来记录测试执行过程的同时做测试用例的设计，这种方式可以做常规测试的补充。
杨进：我很喜欢探索性测试，它让测试工作变得轻松和富有创造力，它能让你无需复杂的测试准备，就直接进入最核心的测试工作，并且不拘泥用什么方法、什么工具，也不用考虑能否能被自动化，只需要关注能否快速的找到bug就行。当然好的探索性测试实际上对工程师的逻辑分析能力和产品整体理解要求很高，这种依赖于个人能力的测试手段，执行的效果也比较难以控制。
探索性测试的实践方面，我们之前尝试过多人组队测试，这种方式适用于多人进行的大型项目，大家一起进行探索性测试，bug系统即时显示你在这个版本发现了多少个bug，并且排名，我们每天乐于寻找更多的bug，并且分享找bug的技巧，在这个过程中我们都得到了很多的成就感，并且对产品的理解和测试技巧也大幅提升。现在回想起来也还是一个很有意思的事情。
您怎么看敏捷测试，执行后会质量有哪些明显的改善？
徐毅：我认为，敏捷测试（关于敏捷测试的定义、介绍，请参考Lisa Crispin书中的描述）并无法单独的执行，必须在敏捷的环境下，结合开发人员方面的敏捷实践（以及组织结构）齐头并进方可实现。而此时，质量的提升乃是源于软件开发工作整体的改善，很难说一定是测试的功劳。另一方面则在于，测试本来就无法“控制”质量，自然也无法改善质量，因为测试工作本身并不改变那些可以影响质量产生的因素。但敏捷测试的实践对于质量的提升是肯定有影响的。
● 敏捷中对于团队内外参与、交流的追求，能够更容易“do things right”
● 快速地交付和反馈，有助于做到更多地“do right things”
● 完整团队、跨职能团队等实践，团队负责自己的工作方式改进，更容易做到“do things rightly”
公直：敏捷测试是一个被过度炒作的概念，和架构师、云计算一起被大家私下称呼“大忽悠”的工具，特别是最近几年。传统上将敏捷测试就是在敏捷研发流程下的测试，例如使用XP、或者scrum的研发流程下的测试活动，怎样在这样的研发背景下做测试，挑战在于如何使用敏捷的流程。另外一种敏捷测试，就是按照敏捷宣言中的几个关键词，“速度快”、“反馈”、“持续”，做的测试。由于敏捷强调的重点，还是在“快”上，无论中文含义的字面解释，“敏”、“捷”其实都是快的意思，这正是自动化程序的特长，机器的运行速度总是比人的操作要快，所以我们一般在敏捷项目中使用了非常多的自动化技术。个人感觉十分使用敏捷测试与质量提升方面没有直接关系。
杨进：我理解敏捷测试就是让项目相关的角色全体直接承担项目最终目标，由于都是为最终目标服务，因而角色也变得模糊，并且每个人的工作也需要考虑是否对当前最急迫的事情，这种集中所有角色力量为共同目标前进的开发方式，减少了大家沟通和项目迭代成本，最终很容易得到项目整体效率和质量的提升。由于各角色对目标理解一致，对产品理解都很深入，因而可以更多的把bug消灭在开发的早期，比如单元测试、新功能测试阶段，使得后期的集成和系统测试问题变得更少，尤其是产品最终的效果问题也会减少。
开源对测试的影响，如何看待测试的开放性？
徐毅：平台、工具、框架在我看来属于比较相同的情况，我就拿我自己的经历来做例子吧。在诺西的时候，我们有使用过一个叫robotframework的测试自动化框架，它最开始是一个和诺西合作的芬兰专家开发出来的，在诺西（当时还叫诺基亚网络）最先开始使用， 而后逐步推广，在此过程中这个框架也在不断地更新、改进、完善。后来在公司之外也有很多的使用者，于是开发者和诺西把这个框架开源出来，也吸引了更多的人加入到这个框架的开发中来，包括衍生工具的开发，这都推动了这个工具的广泛使用和不断完善。诺西作为最主要的支持者，并没有因为开源而受损，反而因为这个开源框架庞大的用户群体和开发者队伍而受益颇多，有更多的人可以分享经验、讨论问题，也有更强大的开发力量提供所需的功能。不过，开源的软件，或者开源的社区相对来说更倾向于Linux的设计理念，也即是更专注于某一个领域、某一块功能，做精，而不像是Windows那样的设计理念，强调易用性、一站式体验。这意味着，企业内要完成所有的测试工具，可能需要和多个开源工具、框架打交道，整体上如何协调使用并不容易，需要培养相关方面的人才。
测试开放性，没有特别想法，也没啥体验，只能凭感觉谈谈。个人观点比较悲观或者比较现实。测试就是测自己产品的功能、特性，让别人知道自己的测试，也就是知道了自己产品的细节和特性。出于商业上的考虑，我认为各企业恐怕会较难把最核心部分的东西拿出来公开。不过这个很可能会是一个趋势，即使拿出来的测试用例的范围比较小而已。对于产品也有要求，得要是相对标准化程度比较高的产品，不然拿出来的测试最多别人参考一下，而无法直接使用，也无法反馈改进，意味着拿出来的那一方也无法受益，这样的话这些测试也就等同于是“死亡的文档”（dead documentation），没有实效。
公直：开源意味着更多可以利用的资源，特别是在测试工具上，开源也是一种开放的心态。测试的开放性，在于比较坦诚地把自己在怎样的场景下如何去做测试给大家做个介绍。非常典型的就是Google，在James的带领下，有一系列的博客、文章、工具在介绍他们的测试，介绍他们测试中遇到的问题已经他们是怎么解决的。非常期望各个公司，无论大小，测试做的程度，都可以把自己的测试通过微博、博客、文章、公开演讲等形式公布出来，毕竟这一部分不太涉及太多的商业机密或者核心技术。
杨进：测试的开放性，或者说基于某种特性测试的开放性是未来发展的趋势，原因是互联网的创业越来越依托一些基础的平台，比如iOS、Android，而就一个公司内部而言，云的广泛应用也使得不同产品基于一个相同的基础，由于有了共同的基础，这些都表征出测试也会慢慢走向开放，从部门走向公司，从公司内走向开源。一个好的开放性测试框架，是依托于具体测试资源，以满足具体某种测试需求而诞生的。这种测试框架因为和用户的某些需求绑定因而生存能力很强，并且也能很好的一站式完成用户的需求。
我们把测试当成了质量保证的主要手段，当质量低下时，或者为了达到高质量时，一般的选择都是加大测试的工作量。您怎么看？
徐毅：临时抱佛脚，没用。就算真要加大，同时也得加大开发的工作量，找出来的bug没人修复的话，质量是不会提高的，只不过是我们更加清楚自己的产品质量很烂而已。
公直：测试工程师做的测试活动一般都被称之为是“检测”，与之对应的开发工程师做的测试都是在“预防”，质量高低可以通过测试“检测”出来，但测试永远无法提升产品质量。所以，为了达到高质量，可以做更多的测试，加大测试工作量来发现产品的缺陷并修复，但对于质量，这都是“事后”，是一种下策，不是不可以。更好的办法，是测试前移，让开发来做单元测试、简单的功能测试，在这个过程中会发现大量的问题并自行修复，测试更过地关注在用户使用上，这样高质量会更容易达到一些。
杨进：质量的主体其实是Dev，试想QA完成某个被测对象的测试，它最核心的价值是什么？发现bug 或是证明产品能满足具体应用的需求？我选择后者，因而如何让Dev开发出质量更高的代码是每个产品质量可控的测试团队首先考虑的事情。当然如果当前质量低下的时候，一个比较快速见效的方法就是投入更多的测试，但是这不能是唯一手段，必须有人走到开发的阶段，从上游逐步开始改善代码的质量和可测试性，否则这就是一个死循环。更多的低效投入，更多的测试和debug成本，这足以压坏这个项目的所有角色，而不仅仅是QA。
工作中推荐的测试框架？使用的范畴？
徐毅：我推荐使用robotframework，它是一种基于关键字驱动理念的的测试自动化框架（也支持数据驱动），用于敏捷测试象限（参看Lisa的书或者Brian Marick的博客）中的Acceptance Testing。更多的信息可以参看它的主页，www.robotframework.org。最初是由诺基亚西门子网络资助开发的，如今已经开源，大家都可以使用，国内也有许多的实践者可以交流经验。它支持多种的测试文件格式，包括HTML、CSV和文本文件，测试用例的格式主要是一个表格形式，和FIT、FitNesse比较像。然后通过内部的机制驱动底层的Library进行测试，而Library可以用Python和Java编写，目前已经有很多现成的，例如Selenium、Telnet、SSH、AutoIt等。
我使用这个工具已经很多年，觉得它非常的好用，非常贴合敏捷开发的方式，能够支持我们的ATDD，如今它甚至已经内嵌可以支持BDD格式的关键字脚本。
公直：Selenium，主要做Web UI级别的功能测试； JUnit/GTest, 代码级别的单元测试或者API调用级别的自动化测试；staf/stax，远程调用，在测试环境部署自动化中可以用到；JMeter/ab/http_load, 性能相关的测试；另外，给大家推荐一款自动化调度的工具TOAST，http://toast.taobao.org/ ，是我们这边的一个开源的测试调度工具，主要解决持续集成中的测试执行。
杨进：百度内部有一个测试工具平台，里面有百度内部开发的很多很棒的工具和框架，后续这些工具会慢慢开源出来。大家熟知的工具中，比如：代码覆盖率的gcov、BullseyeCoverage（支持逻辑判断的覆盖率统计），代码扫描工具pclint，内存泄露检查工具Valgrind，单元测试工具GTest，如果测试移动产品，MTC会是一个好选择
在工作中会遇到各种各样的bug或缺陷，能否分享1-2个？
杨进：在测试分布式系统中，曾经遇到过在同一个目录下出现两个同名文件的情况，导致系统直接crash掉了，这个bug让我觉得一切皆有可能。监控发现过工程师在进行换库导致流量下降的问题，这个case让我明白bug不仅来自程序和数据，也来自每个可能对线上造成影响的环节。