测试用例是测试的基础，很多测试说点点点没技术含量，其实这样理解是不正确的，我觉得功能测试才是最重要的，至少你没听说过有公司不做功能测试吧？而且，自动化、性能、安全等测试，都是功能测试主流程稳定后才开始的，特别提出测试用例制度及规范，快速编写测试用例，管理测试用例，才能为后面的自动化、性能、安全保驾护航！
测试用例要素
1、测试用例编号
2、测试标题
3、所属模块
4、测试需求项编号
5、案例状态
6、预置条件
7、优先级
8、测试输入
9、操作步骤
10、预期输出
11、实际结果
12、案例设计者
13、设计日期
要求
- 测试标题：【必填项】用概括语言描述测试用例的测试点，达到一目了然。
- 测试需求项编号：【必填项】测试用例都是根据需求来的，对于用例的来源必须追溯源头，确保其正确性；
- 预置条件：【必填项】执行当前测试用例的前提描述，如不满足这些条件，则无法进行测试。若无预置条件，可标注“无”；
- 优先级：【必填项】分为高中低，对于高级别，大概占比用例的20%，对于中低级别占比用例的80%；
- 测试输入：数据准备
- 操作步骤：执行当前测试用例所要经过的操作步骤，需要给出每一步操作的详细描述。
- 预期输出：当前测试用例的预期输出结果，用来与实际结果比较；
- 实际结果：当前测试用例的实际输出结果，用来与预期输出比较，如果相同则测试通过，否则测试失败。
用例编写原则
- 功能或流程划分时，一定要简单、清晰，一个测试用例只检查一个功能或一个流程；否则测试用例会比较混乱，降低可读性；
- 测试用例要有一个简单直观的名字，有助于读者对测试用例的理解。
- 测试用例的步骤描述要简单、清晰，一步就是一步。
- 测试用例的数据要明确，特别是输入数据和期望结果；
- 测试用例需要保障唯一性，即功能用例之间不存在重叠，流程用例不存在包含关系。没有重复、冗余的测试用例，满足相应的行业标准。
- 描述要清晰、包含特定的场合、对象和术语，没有含糊的概念和一般性的描述。应尽量避免不确定的用词，如：如果、若、否则、大概、可能等。
- 测试用例中保证，正常用例：异常用例=1:2；
- 测试用例应确保覆盖详细设计的所有功能。但功能用例要覆盖所有数据操作处理的功能点；流程用例要尽可能的覆盖程序的各种路径，考虑存在跨年、跨月的数据，兼顾各种业务变化的可能。
- 对于无输入的操作，应该详细描述其具体的操作步骤和结果。
- 测试用例需要保障数据的正确性和操作的正确性；首先保证测试用例的数据正确，其次预期的输出结果应该与测试数据发生的业务吻合，操作的预期结果应该与程序发生的结果吻合。
用例创建原则
创建主用例目录时，需要根据功能模块或者流程模块进行创建；如下图：
image.png
- 编写迭代用例时，根据迭代号创建目录，子目录跟之前创建的功能模块或流程模块吻合，如下图：
image.png
- 迭代结束后，快速把迭代用例合并至主用例目录中，保证主目录的用例完整及最新状态；
