我觉得还是要写测试用例的
如果变动的很频繁，甚至1，2天，半天一变的。但变的也大概只会是细节。总的目标不会变。
哪怕是简单的写写，写上测试目的，内容，测试过程，即使很简单很大略的写写。也是要写的。
测试的工作是相对比较繁琐，比较要求细致完善的。
写下来，其实也是为了有个头绪。有个工作的路线。
更新修改原有用例
如果客户经常性变更需求(增加)，那么必须重新添加用例；如果只是在原有基础上更改需求的话，可以不用添加新的用例，只需在原来用例基础上作以修改，这样就产生新的用例了，而且投入的精力，物力，财力也很少。 就我公司的做法，用户验收项目的时候，是要测试用例的，因此不论需求怎么变化，测试用例还是要编写，当然我公司的做法是，项目后期再写用例，这样改动较小。 当然要写，测试用例是写给自己看的，不写自己不就乱了？有必要写用例，用例是用来保障测试的质量
用例是根据需求来设计的，如果需求改变的话，也可以根据改变的需求，跟踪到具体的用例来修改。我觉得用例没必要写太复杂，不过一定要写，而且要与需求相匹配，这样可以防漏测，也防止变更。 没有必要写，耗力．需求三天两头变，自己随机应变． 需要编写 写还是有必要的，关键是怎么写，什么时候写：
首先，我们要搞清楚为什么写用例，依据是什么。我觉得写用例有三个目的：
一个是为了更好的理解需求，只有在写用例的过程中我们测试人员才能深入的理解某些需求。二是为了测试过程中能够更好的方便快捷的进行测试。
三是能够为下个版本的测试提供一些帮助。
如果需求变动很频繁，可以说我们如果一开始就去写用例的话，变一次需求就改一次用例，其实达不到方便快捷的目的。深入理解需求也谈不上，因为需求不停的变，你理解了又变了。。。所以呢，我一般遇到这种项目，都是先会把大概的用例写出来，测试的过程中，不停的添加用例。最后测试完了，用例也出来了。。下次测试忘记了。。还是可以依据这次的用例去给出些指导。
用例是必须的，否则无法保证整个测试过程是否符合需求
必须要写，不写用例，你何以保证你的测试是满足需求的？何必保证你的执行过程是正确的？对于需求经常变的项目，为什么不让需求进入到稍微稳定的阶段再进入用例的编写？需求变更是不可避免的，但是有时候，需求变更的频率是我们可以控制的。
用例天天修改可能会浪费一些时间，但是对于整个项目来说还是有必要的，可以用一种简单的方式来写用例，保证前后可追溯。
测试用例可以是证据
没有测试用例，在一些偶然出现缺陷即不可重现的缺陷，是很难被记录下来的。在向开发人员说明曾出现这个错误的时候，没有证据，没有证据谁相信啊！自己做了事情反而没有得到效果，这样干工作太笨了。 有人力就写，没人力何必写。 有必要写 原帖由 wuyu702 于 2009-2-18 13:57 发表 http://bbs.51testing.com/images/common/back.gif
写还是有必要的，关键是怎么写，什么时候写：
首先，我们要搞清楚为什么写用例，依据是什么。我觉得写用例有三个目的：
一个是为了更好的理解需求，只有在写用例的过程中我们测试人员才能深入的理解某些需求。二是 ...
不错不错． 原帖由 wuyu702 于 2009-2-18 13:57 发表 http://bbs.51testing.com/images/common/back.gif
写还是有必要的，关键是怎么写，什么时候写：
首先，我们要搞清楚为什么写用例，依据是什么。我觉得写用例有三个目的：
一个是为了更好的理解需求，只有在写用例的过程中我们测试人员才能深入的理解某些需求。二是 ...
不错不错 唉，写简单一点。没有规矩，不成方圆。要是你能控制过来，你NX 希望大家都讨论起来．
有必要写测试用例
测试的目的就是尽可能的减少系统的bug，确保软件的质量，好的测试用例是保证测试质量的前提。如果没有测试用例，对于相对比较复杂的功能，尤其是多人同时参与测试的情况下，很可能忽略某些很重要的细节，从而放过了很多bug。严格的讲，不仅需要测试用例，而且测试用例必须经过多人评审，确保其质量才行。需求变动，测试人员拿不到最新的需求，但这不是不写测试用例的借口，相反，应该尽可能的督促相关人员以拿到最新的需求，根据变动及时更新测试用例。:)
敏捷性测试团队才是王道
1、LZ的题目中缺少两个关键属性：项目的规模（包括需求变更规模）和测试资源2、浅析项目规模和测试资源的影响
其实LZ这个题目最大的争议点就是在这里，如果这两个属性可以确定，相信大家的思路会清晰很多。下面偶只分两类进行简单的分析：
A、项目规模大（需求变更规模大），测试资源少：按照CMMI 5中测试用例的编写标准来说，限定6个月的时间。测试团队需要完成测试策略/计划的拟定和评审、测试用例的设计/评审/修改、变更需求的评审/修改、新需求测试用例的设计/评审/修改...
显而易见，剩余还有多少时间完成测试执行的跟踪和改进？即使前期能勉强跟进，偶相信在后期也只能疲于奔命，敷衍了事，什么“测试驱动开发”也只是梦中花而已。
国内很多企业都是这样的情况，相信N多测试同仁对此是深有体会。
B、项目规模小（需求变更规模小），测试资源多：人多好办事，只要Test Manger不是个草包，将测试工作进行有条理的细分，责任到人，在测试准备阶段选择有利于修改的测试流程（包括简易需求和测试资源变更流程以及便于变更的测试用例模板等等），在测试执行阶段，注意需求收集已经各部门以及客户之间的信息交流，还是很容易搞定的。
3、浅析正方观点的风险：
A、如正方wuyu702 所说：“先会把大概的用例写出来，测试的过程中，不停的添加用例。最后测试完了，用例也出来了。。”。
什么叫大概的用例?
用例最基本的要求就是任何测试人员都可以操作,敢问你如果写出这样缺斤少两的用例，当你临时有其他更重要的任务，然后把这块测试工作交付给其他人来做，能够保证别人肯定能看明白？
B、又如正方Okayde、wuyu702、jessies、兆隆8032等提出的：用例是用来保障测试的质量，以及对测试执行的指引。
测试用例是唯一的保障产品/测试质量的手段？没有测试用例就无法指导和跟踪测试执行了？
当然不是，这里偶引用一个只有部分公司在用的一个概念“测试规程（test procedure）”。它是个提供详细的测试用例执行指令的文档。测试规程更注重测试的流程、方法等比较泛的内容，以方便对测试用列的编写有一个整体的概念和把握。不同的公司规范、要求和详尽程度可能不同。
测试规程与测试用例的区别：理想化的测试用例确实需要很多测试数据集合，但是现实中对某一软件进行测试时，由于涉及的面太广，无法一一列举出所有数据，所以要根据公司的规范来做相应的调整。所以，测试规程的文档编辑量较轻，但是只适合熟练的测试人员执行，而测试用例的执行者可以使任何人。
楼上很多同仁谈到的根据实际情况写简化用列的做法实际就是将设计测试用例变为设计测试规程，然后以测试规程来指导测试执行，提供测试质量（比如测试覆盖率）的评估。但是楼上的同仁没有对简化测试用例提出标准？如果一个测试团队里有3、4个简化标准，大家的测试用例简化的“度”都不一致，岂不乱套？
C、2A中描述的项目情况，仍采用设计常规的测试用例的方法，那么只能有两种结果：a、披着“测试用例”的外套，却是到处缺胳膊少腿，敷衍了事，难以达到测试用例的覆盖标准；b、忙于测试用例的编写，无法在测试执行中完成测试的跟踪与改进，每天都疲于奔命，最终完成N个项目后，测试团队的水平仍然停滞不前，经常受到项目组的“鄙视”。
4、偶的观点：敏捷性测试团队才是王道，项目不同测试流程不同。针对LZ的项目，选择测试规程代替测试用例是明智之举。下面偶只针对与设计测试规程有关的部分提出一个简单的方案。
A、前提：测试团队组成基本由熟练测试人员组成（就软件黑盒测试来说，加入团队半年以上的就可以叫做熟练了）。统一规范的测试流程（相信这个只要是稍微正规点的公司都有）PS：此流程只适用于2B的情况，并且可以进行裁减。有些公司是将标准流程做成checklist形式，方便项目组选择。
B、策划：测试负责人根据项目实际情况在测试准备阶段裁减出适用于该项目的测试流程，并进行评审。其中有两点必须说明：测试执行依据采用测试用例还是测试规程或者两者皆用；测试用例（测试规程）设计的标准。
C、变更：满足以上两个条件，如若遇到实际需求被迫变更，则修改相应测试规程，并评审即可。修改测试规程和修改测试用例在工作量上存在很大的区别，偶举一个例子：
为了简单，用例和规程的格式就忽略了，只写具体输入步骤一部分，书写格式也比较随意。
原需求：编辑框A中允许输入最多20个中文
规程的输入步骤：
只输入0~20个中文,点击确定，检查结果。备注：其中0、20必须测试
输入21个中文，检查结果
输入非中文字符，检查结果。备注：包括英文/特殊符号...
混合输入中文与非中文字符，检查结果。备注：中文字符在第一位的情况必须测试
...
测试用例的输入步骤：
不输入任何字符，点击确定，检查结果
输入10个中文字符，点击确定，检查结果
输入20个中文字符 ，点击确定，检查结果
输入21个中文字符，点击确定，检查结果。
....（不写了，N多）
假如修改需求：编辑框A中允许输入最多20个中文或数字
规程的输入步骤：
输入0~21个中文或数字，点击确定，检查结果。备注：数字/中文混合输入、0/20/21位字符输入必须测试。
....
假如换成测试用例，那就只有....慢慢写了~
D、跟踪/评估：其实从4C中的例子可以看出，测试规程是可以对测试质量进行跟踪和评估的。当然还有其他很多测试质量评估方法，比如缺陷分析技术，详细信息请看http://bbs.51testing.com/thread-117496-1-2.html
小结：综上，LZ所说的问题可以使用测试规程代替测试用例来解决。
建立敏捷性测试团队，不“墨守成规”的进行测试活动，才是测试的王道
[ 本帖最后由 Jackc 于 2009-2-19 14:02 编辑 ]
