1、了解软件的原始需求（测试目的）
　　在编写一个软件或者模块的测试用例时候，一定要明白这个功能的原始需求，也就是软件的使用者（客户）的需求。理解原始需求后，编写的测试用例才更有目的性。

　　2、熟悉软件的功能需求（测试点）

　　这个功能需求是指软件的细化需求点，这个一般在需求文档里面都会体现。这里要做的是把 “粗略”的需求，细化成一个个小需求点。熟悉功能需求后，要知道软件是怎么使用的，这也才能覆盖到各种操作。

　　总之，测试用例一定要全部覆盖所有的需求点，这是最基本的一点。

　　3、熟悉软件的实现原理（测试点）

　　在理解原始需求和软件的功能需求后，根据需求编写的测试用例，基本上都能覆盖得比较全面了。

　　在此基础上，熟悉软件的实现原理，理解软件的内部处理。

　　（1）熟悉原理的过程是进一步深入熟悉软件的过程。如果单单是从需求点上面覆盖案例，测试用例只能覆盖“表面”的一层。一些内部的处理流程也许没有覆盖到，而这些没有覆盖到的代码很可能就是一个风险点。

　　（2）熟悉模块原理后，还有一点就是易于分析软件模块的关联性。一个大型的软件，都是一些小模块的组合而成。软件越是大型，耦合就越大，“互相影响”就会越多，若设计用例单单从模块本身考虑的话，很可能就会对其他模块造成风险。

　　4、用户场景和网上问题（测试点）

　　从用户的使用场景考虑，这在一些网络设备比较重要，比如软件后期在一些真实的使用环境中使用。

　　还要就是从一些网上问题总结出来的，那些地方容易出错，在设计案例的时候需要考虑进去 。

　　5、测试用例的框架

　　一个测试用例的框架体现了一个测试人员在设计测试用例的整体思路。框架也是从大到小划分下来，可以是：

　　UI界面，功能，容错，兼容，性能等几大类，每个大类在根据软件的逻辑等进行划分成小类，最后细分到测试点。

　　6、测试步骤（测试技巧方法）

　　前面4点都是从测试点的角度考虑，测试用例在完成测试点外，接下来就是测试步骤和测试结果啦。

　　测试用例可以写的很详细，也可以写的比较简单。这要看公司的要求，有些公司要求测试步骤很细很细，包括测试结果和测试步骤一一对应。

　　要求测试步骤写的很详细的公司，一般是怕执行人员的执行力不到位，导致没有理解案例的目的，导致漏测。一般出现在新员工对软件系统的不熟悉。

　　如果测试步骤写的很详细的话，会很耗时间，而且过于详细的会限制执行人员的思维。个人认为测试用例的重点在于测试点上。

　　7、测试用例的一些思路

　　在设计测试用例中，通常较多使用的是边界值，等价类，通过和不通过测试。下面从单个模块或者单个功能点考虑：（结合一些网上文章的观点）

　　（1）UI界面：易用性，提示信息，整体布局，按钮图标，色彩，中英文标点错别字。

　　（2）数据的多样性：有效数据，合法的无效数据（边界值），非法的异常数据，产生错误输出的合法数据组合等各种数据的组合。

　　（3）操作多样性：添加删除编辑查询 ，多用户的操作。

　　（4）容量测试

　　（5）用户权限：使用权限，各种操作的权限。

　　（6）升级安装卸载：平滑升级

　　（7）日志相关（包括调试日志）

　　（8）软件功能的逻辑划分：功能上划分未能覆盖的代码逻辑，可以添加白盒灰盒用例。

　　（9）可靠性，容错性

　　（10）兼容性：浏览器，系统，支撑软件。

　　（11）安全性

　　（12）性能（这里的性能是指，单个模块或者子系统的性能）

　　总之测试用例首先要能覆盖所有功能需求点，然后搞懂软件处理逻辑，可以找开发一起看测试用例，把没有覆盖到的代码流程相应的用例补充，至此，用例基本不会出现基本功能的问题。

　　在此基础上，可以进行一些可靠性，容错性，兼容性等用例的设计，测试下软件的稳定性。

本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/