Какие знаешь виды тестирования?

Виды тестирования в разработке

Тестирование — это критически важный аспект обеспечения качества системы. Как system analyst, я должен знать все виды тестирования, чтобы правильно определить требования к качеству и вклад в документацию о том, как тестировать систему.

Классификация по уровню

1. Unit Testing (Модульное тестирование)

Что это: Тестирование отдельных функций/методов в изоляции. Фокус на логике малого размера.

Примеры:

# Функция для проверки
def calculate_discount(amount: float, is_vip: bool) -> float:
    if is_vip and amount >= 1000:
        return amount * 0.9  # 10% скидка
    return amount

# Unit тесты
def test_calculate_discount_for_vip_over_1000():
    assert calculate_discount(1500, True) == 1350

def test_calculate_discount_no_vip():
    assert calculate_discount(1500, False) == 1500

def test_calculate_discount_vip_under_1000():
    assert calculate_discount(500, True) == 500

Плюсы:

• Быстрые (миллисекунды)
• Изолированные (не зависят от других модулей)
• Легко написать много
• Покрывают 90%+ логики

Минусы:

• Не проверяют integration между модулями
• Требуют mocking внешних зависимостей
• Не проверяют real database/API

Когда использую:

• Для каждой business logic функции
• Для edge cases и граничных значений
• Для обработки ошибок

2. Integration Testing (Интеграционное тестирование)

Что это: Тестирование взаимодействия между несколькими компонентами.

Примеры:

# Интеграция: Service + Repository + Database

@pytest.mark.asyncio
async def test_create_order_integration(db_session):
    # Arrange
    order_repo = OrderRepository(db_session)
    order_service = OrderService(order_repo)
    
    # Act
    order_id = await order_service.create_order(
        customer_id='cust-123',
        amount=1000
    )
    
    # Assert
    # 1. Проверяем, что сохранилось в БД
    saved_order = await order_repo.get(order_id)
    assert saved_order.amount == 1000
    
    # 2. Проверяем, что status был установлен правильно
    assert saved_order.status == 'created'
    
    # 3. Проверяем, что audit log создался
    audit_entries = await db_session.query(AuditLog).filter(
        AuditLog.order_id == order_id
    ).all()
    assert len(audit_entries) > 0

Плюсы:

• Проверяют real interactions
• Ловят проблемы на границах модулей
• Используют real database

Минусы:

• Медленнее (секунды)
• Требуют setup/cleanup БД
• Более сложны в написании
• Зависят от окружения

Когда использую:

• Для critical flows (создание заказа, платёж)
• Для проверки database integrity
• Для проверки message queue integration

3. End-to-End Testing (E2E тестирование)

Что это: Тестирование полного пути пользователя через систему. От UI до Backend.

Примеры (Playwright):

# Frontend E2E: менеджер логистики создаёт заказ

async def test_create_order_e2e(page):
    # 1. Логинимся
    await page.goto('https://logistics.com/login')
    await page.fill('[name="email"]', 'manager@company.com')
    await page.fill('[name="password"]', 'password123')
    await page.click('button:has-text("Login")')
    
    # 2. Ждём, что загрузится dashboard
    await page.wait_for_url('**/dashboard')
    
    # 3. Нажимаем "Create Order"
    await page.click('button:has-text("New Order")')
    
    # 4. Заполняем форму
    await page.fill('[name="customer_name"]', 'Ivan')
    await page.fill('[name="address"]', 'Moscow')
    await page.click('button:has-text("Create")')
    
    # 5. Проверяем, что заказ появился в списке
    await page.wait_for_selector('text=Ivan')
    assert 'Ivan' in await page.text_content('body')
    
    # 6. Проверяем, что backend сохранил данные
    order_id = await page.get_attribute('.order-id', 'data-id')
    response = await page.request.get(f'/api/v1/orders/{order_id}')
    assert response.status == 200
    order_data = await response.json()
    assert order_data['customer_name'] == 'Ivan'

Плюсы:

• Проверяют real user experience
• Ловят проблемы UI + API
• Проверяют весь flow

Минусы:

• Очень медленные (минуты)
• Хрупкие (зависят от UI селекторов)
• Требуют real browser
• Сложны в поддержке

Когда использую:

• Для critical user journeys (login, payment)
• Для regression testing перед релизом
• Для проверки интеграции frontend + backend

Классификация по функциональности

4. Functional Testing (Функциональное тестирование)

Что это: Проверяем, что система делает то, что требуется в требованиях.

Примеры:

Требование: "Система должна рассчитать скидку 10% для VIP клиентов при покупке >= 1000 руб"

Функциональные тесты:
1. VIP клиент, заказ 1000 -> скидка применена ✓
2. VIP клиент, заказ 999 -> скидка не применена ✓
3. Обычный клиент, заказ 1000 -> скидка не применена ✓

Когда использую:

• Для каждого требования
• Базовая проверка, что сделано правильно

5. Non-Functional Testing (Нефункциональное тестирование)

5.1 Performance Testing (Тестирование производительности)

Что это: Проверяем, что система работает быстро.

Примеры (k6 tool):

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 100,           // 100 одновременных пользователей
  duration: '30s',     // 30 секунд
  thresholds: {
    http_req_duration: ['p(95)<200'],  // 95% запросов < 200ms
    http_req_failed: ['rate<0.1'],     // < 10% ошибок
  },
};

export default function () {
  const res = http.get('https://api.logistics.com/orders');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });
  sleep(1);
}

Метрики:

• Response time (время ответа)
• Throughput (запросов в секунду)
• Error rate (процент ошибок под нагрузкой)

Когда использую:

• Перед production deployment
• При изменении архитектуры
• Когда production испытывает slow queries

5.2 Load Testing (Тестирование нагрузки)

Что это: Проверяем, как система ведёт себя при растущей нагрузке.

Пример:

1 час тестирования:
- 0-10 минут: 10 пользователей
- 10-20 минут: 100 пользователей (линейный рост)
- 20-30 минут: 1000 пользователей
- 30-40 минут: 5000 пользователей
- 40-50 минут: стабильно 5000 пользователей
- 50-60 минут: снижение до 0

Проверяем, как система масштабируется

5.3 Stress Testing (Тестирование на стресс)

Что это: Проверяем, что происходит, когда система выходит за пределы нормальной нагрузки.

Пример:

Нормальная нагрузка: 1000 req/sec
Тесты на стресс: 5000 req/sec (5x больше)

Ожидаем:
- Система gracefully degrade (деградирует)
- Не падает вообще
- Response time увеличивается, но не infinitely
- После снижения нагрузки восстанавливается

6. Security Testing (Тестирование безопасности)

Что это: Проверяем, что система защищена от атак.

Примеры:

# SQL Injection тест
def test_sql_injection_prevention():
    malicious_input = "'; DROP TABLE users; --"
    response = client.get(f"/api/v1/orders?search={malicious_input}")
    # Должен быть либо 400 (bad request), либо результат поиска
    # НЕ должно быть 500 (database error)
    assert response.status_code != 500

# XSS (Cross-Site Scripting) тест
def test_xss_prevention():
    malicious_input = "<script>alert('hack')</script>"
    response = client.post("/api/v1/comments", json={
        "content": malicious_input
    })
    # Проверяем, что скрипт был escapped
    comment = response.json()
    assert "<script>" not in comment["content"]
    assert "&lt;script&gt;" in comment["content"]  # escaped

# CSRF (Cross-Site Request Forgery) тест
def test_csrf_protection():
    # Попытка отправить POST без CSRF token
    response = client.post("/api/v1/orders", json={...})
    # Без token должна быть ошибка
    assert response.status_code == 403

7. Usability Testing (Тестирование удобства)

Что это: Проверяем, что система удобна для пользователя.

Методы:

• A/B Testing: две версии, смотрим какая лучше
• User Testing Sessions: реальные пользователи используют систему
• Surveys: спрашиваем у пользователей

Пример:

Тестируем две версии формы создания заказа:
Вариант A: 5 полей (классический)
Вариант B: 3 поля (минимальный)

Метрики:
- Какой процент пользователей завершают создание?
- Сколько в среднем времени на создание?
- Сколько ошибок при заполнении?

Если вариант B лучше -> перемигрируем

8. Regression Testing (Регрессионное тестирование)

Что это: Проверяем, что новые изменения не сломали старый функционал.

Когда использую:

• Перед каждым deployment
• После добавления новой фичи
• При исправлении bug'а

Пример:

Текущий release: v1.0
- Заказы работают
- Платежи работают
- Доставка работает

Разрабатываем v1.1: новая фича "реферальная система"

Регрессионные тесты:
- Заказы по-прежнему создаются? ✓
- Платежи по-прежнему обрабатываются? ✓
- Доставка по-прежнему отслеживается? ✓
+ новая фича реферальная система работает? ✓

9. Compatibility Testing (Тестирование совместимости)

Что это: Проверяем, что система работает во всех поддерживаемых браузерах, OS, device'ах.

Пример (для веб-приложения):

Браузеры:
- Chrome 90+ (Windows, Mac, Linux)
- Firefox 88+ (Windows, Mac, Linux)
- Safari 14+ (Mac, iOS)
- Edge 90+ (Windows)

Устройства:
- Desktop (1920x1080, 2560x1440)
- Tablet (iPad, Android tablet)
- Mobile (iPhone, Android)

10. Smoke Testing (Дымовое тестирование)

Что это: Быстрая проверка, что основная функциональность работает (не детально).

Примеры:

После deploy на production:

1. Система доступна? (GET /health)
2. Пользователь может залогиниться?
3. Может создать заказ?
4. Может просмотреть заказ?

Если smoke тесты не прошли -> rollback!

Когда использую:

• После каждого deployment
• Очень быстро (минуты)
• Проверяем только critical path

Таблица сравнения видов тестирования

Test Pyramid (Пирамида тестирования)

       ╱╲
      ╱  ╲     E2E Tests (slow, expensive)
     ╱────╲    10%
    ╱      ╲
   ╱        ╲
  ╱──────────╲  Integration Tests (medium)
 ╱            ╲ 30%
╱──────────────╲
╱                ╲ Unit Tests (fast, cheap)
╱────────────────╲ 60%

Пирамида показывает идеальное соотношение

Мой подход в проекте

В системе PrepBro я определил:

1. Unit Testing:

   • Все use cases протестированы (90%+ coverage)
   • Все domain entities
   • Все utilities

2. Integration Testing:

   • API endpoints (submit answer, get next question)
   • Database operations
   • Message queue integration

3. E2E Testing:

   • Critical path: agent gets question → submits answer
   • Not all edge cases (too slow)

4. Security Testing:

   • API key validation
   • Input validation (SQL injection, XSS)
   • Authorization checks

5. Performance Testing:

   • Response time < 200ms для получения следующего вопроса
   • Throughput >= 1000 requests/sec
   • Load test перед deployment

Этот подход обеспечивает баланс между скоростью разработки, качеством и затратами.