对于目前大部分公司存在的状况，很多测试计划文档只是一种形式而已
　　

        所以我的理解是：怎样让测试计划对整个测试工作真正具有指导作用

　　这里把测试计划和测试方案分开来讲（计划对应于管理层面的问题，方案对应于技术方面的问题）

　　测试计划中重要的内容包括： 进度安排；人力、物力资源分配（包括组织结构等）、风险假设和规避措施。（其他像软件版本号之类的，只要是个人都会写，这里不列了）

　　写好测试计划的关键在于：

　　1 充分了解你的团队的整体实力和团队中每个成员的特点

　　2 充分理解为当前软件制订的整个研发活动过程

　　带过项目的人都知道：在实际项目中，往往进度才是第一位的，但是对进度的把握和估算却是极其困难的。只有做到这两点才有可能对进度有比较准确的把握，对人员有一个合理的分配。否则所谓的进度，所谓的资源分配，都是拍脑袋得出的结果，风险假设更是无从谈起，这样的测试计划文档只能流于形式也不足为奇了。

　　写好测试方案的关键在于：

　　1 有一个合理的测试计划

　　2 熟悉相关业务

　　3 深入体会用户的实际需求

　　这个不想多解释了，不难理解。

　　至于测试用例，看到上面不少朋友认为关键在于理解用户需求。

　　其实理解用户实际需求是一切的根本，并且对于有些测试（比如像单元测试）对应的测试用例通常和用户需求之间的关系可能并不直接或是十分密切。

　　当然，如果有一份好的需求和设计文档的话，什么事情都解决了。 可是现实往往是不存在这样的文档的。

　　所以我的看法是：

　　1 对业务理解的深入程度

　　2 经验

　　3 有自己的文档

　　前两条不解释了。 自己的文档包括两方面：一个是常用的特殊测试数据，比如一些特殊字符，极限长度的输入等等。这个在项目时间紧迫的时候是非常有帮助的（有的时候甚至可以当成check list）。 另一个是自己测试模块对应的相关需求和设计文档。服务器上的标准文档拖到本地来并且记得及时更新。然后在测试过程中，需要什么内容文档上没有，直接的方法是和开发人员沟通。（其实我很反对这么做。你想，按开发人员自己说的标准去测他们自己开发的模块能测出因为需求或者设计错误导致的问题么……应该是和客户和designer去沟通，可惜一般没有这条件-_-）任何标准文档上缺少的内容，只要是和你有关的，一定要记得做记录。 当然你有时间有精力把整个系统的需求和设计文档都捣鼓出来好，不过通常是没这可能性的。

　　补充说明：lz后提到的“完全凭借自己的经验在执行测试活动”不如说是完全凭借自己的感觉在执行测试活动。

　　项目需要的用例详尽程度可以商量，但是必须要有。 如果进度很紧，可以用一部分用例加上check list进行测试活动（比如很多日本外包项目的UI测试，相当一部分可以用check list来代替具体的用例，效果并不差）