Перейти на PRO

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

Тип вопроса: Основы тестирования Вероятность: 10% Категория: QA Тестировщик

Ответ

Сложный баг: Race Condition (состояние гонки) при параллельном обновлении баланса пользователя через API.

Проблема: При быстрых последовательных запросах на пополнение счета (например, два одновременных запроса на +50 и +30 к балансу 100) итоговый баланс мог стать 130 или 150, вместо корректных 180. Данные терялись.

Исследование и воспроизведение:

  1. Анализ: Изучение логики кода показало уязвимость: баланс = прочитать_из_БД(); баланс += сумма; сохранить_в_БД(баланс).
  2. Воспроизведение: Создание скрипта для имитации параллельных запросов. 
    
import concurrent.futures
import requests

Функция для пополнения баланса

def add_funds(user_id, amount): response = requests.post( f"https://api.example.com/users/{user_id}/balance", json={"action": "add", "amount": amount} ) return response.json()

Запуск 10 параллельных запросов

user_id = "user123" with concurrent.futures.ThreadPoolExecutor(max_workers=10) as executor: futures = [executor.submit(add_funds, userid, 10) for in range(10)] results = [f.result() for f in futures]

Проверка итогового баланса - может быть меньше 100 (стартовый 0 + 10*10)

final_balance = requests.get(f"https://api.example.com/users/{user_id}/balance").json() print(f"Итоговый баланс: {final_balance}") # Может быть 60, 70 и т.д.


3.  **Логирование:** Добавление детального логирования (ID запроса, баланс до/после) помогло увидеть "наложение" операций.

**Причина и решение:**
*   **Причина:** Отсутствие механизма блокировки или атомарности операций на уровне БД.
*   **Решение:**
    1.  **Оптимальное:** Изменить логику на атомарную операцию БД: `UPDATE balance SET value = value + :amount WHERE user_id = :id`.
    2.  **Альтернативное:** Внедрить **оптимистичную блокировку** (проверка версии записи) или **пессимистичную блокировку** (SELECT FOR UPDATE) на уровне приложения.

**Итог:** Баг был исправлен переходом на атомарный SQL-запрос. Это подчеркивает важность тестирования многопоточных сценариев и понимания работы с данными в конкурентной среде.

Ответ 18+ 🔞

Ах ты ж ёпта, ну и накололись мы с этим балансом, блядь! Прямо классика жанра, состояние гонки, сука! Представь: два запроса прилетают одновременно, как два охуевших курьера в одну дверь, и начинают там в нашей базе данных хуйню творить.

В чём, блядь, соль была? Проблема-то проще пареной репы, но коварная, как змея подколодная. Логика у нас была — просто пиздец какая наивная:

  1. Читаем текущий баланс из БД. Допустим, 100 рублей.
  2. Прибавляем к нему сумму, скажем, 50. Получаем 150 в уме.
  3. Пишем эти 150 обратно в БД.

А теперь, блядь, смотри сюда, как это ебётся. Прилетают два запроса почти одновременно:

  • Запрос А читает баланс (100).
  • Запрос Б ТОЖЕ, сука, успевает прочитать баланс, пока А ещё не записал (тоже 100, ёбта!).
  • Запрос А прибавляет свои 50, получает 150 и пишет.
  • Запрос Б, который уже прочитал старые 100, прибавляет свои 30, получает 130 и ПИШЕТ ПОВЕРХ результата А! Вот и всё, пиши пропало. Вместо 180 на счёте красуется 130. Деньги, блядь, испарились! Пользователь в ярости, бухгалтер в панике, а мы сидим и чешем репу.

Как мы эту поебень ловили? Ну, сделали мы скриптик, который как обезьяна с гранатой — начинает долбить АПИшку параллельными запросами. Смотри, какой простой, но убийственный инструмент:

import concurrent.futures
import requests

def add_funds(user_id, amount):
    response = requests.post(
        f"https://api.example.com/users/{user_id}/balance",
        json={"action": "add", "amount": amount}
    )
    return response.json()

user_id = "user123"
with concurrent.futures.ThreadPoolExecutor(max_workers=10) as executor:
    futures = [executor.submit(add_funds, user_id, 10) for _ in range(10)]
    results = [f.result() for f in futures]

final_balance = requests.get(f"https://api.example.com/users/{user_id}/balance").json()
print(f"Итоговый баланс: {final_balance}")  # Может быть 60, 70 и т.д.

Запустили — и охуели! Отправили 10 запросов по 10 рублей, а на счёте вместо сотни — 60, 70, всякая хуйня. Прямо волнение ебать! Потом логи добавили, смотрели, как один запрос перетирает результаты другого. Картина маслом, блядь.

И как, спрашивается, лечили эту хворь? А корень зла, блядь, в том, что мы с базой работали как слоны в посудной лавке — прочитали, посчитали в приложении, записали. Надо было доверить эту работу профессионалу — самой базе данных!

Решение, которое всех спасло:

  1. Идеальное, блядь: Выкинули всю свою хуйню с чтением-сложением и сделали один атомарный SQL-запрос: UPDATE balance SET value = value + :amount WHERE user_id = :id. Теперь база сама, одним движением, накидывает сумму. Никакие два потока друг другу не помешают. Красота!

  2. Можно было и так, но сложнее: Заморачиваться с оптимистичной блокировкой (проверять версию записи) или пессимистичной (лочить строку нахуй через SELECT FOR UPDATE). Но зачем, если есть простое решение?

Итог, блядь: Починили всё одним SQL-запросом. Мораль сей басни такова: никогда не рассчитывай, что твой код будет выполняться в вакууме один-одинёшенек. Всгда найдётся ещё один поток, который прилетит и нассёт тебе в тапки, если не предусмотреть блокировки. Тестируй на параллелизм, сука, как следует!

© ХакСобесов, 2026
support@hacksobesov.com