Table of Contents

Переосмысление проверки в современном инженерном программном обеспечении

Инженерное программное обеспечение — будь то имитирующее гидродинамику, управляющее роботизированной рукой или отслеживающее структурную целостность — должно вести себя с абсолютной предсказуемостью. Стоимость просчета может выходить далеко за рамки аварийного применения; это может означать дорогие физические прототипы, скомпрометированную безопасность или нормативные штрафы. В прошлом проверка часто рассматривалась как ворота поздней стадии, монолитная деятельность, зажатая между «завершенной разработкой» и «отгрузкой». Этот подход пристегнулся под скоростью и сложностью сегодняшней итеративной разработки. Чтобы построить надежные инженерные инструменты, не отставая от требований рынка, команды встраивают проверку непосредственно в свои гибкие ритмы. В этой статье исследуется, как вплетать проверку в каждый спринт, использовать автоматизацию и поддерживать отслеживаемость, необходимую как для инноваций, так и для соответствия.

Что означает проверка внутри гибкого контекста

В программной инженерии верификация отвечает на вопрос: « Правильно ли мы создали продукт?» Она отличается от валидации, которая спрашивает, правильно ли мы создали продукт для реальных проблем пользователей. Для инженеров, разрабатывающих инструменты моделирования, встроенное прошивочное ПО или конвейеры анализа данных, верификация выходит за рамки базовых функциональных проверок. Она включает в себя проверку численной точности, подтверждение того, что использование краевой физики остается стабильным, проверку того, что использование памяти остается в жестких пределах реального времени, и обеспечение того, чтобы результаты соответствовали известным бенчмаркам. Когда гибкая команда охватывает итеративную доставку, эти проверки не могут ждать заключительной фазы тестирования. Вместо этого верификация становится непрерывной деятельностью на уровне спринта, которая напрямую входит в цикл обратной связи разработки. Этот сдвиг требует, чтобы вся команда — от разработчиков до экспертов домена — приняла менталитет проверки, где каждое изменение кода тщательно проверяется на основе как функциональных, так и нефункциональных требований.

Почему традиционные стратегии проверки сталкиваются с гибкими

Многие инженерные организации выросли с V-моделью, вдохновленной водопадом: требования с одной стороны, проверка с другой, с длинной фазой разработки между ними. В этой модели проверка часто начинается только после интеграции, что означает, что дефекты накапливаются молча. Небольшая алгебраическая ошибка в решателе может оставаться незамеченной в течение нескольких недель, только для того, чтобы всплыть, когда вся система собрана. Переработка на этом этапе является разрушительной и дорогой. Короткие циклы Agile выставляют это несоответствие. Команды, отправляющие новый прирост каждые две недели, не могут позволить себе ждать дней для ручной проверки; им нужна обратная связь в течение нескольких часов. Кроме того, инженерное программное обеспечение часто подчиняется строгим стандартам, таким как DO-178C для авионики или ISO 26262 для функциональной безопасности автомобиля. Традиционная документация проверки становится узким местом, когда каждый конец спринта требует новых доказательств правильности.

Основной конфликт заключается в предположении, что проверка является отдельной фазой. В гибкой проверке должна быть параллельная деятельность, интегрированная в каждый шаг развития. Команды, которые пытаются сохранить традиционную проверку после каждого спринта, часто оказываются с постоянно растущим отставанием тестовых задач и растущим чувством риска. Поздняя проверка V-модели также поощряет менталитет «бросать его через стену», где разработчики отстраняются от проблем качества. Agile нарушает это, делая качество ответственность каждого из спринта.

Встраивание проверки в каждый спринт

Перемещение проверки внутри цикла спринта требует преднамеренного планирования, а не только надежды на то, что тестировщики «догонят». Описанные ниже методы помогают инженерным командам сделать проверку естественной, повторяемой частью гибкой доставки. Эти методы смещают проверку от второстепенной мысли к первоклассной проблеме, которая формирует отставание от спринта.

Написание проверяемых пользовательских историй

Хорошо сформированная пользовательская история уже содержит семена проверки. Вместо «Внедрения решения Navier-Stokes», команда пишет: «Как аналитик CFD, я хочу, чтобы решатель вычислял распределение давления по аэродинамической поверхности NACA 0012 на 0,7 Маха, чтобы я мог проверить коэффициенты подъема. Критерии принятия: коэффициент подъема соответствует критериям CFD в пределах 2% относительной ошибки по крайней мере для 90% стандартных тестовых случаев. Эта ясность позволяет команде разрабатывать автоматизированные проверки проверки перед написанием одной строки кода решателя. Критерии принятия становятся основой для единичных тестов, контрольных показателей регрессии и демонстрационных спринтов. Встраивая план проверки в историю, команда создает общее понимание того, что означает «сделано» с самого начала. Для сложных инженерных задач рассмотрите разделение историй на более мелкие, проверяемые приращения — например, сначала реализуйте решение для одного граничного условия, а затем расширьте охват в последующих спринтах».

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

Во время планирования спринта команда разбивает верификацию на осязаемые задачи: «Создать набор автоматической регрессии для генерации сетки», «Добавить шаг статического анализа к конвейеру CI» или «Доклады проверки обзора с производительности последнего спринта». Эти задачи получают тот же приоритет, что и разработка функций. Они появляются на панели задач вместе с задачами кодирования, и они рассчитывают на определение выполненных. История не делается до тех пор, пока ее артефакты проверки не пройдут проверку, а не только до тех пор, пока код не компилируется. Эта практика гарантирует, что проверка не откладывается; она явно выделяет пропускную способность каждого спринта. Например, команда, работающая над модулем обработки радиолокационных сигналов, может зарезервировать 20% точек каждого спринта для улучшения автоматизации и проверки тестовых данных. Лечение проверки как первоклассная работа предотвращает ее жертву, когда надвигаются сроки.

Определение выполненного, которое включает в себя доказательства проверки

В гибком, надежном определении сделанного предотвращает накопление технического долга. Для инженерного программного обеспечения это определение должно явно требовать:

  • Все тесты проходят и охватывают новую логику.
  • Численные результаты теста находятся в пределах толерантности.
  • Статические аналитические отчеты не показывают никаких новых критических предупреждений.
  • Интеграционные тесты подтверждают, что интерфейсы между модулями остаются стабильными.
  • Резюме проверки задокументировано в легкой записи прослеживаемости спринта.

Когда коллективно владеет этим определением, никто не может молча урезать углы по безопасности или надежности - обзор спринта будет выставлять неполную проверку так же легко, как сломанная сборка. Определение должно быть видно на информационном радиаторе команды и рассмотрено во время ретроспектив, чтобы обеспечить его развитие с профилем риска проекта. Для критически важной работы по безопасности добавьте такие элементы, как «отчет о структурном покрытии (например, MC / DC) не показывает новых непокрытых решений» к определению. Эта прозрачность создает доверие как с внутренними заинтересованными сторонами, так и с внешними аудиторами.

Проверка в обзорах и ретроспективах Sprint

Демо-версии Sprint должны демонстрировать проверенное поведение, а не только новые функции. Команда структурного анализа может представить тест живой нагрузки, где выходной результат отклонения программного обеспечения соответствует известным аналитическим решениям. Эта практика подтверждает, что проверка является доставкой ценности, а не рутиной. В ретроспективах команда изучает метрики проверки: были ли скользкие тесты, которые теряли время? Указывает ли поздний прорыв контрольной регрессии на неясные требования? Отношение к улучшению процесса проверки как к первоклассной проблеме приводит к стабильно более быстрой, более надежной обратной связи. Например, одна команда обнаружила, что их самый продолжительный тест моделирования может быть разделен на быструю проверку здравомыслия и полный ночной прогон, уменьшая основной цикл проверки с 45 минут до 8 минут. Другая команда использовала ретроспективы, чтобы определить, что в их тестовой среде не хватало той же точности с плавающей точкой, что и производство, что привело к ложным сбоям; они решили это, стандартизировав изображение контейнера.

Автоматизация: двигатель непрерывной проверки

Ручная верификации просто не может идти в ногу с двухнедельным спринт-каденсом в инженерном программном обеспечении. Автоматизация трансформирует верификацию из ажурного действия в постоянно включенную сеть безопасности. Ключ заключается в реализации иерархии автоматизированных проверок, которые выполняются на разных этапах конвейера разработки, давая разработчикам быструю обратную связь на своих локальных машинах и всестороннюю обратную связь перед любым слиянием. Эту многоуровневую автоматизацию иногда называют «тестовой пирамидой», адаптированной для инженерного программного обеспечения, где база состоит из быстрых единичных тестов, а вершина состоит из длительных системных симуляций.

Строительство трубопровода CI/CD для инженерного кода

Сервер непрерывной интеграции (CI) - такой как Jenkins , GitLab CI или GitHub Actions - автоматически строит программное обеспечение и запускает эскалацию серии тестов проверки с каждым фиксированным выполнением. Трубопровод может начинаться с компиляции проверок и единичных тестов, которые выполняются менее чем за пять минут, давая разработчику немедленную уверенность. Второй этап запускает более длинные интеграционные тесты и численные бенчмарки на более крупной матрице входных параметров. Ночная сборка может выполнять полномасштабное тестирование производительности и профилирование памяти. Этот многоуровневый подход может быстро поддерживать цикл обратной связи ядра, все еще подвергая код требовательным сценариям проверки. Для команд, работающих с доменными языками или специализированным оборудованием, трубопровод может включать контейнерные среды (например, Docker) для обеспечения воспроизводимости на машинах разработчика и бегунах CI. Для встроенных систем рассмотрите возможность использования эмуляторов аппаратного обеспечения в цикле внутри трубопровода CI или, по крайней мере

Виды автоматизированных проверок

Различные слои улавливают различные классы дефектов. Инженерное программное обеспечение извлекает выгоду из набора инструментов, который выходит за рамки типичного тестирования бизнес-приложений:

  • Единичные тесты проверяют отдельные алгоритмы — например, матричная процедура факторизации возвращает ожидаемые факторы в пределах допуска с плавающей точкой. Используйте такую структуру, как Google Test или pytest с помощниками числового утверждения.
  • Регрессионные эталоны сравнивают результаты моделирования с золотым набором данных. Гидрологическая модель может проверить, что 100-летнее моделирование наводнения дает тот же гидрограф, что и проверенный эталонный прогон. Эти эталоны часто требуют тщательного управления данными испытаний и допусками.
  • Статические инструменты анализа , такие как SonarQube или анализаторы, специфичные для домена (например, Polyspace для встроенного C), обнаруживают потенциальные ошибки, утечки памяти и нарушения стандартов кодирования до того, как код когда-либо запустится.
  • Интеграционные тесты проверяют, что такие компоненты, как графический интерфейс, библиотека решателей и файловый парсер, взаимодействуют без несоответствующих форматов данных. Эти тесты выполняют реальные интерфейсы и могут улавливать тонкие несоответствия, которые пропускают единичные тесты.
  • Модульная верификации использует формальные методы или имитационные модели для доказательства свойств логики управления, что особенно ценно в критически важных для безопасности встроенных системах.

Помимо этого, рассмотрите возможность добавления основанного на свойствах тестирования для числовых алгоритмов, где инструмент генерирует случайные входы в пределах ограничений и проверяет инварианты (например, выход сортировки всегда сортируется). Это может выявить крайние случаи, которые фиксированные тестовые случаи пропускают.

Сохранение автоматического пакета здоровым

Некачественные тесты - те, которые проходят иногда и не срабатывают в другое время из-за условий гонки или чувствительности к плавающей точке - разрушают доверие к автоматизации. Инженерные команды должны рассматривать нечеткие тесты как дефекты и немедленно их исправлять. Изолирование семян случайных чисел, ужесточение порогов допуска и проведение тестов в детерминированных виртуальных средах - все это помогает. Тестовый пакет, которому команды могут доверять, становится основой ежедневных решений по разработке. Также важно периодически пересматривать тестовый пакет для избыточности и производительности. В конечном итоге, набор, который растет без контроля, замедлит цикл обратной связи. Используйте динамическое тестирование приоритетизации: сначала запустите тесты, которые с наибольшей вероятностью уловят регрессии, особенно во время предварительных проверок. Например, тест, который выполняет недавно измененный модуль, должен иметь приоритет над тестом для нетронутой подсистемы. Инструменты, такие как встроенный тестовый заказ pytest или пользовательские сценарии конвейера CI, могут реализовать эту приоритетность.

Поддержание легкой прослеживаемости и документации

В регулируемых отраслях слово «гибкий» может звучать несовместимо с «документацией». Реальность такова, что agile не устраняет документацию; он делает ее бережливой и непосредственно ценной. Вместо тяжелых требований спецификации, которые никто не читает, команда поддерживает матрицу прямой прослеживаемости, привязанную к историям пользователей и автоматизированным результатам проверки. Современные инструменты управления тестами (например, Jira Xray, TestRail или Polarion) могут связать каждый критерий принятия с тестовым случаем, а конвейер CI может автоматически отмечать этот тест как пройденный или неудавшийся в системе. Этот подход генерирует современные доказательства проверки каждый спринт, уменьшая схватку перед регуляторным аудитом. Документация проверки становится побочным продуктом выполнения работы, а не отдельной деятельностью. Ключ к проверке сценариев тестирования и тестовых данных вместе с исходным кодом, чтобы конкретное обязательство соответствовало известному состоянию проверки. Для дополнительной уверенности используйте подписанные обязательства или теги для создания неизменных исходных линий выпуска, которые аудиторы могут проверить.

Соответствие нормативным стандартам без ущерба для гибкости

Инженерные области, такие как аэрокосмическая промышленность (DO-178C), автомобильная промышленность (ISO 26262) и медицинские устройства (IEC 62304), требуют документированных доказательств того, что программное обеспечение соответствует его требованиям. Agile-команды часто опасаются, что соблюдение заставит их вернуться к документации водопада. На практике эти стандарты сосредоточены на том, что требуется ], а не , как ]. Встраивая проверку в каждый спринт и генерируя автоматизированные отчеты о прослеживаемости, команды могут удовлетворять аудиторов, все еще работая итеративно. Подход часто включает в себя:

  • Захват планов верификации в качестве легких историй пользователей с критериями принятия, которые соответствуют целям стандарта.
  • Использование автоматизированных тестов в качестве основного источника объективных доказательств с результатами, архивированными на спринт.
  • Проведение экспертных обзоров верификационных артефактов (например, тестовых целей, анализов охвата) в рамках спринт-цикла.
  • Поддержание базового уровня проверенных версий программного обеспечения, которые могут быть проверены в любое время - каждый кандидат на выпуск - это просто фиксированный набор обязательств с соответствующими отчетами о проверке.

Ключ в том, чтобы рассматривать цели стандарта как нефункциональные требования, которые должны быть выполнены самим процессом разработки, так же как производительность или безопасность. Например, команда, разрабатывающая программное обеспечение для управления полетом в соответствии с DO-178C, может структурировать свое отставание, чтобы включить «мероприятия по проверке» в качестве эпосов, которые охватывают несколько спринтов, причем каждый спринт предоставляет дополнительные доказательства в отношении артефактов сертификации. Многие команды успешно прошли аудиты, представив матрицу прослеживаемости в реальном времени, которая показывает, как каждое требование было проверено в последнем спринте, а также резюме охвата.

Создание культуры совместной проверки

Проверка не может быть ответственностью отдельной команды «QA», которая получает сборку в конце спринта. В эффективных гибких инженерных командах разработчики, инженеры-испытатели и эксперты в области разделяют ответственность за правильность. Кросс-функциональные команды включают кого-то, кто может создавать контрольные показатели проверки, писать автоматизированные проверки и интерпретировать числовые результаты. Это размывает традиционные границы, но резко сокращает временную задержку между введением дефекта и его обнаружением. Бесполезные посмертные случаи после побегов проверки (например, упущенный край, который достигает клиента) помогают команде улучшить свою тестовую конструкцию без указания пальца.

Специалисты по проверке парных соединений с разработчиками

В спринтах, где затрагиваются сложные физические или контрольные алгоритмы, сопряжение инженера по проверке с разработчиком может быть весьма эффективным. Инженер по проверке помогает на ранних этапах разработать критерии принятия и автоматизацию, в то время как разработчик гарантирует, что код тестируем. Это сотрудничество часто раскрывает неоднозначные требования, прежде чем они кальцифицируются в код, сохраняя переделку позже. Это также распространяет знания домена в обоих направлениях, уменьшая силосы знаний. Со временем разработчики становятся более опытными в написании проверяемых требований и создании собственного кода проверки, в то время как инженеры по проверке получают более глубокое понимание алгоритмических компромиссов. Например, пара может обнаружить, что значение допуска в критериях принятия было основано на устаревшем оборудовании; они обновляют его вместе, предотвращая несоответствие позже.

Приоритетность проверки на основе рисков

Не все части инженерной программной системы несут один и тот же риск. В гибком спринте команды должны решить, где сосредоточить свои усилия по проверке, чтобы максимизировать обнаружение дефектов с учетом временных ограничений. Риск-ориентированный подход включает классификацию компонентов по степени тяжести и вероятности отказа. Области высокого риска - такие как критически важная функция автопилота или решатель, который обрабатывает анализ пристегнутости - должны пройти более тщательную проверку: несколько независимых реализаций испытаний, формальные методы, где это возможно, и ручной обзор результатов покрытия. Компоненты с более низким риском, такие как модуль отчетности, могут полагаться на меньший набор автоматизированных проверок. Эта приоритизация пересматривается каждый спринт по мере развития системы. Она обеспечивает, что усилия по проверке сосредоточены там, где они обеспечивают наибольшую безопасность и бизнес-ценность. Используйте простую матрицу: назначьте каждому компоненту значение от 1 (низкое) до 5 (высокое) как для воздействия, так и для вероятности, умножьте, чтобы получить оценку риска и распределите часы проверки пропорционально.

Преодоление общих проблем проверки в Agile инженерных проектах

Даже при наличии надлежащей практики команды сталкиваются с препятствиями. Признание их заранее позволяет осуществлять превентивное планирование:

  • Долгосрочные числовые эталоны:] Запускайте их ночью или на специальном оборудовании, чтобы они не блокировали конвейер CI. Результаты кэша для конфигураций, которые не изменились. Рассмотрите возможность использования инкрементной проверки: если только один модуль модифицирован, запустите только те эталоны, которые осуществляют этот модуль. Для больших проверочных параметров используйте статистическую выборку, чтобы получить уверенность без запуска каждой комбинации.
  • Зависимости от аппаратного обеспечения: Используйте виртуальные или смоделированные аппаратные интерфейсы для ранней проверки спринта, резервируя физические настройки для интеграционных тестов позже в цикле выпуска. Слои абстракции (например, слои абстракции оборудования) могут отделить разработку от фактической доступности аппаратного обеспечения. Когда физическое оборудование неизбежно, планируйте выделенные временные блоки на испытательном стенде и автоматизируйте как можно больше, чтобы максимизировать использование.
  • Проверка унаследованного кода без тестов: Добавить тесты на характеристики, которые фиксируют текущее поведение перед рефакторингом. Как только существует система безопасности, рефакторируйте постепенно и расширяйте охват. Начните с наиболее важных модулей, чтобы получить быстрые выигрыши. Для унаследованного решателя тест на характеристики может запустить существующий алгоритм против набора известных входов и выходов записи; любой рефакторинг должен производить те же результаты в пределах допуска.
  • Ограничения ресурсов: Относитесь к инфраструктуре автоматизации как к инвестициям в продукт. Неудачный сервер CI так же важен, как и сломанный компилятор. Выделите выделенное время для обслуживания тестовых скриптов и трубопроводов CI; это может быть повторяющейся задачей в каждом отставании от спринта. Рассмотрите возможность использования облачных бегунов CI для эластичного масштабирования, когда многие совершают посадку одновременно.
  • Управление данными теста: Наборы тестов для управления версиями вместе с кодом, чтобы тесты оставались воспроизводимыми среди членов команды и с течением времени. Используйте такие инструменты, как Git LFS для больших двоичных файлов. Документируйте источник и вывод каждого набора данных, чтобы избежать случайного дрейфа. Для генерируемых данных храните сценарий генерации и семя, а не полный файл.

Еще одна распространенная проблема заключается в том, чтобы иметь дело с недетерминизмом в симуляции из-за генерации случайных чисел или параллельной обработки. Митировать путем фиксации семян в тестовых конфигурациях, используя детерминированные алгоритмы, где это возможно, и принимая небольшую терпимость к вариациям с плавающей точкой. Если тесты остаются нечеткими после этих шагов, рассмотрите возможность расслабления критериев сравнения или выполнения теста несколько раз и требуя прохождения большинства.

Измерение того, что имеет значение: метрики для гибкой проверки

Метрики направляют команду к состоянию, когда проверка является одновременно быстрой и надежной. Вместо того, чтобы одержимы одним числом, посмотрите на небольшой набор показателей по нескольким спринтам:

  • Частота выхода из строя: Сколько проблем сообщают пользователи или команды, работающие ниже по течению, по сравнению с обнаруженными во время проверки спринта? Низкая частота выхода указывает на то, что проверки в спринте ловят реальные проблемы. Отслеживайте это на компонент для выявления слабых мест. Если скорость выхода для шипов сетчатого генератора, исследуйте, нуждается ли его тестовый набор в расширении.
  • Время цикла проверки: Прошедшее время от кода обязывает к завершению результатов проверки. Укороченный цикл (без пропуска проверок) сигнализирует об улучшении автоматизации и эффективности тестирования. Для двухнедельного спринта нацельте время цикла менее суток для магистрального трубопровода. Если оно превышает день, посмотрите на параллелизацию выполнения теста или оптимизацию самых медленных заданий.
  • Тестовый пакет здоровья: Процент тестов, которые последовательно проходят против хлопчатобумажных. Здоровый пакет повышает уверенность разработчика. Если хлопчатобумажные тесты превышают 5%, расставьте приоритеты их стабилизации. Автоматически пометьте любой тест, который периодически выходит из строя в течение семидневного окна и назначьте его разработчику для разрешения.
  • Покрытие условий для критически важных для безопасности модулей: В таких областях, как авионика, показатели структурного покрытия (например, MC/DC) обеспечивают объективное доказательство того, что тесты осуществляют точки принятия решений. Покрытие трека на модуль и адрес раскрытых условий в следующем спринте. Для менее критических модулей покрытие линии может быть достаточным.

Если время цикла проверки увеличивается, исследуйте, не слишком ли раздут набор тестов или не нуждается ли инфраструктура трубопровода в масштабировании. Используйте данные для конкретных улучшений, а не для того, чтобы обвинять отдельных лиц. Например, одна команда заметила, что их коэффициент выхода из дефекта для решателей был последовательно выше, чем для пользовательского интерфейса; они ответили, добавив выделенного члена команды для написания регрессионных тестов для конкретного решателя и введя обязательную экспертную оценку для всего кода решателя.

Начало работы: практический путь вперед

Переход команды инженерного программного обеспечения на гибкую проверку не требует капитального ремонта. Начните с выбора одного модуля высокого риска. Напишите его критерии принятия в проверяемых терминах, добавьте небольшой автоматизированный эталон регрессии и подключите его к трубопроводу CI, который работает на каждом толчке. Отпразднуйте первый раз, когда трубопровод ловит регрессию, прежде чем он достигнет стола коллеги. Пусть этот успех набирает обороты. Расширьте подход к другим модулям, спринт за спринтом, расширьте набор тестов и беглость автоматизации команды. Со временем проверка превращается из беспокойства о сроках в рутину, которая повышает скорость и безопасность. По мере взросления команды они могут применять более передовые методы - такие как тестирование на основе свойств для числовых алгоритмов или формальная проверка для логики управления - но основа всегда представляет собой плотный цикл автоматической проверки, встроенный в гибкий ритм.

Быстрая дорожная карта на первый месяц

Чтобы сделать старт ощутимым, вот возможный план на первый месяц:

  • Неделя 1: Определите модуль с наибольшим риском (например, решатель или контроллер). Напишите проверяемые критерии принятия для его основного поведения. Выберите инструмент CI (даже простой рабочий процесс GitHub Actions).
  • Неделя 2: Реализуйте один эталон регрессии, который сравнивает выход с доверенной ссылкой. Добавьте его в трубопровод CI, чтобы он работал по каждому запросу на вытягивание.
  • Неделя 3: Расширить охват, включив в него единичные тесты для подпрограмм модуля. Добавить проверки статического анализа для этого модуля.
  • Неделя 4: Представление результатов в обзоре спринта. Сбор отзывов. Обновление определения сделанного для того, чтобы требовать прохождения эталонного и статического анализа для всех изменений кода в этом модуле. Поделитесь историей успеха с более широкой организацией.

Этот постепенный подход создает импульс без перегрузки команды. Ключ заключается в том, чтобы показать ценность на ранней стадии - как только разработчики испытают сеть безопасности автоматической проверки, они будут выступать за ее расширение до всей кодовой базы.