不错，，收藏先，再仔细看看，谢谢了

这个问题需要根据各个项目的时间来确定。
如果该项目的时间必须充裕的话应该严格地按照流程来操作，即
输入条件：Requirement & Function Spec经过评估，并且通过。
执行过程：根据Requirement & Function Spec绘制业务逻辑图，罗列测试点，参照测试点编写测试用例。
输入条件：项目小组相关成员对测试用例进行评估，并且通过。（基本条件是Requirement & Function Spec的100％的覆盖。）

如果项目的时间很紧张，则可以把正规的评估过程改为简单的走查，测试用例可以用业务逻辑图来替代。但是在一个项目周期结束之后，应该对测试用例进行整理，编写并备份入库！

另外，测试用例有一个关键地方就是测试用例的更新，因为在软件测试过程中经常使用同一个用例进行测试，软件会增加对该测试用例的”抗性“。因此，我们要对用例进行及时的更新，在一个项目周期结束之后，应该对测试用例的有效性进行评估，该评估准则是测试用例发现的BUG数量/BUG的总数量。对于用例没有发现的BUG应该添加到测试用例中，此外，用户提交的BUG是很宝贵的，也需要添加到测试用例中！

对了测试用例的管理应该纳入到项目的配置管理中！

以上是我个人的一点心得，和大家share一下！
各个公司，各个team的规定和文化的不同，流程也不一样，大家具体问题具体分析！

[ 本帖最后由 lovemiya 于 2008-4-25 16:24 编辑 ]

兄弟是不是华为的人啊。感觉和做过的华为项目很类似唉

在有限的时间内写出完整的用例，是不可能的。但确定有效的和主要的测试点并且把用例写完整是可能的。
接下来的问题是如何确定测试点？
从几个方面考虑：软件将来由谁在用？
                那些功能用户常用？
                软件的卖点在那里？

首先，得到该软件的需求及设计文档，理解该系统原理及功能。这实际上是熟悉系统，理解需求，找到测试的要点
其次，根据软件理解，选择恰当的测试方法，设计测试例
最后，根据测试中的理解的不断加深，增加测试用例，完善测试方法。

说人家落后，我看你们才是很落后呢……

呵,我们公司比较特别,我是根据功能规范来写测试用例的.公司根本没有需求文档,但在开发前会详细讨论功能点.形成功能规范.我就根据这个来写的.基本上是等产品开发出来,我用例早写好了,只需稍舟增,改一下,执行,结果就行了.