敏捷 测试是否写 测试用例 ?答案多种化如果是你 , 你会选用写还是不用写呢 ? 软件测试 时代 风起云涌 , 问题虽小 , 意义却大 , 让大家一起 学习 一起" name="description" />

敏捷测试是否写测试用例?

发表于:2009-04-10来源:作者:点击数: 标签:
MI LY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'"> 敏捷 测试是否写 测试用例 ?答案多种化如果是你 , 你会选用写还是不用写呢 ? 软件测试 时代 风起云涌 , 问题虽小 , 意义却大 , 让大家一起 学习 一起

MILY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">敏捷测试是否写测试用例?答案多种化如果是你,你会选用写还是不用写呢?

软件测试时代风起云涌,问题虽小,意义却大,让大家一起学习一起探讨!点击问题参与辩题

经过大家的水深火热的探讨答案出来了,但是各有各的想法各有各的不同,但我想他们的所想和所论对于大家都是有帮助的,大家可以看一下这个讨论题,希望在技术上能帮到大家一些.以下来测试时代论坛上的版主和会员们的部分经典回答。

 

LoveTT : 我觉得敏捷测试不需要写测试用例;
所谓敏捷,就是要快准狠,快速的找到系统中存在的问题,高效率的完成测试任务!
谁来跟我辩论???

傲气凌云 : 我认为需要写,因为所有的用例都是人类靠思维来编写的,不是凭空出现的。就算是敏捷性测试,也是需要记录的。

 

tigerbbs : 在敏捷开发中,测试管理者不可能像传统的项目测试一样制定详细的测试计划,那怎样执行测试呢?以下是我总结的一些琐碎经验: 敏捷开发中整个团队都是测试人员,一起需要对产品质量负责,测试管理人员需要指引大家共同测试,需要发动起大家一起执行测试,而不仅仅是测试人员的事情,这同时也要求整个团队中每个成员对自己的产品了如指掌,测试人员需要共同参与产品的设计和需求分析,在敏捷开发中需求在不断变化,你不可能等着完整的需求文档进行测试需求分析,当产品定义和需求不断的细化时,测试分析也要不断的细化,我很喜欢让测试人员去绘制业务流程图,以及整理功能列表进行测试分析,因为在绘制业务流程图中你可以发现很多的逻辑问题,和产品定义问题,可以即时的和产品定义人员、需求人员进行沟通,立马改进产品设计,敏捷测试中,根据业务流程图或测试分析图书写主要测试用例就行了,你根本就没有时间能面面俱到去维护那么的测试用例,更何况需求和产品定义一直在变化一定要自动化测试,自动化测试脚本中要写好注释,这是测试用例的体现,也便于读取在测试之前制定好测试方案,但测试执行的时间很难控制,一定要熟知数据库

LoveTT : 楼上的傲气凌云 有点狡辩了,混淆视听,人类的精髓很多,马克思主义毛泽东思想,都是人类的精华,但是这些老前辈都还说,具体问题具体分析呢,而你一概而论,我觉得站不住脚!我觉得阁下还是好好看看什么是敏捷开发,和敏捷测试再来发表见解吧!否则贻笑大方就不好了!

test110 : 肯定得写哈,那是测试的依据。  

敏捷宣言:


  个体和交互比过程和工具更有价值;


  能工作的软件比全面的文档更有价值;


  顾客的协作比合同谈判更有价值;


  及时响应变更比遵循计划更有价值。


  并非每个企业都能严格按敏捷的相关开发方法进行项目管理,例如测试驱动、XPSCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓,我认为很多方法、很多地方都可以应用敏捷的思想,实现敏捷的管理。


  测试用例的设计是其中一项。


  测试用例的粒度


  测试用例可以写得很简单,也可以写得很复杂。最简单的测试用例是测试的纲要,仅仅指出要测试的内容,如探索性测试(Exploratory Testing)中的测试设计,仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样,会指定输入的每项数据,期待的结果及检验的方法,具体到界面元素的操作步骤,指定测试的方法和工具等等。


  测试用例写得过于复杂或过于详细,会带来两个问题:一个是效率问题,一个是维护成本问题。另外,测试用例设计得过于详细,留给测试执行人员的思考空间就比较少,容易限制测试人员的思维。


  测试用例写得过于简单,则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行设计,只是把需要测试的功能模块记录下来而已,它的作用仅仅是在测试过程中作为一个简单的测试计划,提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求,检验需求,并把对软件系统的测试方法的思路记录下来,以便指导将来的测试。


  大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键,也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。


  软件是开发人员需要去努力实现敏捷化的对象,而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用能工作的软件比全面的文档更有价值这一敏捷原则,则关键是考虑怎样使设计出来的测试用例是能有效工作的。


  基于需求的测试用例设计


  基于需求的用例场景来设计测试用例是最直接有效的方法,因为它直接覆盖了需求,而需求是软件的根本,验证对需求的覆盖是软件测试的根本目的。


  要把测试用例当成的文档(Effective Software Testing : 50 Specific Ways to Improve Your Testing – Elfriede Dustin),因为需求是的、善变的。因此在设计测试用例方面应该把敏捷的及时响应变更比遵循计划更有价值这一原则。


  不要认为测试用例的设计是一个阶段,测试用例的设计也需要迭代,在软件开发的不同的阶段都要回来重新审视和完善测试用例。


  测试用例的评价


  测试用例设计出来了,质量如何,如何提高测试用例设计的质量?就像软件产品需要通过各种手段来保证质量一样,测试用例的质量保证也需要综合使用各种手段和方法。


  测试用例的检查可以有多种方式,但是最敏捷的应当属临时的同行评审。我认为同行评审,尤其是临时的同行评审,应该演变成类似结对编程一样的方式。从而体现敏捷的个体和交互比过程和工具更有价值,要强调测试用例设计者之间的思想碰撞,通过讨论、协作来完成测试用例的设计,原因很简单,测试用例的目的是尽可能全面地覆盖需求,而测试人员总会存在某方面的思维缺陷,一个人的思维总是存在局限性。因此需要一起设计测试用例。


  除了同行评审,还应该尽量引入用户参与到测试用例的设计中来,让他们参与评审,从而体现敏捷的顾客的协作比合同谈判更有价值这一原则。这里顾客的含义比较广泛,关键在于你怎样定义测试,如果测试是对产品的批判,则顾客应该指最终用户或顾客代表(在内部可以是市场人员或领域专家);如果测试是指对开发提供帮助和支持,那么顾客显然就是程序员了。


  因此,参与到测试用例设计和评审中来的人除了测试人员自己和管理层外,还应该包括最终用户或顾客代表,还有开发人员。


  测试用例数据生成的自动化


  在测试用例设计方面最有希望实现自动化的,要当属测试用例数据生成的自动化了。因为设计方面的自动化在可想象的将来估计都很难实现,但是数据则不同,数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工作。


  很多时候,测试用例的输入参数有不同的类型、有不同的取值范围,我们需要得到测试用例的输入参数的不同组合,以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不可思议地广泛,我们又需要科学地筛选出一些有代表性的数据,以便减轻测试的工作量。在这方面可利用正交表设计数据或成对组合法设计数据。


  可利用一些工具,例如TConfigPICT等来产生这些数据。


  在性能测试容量测试方面,除了设计好测试用例考虑如何测试外,还要准备好大量的数据。大量数据的准备可以使用多种方式:编程生成、SQL语句生成(基于数据库的数据)、利用工具生成。


  工具未必能生成所有满足要求的数据,但是却是最快速的,编程能生成所有需要的数据,但是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具,例如DataFactory等。

测试时代原创文章,转载请注明出处,否则追究相关法律责任

 

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