1、题目中缺少两个关键属性：
项目的规模（包括需求变更规模）和测试资源
2、浅析项目规模和测试资源的影响
这个题目最大的争议点就是在这里，如果这两个属性可以确定，相信大家的思路会清晰很多。下面偶只分两类进行简单的分析：
A、
项目规模大（需求变更规模大），测试资源少：按照
CMMI 5中测试用例的编写标准来说，限定6个月的时间。测试团队需要完成测试策略/计划的拟定和评审、测试用例的设计/评审/修改、变更需求的评审/修改、新需求测试用例的设计/评审/修改...
显而易见，剩余还有多少时间完成测试执行的跟踪和改进？即使前期能勉强跟进，偶相信在后期也只能疲于奔命，敷衍了事，什么“测试驱动开发”也只是梦中花而已。
国内很多企业都是这样的情况，相信N多测试同仁对此是深有体会。
B、
项目规模小（需求变更规模小），测试资源多：人多好办事，只要
Test Manger不是个草包，将测试
工作进行有条理的细分，责任到人，在测试准备阶段选择有利于修改的测试流程（包括简易需求和测试资源变更流程以及便于变更的测试用例模板等等），在测试执行阶段，注意需求收集已经各部门以及客户之间的信息交流，还是很容易搞定的。
3、浅析正方观点的风险：
A、如正方所说：“先把大概的用例写出来，测试的过程中，不停的添加用例。最后测试完了，用例也出来了。。”。
什么叫大概的用例?
用例最基本的要求就是任何测试人员都可以操作,敢问你如果写出这样缺斤少两的用例，当你临时有
其他更重要的任务，然后把这块测试工作交付给其他人来做，能够保证别人肯定能看明白？
B、又如正方提出的：用例是用来保障测试的质量，以及对测试执行的指引。
测试用例是唯一的保障产品/测试质量的手段？没有测试用例就无法指导和跟踪测试执行了？
当然不是，这里偶引用一个只有部分公司在用的一个概念“测试规程（test procedure）”。它是个提供详细的测试用例执行指令的文档。测试规程更注重测试的流程、方法等比较泛的内容，以方便对测试用列的编写有一个整体的概念和把握。不同的公司规范、要求和详尽程度可能不同。
测试规程与测试用例的区别：理想化的测试用例确实需要很多测试数据集合，但是现实中对某一软件进行测试时，由于涉及的面太广，无法一一列举出所有数据，所以要根据公司的规范来做相应的调整。所以，测试规程的文档编辑量较轻，但是只适合熟练的测试人员执行，而测试用例的执行者可以使任何人。
楼上很多同仁谈到的根据实际情况写简化用列的做法实际就是将设计测试用例变为设计测试规程，然后以测试规程来指导测试执行，提供测试质量（比如测试覆盖率）的评估。但是楼上的同仁没有对简化测试用例提出标准？如果一个测试团队里有3、4个简化标准，大家的测试用例简化的“度”都不一致，岂不乱套？
C、2A中描述的项目情况，仍采用设计常规的测试用例的方法，那么只能有两种结果：a、披着“测试用例”的外套，却是到处缺胳膊少腿，敷衍了事，难以达到测试用例的覆盖标准；b、忙于测试用例的编写，无法在测试执行中完成测试的跟踪与改进，每天都疲于奔命，最终完成N个项目后，测试团队的水平仍然停滞不前，经常受到项目组的“鄙视”。
4、偶的观点：敏捷性测试团队才是王道，项目不同测试流程不同。针对这个项目，选择测试规程代替测试用例是明智之举。下面偶只针对与设计测试规程有关的部分提出一个简单的方案。
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小结：综上所说的问题可以使用测试规程代替测试用例来解决。
