自动化测试基础杂谈

自动化测试的优势

1）代替大量的手工机械重复性操作。
2）大幅提升回归测试的效率。
3）实现某些手工测试无法完成的测试类型如7*24小时持续运行的系统稳定性测试和高并发场景的压力测试。

4）可以进行兼容性测试。

自动化测试劣势

1）不能取代手工测试。自动化测试不能发现新的缺陷。
2）比手工测试脆弱，测试用例维护成本高
3）开发工作量大
4）需要编程能力。

5）不是所有项目都能够自动化。

什么项目适合自动化测试？

1）需求稳定，不会频繁变更。
2）研发和维护周期长，需要频繁执行回归测试。
短期项目建议手工探索式测试。

中长期项目-对比较稳定的软件功能进行自动化测试，对变动较大或需求暂时不明确的功能进行手工测试。

用20%的精力去覆盖80%的回归测试。
3）需要在多平台上重复运行相同测试的场景。
4）某些测试手工无法实现如性能和压力测试。
5）被测软件测开发较为规范，能保证系统的可测试性
 

软件开发不同阶段的自动化

单元测试自动化

单元测试本身就是自动化的，因为它根据软件详细设计采用等价类划分和边界值分析方法设计测试用例，在测试代码实现后再以自动化的方式统一执行。这个观点非常正确，但这仅仅是一部分，并没有完整地描述单元测试“自动化”的内涵。

从广义上讲，单元测试阶段的“自动化”内涵不仅仅指测试用例执行的自动化，还应该包含以下五个方面：

用例框架代码生成的自动化

（TestNG 框架代码应该由自动化工具生成 框架代码都可以自动生成）

部分测试输入数据的自动化生成

自动桩代码的生成

（自动桩代码的生成是指自动化工具可以对被测试代码进行扫描分析，自动为被测函数内部调用的其他函数生成可编程的桩代码，并提供基于测试用例的桩代码管理机制 比如什么工具？）

自动桩代码的生成是指自动化工具对被测试代码进行扫描分析，并自动为被测函数内部调用的其他函数生成可编程的桩代码。这种自动化工具可以提供基于测试用例的桩代码管理机制，使得单元测试开发者可以专注于桩代码内的具体逻辑实现以及桩代码的返回值。在必要时，这种自动化工具还可以实现“抽桩”，以适应后续的代码级集成测试的需求。

好的，以Python的unittest框架为例，可以手动创建一个测试用例，并在测试用例中创建一个Mock对象来模拟被测函数所依赖的其他函数。例如：

在这个例子中，我们使用Mock对象来模拟my_function所依赖的其他函数。然后我们调用my_function并断言它的返回值。

然而，这种方法可能会比较繁琐，尤其是在有大量被测函数需要测试的情况下。因此，一些自动化工具可以帮助我们自动创建Mock对象。例如，在上述代码中，我们可以使用Python的unittest框架的patch装饰器来自动创建Mock对象。例如：

from unittest.mock import Mock  
  
def test_some_function():  
    # 创建一个Mock对象来模拟被测函数所依赖的其他函数  
    mock_dependency = Mock()  
  
    # 用被测函数调用Mock对象  
    result = my_function(mock_dependency)  
  
    # 断言被测函数的返回值  
    assert result == "expected result"

from unittest.mock import patch  
  
def test_some_function():  
    # 使用patch装饰器来替换被测函数所依赖的其他函数  
    with patch('mymodule.mydependency') as mock_dependency:  
        # 用被测函数调用Mock对象  
        result = my_function()  
  
        # 断言被测函数的返回值  
        assert result == "expected result"

在这个例子中，使用了patch装饰器来自动创建Mock对象，我们不再需要在测试用例中手动创建Mock对象。patch装饰器会自动将被测函数所依赖的其他函数替换成Mock对象。然后我们就可以用被测函数调用这个Mock对象并执行测试用例了。这种自动化方式可以减少我们的工作量，使我们可以专注于测试用例的逻辑实现。

好的，再以Java的Mockito库为例，可以手动创建一个测试用例，并在测试用例中创建一个Mock对象来模拟被测函数所依赖的其他函数。例如：

import static org.mockito.Mockito.*;  
  
public class MyTest {  
  
    @Test  
    public void testSomeFunction() {  
        // 创建一个Mock对象来模拟被测函数所依赖的其他函数  
        MyDependency mockDependency = mock(MyDependency.class);  
  
        // 用被测函数调用Mock对象  
        String result = myFunction(mockDependency);  
  
        // 断言被测函数的返回值  
        assertEquals("expected result", result);  
    }  
}

在这个例子中，我们使用Mockito库来手动创建一个Mock对象。然后我们调用myFunction并断言它的返回值。

然而，这种方法可能会比较繁琐，尤其是在有大量被测函数需要测试的情况下。因此，一些自动化工具可以帮助我们自动创建Mock对象。例如，在上述代码中，我们可以使用Java的Mockito库的@Mock注解来自动创建Mock对象。例如：

import static org.mockito.Mockito.*;  
  
public class MyTest {  
  
    @Mock  
    private MyDependency mockDependency;  
  
    @Test  
    public void testSomeFunction() {  
        // 用被测函数调用Mock对象  
        String result = myFunction();  
  
        // 断言被测函数的返回值  
        assertEquals("expected result", result);  
    }  
}

在这个例子中，使用了@Mock注解来自动创建Mock对象，我们不再需要在测试用例中手动创建Mock对象。@Mock注解会自动将被测函数所依赖的其他函数替换成Mock对象。然后我们就可以用被测函数调用这个Mock对象并执行测试用例了。这种自动化方式可以减少我们的工作量，使我们可以专注于测试用例的逻辑实现。

被测代码的自动化静态分析

（比较常用的代码静态分析工具有 Sonar 和 Coverity）

测试覆盖率的自动统计与分析。（代码行覆盖率、分支覆盖率、MC/DC 覆盖率）

代码级集成测试的自动化技术

现在的开发理念追求的是系统复杂性的解耦，会去尽量避免“大单体”应用，采用 Web Service 或者 RPC 调用的方式来协作完成各个软件功能。所以现在的软件企业，尤其是互联网企业，基本不会去做代码级集成测试，在这里也就不再进一步展开了。

Web Service 测试的自动化技术

Web Service 测试，主要是指 SOAP API 和 REST API 这两类 API 测试，最典型的是采用 SoapUI 或 Postman 等类似的工具。但这类测试工具基本都是界面操作手动发起 Request 并验证 Response，所以难以和 CI/CD 集成，于是就出现了 API 自动化测试框架。如API 自动测试框架是 REST Assured

GUI 测试的自动化技术

基于页面元素识别技术，对页面元素进行自动化操作，以模拟实际终端用户的行为并验证软件功能的正确性。

对于传统 Web 浏览器的 GUI 自动化测试，业内主流的开源方案采用 Selenium，商业方案采用 Micro Focus 的 UFT（前身是 HP 的 QTP）；

对于移动端原生应用，通常采用主流的 Appium，它对 iOS 环境集成了 XCUITest，对 Android 环境集成了 UIAutomator 和 Espresso