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

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

　　敏捷测试是否写测试用例?答案多种化如果是你，你会选用写还是不用写呢?

　　软件测试时代风起云涌，问题虽小，意义却大，让大家一起学习一起探讨!

　　经过大家的水深火热的探讨答案出来了，但是各有各的想法各有各的不同，但我想他们的所想和所论对于大家都是有帮助的，大家可以看一下这个讨论题，希望在技术上能帮到大家一些。

　　LoveTT ： 我觉得敏捷测试不需要写测试用例;

　　所谓敏捷，就是要快准狠，快速的找到系统中存在的问题，高效率的完成测试任务!

　　谁来跟我辩论?

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

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

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

　　test110 ： 肯定得写哈，那是测试的依据。

　　敏捷宣言：

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

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

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

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

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

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

　　测试用例的粒度

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

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

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

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

原文转自：http://www.uml.org.cn/Test/20112235.asp