设计测试用例是个很大的主题，而且其中所需要的方法也很多。我计划一点一点的总结并记录下来。我这次讨论的不是针对一个软件的测试用例设计，而是针对一个模块或多个模块用例的设计。
今天我要写的主要是我自己在工作中所用的一些方法，当然不是最好用的。但我一直在研究最高效，最实用的方法。
首先我们要了解一下为什么要设计测试用例以及它在软件测试中的地位。
影响软件测试的因素很多，软件本身的复杂程度，开发人员的素质（包括分析，设计，编程和测试），测试方法和技术的应用。那么如何保证测试质量的稳定呢？测试用例就可以把一些人为的因素减低，因为人员的流动不会造成测试用例的流动，而且我们可以在以后的测试中不断的维护和更新测试用例。所以说测试用例的设计和编制是软件测试活动中最重要的。它是测试工作的指导和软件测试必须遵守的准则。它更是软件测试质量稳定的根本保障。
当自己接受到一个设计测试用例的任务时，如何对一个庞大的模块进行设计测试用例呢？这时候测试用例的划分就显的尤为重要。
我总结的测试用例的划分有三种：
1）按照功能划分
2）按照路径（业务流程）划分
3）按照功能和路径（业务流程）划分
目前我用的方法是第三种。第一种按照功能划分，优点是最简捷，但其缺点是：对于复杂操作的程序模块，其各功能的实施是相互影响，紧密相关，环环相扣的。如果没有严密的逻辑分析，很容易产生遗漏。第二种纯粹按照路径划分也容易造成对功能点的遗漏。所以我基本都是大方向用功能块的划分来走，然后再结合上路径（业务流程）的划分方法。
例如下面的一个模块测试，我就先按照功能划分为几大块，然后针对每个功能块再按照路径（业务流程）来划分：
那么有人会问，当我拿到一个任务的时候，简单一点还好办，一旦复杂了就没有头绪，无处下手了。我告诉大家不会的。只要你按照我的这个流程来设计我认为是不会无处下手的的：
在这个流程当中，我要强调的重点是前两步："Understand Software Requirement" and "Be familiar with the corresponding functions".
1、Understand Software Requirement: 当接到一个任务的时候，我们首先接触到的是需求说明书，那就要了解需求说明，或者应该说掌握其需求说明。其中的任何一个细节都不能忽略，都要把它搞得很清楚。不仅要搞清楚每个功能块所实现的功能，更要从业务的角度理解其功能块之间的关系。因为任何的软件测试都不能脱离实际的业务逻辑，否则测试是没有意义的。
2、Be familiar with the corresponding functions.如果这个模块已经实现，那就更好办了。可以结合需求说明直接操作该软件，以便提高对该软件功能的理解。
我们接到测试用例设计的任务，不要急着下手，首先按照我上面所说的两步来完成。等把这些前提工作完成了，现在基本就对要设计的软件了解差不多70％了。
当我们完成前两步以后，开始对测试用例进行划分，就可以采用我上面推荐的功能加上路径（业务流程）的划分方法。当我们罗列出很多测试用例以后，那我们是否要对所有的测试用例进行详细的设计呢？这个就不一定了，因为往往时间或者资源的关系我们无法覆盖到所有的测试用例。那我们这里就需要采取优先级的顺序来进行选取了。
我们为每个测试用例设置优先级需要采取两个原则：
1、将使用频率比较高的设置为高优先级的。
2、根据测试用例失败后对系统的影响大小还设置其优先级。
这样将两者相加就得到了每个测试用例的优先级了。根据优先级的排序就可以更有针对性的进行测试用例的详细设计了。这是我们先不急着设计测试用例，我们还要为每个测试用例设计相关的测试数据。
我们对测试数据的设置有两个要求：
1、正常数据
2、非法数据
我们要优先考虑正常数据，而且正常数据的设计必须是有实际意义的。然后再考虑设计非法数据。这两种数据中都应该包含边界数据，因为边界数据往往是容易出错的地方。
当我们设计完测试数据后，就可以开始对测试用例进行详细设计了。具体测试用例的模板可以根据自己公司的要求来定义。我这里给出测试用例模板的一些要包括的要素：
1、Objective
2、Testing Configuration
3、Test Steps & Results
另外在具体的测试步骤中，我们需要包含的主要内容是：操作步骤，测试数据以及期望结果。
当我们完成了这些工作，一个完整的测试用例就写完了。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/
