Приведи примеры статического тестирования

Примеры статического тестирования

Статическое тестирование — это анализ артефактов разработки ПО без выполнения самого кода. Оно проводится на ранних этапах жизненного цикла, позволяет находить дефекты дешевле и быстрее. Его также называют анализом "белым ящиком" без исполнения (Static White Box Testing). Главная цель — повысить качество требований, дизайна и кода до начала динамического тестирования.

Основные категории статического тестирования

1. Неформальное и формальное ревью

Проверка документов коллегами для выявления несоответствий, двусмысленностей и ошибок.

• Неформальное ревью (ad-hoc): Коллега просматривает требования к новой функции CRM-системы, отмечает, что описание поля "Дата контракта" не указывает формат (DD.MM.YYYY vs YYYY-MM-DD).
• Техническое ревью: Архитектор и старший разработчик анализируют диаграмму последовательности (sequence diagram) для микросервиса оплаты, находят отсутствие обработки таймаута при вызове банковского шлюза.
• Инспекция (формальное ревью): Структурированный процесс с ролями (модератор, автор, секретарь). Например, инспекция требований к API перед началом разработки. Команда сверяет спецификацию OpenAPI с бизнес-требованиями, используя чек-лист, фиксируя все замечания в протоколе.

2. Статический анализ кода (Static Code Analysis)

Автоматизированная проверка исходного кода на соответствие стандартам, выявление потенциальных уязвимостей и "запахов кода" (code smells).

Пример 1: Поиск уязвимостей безопасности (SAST)

# Пример кода с уязвимостью SQL-инъекции (плохая практика)
def get_user_input():
    user_id = request.args.get('id')  # Пользовательский ввод напрямую из запроса
    query = f"SELECT * FROM users WHERE id = {user_id}"  # ОПАСНО: вставка в строку запроса
    result = execute_sql(query)
    return result

Статический анализатор (например, SonarQube, Bandit для Python) автоматически обнаружит эту ошибку и выдаст предупреждение: "Detected possible SQL injection". Рекомендация — использовать параметризованные запросы.

Пример 2: Проверка соответствия стандартам кодирования

// Пример нарушения соглашений о коде (Code Conventions)
public class OrderService {
    private String OrderID; // Нарушение: имя поля должно начинаться с lowercase (orderID)

    public void Process() { // Нарушение: имя метода должно начинаться с lowercase (process)
        if(true) { // Нарушение: условие всегда true - dead code
            System.out.println("Processing...");
        }
    }
}

Инструменты вроде Checkstyle, PMD или встроенные линтеры IDE (ESLint для JS, Pylint для Python) проверят код на соответствие Google Java Style Guide или PEP 8 для Python и сгенерируют отчет о нарушениях.

Пример 3: Анализ метрик кода и зависимостей

// Пример функции с высокой цикломатической сложностью (плохая читаемость)
function calculateDiscount(userType, cartTotal, isPromo, yearsClient) {
    if (userType === "vip") {
        if (cartTotal > 1000) {
            if (isPromo) {
                return cartTotal * 0.25;
            } else {
                if (yearsClient > 5) {
                    return cartTotal * 0.2;
                } else {
                    return cartTotal * 0.15;
                }
            }
        }
        // ... и ещё множество вложенных if-else
    }
    // ... другие условия
}

Анализаторы (например, SonarQube) рассчитают цикломатическую сложность (McCabe). Если она превысит порог (например, 10), будет зафиксировано нарушение "Refactor this function to reduce its complexity". Также инструменты могут строить графы зависимостей между модулями и выявлять циклические зависимости.

3. Анализ моделей и спецификаций

Проверка корректности архитектурных и дизайн-артефактов.

• Валидация UML-диаграмм: Проверка, что на диаграмме классов для модуля аутентификации корректно отображены отношения наследования между классами User, AdminUser, GuestUser.
• Анализ пользовательских историй (User Stories): Проверка, что каждая история в бэклоге продукта соответствует шаблону: "Как [роль], я хочу [функция], чтобы [ценность]". Например, история "Добавить кнопку" будет отклонена как некорректная, так как не описывает ценность.
• Проверка State Transition-диаграммы: Анализ диаграммы состояний заказа ("Создан", "Оплачен", "Отгружен", "Отменен") на полноту и отсутствие недостижимых состояний.

4. Анализ тестовых артефактов

Проверка качества самих тестовых сценариев и данных.

• Ревью тест-кейсов: Коллега проверяет набор тест-кейсов для формы регистрации. Обнаруживает, что отсутствует проверка граничных значений для поля "Возраст" (например, значение 0 или 150).
• Статический анализ автотестов:

# Пример потенциально хрупкого (flaky) автотеста
def test_login(driver):
    driver.get("https://example.com/login")
    # Потенциальная проблема: явное ожидание без обработки исключений
    time.sleep(10)  # Жёсткая пауза - тест может упасть, если страница загрузится медленнее
    driver.find_element(By.ID, "username").send_keys("test")

Анализ может выявить использование time.sleep() и рекомендовать заменить на явные ожидания (Explicit Waits) из Selenium WebDriver.

Преимущества статического тестирования на практике

• Раннее обнаружение дефектов: Нахождение противоречий в требованиях до начала разработки экономит в 10-100 раз больше ресурсов, чем исправление бага на продакшене.
• Предотвращение "размывания" архитектуры: Статический анализ графа зависимостей не даст разработчикам создать циклическую зависимость между модулями "Платежи" и "Заказы", что сохранит поддерживаемость системы.
• Унификация кодовой базы: Автоматические проверки стиля кода гарантируют, что код 50 разработчиков в большой команде выглядит единообразно, что упрощает его чтение и ревью.
• Повышение безопасности: SAST-инструменты, интегрированные в CI/CD пайплайн, непрерывно сканируют код на наличие известных уязвимостей (OWASP Top 10), например, XSS или небезопасные десериализации.

Итог: Статическое тестирование — это не единовременное действие, а непрерывная практика, встроенная в процесс разработки (часть Shift-Left подхода). Его комбинация с динамическим тестированием создает мощный механизм контроля качества на всех этапах жизненного цикла ПО.