对被测版本足够了解
由粗略详细步骤来解读产品需求文档，如交互、功能流程、边界、约束等等。充分理解技术实现原理，实现的逻辑原理、架构及对其他平台的依赖、接口等。深入理解用户群，分析用户使用场景、可能的使用方法及用户心理，完全从用户角度出发，来设计Case，同时对用户体验做出一定的判断。
设计Case优先级
一般使用专业测试工具，测试用例设计工具编写好Case后可以按优先级来筛选优先级，如果是用Excel文档来写可以来通过不同背景色来标识相应的优先级，无论评审还是执行，都可以按此来查阅。无论是冒烟测试用例还是功能测试用例，节省大量时间。
从粗到细分析需求
可以使用工具辅助，第一遍需求分析时，粗略画出测试需求框架；第二遍分析需求时，开始延伸每个出子测试点；细化测试点时，可参考或引用写好的公共Case， 也要考虑到被测版本中该功能的特性。另外需要考虑的就是测试点的颗粒度要把握好。
测试用例更新
需求分析阶段和开发阶段 ，都可能出现需求变更，这时对于我们前期粗略整理好的测试点就需要及时的同步更新了。另外在Case评审阶段，可能会出现Case冗余或遗漏，也需要在评审结束后在Case池里及时修整。如果项目中有使用需求工具之类的，可以利用工具去同步通知到每个节点的负责人，会大大 减少更新的时间。
推荐阅读：
sales@spasvo.com
