下面我就个人体会谈谈做好测试用例的关键 。首先 ， 在做用例之前 ， 要做两件事情 。
第一 ， 透彻了解程序（需求和架构） 。第二 ， 做一个正式的测试设计（最好文档化） 。
然后再开始写用例 。一般写用例的步骤和建房子一样 ， 先搭框架 ， 然后填材料 ， 填材料的时候 ， 主要根据需求做相关的设计 ， 具体的设计方法就是那几种（郑老的书上写的很清楚） 一般来说 ， 设计一个比较实用的测试用例 ， 注意如下几个方面：a. 选用好的用例管理工具（这个很重要 ， 千万不要用word,excel） b. 用例一定要及时更新（补充新的想法 ， 删除过时的需求） c. 做好用例分级 d. 做好用例评审 ， 写用例之前可以征询相关人员的意见 e. 可以考虑结对编写 ， 这个是不错的主意 f. 要全面 ， 包括功能、性能、兼容性、安全性、易用性、容错性等等 g. 注意把握适当的颗粒度 OK ， 以上是我个人总结的一些心得 ， 希望对您有些帮助.----------------------------------------------------------------------------------------- 我不知道lz说的做好测试计划中的“做好”两字具体指的是什么 对于目前大部分公司存在的状况 ， 很多测试计划文档只是一种形式而已 所以我的理解是：怎样让测试计划对整个测试工作真正具有指导作用 这里把测试计划和测试方案分开来讲（计划对应于管理层面的问题 ， 方案对应于技术方面的问题） 测试计划中最重要的内容包括：进度安排；人力、物力资源分配（包括组织结构等）、风险假设和规避措施 。
（其他像软件版本号之类的 ， 只要是个人都会写 ， 这里不列了） 写好测试计划的关键在于：1 充分了解你的团队的整体实力和团队中每个成员的特点2 充分理解为当前软件制订的整个研发活动过程 带过项目的人都知道：在实际项目中 ， 往往进度才是第一位的 ， 但是对进度的把握和估算却是极其困难的 。只有做到这两点才有可能对进度有比较准确的把握 ， 对人员有一个合理的分配 。
否则所谓的进度 ， 所谓的资源分配 ， 都是拍脑袋得出的结果 ， 风险假设更是无从谈起 ， 这样的测试计划文档只能流于形式也就不足为奇了 。写好测试方案的关键在于：1 有一个合理的测试计划2 熟悉相关业务3 深入体会用户的实际需求 这个不想多解释了 ， 不难理解 。
至于测试用例 看到上面不少朋友认为关键在于理解用户需求 其实理解用户实际需求是一切的根本 并且对于有些测试（比如像单元测试）对应的测试用例通常和用户需求之间的关系可能并不直接或是十分密切 当然 ， 如果有一份好的需求和设计文档的话 ， 什么事情都解决了 。可是现实往往是不存在这样的文档的 。
所以我的看法是：1 对业务理解的深入程度2 经验3 有自己的文档 前两条不解释了 。自己的文档包括两方面：一个是常用的特殊测试数据 ， 比如一些特殊字符 ， 极限长度的输入等等 。
这个在项目时间紧迫的时候是非常有帮助的（有的时候甚至可以当成check list） 。另一个就是自己测试模块对应的相关需求和设计文档 。
服务器上的标准文档拖到本地来并且记得及时更新 。然后在测试过程中 ， 需要什么内容文档上没有 ， 最直接的方法是和开发人员沟通 。
（其实我很反对这么做 。你想 ， 按开发人员自己说的标准去测他们自己开发的模块能测出因为需求或者设计错误导致的问题么……应该是和客户和designer去沟通 ， 可惜一般没有这条件-_-）任何 。