О тестировании программных систем

О тестировании программных систем

Пролистал "Профессиональная верификация: Руководство по продвинутой функциональной верификации / пер. с англ. А. Ю. Романова. – М.: ДМК Пресс, 2025, Уилкокс П., Романов А. Ю.".

Книга, которую вы держите в руках, продолжает серию «Книжная полка истового инженера», которая издается при поддержке компании YADRO. Это издание подготовлено

к публикации Московским институтом электроники и математики им. А. Н. Тихонова

НИУ ВШЭ совместно с издательством «ДМК Пресс».

Она, конечно, про интегральные схемы, а не про бизнес-приложения.

Но это интересно - смотреть практики по тестированию в сложных промышленных направлениях: авиа, космос, аппаратная разработка...

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

Основные мысли

1. Начинать с самих ранних этапов.

2. Делать "модели", тестировать их.

3. Тестирования каждого блока.

4. "Аппаратное" ускорение.

Ускорение это интересная аналогия. В контексте нагрузочного тестирования.

В таком тестировании проводим тестирование на каждую компоненту, но не учитываем, когда компонента состоит из других подкомпонент.

А что если какая-то внутренняя часть ускорится? Можно ли это эмулировать и тестировать на этапе разработки?

Аудит системы с составлением её модели для выявления узких мест и т.д. вполне разумен. Трудозатратно, но окупается на объемах сэкономленных ресурсов.

Во всех командах, где работал, мне всегда нравилось делать оптимизации кода/внутренней архитектуры.

И часто находился хотя бы один коллега, который на мои изменения реагировал примерно так: "это что за дичь/работать не будет/поддерживать сложно/...".

Потом мы видели, как на графиках тайминги падают в 10 раз/CPU в 2 раза упал/память снижается в кластере.

Но как изначально доказывать, валидировать. На проде ведь особо не натестируешься 😊

Вы сталкивались с какими-нибудь историями моделирования архитектуры приложения с целью тестирования качества и производительности? Инструменты может есть?

С верификацией ИС моделирование должно быть первоочередным:

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

В информационных системах большинство крупных ошибок, которые встречал, были связаны с тем, что кто-то (бывало и я) забыл про [обратную] совместимость и контракты с каким-нибудь ещё одним сервисом.

ИИ-агент(ы) могли бы этим заниматься: проверить, что контракты сервисов не изменились, промоделировать исполнение на основе кода, выдать отчёт о валидации.

Как считаете? Пробовали уже?

#pro@egorword

#read@egorword