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

Программное обеспечение управляет миром, но дефекты в нем неизбежны — растет число случаев отзыва продукции и судебных исков из-за плохого ПО, обеспечивать качество которого необходимо еще на этапе проектирования, но и этого недостаточно — необходима систематическая верификация и валидация (verification & validation, V&V).

Сегодня организации вкладывают больше трети ИТ-бюджетов в обеспечение качества и тестирование ПО. При этом больше половины бюджета поддержки жизненного цикла процессов и продуктов приходится на системы, имеющие повышенные требования к безопасности [1–3]. Рост применения Agile-методов и непрерывное обновление ПО ведет к увеличению количества процедур тестирования. Внедряются непрерывная верификация и валидация — намного более сложные процессы, чем базовое тестирование разработчиком. Соответственно, имеется потребность в автоматизации непрерывных конвейеров и принципиально новых схемах тестирования, в том числе методах когнитивного тестирования автономных систем.

Сложность тестирования

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

Широкое внедрение конвейеров непрерывной интеграции и поставки порождает потребность в аналогичных механизмах непрерывной верификации и валидации, однако на практике такие механизмы не реализуются по следующим причинам [1–3]:

резкое усложнение процессов, обусловленное переходом на непрерывное обновление ПО и гибкие принципы DevOps, препятствует использованию традиционных методов V&V, таких как функциональное тестирование и покрытие кода;
отказ от следования установленным процедурам в рамках agile-подходов привел к игнорированию устоявшихся процессов разработки ПО, следствием чего стал рост дефектов взаимодействия и интеграции;
принцип непрерывной поставки подразумевает, что ПО с определенным уровнем качества, развернутое сегодня, завтра уже будет устаревшим, а его качество снизится;
число дефектов и уязвимостей также растет из-за постоянного повышения уровня сложности систем на фоне потребности в ускорении выпуска;
кибератаки совершаются крупными, хорошо подготовленными группировками (сегодня объем киберпреступности превышает объемы мирового наркотрафика);
адаптивные платформы на основе искусственного интеллекта непрерывно меняют собственное программное обеспечение, и традиционные методы тестирования для них не подходят;
растет разрыв между уровнем сложности систем и числом квалифицированных специалистов — все больше ПО разрабатывается лицами без достаточного объема навыков;
принцип приоритета качества отходит на второй план — новое поколение разработчиков выросло с привычкой к тому, что для каждого действия есть кнопка отмены.

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

При систематическом тестировании необходимо учитывать следующие вопросы [2, 3]:

Какова функциональность согласно спецификации?
Соответствует ли система спецификации?
Описаны ли в спецификации должным образом все возможные ситуации, в том числе критические, и их взаимосвязи?
Какова запланированная функциональность и является ли она безопасной?
Каким образом осуществляются прослеживание и оценка принятия решения? Как этот процесс контролируется?
Как определяется степень надежности при отказах?
Что происходит в случае отказа запланированной функциональности в связи с аварией, ошибкой проектирования, атакой?
Какой отрицательный результат должен быть в любом случае недопустимым?
Какие виды регрессионного тестирования потребуются для различных адаптивных и обучающихся подсистем?
Какие сведения об обновлениях ПО и механизмах машинного обучения необходимо предоставить пользователю?
Какие стратегии минимально необходимого тестирования следует применять при изменении, обновлении и обучении систем на основе ИИ?

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

Технологии тестирования

На сегодня в тестировании произошел отход от традиционных «лобовых» и ситуативных подходов — теперь тестирование начинается еще до проектирования в форме методов тест-ориентированного формирования требований и разработки. Основы обеспечения качества программного обеспечения закладывает стандарт ISO/МЭК 12207 и описанные в нем процессы верификации и валидации. В качестве абстракции в стандарте используется V-образная наглядная схема — «модель трех пиков», в которой каждому процессу разработки в левой ветви сопоставлен процесс V&V справа. Опираясь на схему, можно выделить три области, позволяющие проследить требования от разработки до валидации (рис. 1). С помощью модульных тестов проверяется соответствие исходного кода архитектуре низкого уровня, интеграционные тесты позволяют проверить сопряжение ранее протестированных компонентов, а системные тесты — соответствие полностью интегрированного продукта спецификации. С помощью заключительных приемочных тестов проверяется, соответствует ли продукт ожиданиям пользователя или клиента. Сами процедуры тестирования ПО подробно описаны в стандарте ISO/МЭК/IEEE 29119.

Рис. 1. Модель трех пиков (вертикальные уровни) и ее различные абстракции (горизонтальные уровни): а) требования, б) архитектура, в) тесты. HARA (health assessment and risk analysis) — оценка работоспособности и риск-анализ, TARA (threat assessment and remediation analysis) — оценка угроз и анализ возможностей защиты

Серия стандартов в области проектирования систем и программного обеспечения ISO 25000 определяет основные характеристики качества продуктов и требования к качеству измерений и тестов:

функциональная пригодность: степень, в которой продукт или система предоставляет функции, отвечающие объявленным и подразумеваемым потребностям при использовании в указанных условиях;
безопасность — степень, в которой продукт или система защищает информацию таким образом, чтобы у пользователя и взаимодействующих систем был необходимый доступ к данным;
сопровождаемость: возможность эффективно и результативно модифицировать продукт или систему с целью улучшения, исправления и адаптации к изменениям в средах и требованиях;
удобство использования (usability): показатель возможности применения продукта или системы указанными пользователями для эффективного и результативного достижения заданных целей;
относительный уровень производительности: соотношение производительности и объема ресурсов, использованных при заданных условиях.

В таблице приведен обзор процедур тестирования и соответствующих методологий с типичными дефектами, рисками, инструментами и уровнем относительных трудозатрат. Таблица подготовлена с учетом актуальных стандартов и практического отраслевого опыта [2].

Новые технологии тестирования

Как теория, так и практика тестирования активно меняются. Традиционных методов для автономных систем недостаточно, учитывая уровень их сложности и спектр потенциальных проблем с надежностью, безопасностью и защищенностью. Для критичных к безопасности автономных систем введена концепция безопасности заданных функций (safety of the intended functionality, SOTIF) — отсутствие необоснованного риска, возникающего из-за дефектов запланированной функциональности. Для таких систем также проводят регрессивную валидацию — тесты, выполняемые после изменения управляющих алгоритмов, чтобы проверить, продолжает ли функция удовлетворять заданным требованиям. Такой тест особенно важен для конвейеров непрерывной интеграции и поставки с частым обновлением ПО.

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

Для повышения эффективности и результативности тестирования в рамках процедур верификации и валидации все шире применяются средства искусственного интеллекта и машинного обучения. Интеллектуальные механизмы валидации позволят автоматизировать тестирование целиком или частично [1, 3]. Когда алгоритмы искусственного интеллекта используются в обучаемых системах управления, валидация ПО усложняется.

Виды такой валидации: тестирование на основе требований, тестирование на основе онтологии, когнитивное тестирование.

Рис. 2. Применение когнитивного тестирования на примере экзамена по вождению

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

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

***

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

Правильно организованное систематическое тестирование помимо прочего помогает избежать юридических рисков. Выбор верной стратегии, методики и технологии тестирования зависит от многих факторов — в каждой организации и среде разработки такой выбор будет своим. Но до внедрения тех или иных инструментов необходимо позаботиться о наличии нужных навыков в области верификации и валидации. Нередки случаи, когда организации внедряют сложные инструментальные цепочки, не имея при этом четкой стратегии и систематизированных процессов тестирования. Чтобы исправить ситуацию, нужны ответы на следующие вопросы:

Каковы ваши критерии готовности к выпуску помимо сроков?
Какова ваша стратегия регрессии, каковы характеристики соответствующих тестовых случаев?
Проводится ли систематическое тестирование на ситуации превышения предельно допустимых параметров и взаимосвязь функций?
Как измеряется и улучшается качество вашего ПО?

Чтобы уменьшить риски для человека, программно-конфигурируемые системы должны быть способными автоматически обнаруживать собственные дефекты и точки отказа. Но одних инструментов для этого недостаточно — необходимы верные процессы, внедряемые опытными специалистами на основе практического опыта.

Литература

1. World Quality Report (WQR) 2021–22, Capgemini, Paris, France, 2021. [Онлайн]. URL: https://www.capgemini.com/research/world-quality-report-wqr-2021-22/

2. D. Graham et al. Foundations of Software Testing: ISTQB Certification, vol. 4. Andover, U.K.: Cengage Learning, 2019.

3. S. Goericke. The Future of Software Quality Assurance. Heidelberg, Germany: SpringerOpen, 2020.

Кристофер Эберт (christof.ebert@vector.com) – управляющий директор; Дивит Баджадж (divith.bajaj@vector.com) – специалист, Vector Consulting Services; Микаэль Вейрих (michael.weyrich@ias.uni-stuttgart.de) – директор, Институт промышленной автоматизации и программной инженерии Штутгартского университета.