一个项目启动后，开发会根据项目的需求文档（RFP：Request for Proposal）编写开发计划（SDP：System Development Plan）和系统需求说明书（SRS：System Requirement Specification）;与此同时，测试根据需求文档，SDP和SRS来提取测试范围（或者测试需求），思考可能使用到的测试方法和测试工具，测试环境等，这些都会编写在测试计划文档里。
根据RFP，SDP，SRS，STP就去详细地写一条一条的测试用例可能并不实际，因为项目初期RFP这些文档就是粗略型的大纲文章。当然需求越早确定越好，并尽量避免后期的频繁改动。然而实际项目中你会发现需求在早期就确定下来是一件多么困难的事情。为了梳理当前测试需求，并指导后期测试用例编写，在测试用例编写之前需要输出一份测试需求文档或者叫做测试设计文档（STD：System Test Design，文章最后会附STD具体包含的内容）。文档编写形式多样，里面可以用思维导图（Xmind，FreeMind）列出每个正常测试点，异常测试点等等，整理出测试思路。更重要的是从这份文档里测试人员能够有个清楚的测试思路，并找出自己为了达到测试目的，自己需要做哪些准备。
STD顺利完成之后，再转换成STC就很容易，且不容易遗漏。STC永远不是一蹴而成的，它是个持久性活动。一轮测试后，探索测试，交叉测试使得测试人员又有新的测试思路，都可以作为补充STC的来源。
测试用例设计出来以后是需要评审的，评审人员主要有需求方，设计人员，开发人员，其他测试人员，以及开发主管和测试主管。最后将评审结果记录在文档里或者记录在管理文档的系统里，比如CC或者在线管理工具RedMine，以便后期查看和维护。
做好测试用例的关键
1.多和开发沟通，在项目前期就达到深层次理解和分析需求，最后经过STD将这份理解分析转化成后期可执行的测试用例。
2.多和开发沟通，控制需求变更对测试用例的影响。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
