您怎么看敏捷测试，执行后会质量有哪些明显的改善？

　　徐毅：我认为，敏捷测试（关于敏捷测试的定义、介绍，请参考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不仅来自程序和数据，也来自每个可能对线上造成影响的环节。