测试用例基础

软件测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

IEEE Standard 829-1983中定义测试用例为:测试用例是指定输入，预期结果和一组测试项的执行条件的文档。

一、测试用例的作用：

1.避免盲目测试，提高测试效率

编写测试用例有利于测试的组织。在开始实施测试之前设计好测试用例，可以避免盲目测试，提高测试效率，特别是对于测试人员中的新手，好的测试用例可以帮助他们更好地完成复杂的测试任务，提高测试工作的效率。

2.确保功能需求不被遗漏

测试用例是根据功能需求细细推敲而来的并且通过了严格的评审，按照测试用例执行测试，可以使软件测试的实施重点突出、目的明确，确保功能不会被漏测。

3.便于回归测试

在项目执行测试期间会有多次回归测试，以保证老的缺陷被成功修复，同时没有引入新的缺陷。如果没有测试用例，凭脑子记住之前的操作步骤是不可能的，这样就无法复原原有的测试过程。

4.为测试的度量提供评估基准

测试完毕后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量软件测试质量都需要一些量化的结果。比如测试用例的执行率是多少、成功测试用例的执行率是多少、需要的测试合格率是多少，等等。测试用例可以为这些结果提供量化数据和评估的基准。

二、测试用例的设计步骤

1.获取需求的测试点：

显性需求和隐性需求（需求文档）

没有需求文档时，应该怎么做:阅读遗留文档，收集整理已有的需求； 向有关人员咨询； 参考同类产品的需求说明书； 采用探索性测试的解决方案。

分析系统程序的工作流程，明确各个功能模块的需求，明确测试范围，提取所要测试的具体测试点，为编写测试用例提供依据和思路。

2.设计测试用例模板，设计测试步骤

3.确定测试数据

4.评审测试用例

三、测试用例模板

编写测试用例应有文档模板，模板必须符合内部的规范要求。软件测试用例的基本要素应该包括用例编号、测试模块（测试对象）、测试标题（测试点）、用例级别、测试环境、测试输入、操作步骤、预期结果。

通常，我们用 Excel 表格的形式来书写测试用例

用例编号:用例编号是标识该测试用例的唯一编号，用以区别其他测试用例。测试用例的编号有它的定义规则，可以写成“项目名称-测试阶段类型-编号”或者“项目名称-模块名-编号”。比如 LQ-ST-001（LQ 软件系统测试用例 001，此处假设“LQ”是一个项目的名称）或者 LQ-Login-001（LQ 软件登录模块测试用例 001）。定义编号的规则主要是便于检索。

测试对象:也可以叫做“测试模块”。指明要测试的项目、子项目或者软件的被测模块。如：xx 菜单、登录模块、购物车等。测试模块有时候还有子模块、子子模块，直接增加在表格中即可。

测试点：也可以叫做“测试标题”。测试点应该清楚地表达测试用例的用途，如“测试输入错误的密码进行登录时，软件的响应情况”。

测试环境：有时候也写作“前提条件”。是执行测试时所单独需要的特殊环境要求。或者执行测试用例之前所做的操作，如启动程序等。

操作步骤：操作步骤是执行本测试用例的每一步操作。需要注意的是每一步骤都要有一个编号，便于查看。描述要简洁、清楚、明确、完整、一致。

测试数据：描述测试用例所需的输入数据或条件。例如：测试计算器时，输入可以是 1+1，也可以是 1+2；除了数据之外，还可以是文件或具体操作（如单击鼠标、在键盘做按键处理等）。

用例级别；也叫测试用例的优先级，这部分涉及内容比较多，也是测试用例中比较重要的一个项，在本章下一个小节中单独详细介绍。

预期结果:描述输入数据后程序应该的输出结果。例如，输入 1+1，预期结果是 2；输入文件名，预期结果是可以正确打开文件，文件的内容和预期一致。通常，我们可以通过检查具体的屏幕、报告、文件等方式来确认实际结果与预期结果是否一致。

以下以登录界面（假设界面只有“用户名”输入框和“密码”输入框，以及“登录”按钮）为例，来写几条测试用例，供读者熟悉具体写法。

四、测试用例优先级

1-小版本确认测试（Build Verification Tests，BVTs）：也叫冒烟测试，这是一组需要优先执行以确认该软件版本是否可以继续测试的测试用例。BVTs 级别的测试用例如果测试失败会阻碍其他测试用例的验证，因为 BVTs 测试不能通过的时候，试图去执行其他部分的测试没有意义。比如登录功能中，如果连正确的用户名和正确的密码都无法成功登录的话，再去测试其他登录的情况就是毫无意义的。这种用例一般占总用例的 10%~15%。

2-高（High）：是指最常被执行的、保证功能稳定、目标的行为和能力正常工作的、能发现重要错误的测试用例的集合，这部分测试用例一般占总用例的 20%~30%。

3-中（Medium）：这部分用例更全面的验证功能的各个方面，主要指异常测试，如边界、断网、容错和配置测试的测试用例。这部分用例一般占总用例的 40%~60%。

4-低（Low）：这是一组最少被执行的测试用例。但这并不是说这些测试用例不重要，只是说他们在项目的生命周期里不是常常被执行，例如 GUI，错误信息，可用性，压力和性能测试。这部分用例一般占总用例的 10%~15%。

那如何划分测试用例优先级呢？

1.按照一定的逻辑把软件测试用例先随意进行分级

把所有功能性验证的测试用例标记为“高”优先级；把所有错误和边界值的测试用例标记为“中”优先级；把所有非功能性的测试用例（如性能和可用性）标记为“低”优先级。

2.并非所有的功能性测试用例都一样的重要。那么对于已经分配好优先级别的测试用例可进行提级或降级。

把功能性验证的测试用例分成两组：重要的和不十分重要的。

把“不十分重要的”测试用例降级为“中”优先级；

把所有错误和边界值的测试用例分成两组：重要的和不十分重要的。

然后把“重要的”升级为“高”优先级；

把非功能性测试用例分为两组：重要的和不十分重要的。把“重要的”升级为“中”优先级

3.识别 BVTs 测试用例：

将“高”优先级别的测试用例分成两组：严重和重要的。然后把“严重的”测试用例升级为 BVTs 优先级。

五、测试用例基本设计原则

1.测试用例的描述要明确

2.测试用例的描述要简洁

3.测试用例对需求的覆盖采用最小化原则：比如说，有一个系统功能模块，有 3 个子功能，那么我们是用一个测试用例覆盖三个子功能呢？还是用三个单独的测试用例分别覆盖三个子功能呢？对于稍微有点规模的项目，推荐后者。因为一旦发现了缺陷，指向性更强，便于调试。

4.测试用例编写要有条理、逻辑性强：测试用例可以按照功能点分类、操作顺序等逻辑顺序编写，而不要一会测试这里，一会测试那里，会让人无所适从。

5.功能覆盖全面、深入，能够发现软件中更多的缺陷：除了通过测试外，可以多想一些异常的操作流程进行失败测试，试图破坏软件，查看软件的响应情况。