Тестирование кода

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

Обзор кода

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

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

Какие функции обеспечения безопасности необходимо проверить?

• Аутентификацию.

• Авторизацию.

• Конфигурацию безопасности (такие особенности шифрования, как длина ключа или алгоритм, а также настройки заголовков безопасности).

• Управление идентификацией и системы идентификации.

• Управление сессиями.

• Валидацию ввода.

• Кодирование выходных данных.

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

Для чего проводится обзор? Во-первых, чтобы убедиться в наличии контроля безопасности во всех компонентах приложения, где он должен быть. Во-вторых, чтобы подтвердить, что надлежащий контроль безопасности отвечает установленным условиям и требованиям, и, в-третьих, что его реализация и настройка были выполнены корректно.

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

СОВЕТ. Алиса всегда поручает кому-то другому проверить свои презентации и документы, прежде чем показать их начальству, поскольку знает, что часто не замечает своих ошибок. Такой же подход верен и в отношении кода. Лучше всего, если его обзором будет заниматься не тот же человек, который его написал.

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

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

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