软件敏捷测试是否写测试用例

软件敏捷测试是否写测试用例

敏捷测试是否写测试用例？答案多种化如果是你，你会选用写还是不用写呢？
　　软件测试时代风起云涌，问题虽小，意义却大，让大家一起学习一起探讨！
　　经过大家的水深火热的探讨答案出来了，但是各有各的想法各有各的不同，但我想他们的所想和所论对于大家都是有帮助的，大家可以看一下这个讨论题，希望在技术上能帮到大家一些。
　　LoveTT ： 我觉得敏捷测试不需要写测试用例；
　　所谓敏捷，就是要快准狠，快速的找到系统中存在的问题，高效率的完成测试任务！
　　谁来跟我辩论？
　　傲气凌云 ： 我认为需要写，因为所有的用例都是人类靠思维来编写的，不是凭空出现的。就算是敏捷性测试，也是需要记录的。
　　tigerbbs ： 在敏捷开发中，测试管理者不可能像传统的项目测试一样制定详细的测试计划，那怎样执行测试呢？以下是我总结的一些琐碎经验： 在敏捷开发中整个团队都是测试人员，一起需要对产品质量负责，测试管理人员需要指引大家共同测试，需要发动起大家一起执行测试，而不仅仅是测试人员的事情，这同时也要求整个团队中每个成员对自己的产品了如指掌，测试人员需要共同参与产品的设计和需求分析，在敏捷开发中需求在不断变化，你不可能等着完整的需求文档进行测试需求分析，当产品定义和需求不断的细化时，测试分析也要不断的细化，我很喜欢让测试人员去绘制业务流程图，以及整理功能列表进行测试分析，因为在绘制业务流程图中你可以发现很多的逻辑问题，和产品定义问题，可以即时的和产品定义人员、需求人员进行沟通，立马改进产品设计，敏捷测试中，根据业务流程图或测试分析图书写主要测试用例就行了，你根本就没有时间能面面俱到去维护那么的测试用例，更何况需求和产品定义一直在变化一定要自动化测试，自动化测试脚本中要写好注释，这是测试用例的体现，也便于读取在测试之前制定好测试方案，但测试执行的时间很难控制，一定要熟知数据库。
　　LoveTT ： 楼上的傲气凌云 有点狡辩了，混淆视听，人类的精髓很多，马克思主义毛泽东思想，都是人类的精华，但是这些老前辈都还说，具体问题具体分析呢，而你一概而论，我觉得站不住脚！我觉得阁下还是好好看看什么是敏捷开发，和敏捷测试再来发表见解吧！否则贻笑大方就不好了！
　　test110 ： 肯定得写哈，那是测试的依据。
　　敏捷宣言：
　　个体和交互比过程和工具更有价值；
　　能工作的软件比全面的文档更有价值；
　　顾客的协作比合同谈判更有价值；
　　及时响应变更比遵循计划更有价值。
　　并非每个企业都能严格按敏捷的相关开发方法进行项目管理，例如测试驱动、XP、SCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓，我认为很多方法、很多地方都可以应用敏捷的思想，实现敏捷的管理。
　　测试用例的设计是其中一项。
　　测试用例的粒度
　　测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试（Exploratory Testing）中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等等。
　　测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
　　测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
　　大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。
　　软件是开发人员需要去努力实现敏捷化的对象，而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则，则关键是考虑怎样使设计出来的测试用例是能有效工作的。
　　基于需求的测试用例设计
　　基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。
　　要把测试用例当成“活”的文档（Effective Software Testing ： 50 Specific Ways to Improve Your Testing – Elfriede Dustin），因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。
　　不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。

测试用例的评价
　　测试用例设计出来了，质量如何，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。
　　测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。我认为同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。
　　除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让他们参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于你怎样定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是指对开发提供帮助和支持，那么顾客显然就是程序员了。
　　因此，参与到测试用例设计和评审中来的人除了测试人员自己和管理层外，还应该包括最终用户或顾客代表，还有开发人员。
　　测试用例数据生成的自动化
　　在测试用例设计方面最有希望实现自动化的，要当属测试用例数据生成的自动化了。因为设计方面的自动化在可想象的将来估计都很难实现，但是数据则不同，数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工作。
　　很多时候，测试用例的输入参数有不同的类型、有不同的取值范围，我们需要得到测试用例的输入参数的不同组合，以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不可思议地广泛，我们又需要科学地筛选出一些有代表性的数据，以便减轻测试的工作量。在这方面可利用正交表设计数据或成对组合法设计数据。
　　可利用一些工具，例如TConfig、PICT等来产生这些数据。
　　在性能测试、容量测试方面，除了设计好测试用例考虑如何测试外，还要准备好大量的数据。大量数据的准备可以使用多种方式：编程生成、SQL语句生成（基于数据库的数据）、利用工具生成。
　　工具未必能生成所有满足要求的数据，但是却是最快速的，编程能生成所有需要的数据，但是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具，例如DataFactory等。
　　seanhe ： 先抛观点：需要写测试用例
　　先看测试用例是什么，也就是我们打算进行的测试执行的具体内容
　　测试用例可以分级别：如大纲型、方案型、具体操作数据型，但是根本一点就是要使测试过程有序的进行，尽量少做无必要的重复。
　　敏捷宣言是什么？拥抱变化
　　拥抱变化不代表着杂乱无章，代码即文档，不代表着代码没有注释，所有人都靠代码去看逻辑。
　　敏捷下测试是需要规划的，用例是需要书写的，但是书写的用例并不应该是我们通常意义上非常详尽的测试用例，而可能演变成单元测试框架或者功能自动测试框架，或者测试大纲。
　　总之，测试过程是需要规划的，在有效规划的前提下，尽量少的做无用工作
　　LoveTT ： 楼上的Test110写了很多关于测试用例设计的东西，写道粒度问题！我不知道这些你是从哪里抄来的，但是我觉得用例这样写没有问题，但是敏捷测试作为一种特殊的测试类型如”tigerbbs“所说 因为敏捷开发和测试的快捷性和多变性，导致测试的设计变得困难，或者根本就没办法实现”你根本就没有时间能面面俱到去维护那么的测试用例，“正如文章中提到，所以我觉得楼上的论据站不住脚，如果说一般的测试类型，应该没有问题的！
　　魅力彩虹 ： 我认为测试用例是一定要的，没有用例怎样做到快和准？请问LOVETT一个系统中你能记住那里测过那里没有测过？等到新的版本出来，恐怕就会乱套了吧，何来快准狠？敏捷有从何体现？
　　test110 ： CASE也有简单和复杂呀~~`针对不同的项目也可以具体考虑的，但是肯定是必须写的
　　LoveTT ： 楼上的说道用例设计过程中的跟踪，说道那些是测试了那些是没有测试，这个我们完全可以通过功能点，或者流程图等跟踪方式进行跟踪，只要我所有的需求被覆盖被测试，就可以了！
　　shinnoshi ： 敏捷测试需要写测试用例，既然是敏捷测试，就应有与其相衬的敏捷测试用例。
　　敏捷测试同样需要合理的分析，快速、准确并不应建立在毫无条理的测试中。敏捷不是抛弃所有只注重效率。
　　test110 ： 其实我们在这里说的都是理论的，老大弄个模拟环境吧 我们实际做下就得了的 我很现实的，实践才是真知
　　LoveTT ： 楼上的又在教条主义，和本本主义，你为什么说测试必须写测试用例呢！
　　另外敏捷测试作为一种快速的测试方式，我们没有必要把时间花费到用例设计的过程中，但是我们当然需要设计，但设计的不是测试用例，而是细化的需求！
　　test110 ： 设计case都是测试流程中的一部分的，我们平时测试项目也是按照流程去测试的，也就是说流程制约着我们去测试的，如果我们把测试流程做得很细化了的，那我们的测试就是很精确的，我们得一步一步的走，设计case必须是测试流程中的一部分
　　实际还有一个问题的，就是时间！我们在前期就把时间放在case的设计上的，到我们实际测试的时候就会节约很多时间的；如果你一边测试一边在自己大脑中设计case肯定会浪费时间的，而且还会造成自己和项目组内的人一种紧张的气氛。 大家可以对比下的，case在前期设计和在测试过程中设计，那个更节约时间！那个 效率更高的
　　pi_pi ： 个人觉得不管是为了告诉领导你做了那些东东，还是自己记录分析自己的测试思路和策略也好，暂且不管用例的简易复杂程度有多少，这个用例肯定是需要写的。
　　魅力彩虹 ： 没有用例的测试是不可行的，首先你的测试是不是有效的验证了需求呢？要有一个测试的执行步骤和执行数据，通过评审之后才能够成为可行的测试。否则只是个人进行的测试怎样判定是系统真的有缺陷还是测试的过程或测试的理解存在问题？总不能等到发现问题后再来讨论测试步骤及测试数据你是否合理吧？即使可以，又怎样能够正确的描述出当时的操作步骤呢？
　　angel0527 ： 在对一个系统进行测试之前，都会去找测试点，再从测试点整理出测试用例。只是所整理用户的简单复杂程度不同。
　　如果不去整理测试用例，就没有办法明确是否将该进行测试的点都已经测试完。有可能会做许多重复的工作。这样就谈不上敏捷了。
　　shinnoshi ： 如果说没有必要写测试用例，其实最终想说的就是时间，写测试用例需要时间，需要大量的时间。
　　其实不然，清晰的了解需求，用简洁的语言，可以是符号语言，从代码级出发，与开发同步，直到最终的组件完成。如果说你在开发人员写代码的时候都无法利用，那你所谓的时间真的很不够。随着开发的继续，反复的回归测试，如若不是记忆力超群，测试已经达到什么程度，你能给出一个准确的答案吗？
　　LoveTT ： 请16楼的朋友注意，你说的一你们平常的工作，第一点，你们做的不是敏捷开发，当然你们也不是敏捷测试，你们按部就班没有问题，但是我们今天的辩题是”敏捷测试“作为现在一个新的概念，或者一种新的方法，正在为大家研究，所以你的经验主义不值得一提
　　appoint ： 测试肯定要用到测试用例。敏捷开发是靠测试来驱动开发，测试通过了开发就完成了。所以支持正方观点
　　LoveTT ： 一看你就是科班出身，是做质量管理的吧！
　　什么事情都看得这个规矩，我觉得规矩没有错，但是规矩制约了发展就是错误了，你所谓的评审，审核，在一般的测试过程中是没有问题的，而在敏捷测试过程中，他的测试团队覆盖面很广，可以快速的识别问题并且修改问题，要是等待你的评审恐怕黄花菜都凉了！
　　魅力彩虹 ： 楼上LOVETT的观点我不同意，你老说这个教条，那个是平时的工作，不是做敏捷测试。那请问一下你做过敏捷测试吗？你的观点依据又是什么呢？
　　LoveTT ： 根据我这个测试新手孜孜不倦的学习，倒是接触过一些，记得前几天IBM刚开了一个什么大会好像这个论坛中也有报道，我演戏了他的整个敏捷开发的过程，以及他的质量控制方法，所以我以此为依据说出上述论断，大家要是有争议，可以看IBM关于敏捷开发的文章
　　魅力彩虹 ： 评审用例不仅是规矩的问题，用例不去评审就盲目的执行，怎样保证执行的正确性？发现了BUG怎样反应给开发人员？有些用例你认为覆盖了需求，你有怎样知道自己执行的用例真正体现了需求的定义？如果根据个人临时在大脑中想到的用例来测试系统，测试的有效性和以体现
　　LoveTT ： 《Agile Testing - What is it？ Can it work？》和《Agile Testing Challenges》
　　大家可以看一下这个两本书！
　　所以我觉得敏捷测试有没有设计测试用例，要不要评审，这个是两个概念，楼上的跑题了
　　傲气凌云 ： 但是在你工作中，你可以这么做吗？即便是公司就你一个测试人员，也是需要编写测试用例的。同样，也就伴随着评审等一系列活动。
　　shinnoshi ： 敏捷是少文档，少流程，多沟通，使开发与测试更加紧密。不是不需要文档，不需要流程，不需要测试用例。
　　请问你提及的测试通过，开发完毕是用什么来衡量的？
　　ash ： 敏捷的不是反文档的。
　　测试用例最终生成也会以文档数据方式存在，并且是显性知识，是可以传播、共享和继承的。（不清楚看下面解释）
　　我们应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价（特别是更新同步文档的代价）。
　　因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。
　　new.bug ： 个人觉得，敏捷测试只是相对而言的，比如让你测试一个比较复杂的系统，功能很多，那你说不用测试用例怎么比较有条理的进行测试？

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