不建议去做什么测试需求，理由有如下两点：
1、如果我们测试人员增加所谓的测试需求，测试需求是否需要相关人员评审，
    如果没有的话，谁来保证测试需求的正确性？如果需要无疑增加了软件开发成本
    而且会在各相关团体之间增加沟通confusion，估计会有很多问题是需要澄清是哪个需求
2、现代软件需求可以说每天在变，软件的需求有change request flow进行管理，
    测试需求呢？

需求分析是必需的，但是本人觉得所谓的测试需求是完全错误的提法，
是误人子弟的虚假专业概念

个人观点:
QA可以参预需求分析,设计. 对于已经成行的MRD/PRD (market request document or customer request document/production request document), QA一定要看的, 但这是并没有形成最后的spec(设计文档), QA只能提出相关建议,如果能看出问题,提出问题更好, 这个阶段不需要做测试.
对已经形成的正规的spec, QA是需要全面看的, 需要理解的.如果有问题及时提出,要求修正,这也就是测试spec了.
note: 质量保证是贯穿软件开发整个过程.

[ 本帖最后由 耶罗 于 2006-4-25 09:27 编辑 ]

sorry, 这里所说的测试需求是个名词，不是对需求进行测试

我不反对对需求进行静态测试

只是对某些人的对于要把软件需求转化成测试需求感到迷惑

个人认为：
1.和开发人员沟通是必要的，竟然要对软件需求进行测试，如何体现测试人员对软件需求的理解呢
2.软件测试与软件开发都是软件工程的组成部分，竟然软件开发由需求—>设计，是一条成熟的流程，这个无可厚非，软件测试引入这种做法会有什么不好呢
3.软件测试应该是一个可维护的过程，不根据测试需求，如何把握测试用例设计如何来保证其有效性呢
4.当软件需求变更以后，测试人员也必须变更他们的测试对象、属性值；
5.至于测试需求的管理，版本迭代这种方式应该也是可行的
综上，个人认为测试需求—>测试设计这种方式应该是比较可行的，由于经验有限，是否存在更好的方式，就是一个值得大家一起来讨论的问题了

同意winterson的说法

一般来说不会再单独写测试需求的，就是在写用例的时候，根据某条需求项无法写出需求项，比如需求项里面提到界面而没有给出具体的，测试人员可以提需求需要一个UI界面来进行测试写用例。一般来说会具体针对某个具体的需求项，而不是再单独的写一份测试需求的。

我觉得每个公司都不同，我们公司的QA不参与需求的具体工作，只看流程，而我们测试的流程是先测试需求，为什么要测试需求呢，因为测试用例根据需求写，有些问题要从写测试用例的角度去分析一下，所以写测试用例前要先熟悉需求，同时找出疑问，然后和相关人员沟通！

有比较详细的测试需求对测试人员的工作会起到很大帮助.所以我觉得还是要有需求出现,这样工作会比较明确

process本来就无所谓好坏，好用管用才是硬道理
要不要测试需求还是要看个人和所处的环境

现在我不知道要用什么来知道QA的测试案例？简单的说就是测试Case从何而来？
我的一点浅薄理解是，用测试需求来知道案例的范围，用测试计划以及测试策略来知道测试案例的深度。
但是测试需求的应该这么形成呢？
从软件需求和一些系统的隐性需求来。
在我实际工作中没写过测试需求方面的文档，感觉写出来的案例内容有点乱，不知道是不是这个原因。