如何进行有效的
用例设计？作为任何一个
测试用例设计者，这永远是一个非常难以回答的问题。这个问题至今为止也再不断的困扰我，人见人智。下面是我的一些个人见解，或许能对大家有一些启示。
第一：“明确”待测试项目的需求。对于任何一个项目，无论你接手的项目有多小，甚至可能都算不上一个项目，而仅仅是一个小工具，明确需求非常重要。可能 很多人会说，公司现状，测试能看到需求文档几乎不可能；也或者公司有需求文档，但与实际的待测试项目相差甚远；也或者还有其他的各种可能情况，但无论是什么原因，明确需求是任何一名测试用例设计者必须坚持也必须执行的一条原则。如果你是测试部的负责人，在面对需求不明确的项目时， 请你先收集待测试项目尽可能多的“文档”，这些文档有时并不一定需要是已经现成成稿的，其实我们可以通过“不耻下问”之后自行整理。测试负责人自己必须对 待测试项目做到“胸有成竹”。
第二：“分析”待测试项目。可能很多人这个时候会非常不以为然了，为什么要经过这么一个过程？“分析”待 测试项目的目的是让我们更进一步的了解待测试项目，那可能大家这个时候又会问了，了解什么？大家想想，你明确了需求，可是你知道待测试项目的体系结构是什 么吗？你知道我们采用了什么技术吗？你知道这个项目蕴涵的业务知识有哪些吗？对了，我们就是要通过更进一步的分析，整理出更为详细的资料，服务于我们的测 试工作。
第三：“学习” 待测试项目的业务知识。这一点我相信很多人都能认同，比如你是做银行相关项目的，那你肯定要具备银行相关方面的知识，只有这样，才能非常容易的明白为什么 这么设计，或者这么设计的优势在哪里？针对采用的某种实现技术，只有更进一步的学习了解，你才能明确这种技术的优势与弱势分别是什么，针对这种技术的弱 势，我们测试又需要重点测试哪些地方等等。这些问题都需要在我们提升我们自身业务水平的同时得到解决。
第四：内部讨论。对于这点，我有 非常切身的感受，作为项目测试负责人，一定要更自己的测试团队针对某个项目进行多次内部的讨论，通过内部讨论更进一步发现我们忽律的地方，同时也让大家的 资源共享，用最短，最快的方式收获最好的效果。