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

　　其次，ET的目的在于“探索”，也即有一个明确的测试目标，但是目标的细节或是达成目标的步骤尚不清晰，所以需要边走边看，同时间地进行学习、设计、执行、解析的结果，与PDCA循环颇有相似之处。

　　第三要区分开ET和手工测试的关系。“手工测试”所强调的是执行的手段，也即“手工”。而ET主要强调目的，也即“探索”，当然还有就是，执行只不过是ET中的一部分而已，而这一部分，可以借助自动化。例如，修改某个已有自动化测试脚本中的部分测试数据，借助于脚本快速地执行某些操作，而去掉或暂停分析部分的脚本执行，因为此时测试的结果未知，需要依赖人工来判断、分析测试结果。

　　公直：探索式测试最近2年异常火爆，很多人以为是最新出的一个测试技术或者方法。Cem Kaner 在1983年(都快30年了)就提出了。这是一种强调个人自由与责任的测试方法，让独立测试人员可以借由不断的学习来改善测试的规划与测试的执行，而在测试的过程中也会同时改善测试用例从而达到相辅相成的效果。在一淘这边，其实很早就开始使用这种实践方法了，但很多一线的测试人员并不知道自己的做法就是探索式测试，在互联网研发模式下，一般都或多或少地使用敏捷模式，或者其他的土方法，但迭代周期都很短，一个月就要上线。在这样的环境下，文档少，在测试计划制定设计上都不可能完善，一般在测试过程中是用freemind等脑图工具来记录测试执行过程的同时做测试用例的设计，这种方式可以做常规测试的补充。

　　杨进：我很喜欢探索性测试，它让测试工作变得轻松和富有创造力，它能让你无需复杂的测试准备，就直接进入最核心的测试工作，并且不拘泥用什么方法、什么工具，也不用考虑能否能被自动化，只需要关注能否快速的找到bug就行。当然好的探索性测试实际上对工程师的逻辑分析能力和产品整体理解要求很高，这种依赖于个人能力的测试手段，执行的效果也比较难以控制。

　　探索性测试的实践方面，我们之前尝试过多人组队测试，这种方式适用于多人进行的大型项目，大家一起进行探索性测试，bug系统即时显示你在这个版本发现了多少个bug，并且排名，我们每天乐于寻找更多的bug，并且分享找bug的技巧，在这个过程中我们都得到了很多的成就感，并且对产品的理解和测试技巧也大幅提升。现在回想起来也还是一个很有意思的事情。

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

　　徐毅：我认为，敏捷测试(关于敏捷测试的定义、介绍，请参考Lisa Crispin书中的描述)并无法单独的执行，必须在敏捷的环境下，结合开发人员方面的敏捷实践(以及组织结构)齐头并进方可实现。而此时，质量的提升乃是源于软件开发工作整体的改善，很难说一定是测试的功劳。另一方面则在于，测试本来就无法“控制”质量，自然也无法改善质量，因为测试工作本身并不改变那些可以影响质量产生的因素。但敏捷测试的实践对于质量的提升是肯定有影响的。

　　敏捷中对于团队内外参与、交流的追求，能够更容易“do things right”

　　快速地交付和反馈，有助于做到更多地“do right things”

　　完整团队、跨职能团队等实践，团队负责自己的工作方式改进，更容易做到“do things rightly”

　　公直：敏捷测试是一个被过度炒作的概念，和架构师、云计算一起被大家私下称呼“大忽悠”的工具，特别是最近几年。传统上将敏捷测试就是在敏捷研发流程下的测试，例如使用XP、或者scrum的研发流程下的测试活动，怎样在这样的研发背景下做测试，挑战在于如何使用敏捷的流程。另外一种敏捷测试，就是按照敏捷宣言中的几个关键词，“速度快”、“反馈”、“持续”，做的测试。由于敏捷强调的重点，还是在“快”上，无论中文含义的字面解释，“敏”、“捷”其实都是快的意思，这正是自动化程序的特长，机器的运行速度总是比人的操作要快，所以我们一般在敏捷项目中使用了非常多的自动化技术。个人感觉十分使用敏捷测试与质量提升方面没有直接关系。

　　杨进：我理解敏捷测试就是让项目相关的角色全体直接承担项目最终目标，由于都是为最终目标服务，因而角色也变得模糊，并且每个人的工作也需要考虑是否对当前最急迫的事情，这种集中所有角色力量为共同目标前进的开发方式，减少了大家沟通和项目迭代成本，最终很容易得到项目整体效率和质量的提升。由于各角色对目标理解一致，对产品理解都很深入，因而可以更多的把bug消灭在开发的早期，比如单元测试、新功能测试阶段，使得后期的集成和系统测试问题变得更少，尤其是产品最终的效果问题也会减少。

　　InfoQ：开源对测试的影响，如何看待测试的开放性?

　　徐毅：平台、工具、框架在我看来属于比较相同的情况，我就拿我自己的经历来做例子吧。在诺西的时候，我们有使用过一个叫robotframework的测试自动化框架，它最开始是一个和诺西合作的芬兰专家开发出来的，在诺西(当时还叫诺基亚网络)最先开始使用， 而后逐步推广，在此过程中这个框架也在不断地更新、改进、完善。后来在公司之外也有很多的使用者，于是开发者和诺西把这个框架开源出来，也吸引了更多的人加入到这个框架的开发中来，包括衍生工具的开发，这都推动了这个工具的广泛使用和不断完善。诺西作为最主要的支持者，并没有因为开源而受损，反而因为这个开源框架庞大的用户群体和开发者队伍而受益颇多，有更多的人可以分享经验、讨论问题，也有更强大的开发力量提供所需的功能。不过，开源的软件，或者开源的社区相对来说更倾向于Linux的设计理念，也即是更专注于某一个领域、某一块功能，做精，而不像是Windows那样的设计理念，强调易用性、一站式体验。这意味着，企业内要完成所有的测试工具，可能需要和多个开源工具、框架打交道，整体上如何协调使用并不容易，需要培养相关方面的人才。

　　测试开放性，没有特别想法，也没啥体验，只能凭感觉谈谈。个人观点比较悲观或者比较现实。测试就是测自己产品的功能、特性，让别人知道自己的测试，也就是知道了自己产品的细节和特性。出于商业上的考虑，我认为各企业恐怕会较难把最核心部分的东西拿出来公开。不过这个很可能会是一个趋势，即使拿出来的测试用例的范围比较小而已。对于产品也有要求，得要是相对标准化程度比较高的产品，不然拿出来的测试最多别人参考一下，而无法直接使用，也无法反馈改进，意味着拿出来的那一方也无法受益，这样的话这些测试也就等同于是“死亡的文档”(dead documentation)，没有实效。

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