专家眼中的QA、敏捷测试(3)

　　公直：开源意味着更多可以利用的资源，特别是在测试工具上，开源也是一种开放的心态。测试的开放性，在于比较坦诚地把自己在怎样的场景下如何去做测试给大家做个介绍。非常典型的就是Google，在James的带领下，有一系列的博客、文章、工具在介绍他们的测试，介绍他们测试中遇到的问题已经他们是怎么解决的。非常期望各个公司，无论大小，测试做的程度，都可以把自己的测试通过微博、博客、文章、公开演讲等形式公布出来，毕竟这一部分不太涉及太多的商业机密或者核心技术。

　　杨进：测试的开放性，或者说基于某种特性测试的开放性是未来发展的趋势，原因是互联网的创业越来越依托一些基础的平台，比如iOS、Android，而就一个公司内部而言，云的广泛应用也使得不同产品基于一个相同的基础，由于有了共同的基础，这些都表征出测试也会慢慢走向开放，从部门走向公司，从公司内走向开源。一个好的开放性测试框架，是依托于具体测试资源，以满足具体某种测试需求而诞生的。这种测试框架因为和用户的某些需求绑定因而生存能力很强，并且也能很好的一站式完成用户的需求。

　　InfoQ：我们把测试当成了质量保证的主要手段，当质量低下时，或者为了达到高质量时，一般的选择都是加大测试的工作量。您怎么看?

　　徐毅：临时抱佛脚，没用。就算真要加大，同时也得加大开发的工作量，找出来的bug没人修复的话，质量是不会提高的，只不过是我们更加清楚自己的产品质量很烂而已。

　　公直：测试工程师做的测试活动一般都被称之为是“检测”，与之对应的开发工程师做的测试都是在“预防”，质量高低可以通过测试“检测”出来，但测试永远无法提升产品质量。所以，为了达到高质量，可以做更多的测试，加大测试工作量来发现产品的缺陷并修复，但对于质量，这都是“事后”，是一种下策，不是不可以。更好的办法，是测试前移，让开发来做单元测试、简单的功能测试，在这个过程中会发现大量的问题并自行修复，测试更过地关注在用户使用上，这样高质量会更容易达到一些。

　　杨进：质量的主体其实是Dev，试想QA完成某个被测对象的测试，它最核心的价值是什么?发现bug 或是证明产品能满足具体应用的需求?我选择后者，因而如何让Dev开发出质量更高的代码是每个产品质量可控的测试团队首先考虑的事情。当然如果当前质量低下的时候，一个比较快速见效的方法就是投入更多的测试，但是这不能是唯一手段，必须有人走到开发的阶段，从上游逐步开始改善代码的质量和可测试性，否则这就是一个死循环。更多的低效投入，更多的测试和debug成本，这足以压坏这个项目的所有角色，而不仅仅是QA。

　　InfoQ：工作中推荐的测试框架?使用的范畴?

　　徐毅：我推荐使用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会是一个好选择

　　InfoQ：在工作中会遇到各种各样的bug或缺陷，能否分享1-2个?

　　杨进：在测试分布式系统中，曾经遇到过在同一个目录下出现两个同名文件的情况，导致系统直接crash掉了，这个bug让我觉得一切皆有可能。监控发现过工程师在进行换库导致流量下降的问题，这个case让我明白bug不仅来自程序和数据，也来自每个可能对线上造成影响的环节

原文转自：http://www.ltesting.net