поиск по сайту
Способы автоматизации тестирования СЗИ, функционирующих в ОС, на примере ПСКЗИ ШИПКА

Способы автоматизации тестирования СЗИ, функционирующих в ОС, на примере ПСКЗИ ШИПКА

А.И. ОБЛОМОВА, Т.М. БОРИСОВА
РОССИЯ, МОСКВА, ОКБ САПР

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

Согласно общепринятой классификации выделяют несколько основных видов тестирования ПО:

  • функциональное, которое отвечает за проверку реализуемых функциональных требований;
  • нефункциональное, которое отвечает за тестирование таких характеристик, как производительность, стабильность/надежность (тестирование на отказ, нагрузочное, стрессовое тестирование), а также за тестирование удобства использования.

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

Рассмотренные виды тестирования ПО также применимы для тестирования программно-аппаратных средств с учетом определенных особенностей, которые будут рассмотрены ниже.

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

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

Рассмотрим преимущества автоматизированного тестирования по сравнению с ручным тестированием:

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

Рассмотрим способы автоматизации тестирования на примере программно-аппаратных средств защиты информации (СЗИ). Естественно, что при разработке СЗИ необходимо также выполнять их всестороннее тестирование, как и любых других выпускаемых программных или программно-аппаратных средств. Программно-аппаратные средства защиты информации, в свою очередь, грубо можно разделить на 2 группы: СЗИ, функционирующие до старта операционной системы (ОС) и СЗИ, функционирующие в ОС. В данной статье мы рассмотрим автоматизацию тестирования СЗИ второй группы — функционирующие в операционной системе, и не будем рассматривать автоматизацию тестирования СЗИ первой группы, в связи с тем, что автоматизация тестирования последних затруднена по ряду причин и требует отдельного рассмотрения.

Функциональное тестирование СЗИ, выполняемое вручную, проводится по заранее разработанной тестировщиком программе и методике тестирования (ПМИ). При автоматизированном функциональном тестировании СЗИ, как правило, используются скрипты (тесты, разработанные при помощи специальных программ) для эмуляции действий пользователя. Существует множество программ, позволяющих разрабатывать подобные скрипты. Одни из них основываются на технологии поиска и автоматизации работы с элементами графического интерфейса на основе изображений (скриншотов), другие на основе ключевых слов и т.д. Главным плюсом использования скриптов является экономия времени на тестировании монотонных и однотипных действий, например, при переборе входных данных. Таким образом, один раз написанный тест может долго служить, экономя время тестировщика. Но это будет так до первого изменения в поведении тестируемого СЗИ. Если СЗИ начинает функционировать по-другому, даже если это незначительные отклонения (например, выводится новое информационное окно или была изменена цветовая гамма), то требуется вносить изменения в скрипт теста. Это одна из проблем при использовании такого вида автоматизации — будет ли сэкономленное время перевешивать время написания\изменения скриптов. И конечно, нужно учитывать, что автоматизировать тестирование дружественности интерфейса невозможно.

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

Рассмотрим способы тестирования СЗИ, функционирующих в ОС, на примере персонального средства криптографической защиты информации — ПСКЗИ ШИПКА.

Первый способ, это классический способ уже рассмотренный выше — использование автоматизированных скриптов, разработанных при помощи специальных программ автоматизации. Эти скрипты позволят проводить и функциональное и нефункциональное тестирование ПСКЗИ ШИПКА. Однако, поскольку ПСКЗИ ШИПКА состоит из программного и аппаратного компонента, это обязательно нужно учитывать при организации тестирования — в ходе функционального тестирования ПСКЗИ ШИПКА аппаратную часть продукта необходимо переподключать к USB-порту ПК, что нарушает идеологию проведения автоматизированных тестов, которые должны проводится без участия «человека». Поэтому полностью автоматизировать такое функциональное тестирование затруднительно, так как в данном случае необходимо участие тестировщика для выполнения указанных действий. Аналогичная проблема возникает при нефункциональном тестировании — в случае возникновения ошибок в ходе выполнения скрипта устройство необходимо физически переподключить к ПК.

Второй способ автоматизации тестирования ПСКЗИ ШИПКА представляет собой использование комплекта разработчика (SDK — Software Development Kit) для стандартных интерфейсов, который реализован для ПСКЗИ ШИПКА в целях возможности использования криптографической функциональности устройства сторонними разработчиками в своих продуктах. В настоящее время для ПСКЗИ ШИПКА реализовано три стандартных интерфейса: Crypto API, PKCS#11, APDU, а SDK для них включает набор примеров по их использованию. Эти примеры можно использовать для автоматизации функционального тестирования ПСКЗИ ШИПКА, так как их успешное прохождение, гарантирует, конечно, не полностью, но частично, что и те утилиты, которые работают на базе этих интерфейсов, будут работать корректно с ШИПКой. Естественно, при этом остается необходимость функционального и нефункционального тестирования самих утилит продукта.

На основании описанного в данной статье можно сделать вывод, что ручное и автоматизированное тестирование — две неотъемлемые части при проверке качества любого выпускаемого продукта, в том числе и СЗИ. Невозможно полностью автоматизировать все тесты, так как при работе, например, с ПСКЗИ ШИПКА, может потребоваться переподключение устройства в USB-порт ПК. Также автоматизированный тест никогда не сможет проверить «дружественность» интерфейса и т.д. Но однозначно нужно признать, что внедрение автоматизированного тестирования значительно сокращает время на проведение проверок, и с помощью него становится возможным провести тестирование, которое человек сможет выполнить только за достаточно большой период времени, а, возможно, и никогда не сможет. А именно, сложно представить, как тестировщик вручную тестирует предельные значения, например, в случае с ПСКЗИ ШИПКА, проверяет корректность функционирования устройства с максимально возможным количеством криптографических ключей в устройстве, которое может быть больше 200. Для этого тестировщику нужно вручную сгенерировать все эти ключи и только потом проверить корректность функционирования устройства. Если же окажется, что в этом процессе возникнут ошибки, то нужно будет поэтапно уменьшать количество ключей и повторять тестирование до определения критического значения. Также тестировщику сложно вручную проводить стрессовое тестирование, при котором он должен генерировать различные случайные значения и подавать их в качестве входных параметров в устройство, для проверки реакции ПСКЗИ ШИПКА на каждое из них. В случае, с ПСКЗИ ШИПКА например, необходимо задавать различные случайные значения длины PIN-кода и проверять, как устройство будет реагировать на каждое из введенных значений. Эти факты подтверждают правильность подхода использования автоматизированного тестирования наряду с ручным тестированием.


ФорумФорум
Форум ОКБ САПР
Вопросы специалистовВопросы специалистов
Вопросы, которые нам присылают, и наши ответы на них