其实楼上说的沟通是最重要的了
我们公司测试遇到的也是和楼主情况差不多
1，按照做出的软件把自己知道软件功能写成一颗树的结构形式（把主要的需求点写出来）
2，然后一条一条的找开发经理确认
3，再就可以根据需求点写用例了
4，最后就是和开发确认下用例

这是没有办法的情况下，我们现在也是这样，感觉很混乱，痛苦之中

个人认为重要的几点：
1，测试需求的划分（需求点）
2，版本控制与配置管理
3，资源管理
4，沟通

见笑了

强烈建议换家公司，这样的公司有你受的。
吃亏不讨好！

感觉我们的情况正好与楼主说的相反

我们公司的项目管理情况和大家差不多,需求不明确或者只是在项目经理和开发人员的头脑中,没有文档,很多时间他们说怎么样就怎么样(有时候某个问题被我们反问一下,他们自己也说不清楚)
公司领导层面应该是知道测试的重要性,但他们没有精力管这么多,当然,一旦有什么问题他们也不会一直责怪测试人员
但这种情况我觉得却不助于测试效果的提高

我反而希望领导能追究责任,然后与项目有关的人员一起讨论,看看到底问题出在哪,这样才有利于开发,测试,项目管理的效果,

关于需求文档的问题，我想其实很多公司都有。
我觉得需求文档应该不是开发人员写的，至少应该是需求分析人员去写的。

关于测试管理人员，我觉得可以从两个方面入手
第一：规范测试方面的流程。至少要在整个项目组内部达成一致，一个项目中，测试的活动，测试的流程，规范先建立起来，这样才能保证测试的质量
第二：做好数据收集。这其实需要建立在第一上面，比如测试用例的执行分析情况，缺陷的数据统计分析，测试人员的工作量分布等等。这样最后说话的时候有理可说，有据可依
第三：沟通。不仅仅是项目内部的沟通，包括公司高层的沟通。

需求不应该是开发人员写的,他们也是根据需求来开发的.
我想问问项目经理是干嘛的,吃干饭的?有问题要协调,要找原因,想办法解决或最大限度降低
损耗.谁来做,项目经理!
测试就不是项目组中的一员了?

我们公司都没的项目经理，所谓的经理就是在公司呆的时间比较长有一定管理能力带头写代码的程序员。
需求调研做的也不行，客户说的也模棱两可。  天天都是按老板意思做（老板懂点技术比较熟悉业务），给客户看了再改。

[ 本帖最后由 371552995 于 2008-1-23 12:50 编辑 ]

把测试得重要性写成书面形式,提交给项目管理者...然后就是让他看着你写得..和他沟通.,,,重点就是测试得重要性和在整个项目得地位..如果还是不能让项目管理者重视测试得话..那唯一得选择就是跳了..

我不同意楼上的看法，跳不是解决问题的途径，而且没有解决不了的问题。你能跳一家，以后多遇到几次每次都跳？
测试固然重要，但是不要颠倒了，测试是为项目服务的，为了保障项目的质量。沟通是王道，有时候需要多动动脑子。

现在国内的公司重来不写需求文档的多得是。这个事情主要看领导的态度了。如果领导意识到了就好推广，如果领导根本意识不到就没办法了，因为他根本就不认同你的看法呀。
在没有需求文档的情况下也一定要做好测试。按照自己的猜想，如果你是客户，你怎么去用这个软件，软件的界面和提示语言是否有好呢，这些都需要你自己去掌握了。你也可以提出让研发更改的意见，如果研发说需求就是这样的，不需要更改，那么就记录，并双方签字确认，以后产品使用中出现了问题，那么就不知测试的事情了。自己要保护自己，划清责任。
如果你是个管理者，那么就做好自己的本分，自己规范了就行了。如果要想该善研发，可以跟领导提交报告，一定不要口头的谈论，这样起不到作用，而且以后出了问题也不好说清。
如果以上的努力还不能起作用，并且你还忍受不了这样的不规范环境，那就只有换个规范的公司了。不过要劝你，天下乌鸦一般黑。
以上为个人意见。

哎～～～～
现在的公司，要不不写，要不就是胡乱写。
多是程序员写的，写也是应付，胡乱编的感觉，没有模版也没有规范的格式，身边也没的人知道要写成什么样子才算好～～～

总是在项目要验收的时候赶快补文档，老板只看字数和页数，真是恶心～～～～～