软件测试用例(3)

た入场券 2024-04-06 15:58 92阅读 0赞

**目录**

什么样的测试用例是一个好的测试用例

什么是测试用例的有效性?

测试用例的粒度和评价

粒度

评价

--------------------

## 什么样的测试用例是一个好的测试用例 ##

### 什么是测试用例的有效性? ###

**测试用例的有效性指的是测试用例是否能够有效地检测出软件系统中的错误或问题.**

一个有效的测试用例应该具备以下特点:

> 1.**覆盖率**: **测试用例应该覆盖尽可能多的代码路径, 条件和边界情况**, 以确保对系统的各个方面进行全面的测试. (差不多可以理解为白盒测试)
> 
> 2.**准确性**: **测试用例的设计应该准确地反映出系统的实际需求和预期行为.** 测试用例应该基于正确的需求和规范编写, 确保测试的结果是可信的.
> 
> 3.**独立性**: **测试用例应该相互独立, 即一个测试用例的执行不应该影响其它测试用例的结果**. 这样可以确保每个测试用例都能够独立地发现问题, 而不会因为其它因素的干扰而遗漏错误.
> 
> 4.**可重复性**: 测试用例应该能够重复执行, **即在相同的环境和条件下, 多次执行同一个测试用例应该得到相同的结果**. 这样可以确保问题可以被准确地重现和定位.
> 
> 5.**可维护性**: **测试用例的编写应该具有良好的可维护性, 即易于理解, 修改和扩展**, 随着系统的变化和演进, 测试用例也需要相应地进行更新和维护, 以保持测试的有效性.

### 测试用例的粒度和评价 ###

#### 粒度 ####

**好的测试用例是一个不熟悉业务的人也能根据用例来很快地进行测试**.

> **粒度: 指测试用例编写的详细程度**.

**测试用例可以写得很简单, 也可以写得很复杂. 最简单的测试用例是测试的纲要, 仅仅指出要测试的内容**, 如探索性测试中的测试设计, 仅指出需要测试产品的哪些要素, 需要达到的质量目标, 需要使用的测试方法等. 而复杂的测试用例就像飞机维修人员使用的工作指令卡一样, **会指定输入的每项数据, 期待的结果及检验方法**, 具体到界面元素的操作步骤, 指定测试的方法和工具等.

> (1)测试用例写得过于复杂或详细, 会带来两个问题: 一个是效率问题, 另一个是维护成本问题. 另外, 测试用例设计得过于详细, 留给测试人员得思考空间就比较少, 容易限制测试人员思维.
> 
> (2)测试用例写得过于简单, 则可能失去了测试用例的意义. 过于简单的测试用例的设计其实并没有进行"设计", 只是把需要测试的功能模块记录下来而已, 它的作用仅仅是在测试过程中作为一个简单的测试计划, 提醒测试人员测试的主要功能包括哪些而已. 测**试用例的设计本质应该是在设计过程中理解需求, 检验需求, 并把对软件系统的测试方法的思路记录下来, 以便指导将来的测试.**

大多数测试团队编写的测试用例的粒度介于两者之间. 而**如何把握好粒度是测试用例设计的关键, 也将影响测试用例设计的效率和效果**. **应该根据项目的实际情况, 测试资源情况来决定设计出怎样粒度的测试用例**.

主要考虑可以包含以下内容:

> 产品的质量要求.
> 
> 项目对用例的要求.
> 
> 测试时间和资源是否充分.

**但不管用例怎么简化, 都不应该省略**.

#### 评价 ####

测试用例设计出来了, 如何提高测试用例设计的质量? 就像软件产品需要通过各种手段来保证质量一样. 测试用例的质量保证也需要综合使用各种手段和方法. 评审分为正式和非正式评审.

> 同行评审
> 
> 用户检查
> 
> 项目组评审

(1)**测试用例的检查可以有多种方式, 但是最敏捷的应当属于临时的同行评审**. 同行评审, 应该演变为类似结对编程一样的方式. 从而**体现敏捷的"个体和交互比过程和工具更有价值"**, 要强调测试用例设计者之间的思想碰撞, 通过讨论, 协作来完成测试用例的设计, 原因很简单, 测试用例的目的是尽可能全面地覆盖需求, 而测试人员总会存在某方面的思维缺陷, 一个人的思维总是存在局限性. 因此需要一起设计测试用例.

(2)**除了同行评审, 还应该尽量引入用户参与到测试用例的设计中来, 让用户参与评审, 从而体现敏捷的"顾客的协作比合同谈判更有价值"这一原则.** 这里顾客的含义比较广泛, 关键在于如何定义测试, 如果测试是对产品的批判, 则顾客应该指最终用户或顾客代表(在内部可以是市场人员或领域专家); 如果测试是被定义为对开发提供帮助和支持, 那么顾客就是指程序员了.