Доклады, выступления, видео и электронные публикации

Задача тестирования аппаратных средств защиты информации.

Т. М. Борисова
Закрытое акционерное общество "ОКБ САПР", Москва, Россия
В. А. Гадасин, д-р техн. наук
ФГУП «Всероссийский научно-исследовательский институт проблем вычислительной техники и информатизации», Москва, Россия

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

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

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

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

Не стоит путать понятия ЖЦ разработки ПО и ЖЦ ПО. Сам по себе ЖЦ ПО — это более общее понятие, которое состоит из совокупности этапов, начинающихся с момента принятия решения о необходимости создания ПО и заканчивающихся в момент полного вывода ПО из эксплуатации.

В настоящее время существует несколько видов моделей ЖЦ ПО, рассмотрим наиболее распространенные из них.

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

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

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

Еще более современной является итерационная модель ЖЦ (альтернатива последовательной модели), предполагающая разбиение ЖЦ на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. На каждой итерации получается работающая версия ПО, включающая функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность ПО.

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

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

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

Одним из немаловажных факторов при организации процесса тестирования является правильное понимание смысла термина «тестирование».

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

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

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

Цель применения тестирования ПО — минимизация числа дефектов в конечном продукте. Тестирование само по себе не может гарантировать полного отсутствия дефектов в программном коде системы. Однако грамотно организованное тестирование дает гарантию того, что система удовлетворяет требованиям и ведет себя в соответствии с ними во всех предусмотренных ситуациях.

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

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

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

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

Модульное тестирование или юнит-тестирование (unit testing) — это процесс в ЖЦ разработки ПО, позволяющий проверить на корректность отдельные модули исходного кода программы (программные модули). При модульном тестировании, как правило, выделяется и тестируется минимально возможный для тестирования компонент, например, отдельный класс, процедура или функция.

Интеграционное тестирование представляет собой тестирование модулей, объединенных в совместно работающие комплексы. Проверяется корректность взаимодействия между модулями, а также модулей с их окружением (операционной системой, оборудованием и т. п.). Такое тестирование необходимо в любой системе, даже если каждый ее модуль проверен по отдельности, так как даже в этом случае невозможно гарантировать, что объединенные модули будут работать вместе. Интеграция модулей и интеграционное тестирование должны проводится в течение всего ЖЦ разработки ПО. Если же интеграция выполняется на последних этапах ЖЦ, то локализовать дефекты разработки практически невозможно. Часто интеграционное тестирование выполняется итерационно с постепенным подключением каждого последующего модуля.

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

Принято выделять два подхода к системному тестированию:

на базе требований. Для каждого требования пишутся тестовые случаи — тест-кейсы (test cases), проверяющие выполнение данного требования;
на базе случаев использования. На основе представления о способах использования продукта создаются случаи использования системы (use cases). По конкретному случаю использования можно определить один или более сценариев. На проверку каждого сценария пишутся тест-кейсы, которые должны быть протестированы.

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

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

Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие признаки:

по объекту тестирования;
по степени автоматизированности;
по времени проведения;
по степени готовности;
по признаку позитивности сценариев. Тестирование ПО объекту тестирования, в зависимости от преследуемых целей, можно условно разделить на три группы: функциональное, нефункциональное и связанное с изменениями.

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

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

Функциональное тестирование проводится с целью проверки реализуемости функциональных требований к модулю, нескольким модулям или системе в целом (в зависимости от уровня, на котором оно выполняется).

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

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

Нефункциональное тестирование описывает тесты, необходимые для определения характеристик ПО, которые могут быть измерены различными величинами. В целом, это тестирование того, «как» система работает.

Существуют следующие виды нефункциональных тестов: тестирование производительности, надежности, стрессовое тестирование, тестирование установки, удобства использования, тестирование на отказ и конфигурационное тестирование.

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

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

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

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

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

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

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

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

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

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

Итоговым тестированием является тестирование сборки, которое предназначено для определения соответствия выпущенной версии критериям качества для начала тестирования.

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

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

В свою очередь автоматизированное тестирование предполагает, что для выполнения тестов и проверки результатов выполнения используются программные средства (собственные или сторонние).

Гибридом перечисленных вариантов является полуавтоматизированное тестирование, при выполнении которого используются инструменты автоматизации тестирования наряду с тестированием вручную.

Классифицируя процесс тестирования по времени его проведения можно выделить два вида: альфа- и бета-тестирование.

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

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

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

Если говорить об определении тестирования по признаку позитивности сценариев, принято выделять два вида тестирования: позитивное и негативное.

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

В процессе позитивного тестирования проверяется результат работы ПО при получении им «правильных» входных данных.

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

Для каждого из рассмотренных видов тестирования можно использовать любой из трех основных подходов к выявлению недостатков системы: тестирование методом «белого», «черного» и «серого» ящиков. Различия в этих подходах заключаются в тех средствах, которыми располагает тестировщик.

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

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

Метод «серого» ящика балансирует между белым и черным ящиком. Это метод «черного ящика» в сочетании со взглядом на объект с помощью восстановления исходного кода. Исходный код — это неоценимый ресурс, который относительно несложно прочесть и который дает четкое представление о специфической функциональности. Часто для метода «серого ящика» применяют отладчики (дебагеры) и декомпиляторы, позволяющие получить знание об исходном коде.

Помимо трех общепринятых методов тестирования существует еще один метод, основанный на принципе «разработка через тестирование» или Test Driven Development (TDD). Основной идеей этого метода является то, что разработка программного кода должна выполняться, исходя из автоматических тестов. В рамках этой методики предполагается использование двух правил:

написание нового кода осуществляется только тогда, когда автоматический тест не сработал;
периодически необходимо проводить удаление дублирования кода.

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

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

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

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

Рассмотрим тестирование оборудования на примере флешек — USB-носителей информации на основе Flash-памяти. Существует ряд утилит, позволяющих обнаружить ошибки на таких носителях информации, при этом в этих утилитах, как правило, используется метод тщательного сканирования на предмет помарок при чтении/ записи информации.

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

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

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

Из рассмотренного видно, что для тестирования программно-аппаратного средства (на примере USB-носителей информации на основе Flash-памяти) вполне применимы основные понятия, используемые для определения процесса тестирования ПО. Перечисленные варианты тестирования флешек вполне сопоставимы с определением нефункционального тестирования, которое является одним из видов тестирования ПО. Функциональное тестирование и тестирование, связанное с изменениями, здесь не рассматривались, но также вполне могут быть аппроксимированы на тестирование флешек, как и все остальные виды тестирования, классифицирующиеся по степени автоматазированности, времени проведения, степени готовности, признаку позитивности сценариев.

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

Основные методы тестирования («белого», «черного», «серого» ящика) также вполне могут быть применены к программно-аппаратным средствам в зависимости от представленной для тестирования информации.

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

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

Рассматривая три основных метода тестирования в ракурсе тестирования аппаратных СЗИ можно сделать вывод, что использование метода «серого» ящика становится практически невозможным, так как в этом случае пришлось бы выполнять декомпилирование и отладку внутреннего программного кода аппаратных СЗИ, что является невыполнимой задачей. В свою очередь, использование методов «белого» и «черного» ящика в данном случае не вызывает никаких трудностей.

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

Нагрузочное тестирование в случае с аппаратными СЗИ также имеет ряд отличий от тестирования ПО. При тестировании ПО не нужно, например, следить за нагревом устройств, что в случае с аппаратными СЗИ может говорить о неверной разводке платы.

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

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

Авторы: Каннер(Борисова) Т. М.; Гадасин В. А.

Дата публикации: 01.01.2012

Библиографическая ссылка: Каннер (Борисова) Т. М., Гадасин В. А. Задача тестирования аппаратных средств защиты информации // Вопросы защиты информации. М., 2012. № 3. С. 10–16.


Метки документа:
сзи нсд  

Scientia potestas est
Кнопка связи