Интеграционное тестирование

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

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

РАЗРАБОТКА НА ОСНОВЕ ГЛАВНОЙ ВЕТКИ

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

Интеграционное тестирование может проводиться как вручную, так и автоматизированно.

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

В среде DevOps для развертывания программного обеспечения используется конвейер непрерывной интеграции, непрерывной поставки и развертывания (англ. Continuous Integration / Continuous Delivery / Deployment, CI/CD). CI/CD-конвейеры интегрируют, тестируют и развертывают программное обеспечение без вмешательства человека. Как правило, разработчики и команда эксплуатации создают собственные интеграционные тесты для добавления в конвейер, чтобы подтвердить, что их новый код хорошо сочетается со всем остальным приложением.

Более подробно мы обсудим CI/CD в разделе «Развертывание».

Интерактивное тестирование безопасности приложений

Интерактивное тестирование безопасности приложений, сокращенно называемое IAST (англ. Interactive Application Security Testing), – это новый вид автоматизированного инструмента, созданного несколькими компаниями, занимающимися обеспечением безопасности приложений. IAST работает как развернутый в приложении агент, который следит за приложением и во время его работы сообщает о найденных уязвимостях. IAST может собирать информацию в ходе ручного и автоматизированного тестирования, а также в ходе использования приложения пользователем, находя уязвимости и сообщая о них в режиме реального времени (по мере их возникновения).

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

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

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

Регрессионное тестирование

В IТ-среде есть шутка, которая звучит примерно так.

Вопрос: Приложение имеет 10 ошибок, было исправлено 10. Сколько ошибок осталось?

Ответ: 1 или больше.

Суть шутки в том, что каждый раз, когда мы вносим изменения (включая исправления ошибок), существует вероятность возникновения новой проблемы. Как уже говорилось ранее, регрессионное тестирование – это повторное выполнение тестов с целью подтверждения, что работа программного обеспечения не была нарушена после внесения изменений.

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

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