软件测试 | 测试用例——如何写好一个用例

测试用例（Test Case）是为某个测试目标而编制的一组测试输入、执行步骤以及预期结果的集合，以便测试某 个程序的路径或验证软件是否满足某个特定需求，那么怎么写好一个用例呢？

---

1.什么叫测试用例

测试用例（Test Case）是为某个测试目标而编制的一组测试输入、执行步骤以及预期结果的集合，以便测试某 个程序的路径或验证软件是否满足某个特定需求 测试用例的概念包含以下几个方面的特性： 1.目标：测试用例的目的是为了达到一定目标 2.作用：去验证某个路径或某个特定的需求 3.集合：表示测试用例由多个项组成：如输入数据、步骤、预期结果等。

2.为什么需要写测试用例

主要原因如下：

1. 让执行测试的人可以更简单完成
2. 如果出现人员离职时，用例可以让新员工很快切入项目
3. 测试用例也是一种测试能力的积累
4. 可以让测试变的更全面

3.测试用例的格式

测试用例的格式主要包含以下字段：

3.1.测试项目

本次测试的功能点，如登录

3.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.3.测试标题

测试标题表示该用例测试的目标

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)

3.5.预置条件

执行用例之类系统应该达到的状态

3.6.输入

该用例在执行测试时，需要输入的数据

3.7.执行步骤

步骤是我们执行这个用例时我们操作软件的步骤

3.8.预期结果

预期结果是从何而来的，预期结果是来自软件需求

预期应该从哪些维度来描述：

--->GUI界面：例如界面提示、对话框 --->数据库：例如，注册，注册成功后数据库中会有一条用户信息

--->相关文件：例如：QQ文件传输的默认路径，这个路径如果修改了那么就会将保存这个默认路径的配置文件 也修改。

--->日志文件：很多业务每执行一次，不管是成功还是失败都会写一条日志文件信息

4.例子

5.注意事项 （易忽略）

预期输出要把预期结果写完整，不能少写或者写错

执行步骤要写详细，该贴链接贴链接，”傻瓜也能按照步骤流程做下来"

需要输入的内容写清楚，一定是符合本次测试要求的内容

测试用例编号写规范

---

关注我，持续更新中。。。