测试用例设计编写包括：1. 测试项目；2. 测试子项；3. 测试标题；4. 测试用例优先级；5. 预置条件；6. 输入；7. 执行步骤；8. 预期结果。其中，测试项目是本次测试的功能点，如登录。
一、测试用例设计编写
1.测试项目
本次测试的功能点，如登录
2.测试子项
测试子项是表示我们本次测试的目的：如正常登录测试用例编号 测试用例编号，是由字符和数字组合成的字符串。
用例编号应具有少数性、易识别性
测试用例编号的格式：
项目编号_测试阶段_测试项_测试子项_顺序号
测试阶段：ST、IT、UT
项目编号_ST_系统测试项_系统测试子项_001
项目编号_IT_集成测试项_集成测试子项_001
项目编号_UT_单元测试项_单元测试子项_001
例如：
N3310‐ST‐CALL‐URGENTCALL‐001
N3310‐IT‐FILEITF‐READFILE‐001
N3310‐UT‐FILEITF‐READFILE‐001
3.测试标题
测试标题表示该用例测试的目标
4测试用例优先级
之所以对用例进行标级，是因为可以根据用例的优先级来确定我们的测试策略。
常对于用例优先级定义：高、中、低三个级别
确定测试用例的优先级一般有两种方式：一是业务的优先级；二是用例优先级评估模型
业务的优化级 ：
根据业务的优化级来定义的优化级，即如果业务的优化级越高，那么用例的优化越高
业务的优先级有两个方面：一是需求本身优先级；二是业务本身分为基本与备选流。
需求的优先级也分为：高、中、低三个级。
高：如果这个需求不做或者说做的不完善，那么这个产品无法销售
中：该需求一定要实现，但可以做不是那完善或极致
低：该需求是否实现无所谓，不会影响到产品都可以卖出去，但是可能会影响产品的定价和销售量。也称之 为“镀金需求”
VH:核心业务+基本流
H：核心业务+备选流，基本+基本流
M：基本业务+备选流和一般业务+基本流
L：一般业务+备选流 用例优先级模型
用例优先级模型
从三个来评估用例等级：
—>使用频率
使用次数，每天使用多少次或者是每多少天使用一次
—>影响程度
如果这个用例失效了，那么对用户的影响程度
—>失效可能性
这个功能出现问题的概率有多大，每执行多少次会失效一次
上面三个维度又为会高、中、低三个级别，分别对应的权重为5、3、1。
每个维度的权重分别为：0.4、0.2、0.4
例如，如果使用频率为高、影响程度为中、失效可能性为低 5 * 0.4 + 3 * 0.2 + 1 * 0.4 ＝ 3(M)
5.预置条件
执行用例之类系统应该达到的状态
6.输入
该用例在执行测试时，需要输入的数据
7.执行步骤
步骤是我们执行这个用例时我们操作软件的步骤
8.预期结果
预期结果是从何而来的，预期结果是来自软件需求
预期应该从哪些维度来描述：
—>GUI界面：例如界面提示、对话框 —>数据库：例如，注册，注册成功后数据库中会有一条用户信息
—>相关文件：例如：QQ文件传输的默认路径，这个路径如果修改了那么就会将保存这个默认路径的配置文件 也修改。
—>日志文件：很多业务每执行一次，不管是成功还是失败都会写一条日志文件信息
延伸阅读：
二、什么叫测试用例
测试用例（Test Case）是为某个测试目标而编制的一组测试输入、执行步骤以及预期结果的集合，以便测试某个程序的路径或验证软件是否满足某个特定需求 测试用例的概念包含以下几个方面的特性：1.目标：测试用例的目的是为了达到一定目标 2.作用：去验证某个路径或某个特定的需求 3.集合：表示测试用例由多个项组成：如输入数据、步骤、预期结果等。
