1、测试用例的八大要素
1. 用例编号
和其他编号一样，测试用例编号是用来唯一识别测试用例的编号，要求具有易识别和易维护性，用户可以很容易根据用例编号获取到相应用例的目的和作用，在系统测试用例中，编号的一般格式为A-B-C-D
这几部分的作用分别如下：
- A：产品或项目类型，如CMS(内容管理系统)、CRM(客户关系管理系统)
- B：一般用来说明用例的属性，如ST(系统测试)、IT(集成测试)、UT(单元测试)
- C：测试需求的表示，说明该用例针对的需求点，可包括测试项和测试子项等，如文档管理、客户投诉信息管理等。通常可以根据实际情况将格式调整为
C-C1的格式，如客户管理-新增客户，其中客户管理为测试项C，新增客户为测试子项C1。 - D：通常用数字表示，并且一般用三位顺序性数字编号表示，如001、002等。
用例编号示例：CRM-ST-客户管理-新增客户-001
2. 测试项
测试项即是测试用例对应的功能模块，其包含了测试项、测试子项，以及该用例所属的功能模块。以上述的客户管理-新增客户为例，往往一个测试项下会包含若干测试子项或测试用例，因此测试项一般可定义到测试子项级别，这样更便于识别测试用例所属模块及维护用例。
3. 标题
测试标题是用来概括描述本条测试用例的关注点，原则上标题不可重复，每条测试用例对应一个测试目的。例如，输入包含特殊符号'的客户名称，提交新增信息，验证单引号SQL注入是否屏蔽。
4. 重要级别
重要级别是测试用例重要性的体现，可以根据测试用例的重要级别决定测试用例的执行顺序，一般将测试用例划分为高、中、低三个等级。具体的级别可以根据需求的优先级来确定，在一个测试项中，级别为高的测试用例数量往往控制在一个左右，通常从功能风险、功能使用频率、功能关键性等几个因素来考虑用例重要级别设置，高级别的用例越多，预测试项目就越多，就越不利于测试的执行，这样设置重要级别也就没有意义了。
5. 预置条件
预置条件就是执行该条用例的先决条件，也就是说如果预置条件不满足，则根本无法执行本条测试用例。预置条件在实际确定的过程中，往往选择与当前用例有直接因果关系的条件，例如当某个功能A或流程的输出直接影响下一个功能或流程的工作时，可称A是下一功能或流程的预置条件。
预置条件选择的正确与否，可能会影响测试覆盖率、通过率的计算，从而影响停测标准的执行。
6. 测试输入
测试执行时，往往需要一些外部数据、文件、记录驱动等，例如，新增客户信息时，需要客户姓名、联系电话、通信地址等，这些内容构造的测试数据即被称为测试输入。
7. 操作步骤
根据需求规格说明书中的功能需求，设计用例执行步骤。操作步骤描述执行人员执行用例时，应遵循的输入操作动作，编写操作步骤时，需明确给出每个步骤的详细描述。
8. 预期结果
预期结果来源于需求规格说明书，说明用户显性期望或隐性需求。预期结果作为测试用例最重要的一部分，需明确定义。在编写预期结果时，可以考虑从以下两个方面考虑：
- 预期的界面表现
执行相关操作后，被测对象会根据测试输入做出相应，并将结果展现在软件界面上，用例预期结果中可包括此部分的描述。 - 预期的功能表现
通常从数据记录、流程响应等几个方面关注预期功能表现，如输入正确数据格式的用户信息，单击“新增”按钮，数据库插入相关记录，并且在用户列表中正确显示该用户概要信息。
需要注意的是，被测对象根据输入所做出的响应，一定要描述清晰。通常情况下，一条测试用例，仅描述一个预期结果或主题明确的相关结果，不要一条用例描述若干事情，期望若干结果。
2、ANSI/IEEE 829标准
ANSI/IEEE 829标准测试用例说明用于输入输出的实际数值和预期结果，同时还指出了使用具体测试用例产生的测试程序的限制。下面是ANSI/IEEE 829中对测试用例的描述：
如果按照上述标准来写，将非常浪费时间，所以一般将上述标准一般作为规范，然后在其基础上进行修改、简化，下面是一个测试用例的实例。
3、测试用例编写实例
以上面的新增客户测试项为例，可以编写如下的测试用例：
不过，根据实际的情况，我们还可以再此基础上增加新的要素，例如用例属性(指该用例的用途，如功能用例、性能、可靠性、安全性、兼容性用例等，这样可以先确定用例属性，然后再选择相应的测试用例/测试数据，比如安全性测试就选择安全性测试用例)、实际结果(刚开始时为空白，执行测试用例后，如果实际结果与预期结果不一致，将实际执行结果写入此处)，执行人(执行此条测试用例的人员)等。
