总之，测试过程是需要规划的，在有效规划的前提下，尽量少的做无用工作

　　LoveTT : 楼上的Test110写了很多关于测试用例设计的东西，写道粒度问题!我不知道这些你是从哪里抄来的，但是我觉得用例这样写没有问题，但是敏捷测试作为一种特殊的测试类型如”tigerbbs“所说 因为敏捷开发和测试的快捷性和多变性，导致测试的设计变得困难，或者根本就没办法实现”你根本就没有时间能面面俱到去维护那么的测试用例，“正如文章中提到，所以我觉得楼上的论据站不住脚，如果说一般的测试类型，应该没有问题的!

　　魅力彩虹 : 我认为测试用例是一定要的，没有用例怎样做到快和准?请问LOVETT一个系统中你能记住那里测过那里没有测过?等到新的版本出来，恐怕就会乱套了吧，何来快准狠?敏捷有从何体现?

　　test110 : CASE也有简单和复杂呀~~`针对不同的项目也可以具体考虑的，但是肯定是必须写的

　　LoveTT : 楼上的说道用例设计过程中的跟踪，说道那些是测试了那些是没有测试，这个我们完全可以通过功能点，或者流程图等跟踪方式进行跟踪，只要我所有的需求被覆盖被测试，就可以了!

　　shinnoshi : 敏捷测试需要写测试用例，既然是敏捷测试，就应有与其相衬的敏捷测试用例。

　　敏捷测试同样需要合理的分析，快速、准确并不应建立在毫无条理的测试中。敏捷不是抛弃所有只注重效率。

　　test110 : 其实我们在这里说的都是理论的，老大弄个模拟环境吧 我们实际做下就得了的 我很现实的，实践才是真知

　　LoveTT : 楼上的又在教条主义，和本本主义，你为什么说测试必须写测试用例呢!

　　另外敏捷测试作为一种快速的测试方式，我们没有必要把时间花费到用例设计的过程中，但是我们当然需要设计，但设计的不是测试用例，而是细化的需求!

　　test110 : 设计case都是测试流程中的一部分的，我们平时测试项目也是按照流程去测试的，也就是说流程制约着我们去测试的，如果我们把测试流程做得很细化了的，那我们的测试就是很精确的，我们得一步一步的走，设计case必须是测试流程中的一部分

　　实际还有一个问题的，就是时间!我们在前期就把时间放在case的设计上的，到我们实际测试的时候就会节约很多时间的;如果你一边测试一边在自己大脑中设计case肯定会浪费时间的，而且还会造成自己和项目组内的人一种紧张的气氛。 大家可以对比下的，case在前期设计和在测试过程中设计，那个更节约时间!那个 效率更高的

　　pi_pi : 个人觉得不管是为了告诉领导你做了那些东东，还是自己记录分析自己的测试思路和策略也好，暂且不管用例的简易复杂程度有多少，这个用例肯定是需要写的。

　　魅力彩虹 : 没有用例的测试是不可行的，首先你的测试是不是有效的验证了需求呢?要有一个测试的执行步骤和执行数据，通过评审之后才能够成为可行的测试。否则只是个人进行的测试怎样判定是系统真的有缺陷还是测试的过程或测试的理解存在问题?总不能等到发现问题后再来讨论测试步骤及测试数据你是否合理吧?即使可以，又怎样能够正确的描述出当时的操作步骤呢?

　　angel0527 : 在对一个系统进行测试之前，都会去找测试点，再从测试点整理出测试用例。只是所整理用户的简单复杂程度不同。

　　如果不去整理测试用例，就没有办法明确是否将该进行测试的点都已经测试完。有可能会做许多重复的工作。这样就谈不上敏捷了。

　　shinnoshi : 如果说没有必要写测试用例，其实最终想说的就是时间，写测试用例需要时间，需要大量的时间。

　　其实不然，清晰的了解需求，用简洁的语言，可以是符号语言，从代码级出发，与开发同步，直到最终的组件完成。如果说你在开发人员写代码的时候都无法利用，那你所谓的时间真的很不够。随着开发的继续，反复的回归测试，如若不是记忆力超群，测试已经达到什么程度，你能给出一个准确的答案吗?

　　LoveTT : 请16楼的朋友注意，你说的一你们平常的工作，第一点，你们做的不是敏捷开发，当然你们也不是敏捷测试，你们按部就班没有问题，但是我们今天的辩题是”敏捷测试“作为现在一个新的概念，或者一种新的方法，正在为大家研究，所以你的经验主义不值得一提

　　appoint : 测试肯定要用到测试用例。敏捷开发是靠测试来驱动开发，测试通过了开发就完成了。所以支持正方观点

　　LoveTT : to魅力彩虹

　　一看你就是科班出身，是做质量管理的吧!

　　什么事情都看得这个规矩，我觉得规矩没有错，但是规矩制约了发展就是错误了，你所谓的评审，审核，在一般的测试过程中是没有问题的，而在敏捷测试过程中，他的测试团队覆盖面很广，可以快速的识别问题并且修改问题，要是等待你的评审恐怕黄花菜都凉了!

　　魅力彩虹 : 楼上LOVETT的观点我不同意，你老说这个教条，那个是平时的工作，不是做敏捷测试。那请问一下你做过敏捷测试吗?你的观点依据又是什么呢?

　　LoveTT : 根据我这个测试新手孜孜不倦的学习，倒是接触过一些，记得前几天IBM刚开了一个什么大会好像这个论坛中也有报道，我演戏了他的整个敏捷开发的过程，以及他的质量控制方法，所以我以此为依据说出上述论断，大家要是有争议，可以看IBM关于敏捷开发的文章

　　魅力彩虹 : TO LOVETT

　　评审用例不仅是规矩的问题，用例不去评审就盲目的执行，怎样保证执行的正确性?发现了BUG怎样反应给开发人员?有些用例你认为覆盖了需求，你有怎样知道自己执行的用例真正体现了需求的定义?如果根据个人临时在大脑中想到的用例来测试系统，测试的有效性和以体现

　　LoveTT : 《Agile Testing - What is it? Can it work?》和《Agile Testing Challenges》

　　大家可以看一下这个两本书!

　　所以我觉得敏捷测试有没有设计测试用例，要不要评审，这个是两个概念，楼上的跑题了

　　大家可以看一下，以前本论坛的一个版主的博客关于敏捷测试的文章：

　　http://blog.csdn.net/Testing_is_believing/category/333219.aspx

　　傲气凌云 : 34# LoveTT

　　但是在你工作中，你可以这么做吗?即便是公司就你一个测试人员，也是需要编写测试用例的。同样，也就伴随着评审等一系列活动。

　　shinnoshi : 敏捷是少文档，少流程，多沟通，使开发与测试更加紧密。不是不需要文档，不需要流程，不需要测试用例。

　　请问你提及的测试通过，开发完毕是用什么来衡量的?

　　ash : 敏捷的不是反文档的。

　　测试用例最终生成也会以文档数据方式存在，并且是显性知识，是可以传播、共享和继承的。(不清楚看下面解释)

　　我们应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价(特别是更新同步文档的代价)。

　　因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的非常好的效率。

　　new.bug : 个人觉得，敏捷测试只是相对而言的，比如让你测试一个比较复杂的系统，功能很多，那你说不用测试用例怎么比较有条理的进行测试?