1 引言

执行测试时离不开测试用例，测试用例辅佐执行测试，这就好比皇帝与宰相，需要的是相辅相成。

既然相辅相成，那是不是就可以高枕无忧了？

其则不然，任何事情都会有出错的可能，所以，测试用例也不列为。

我们今天来看看，测试用例是如何出错。

2 何为资源泄露

2.1 资源泄露定义

1、什么是资源泄露：

资源泄露是指程序在使用完自己获取的资源之后，没有及时释放。

资源泄露可能导致系统资源耗尽，造成程序不稳定甚至崩溃。

2、举例：

内存是一种资源，内存泄露bug，常常是造成程序out of memory的罪恶魁首。

2.2 TestCase 中资源泄露

1、TestCase的稳定性

自动化测试的稳定性由多方面决定，包括被测软件的稳定性、测试环境的稳定性和测试用例自身的稳定性等。

资源泄漏，是造成测试用例自身不稳定的重要因素。

2、出现原因：

当用例执行结束时，如果没有删除用例执行过程中向数据库插入的数据，可能就会导致数据泄漏。

数据泄漏可能造成后续用例执行失败(当后续用例试图创建同样的数据时)，也可能造成用例在重复执行一定次数之后突然失败(数据量超出一定限制时)。

3 避免资源泄露

3.1 如何避免资源泄露

在实际情况中，我们如何避免资源泄露，提升自动化用例稳定性？

很简单，只需要做一件事：在测试用例结束前，清理不必要的资源。

尤其是当用例出现异常情况(例如执行失败)时，我们要保证清理资源的操作得到执行。

这也就是说，我们在设计自动化框架或者写自动化脚本，最后都需要teardown 或者close的原因。

3.2 自动化执行顺序

1、自动化执行顺序

自动化用例的执行顺序不完全是线性的：初始化资源 -> 测试步骤 -> 释放资源，

而有一定的非线性特征：[Setup] 初始化资源 -> 测试步骤 -> [Teardown] 释放资源。

2、如下：

    setup     testsuit     teardown

    成功         成功             执行

    成功         失败             执行

    失败         不执行         不执行

通过上组示例，可以看出，无论测试步骤成功与否，teardown都一定会执行；

我们应当将释放资源的步骤放置在teardown中，从而确保资源在用例结束前得到释放。

注意到，基于setup、teardown的自动化用例编写方式，与通用编程语言(例如Java、Python、JS等)提供的try — catch – finally语法有异曲同工之妙。

3、try – catch – finally 执行 流程图

无论程序是否出现异常，finally模块都会执行。

因此，最佳编程实践告诉我们，通过将关闭资源的操作放置在finally语句块中，我们可以确保资源得到关闭，从而提升代码的健壮性。

我们可以看到，编写高质量代码与编写高质量测试用例其实是相通的。

灵活运用setup、teardown，像写clean code一样写自动化用例，是我们提升自动化测试稳定性的重要方法。

关注我，带你学习更多测试开发知识。