AI-система для автоматизації тестування та QA ПЗ

AI-система тестування та QA програмного забезпечення

Ваш coverage-звіт показує 90% рядків, але production-баги все одно прослизають. Чому? Тому що line coverage не враховує бізнес-сценарії, граничні значення та інтеграційні стики. AI-система QA вирішує цю проблему, аналізуючи AST, вимоги з Jira та мутаційне тестування. Результат: покриття граничних кейсів зростає з 30% до 95%. Понад 5 років ми впроваджували такі системи для 50+ проєктів — від стартапів до enterprise. Середня економія на QA-команді після впровадження становить 40–60%, а кількість production-інцидентів знижується на 50–70% за перші три місяці. Оцінимо ваш проєкт за один день — просто зв'яжіться з нами. Замовте попередній аналіз і дізнайтеся, скільки багів ховається у вашому коді.

Проблеми, які вирішуємо

• Хибне відчуття безпеки. 100% line coverage не гарантує, що протестовані всі бізнес-сценарії. AI знаходить логічні пропуски.
• Крихкість тестів. При рефакторингу тести ламаються — AI-самовідновлення адаптує їх під нову архітектуру.
• Сліпі зони інтеграцій. Модульні тести не бачать помилки на стиках компонентів. AI генерує інтеграційні тести на основі графа викликів.
• Витрати ручної праці. Тестувальник витрачає до 60% часу на рутину — AI бере на себе генерацію базових та граничних кейсів.

Компоненти AI-системи тестування

[Code Analysis]        [Requirement Analysis]
  AST парсинг            NLP з Jira/Confluence
       ↓                        ↓
[Test Generation Engine]
  Unit | Integration | E2E | API
       ↓
[Test Prioritization]
  Change Impact Analysis → запускати потрібні тести, не всі
       ↓
[Result Analysis]
  Failure Classification + Root Cause Suggestion
       ↓
[Coverage Intelligence]
  Семантичні прогалини в покритті

Кожен компонент — окремий мікросервіс, що спілкується через RabbitMQ. Це дозволяє незалежно масштабувати генерацію та аналіз.

Як AI знаходить семантичні прогалини в покритті?

Традиційний coverage (Istanbul, JaCoCo) рахує рядки. Проблема: 100% line coverage не означає, що протестовані всі бізнес-сценарії. Наш SemanticCoverageAnalyzer використовує GPT-4o з температурою 0.1 для детекції пропусків:

from langchain_openai import ChatOpenAI
import ast
import textwrap

class SemanticCoverageAnalyzer:
    """Аналізує семантичні прогалини в тестовому покритті"""

    ANALYSIS_PROMPT = """Проаналізуй функцію та існуючі тести.
Визнач, які бізнес-сценарії та граничні умови НЕ покриті.

Функція:
```python
{function_code}

Існуючі тести:

{existing_tests}

Визнач непокриті сценарії:

1. Граничні значення (empty string, None, 0, max int, negative)
2. Комбінації параметрів
3. Сценарії помилок (exceptions, invalid input)
4. Конкурентні доступи (якщо застосовно)
5. Бізнес-правила в умовах

Для кожного: опиши сценарій + чому він важливий + можливий баг, якщо не тестувати. Поверни JSON: {{gaps: [{{scenario, importance, potential_bug}}]}}"""

def __init__(self):
    self.llm = ChatOpenAI(model="gpt-4o", temperature=0.1)

def analyze_function_coverage(
    self,
    function_source: str,
    test_source: str
) -> list[dict]:
    result = self.llm.invoke(
        self.ANALYSIS_PROMPT.format(
            function_code=function_source,
            existing_tests=test_source
        )
    )
    import json
    return json.loads(result.content)["gaps"]

def extract_functions_from_module(self, source: str) -> list[dict]:
    """Витягує функції з Python-модуля через AST"""
    tree = ast.parse(source)
    functions = []
    for node in ast.walk(tree):
        if isinstance(node, (ast.FunctionDef, ast.AsyncFunctionDef)):
            func_source = ast.get_source_segment(source, node)
            complexity = self._calculate_cyclomatic_complexity(node)
            functions.append({
                "name": node.name,
                "source": func_source,
                "complexity": complexity,
                "line_start": node.lineno
            })
    return sorted(functions, key=lambda x: x["complexity"], reverse=True)

def _calculate_cyclomatic_complexity(self, node) -> int:
    """Цикломатична складність — пріоритет для тестування"""
    complexity = 1
    for child in ast.walk(node):
        if isinstance(child, (ast.If, ast.While, ast.For, ast.ExceptHandler,
                               ast.With, ast.Assert)):
            complexity += 1
        elif isinstance(child, ast.BoolOp):
            complexity += len(child.values) - 1
    return complexity

| Параметр | Line coverage | Semantic coverage |
|----------|---------------|--------------------|
| Що вимірює | Виконані рядки | Покриті бізнес-сценарії |
| Приклад пропуску | — | None в агрегації, порожній список |
| Виявлення багів | Тільки у виконаних шляхах | Усі можливі входи |
| Середній час аналізу | Миттєво | Залежить від LLM (2-5 сек на функцію) |

<cite>«Після впровадження AI-системи клієнт відзначив: ми виявили 15 критичних багів, яких не знайшли ручні тести» — з відгуку клієнта</cite>

<details>
<summary>Приклад звіту про семантичні прогалини</summary>
```json
{
  "gaps": [
    {"scenario": "Empty list in aggregation", "importance": "high", "potential_bug": "ZeroDivisionError"}
  ]
}

Тест-генератор з мутаційним тестуванням

class AITestGenerator:
    UNIT_TEST_PROMPT = """Згенеруй pytest unit-тести для функції.

Функція:
{function_code}

Непокриті сценарії (сфокусуйся на них):
{gaps}

Вимоги:
- Використовуй pytest + pytest-mock
- Параметризуй через @pytest.mark.parametrize де застосовно
- Для кожного тесту: Arrange-Act-Assert
- Тести на граничні значення
- Тести на помилкові вхідні дані
- Мок для зовнішніх залежностей

Поверни тільки код, без пояснень."""

    async def generate_unit_tests(
        self,
        function_source: str,
        gaps: list[dict]
    ) -> str:
        gaps_text = "\n".join([
            f"- {g['scenario']}: {g['importance']}"
            for g in gaps[:5]  # топ-5 за важливістю
        ])

        result = await self.llm.ainvoke(
            self.UNIT_TEST_PROMPT.format(
                function_code=function_source,
                gaps_text=gaps_text
            )
        )
        return result.content

    async def run_mutation_testing(self, source_file: str, test_file: str) -> dict:
        """Запускає мутаційне тестування через mutmut"""
        import subprocess
        result = subprocess.run(
            ["mutmut", "run", f"--paths-to-mutate={source_file}",
             f"--tests-dir={test_file}"],
            capture_output=True, text=True
        )

        # Аналізуємо вижилих мутантів (тести не спіймали зміну)
        survived = self._parse_survived_mutants(result.stdout)
        if survived:
            additional_tests = await self._generate_for_mutants(survived, source_file)
            return {"survived_count": len(survived), "additional_tests": additional_tests}

        return {"survived_count": 0, "mutation_score": "100%"}

Мутаційне тестування — єдиний спосіб перевірити, чи дійсно тести ловлять помилки в логіці. Наш AI не тільки генерує тести, але й циклічно покращує їх, доки всі мутанти не будуть знищені. Це гарантує, що тести захищають саме від реальних дефектів, а не від формального покриття рядків.

Як AI-тестування вбудовується в CI/CD?

# .github/workflows/ai-qa.yml
name: AI QA Analysis

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  ai-test-analysis:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # потрібен для diff

      - name: Analyze changed files
        run: |
          git diff origin/main...HEAD --name-only --diff-filter=AM | \
            grep "\.py$" > changed_files.txt

      - name: Run AI coverage analysis
        run: |
          python qa_system/analyze_coverage.py \
            --changed-files changed_files.txt \
            --generate-missing-tests \
            --output coverage_report.json

      - name: Comment PR with AI findings
        uses: actions/github-script@v7
        with:
          script: |
            const report = require('./coverage_report.json')
            const comment = formatReport(report)
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              body: comment
            })

Після інтеграції кожен PR отримує автоматичний коментар із переліком нових тестів, рівнем мутаційного покриття та списком невиправлених прогалин. Розробник може прийняти зміни або запросити додаткові тести — без ручного код-рев'ю тестів.

Що входить в роботу

• Аналіз поточного покриття. Запуск семантичного аналізатора на всій кодовій базі, вивантаження звіту з пріоритетами.
• Генерація тестів. Автоматичне створення unit-, інтеграційних та E2E-тестів для кожного виявленого пропуску.
• Мутаційне тестування. Цикл "генерація — запуск — покращення" до досягнення 100% мутаційного покриття.
• Налаштування CI/CD. Інтеграція аналізу в пайплайн (GitHub Actions, GitLab CI, Jenkins) з коментуванням PR.
• Документація. Документування всіх згенерованих тестів та методики їх підтримки.
• Навчання команди. Воркшоп з роботи з AI-системою та написання кастомних правил для вашого бізнесу.
• Підтримка 3 місяці. Безлімітні консультації та доопрацювання під нові версії коду.

Терміни

Терміни можуть варіюватися залежно від розміру кодової бази та складності вимог. Ми пропонуємо безкоштовну попередню оцінку вашого проєкту за 1 день. Замовте її, і ми надамо детальний план впровадження.

Чому AI-тестування ефективніше за ручне?

Понад 5 років досвіду в AI/ML та 50+ впроваджених QA-систем. Ми гарантуємо, що після впровадження ви побачите реальне зниження багів у production, а не просто зростання метрик покриття. Отримайте консультацію: ми покажемо, як AI трансформує ваш QA-процес.

Практичний розбір LLM: fine-tuning, RAG, агенти, деплой

Модель GPT‑4 або Claude 3.5 Sonnet через публічне API — не рішення, а просто інструмент. Коли приходить вимога «зробити як ChatGPT, але на наших даних», за нею стоїть реальна інженерна задача: від налаштування промптів до навчання 70B‑моделі на власній інфраструктурі. LLM розробка під ключ — це складний стек, і ми займаємося цим понад 5 років. За цей час реалізовано понад 20 проєктів у галузі генеративного AI: від RAG‑систем для юридичних департаментів до кастомних агентів для техпідтримки. Де саме знаходиться ваша задача — залежить від даних, latency‑вимог, бюджету та того, наскільки критична конфіденційність.

Типова ситуація: клієнт уже спробував ChatGPT, але результати нестабільні — то відповідає точно, то галюцинує. Або потрібна інтеграція в корпоративний портал з дотриманням політик безпеки. Розберемо кожен шар стеку в деталях — від RAG до production‑деплою.

Чому RAG‑системи ламаються і як це виправити?

RAG (Retrieval‑Augmented Generation) виглядає просто: знайшли релевантні документи, поклали в контекст, модель відповіла. На практиці збоїть у кількох місцях.

Chunking без перекриття. Класична помилка: chunk_size=512, overlap=0. Якщо відповідь лежить на межі двох чанків, retrieval не знайде жодного з достатньою впевненістю. Рішення: overlap 15–25% від chunk_size, а краще sentence‑aware splitting через spaCy або NLTK, а не наївне розбиття за символами.

Поганий embedder. Текст‑embedding‑ada‑002 — хороший для загального випадку, але на юридичних або медичних текстах програє спеціалізованим моделям: E5‑large‑v2, BGE‑M3 або fine‑tuned sentence‑transformers на доменних даних. Різниця в Recall@5 може становити 15–25%.

Відсутність re‑ranking. Векторний пошук оптимізований за швидкістю, не за релевантністю. Cross‑encoder re‑ranker (ms‑marco‑MiniLM‑L‑6‑v2, bge‑reranker‑large) після первинного retrieval піднімає точність топ‑3 при прийнятній затримці (+50–150 ms). Це часто важливіше за покращення embedding‑моделі.

Гібридний пошук. Тільки dense вектори погано працюють на точних запитах: імена, артикули, коди. BM25 (sparse) добре знаходить точні збіги, але не розуміє семантику. Гібрид через RRF (Reciprocal Rank Fusion) — оптимальний компроміс. Qdrant, Weaviate та pgvector 0.7+ підтримують гібридний пошук нативно.

Коли варто fine‑tune, а не промпт‑інжиніринг?

Промпт‑інжиніринг вирішує ~70% завдань адаптації LLM під домен. Решта 30% вимагають донавчання. Три ознаки: модель ігнорує специфічний формат виведення навіть при детальному описі в промпті; задача вимагає глибокого знання спеціалізованої лексики (медицина, право); потрібно значно знизити витрати на токени, замінивши велику модель меншою спеціалізованою.

LoRA та QLoRA — стандарт для SFT. LoRA додає trainable low‑rank матриці до attention‑шарів. Типова конфігурація для Llama‑3 8B: r=64, lora_alpha=128, target_modules=["q_proj","v_proj","k_proj","o_proj"] — параметрів, що навчаються, ~0.8%, навчання на одній A100 40GB. QLoRA додає 4‑бітну квантизацію (NF4) і дозволяє fine‑tune 70B модель на двох A100 40GB, хоча швидкість падає вдвічі порівняно з bf16.

DPO замість RLHF. Direct Preference Optimization вимагає лише пари (chosen, rejected), а не скалярні reward‑сигнали. DPOTrainer з бібліотеки trl (Hugging Face) реалізує це кількома десятками рядків.

Типова помилка. Датасет з 500 прикладів, 5 епох, validation loss 0.8 — здається норм. Але на тесті модель деградувала на загальних інструкціях. Причина: catastrophic forgetting. Рішення — додати 10–20% загальних instruction‑following прикладів (Alpaca, FLAN) у навчальну вибірку, щоб не зруйнувати вихідні здібності.

Як обрати базову модель: 8B чи 70B?

Для більшості задач fine‑tuning 8B моделі достатньо. 70B потрібен, коли потрібне глибоке міркування або baseline 8B не досягає потрібної якості навіть після донавчання. Вартість інференсу Llama‑3 8B через vLLM на A100 значно нижча, ніж у GPT‑4, що робить його економічно вигідним.

Що дає PagedAttention в production?

vLLM — перший вибір для serving open‑source моделей. PagedAttention — ключове технічне рішення: KV‑cache керується як virtual memory в ОС, без фрагментації. Це дає throughput у 2–4 рази вище порівняно з наївним HuggingFace Transformers inference. Документація vLLM підтверджує: continuous batching та PagedAttention — стандарт для високонавантажених LLM‑сервісів.

Типові числа на A100 80GB для Llama‑3 8B (bf16): 400–600 req/s, P50 latency 200–400ms, P99 latency 600–900ms при concurrency 64. Для 70B на двох A100 з tensor parallelism: 80–120 req/s, P99 latency 1.5–2.5s. Квантизація AWQ або GPTQ знижує споживання пам'яті в 2 рази при втраті якості в межах 1–3%.

Мультиагентні системи

Агенти — LLM з доступом до інструментів: пошук, виконання коду, запити до API, робота з БД. Основні патерни:

• ReAct (Reason + Act): модель розмірковує → обирає інструмент → спостерігає результат → знову розмірковує. LangChain та LlamaIndex реалізують з коробки.
• Multi‑agent orchestration: кілька спеціалізованих агентів з координатором зверху. Приклад: coordinator → researcher (пошук + summarization) → coder (генерація та виконання коду) → critic (перевірка). Інструменти: AutoGen (Microsoft), CrewAI, кастомна реалізація на LangGraph.

В продакшені агентні системи недетерміновані. Обов'язкові guardrails, ліміти кроків, логування кожного кроку, human‑in‑the‑loop для критичних дій.

Як ми гарантуємо якість LLM рішення?

Ми використовуємо RAGAS для автоматичної оцінки відповідей: faithfulness, answer relevancy, context precision. Система трекінгу експериментів на базі MLflow фіксує всі метрики, датасети та конфіги. Це дозволяє порівнювати різні гіпотези та доводити покращення з цифрами. Гарантію стабільної роботи забезпечує continuous integration з тестами на специфічних сценаріях (prompt injection, edge‑cases).

Як почати LLM розробку: наступні кроки

Ми передаємо:

• Технічну документацію (model card, конфіги, інструкції з розгортання)
• Доступ до інфраструктури (репозиторій з кодом, навчені ваги)
• 1 місяць підтримки після деплою (консультації, виправлення багів)
• Навчання команди замовника (2–3 заняття з експлуатації системи)

Терміни: базовий RAG‑прототип — 1–2 тижні. Fine‑tuning з даними замовника — 3–6 тижнів (з урахуванням підготовки даних). Production‑система з моніторингом та перенавчанням — 2–4 місяці.

Вартість розраховується індивідуально і залежить від обсягу даних, складності моделі та вимог до інфраструктури. Хочете оцінити свій проєкт? Зв'яжіться з нами — ми підготуємо попереднє резюме за 1–2 робочі дні. Або замовте консультацію фахівця з вибору підходу: RAG, fine‑tuning або гібрид — розповімо, що підійде саме вам.