1、了解软件的原始需求（测试目的）
在编写一个软件或者模块的测试用例时候，一定要明白这个功能的原始需求，也就是软件的使用者（客户）的需求。理解原始需求后，编写的测试用例才更有目的性。
2、熟悉软件的功能需求（测试点）
这个功能需求是指软件的细化需求点，这个一般在需求文档里面都会体现。这里要做的是把需求稳定的“粗略”的需求，细化成一个个小需求点。
熟悉功能需求后，要知道软件是怎么使用的，这也才能覆盖到各种操作。
总之，测试用例一定要全部覆盖所以的需求点，这是最基本的一点。
3、熟悉软件的实现原理（测试点）
在理解原始需求和软件的功能需求后，软件有什么功能，如何使用就基本上都知道啦。这时候在根据需求编写测试用例，基本上都能覆盖的比较全面。
在此基础上，熟悉软件的实现原理，理解软件的内部处理。
（1）熟悉原理的过程是进一步深入熟悉软件的过程。如果单单是从需求点上面覆盖案例，测试用例只能覆盖“表面”的一层。一些内部的处理流程也许没有覆盖到，
而这些没有覆盖到的代码很可能就是一个风险点。
（2）熟悉模块原理后，还有一点就是易于分析软件模块的关联性。一个大型的软件，都是一些小模块的组合而成。软件越是大型，耦合就越大。“互相影响”就会越多，
设计用例单单是从模块本身考虑的话，很可能就会对其他模块造成风险。
4、用户场景和网上问题（测试点）
从用户的使用场景考虑，这些在一些网络设备比较重要。比如软件后期在一些真实的使用环境中使用。
还要就是从一些网上问题总结出来的，那些地方容易出错。在设计案例的时候需要考虑进去
5、测试用例的框架
我觉得一个测试用例的框架体现了一个测试人员在设计测试用例的整体思路。框架也是从大到小划分下来，可以是：
UI界面，功能，容错，兼容，性能等几大类，每个大类在根据软件的逻辑等进行划分成小类，最后细分到测试点。
6、测试步骤（测试技巧方法）
前面4点都是从测试点的角度考虑，测试用例在完成测试点外，下来就是测试步骤和测试结果啦。
测试用例可以写的很详细，也可以写的比较简单。看公司的要求，有些公司要去测试步骤很细很细，包括测试结果和测试步骤一一对应。
我个人不太认同这种做法，测试用例最重要的我认为是测试点。只要理解了测试目的后，下来的就是测试人员的执行工作啦。如果对一些非常娴熟的测试人员，他们一般
看测试用例的标题就是知道你测试目的了，具体的操作就是根据他们的测试方法进行测试。如果测试步骤写的很详细的话，一会很耗时间。你要考虑到文字语音的描述，以及一些前置步骤的操作，这也会导致案例有时候像个文章，而且过于详细的会限制执行人员的思维。
要求测试步骤写的很详细的公司，一般是怕执行人员的执行力不到位，导致没有理解案例的目的，导致漏测。一般出现在新员工对软件系统的不熟悉。
7、测试用例的一些思路
在设计案例中，我用的最多的是边界值，等价类，正常和异常的测试。下面是我想到的几个方面：（结合一些网上文章的观点）
一）从单个模块或者单个功能点考虑
（1）UI界面（易用性，提示信息，整体布局，色彩，中英文标点错别字）
（2）数据的多样性
有效数据
合法的无效数据（边界值）
非法和异常数据
各种数据的组合
（3）操作多样性
添加删除编辑查询
多用户的操作
（4）容量测试
（5）用户权限（使用权限）
（6）升级安装卸载（平滑升级）
（7）日志相关（包括调试日志）
（8）软件功能的逻辑划分
功能上划分未能覆盖的代码逻辑，可以添加白盒灰盒用例；
（9）关联的功能
设计关联的测试的用例
（10）可靠性，容错性
（11）兼容性（浏览器，系统）
（12）安全性
（13）性能（这里的性能是指，单个模块或者子系统的性能）
总之
测试用例首先要能覆盖所有功能需求点，然后搞懂软件处理逻辑，可以找开发一起看测试用例，把没有覆盖到的代码流程相应的补充用例。用例覆盖到这2点基本不会出现基本功能的问题。
在此基础上，可以进行一些可靠性，容错性，兼容性等用例的设计，测试下软件的稳定性。
