тестирование. Тестир. инф. систем Метод материалы. Сыркин Илья Сергеевич Тестирование информационных систем методические указания
 Скачать 2.91 Mb.
|
|
6.4. Методы отбора тестов для White-Box тестирования White-box тестирование является не функциональным, а струк- турным – тестируется код программы. От тестировщика требуются, таким образом, навыки программиста. Главным минусом такого тестирования является то, что тестировщик никогда не сможет об- наружить, что какая-то функциональность не реализована, посколь- ку нельзя протестировать код, который не написан. Различают два метода отбора тестов: 1. Тестирование путей исполнения (control-flow testing). 2. Тестирование работы с данными (data-flow testing). Подробно эти методы описаны в книге A Practitioner's guide to Sofware Test Design (Lee Copeland). Описание их выходит за рамки данной лекции, поскольку они не являются методами функциональ- ного тестирования. Контрольные вопросы 1. Что такое Black Box? 2. Что такое White Box? 3. Приведите порядок отбора тестов для различных случаев. 54 7. Лабораторная работа №4. Тестирование безопасности Целью работы является изучение тестирования безопасности ПО. Результатом работы является отчет, в котором должны быть приведены исходные коды программы, результаты тестирования безопасности ПО. Для выполнения работы студент должен изучить приведенный ниже теоретический материал. Отчет сдается в распечатанном и электронном (файл Word) видах. Тестирование безопасности – процесс достижения совершен- ства в открытом космосе при условии, что с Вашим скафандром что-то не так. Но если вернуться на Землю, то тестирование безо- пасности веб-приложения – это попытка найти все те места, в кото- рых могли допустить ошибку разработчики или просто не преду- смотреть / забыть (подчеркните ваш случай). Веб-приложение и веб-сервер неразрывно связаны. Тестирова- ние одного без другого не даст полной картины бедствия. Тестируя защиту веб-приложения, мы ищем уязвимые места для атаки на пользователей. Тестируя защиту веб-сервера, мы ищем уязвимые места для атаки на сервер, его инфраструктуру. Нужно все это в первую очередь людям: простым смертным, решившим заказать пиццу, а не отправить данные своей карты не- понятно куда; простым владельцам пиццерий, не беспокоящимся, что кто-то смог бесплатно научиться заказывать пиццу через их приложение; простым разработчикам, которым не придется править код в 3 часа утра. Как правило, небольшие организации, имеющие свой сайт и небольшой сервер с битриксом, думают, что они слишком малы для того, чтобы стать мишенью для атаки. И в этом они заблуждаются. Безусловно, вероятность таргетированной атаки на них ниже, чем на финансовых гигантов, но все-таки не равна нулю. В нынешнее время нейронных сетей и повальной автоматизации никто не будет выяснять, большой ли денежный оборот у фирмы. Главное – это ко- личество уникальных посетителей, ведь суммарно в их карманах может оказаться больше «фишек», чем компания получает за год. Существуют компании, которые уже взломали, и компании, которые еще не взломали. На практике это вопрос времени. Пра- вильные компании, которые тратят на безопасность значительную часть прибыли, – это нормальный порядок вещей для всего цивили- 55 зованного мира. В нашей стране, к сожалению, пока к этому не пришли, считая, что «хата наша с краю» студент-старшекурсник вполне способен настроить одну «циску» и запретить доступ к внутренним ресурсам извне (мол, «денег нет, но вы держитесь»). Ведь мы не привыкли тратить деньги на свою безопасность: бюджет отделов по информационной безопасности (ИБ) обычных компаний только сокращается. С другой стороны, многие адекват- ные компании (читай, иностранные) формируют собственный штат по информационной безопасности, другие многие нанимают спе- циалистов на аутсорс, немногие запускают программы баг-баунти, где любой желающий может принять участие в поиске уязвимостей. Безусловно, все они хотят сохранить свои доходы и свою репута- цию. На что и на кого ориентировано тестирование безопасности? Кто получит выгоду от этого в первую очередь? Естественно, в первую очередь от безопасного серфа сайта вы- игрывает пользователь. Если нет нужды беспокоиться о том, что Ваши персональные данные могут утечь в сеть, то и доверять ре- сурсу Вы будете больше. А если счастлив пользователь, то счастлив и владелец веб-ресурса (и тем более он счастлив, чем меньше у него рисков потерять финансы). ИЗНУТРИ Исследование безопасности веб-ресурса – сложная и кропот- ливая работа, требующая внимательности, фантазии и творческого подхода. Исследователю безопасности необходимо глубокое пони- мание технической изнанки работы веб-приложения и веб-сервера. Каждый новый проект дает пищу для фантазии, каждый новый ин- струмент – просторы для творчества. Да и вообще, тестирование безопасности больше похоже на исследовательскую работу – это постоянный поиск и анализ. Каждый новый проект требует применения новых инструмен- тов, изучения новых технологий, поглощения множества книг и статей, которые достаточно трудно найти. Большая часть информа- ции находится в англоязычном пространстве, что добавляет опреде- ленные трудности в освоении материала людям, языком английским не владеющим. Если говорить о процессе тестирования безопасности, то в це- лом он не сильно отличается от тестирования обычного: поиск, ло- 56 кализация, воспроизведение, заведение, отчет. Приоритеты, безус- ловно, зависят от заказчика, от целей тестирования. К сожалению, некоторые курсы по тестированию безопасности / анализу защищенности / аудиту безопасности в интернете внуша- ют, что достаточно пройтись по веб-приложению каким-нибудь сканером безопасности – и все готово! Отчет есть, уязвимости – вот они! Что же еще вам нужно? Но не стоит быть таким наивным. Большинство уязвимостей ищется и находится именно вручную, при внимательном изучении. Они могут быть совершенно неслож- ными, но автоматические сканеры пока еще не способны их обна- ружить. Классификацией векторов атак и уязвимостей занимается со- общество OWASP (Open Web Application Security Project) – между- народная некоммерческая организация, сосредоточенная на анализе и улучшении безопасности программного обеспечения. OWASP (https://www.owasp.org/) составил список из 10-и са- мых опасных уязвимостей, которым могут быть подвержены интер- нет-ресурсы. Сообщество обновляет и пересматривает этот список раз в три года, поэтому он содержит актуальную информацию. По- следнее обновление было сделано 2017: внедрение кода; некорректная аутентификация и управление сессией; утечка чувствительных данных; внедрение внешних XML– сущностей (XXE); нарушение контроля доступа; небезопасная конфигурация; межсайтовый скриптинг; небезопасная десериализация; использование компонентов с известными уязвимостями; отсутствие журналирования и мониторинга. Организация OWASP дополнительно к своему списку из 10 самых опасных уязвимостей разработала методические рекоменда- ции (практикум) по тестированию безопасности веб-приложений. В них подробно, шаг за шагом, описано, как и что необходимо тести- ровать, на что обратить внимание в первую очередь, а на что – во вторую. Методика носит рекомендательный характер и, конечно, никого ни к чему не обязывает (инженер, проводящий тестирова- ние, некоторые моменты может перенести, а другие – вообще опус- 57 тить), но, тем не менее, позволяет сделать максимальное покрытие для веб-приложения. Итак, весь процесс тестирования состоит из двух этапов: 1. Пассивный, во время которого тестировщик пытается по- нять логику приложения и «играет» с ним. Могут использоваться инструменты для сбора информации. Например, с помощью HTTP прокси можно изучить все HTTP-запросы и ответы. В конце данно- го этапа тестировщик должен понимать все точки входа приложе- ния (HTTP-заголовки, параметры, куки и пр.). 2. Активный. Во время данного этапа тестировщик проводит тесты в соответствии с методологией. Все тесты разбиты на один- надцать подразделов: сбор информации; тестирование конфигурации; тестирование политики пользовательской безопасности; тестирование аутентификации; тестирование авторизации; тестирование управления сессией; тестирование обработки пользовательского ввода; обработка ошибок; криптография; тестирование бизнес-логики; тестирование уязвимостей на стороне пользователя. Какие инструменты используются для анализа безопасности? Оценив объемы бедствия, следует сбеж рассмотреть существующие инструменты. Конечно же, главные Ваши аргументы против не- справедливости в сетевых именах – это глаза и мозг. На самом же деле, добрые люди разработали огромный инструментарий – начи- ная от специализированных скриптов, «заточенных» для какой-то одной конкретной цели, и заканчивая целыми комбайнами – гото- выми выжать максимальные выводы из минимума вводных. К со- жалению, часто такой результат оказывается лже-срабатыванием. Как правило, инженер по тестированию при выборе инструментов основывается на приоритетах: что важнее – время или область по- крытия? Современные разработчики довели автоматизацию до не- бывалых высот, поэтому можно смело следовать принципу Парето: 80% работы скармливать автоматизированным анализаторам, а все 58 оставшееся «проходить руками». Но, честно говоря, результаты ав- томатизированных средств все равно придется изучать и проверять. Приведем небольшой список категорий инструментов: сканеры веб-уязвимостей; инструменты для эксплуатации уязвимостей; инструменты криминалистики; сканеры портов; инструменты мониторинга трафика; отладчики; руткит детекторы; инструменты шифрования; инструменты для брутфорса. Из-за разгильдяйства разработчиков. Из-за невнимательности. Из-за халтуры. Из-за лени. Из-за-за… Но чаще всего уязвимости возникают из-за неопытности. Не все разработчики представляют себе, как злоумышленник будет атаковать их продукт. Некоторые считают, что достаточно экрани- ровать кавычку («’») в пользовательском вводе или спастись «magic_quotes» – и можно будет избежать SQL-инъекции. Отсюда и получается, что превентивные меры мы принимаем, а что делать дальше – не знаем. И WAF’ы нас не спасут. Контрольные вопросы 1. Перечислите основные атаки на код. 2. Что такое внедрение кода? 3. Какие основные причины появления уязвимостей в коде? 59 8. Лабораторная работа №5. «Нагрузочное тестирование, стрессовое тестирование» Целью работы является изучение нагрузочного тестирования ПО. Результатом работы является отчет, в котором должны быть приведены исходные коды программы, результаты нагрузочного тестирования ПО. Для выполнения работы студент должен изучить приведенный ниже теоретический материал. Отчет сдается в распечатанном и электронном (файл Word) видах. Подготовка проекта и запись тестов В качестве основного инструмента для нагрузочного тестиро- вания мы будем использовать MS Visual Studio Enterprise 2017 (в других редакциях студии поддержка данного типа проектов может отсутствовать) и тип проекта Web Performance and Load Test Project. Рис. 1. Создание нового проекта После создания проекта нам необходимо будет создать тесты для каждого из ранее определенных пользовательский действий. Ограничимся созданием теста для одного пользовательского дейст- вия в качестве примера, поскольку остальные действия создаются по аналогии. Для тестов мы будем использовать стандартный тип теста Web Performance Test, встроенный в Visual Studio. Нашим первым тестом, который мы создадим, будет тест, от- крывающий детали продукта в интернет-магазине. Для создания теста выберем из списка предложенных Studio тип теста «Web Performance Test», зададим имя «Storefront- ProductDetail». 60 Рис. 2. Выбор типа теста в Visual Studio Для данного типа теста Visual Studio сразу же попытается от- крыть браузер, где можно будет в интерактивном режиме прокли- кать необходимые действия непосредственно на сайте, но мы этого делать не будем, но сразу закроем браузер и остановим запись. В итоге мы получим пустой тест Storefront-ProductDetail.webtest. Далее нам нужно добавить источник данных для данного тес- та, для того чтобы можно было использовать различные параметры запроса в рамках одного теста, для этого в VS Studio Web Performance Test предусмотрена такая возможность. В качестве источника данных для нашего теста мы будем ис- пользовать таблицу в базе данных, где хранятся записи о продуктах. После этого у нас появится возможность использовать данные из подключенного источника в запросе, который должен открывать детали продукта на тестируемом приложении. Достигается это пу- тем вставки конструкции «{{Имя источника данных.Название таб- лицы.Название колонки}}». В итоге после всех манипуляций наш первый тест примет вот такой вид. Рис. 3. Содержимое теста Настало время для первого запуска, попытаемся запустить наш тест и убедиться, что он работает корректно. 61 Рис. 4. Результат работы единичного теста По аналогии создадим тесты для все остальных наших сцена- риев. Рис. 5. Результирующий набор тестов После этого у нас практически все готово к созданию комби- нированного теста, который будет эмулировать реальное поведение пользователя на сайте. Для этого добавляем в наш проект новый LoadTest. 62 Рис. 6. Создание нового load-теста В появившемся мастере выбираем тип On-premises Load test. Рис. 7. Выбор типа теста Этот пункт требует определѐнного разъяснения, ведь вы спра- ведливо спросите: «Причем тут on-premise?» Тема статьи о тестиро- вании с помощью Teams Services и MS Azure, но тут есть нюанс, так как мы для тестов используем источники данных в виде таблиц или других внешних сервисов, то с этим могут возникнуть определен- ные сложности, когда мы попытаемся запустить данный тест в об- лаке. После тщетных попыток заставить работать такие тесты в об- лаке мы отказались от этой затеи и решили использовать для тести- рования так называемые «записанные» тесты, которые получаются 63 путем записи запросов, генерируемых тестами работающих локаль- но и имеющих подключение к источникам данных. Для записи тестов мы используем Fiddler, у которого есть воз- можность экспорта запросов в формат Visual Studio Web Tests. Немного далее мы расскажем более подробно про процедуру записи такого теста. На последующих шагах выбираем продолжительность тести- рования, количество пользователей и, самое главное – указываем, из каких тестов будет состоять наш MixedLoadTest и в каких пропор- циях они будут использоваться. Рис. 8. Составляющие теста В результате после всех действий мы получим комбинирован- ный MixedLoadTest, настроенный для запуска для локально- развернутого приложения. Далее нам необходимо запустить данный тест и попытаться записать с помощью Fiddler все запросы которые будут генериро- ваться в результате работы теста, а также получить «запись», кото- рую мы сможем запустить уже непосредственно в облаке. Предварительно запускаем Fiddler и наш MixedLoadTest тест. 64 Рис. 9. Результат работы теста После отработки всех данных получим вот такую картинку в Fiddler. Рис. 10. Сессия теста в Fiddler Далее в Fiddler сохраняем все сессии в формате Visual Studio Web Tests, File -> Export sessions -> All sessions -> Visual Studio Web Tests и добавляем полученный файл в проект. Напомню, что данное действие необходимо для того, чтобы мы смогли получить тест без привязки к внешним источникам данных, так как с запуском такого рода тестов могут возникнуть проблемы в облачной среде. 65 Рис. 11. Детали «записанного» теста Теперь практически все готово для запуска нашего теста в об- лаке, последним шагом по подготовке теста нужно в любом тексто- вом редакторе открыть «записанный» MixedLoadTest и заменить в нем localhost:8888 (адрес прокси, Fiddler-а) на адрес нашего магази- на в облаке. Запуск теста в облаке Для запуска тестов в облаке нам потребуется действующая учетная запись в Visual Studio Team Services. Создаем новый LoadTest, только на этот раз выбираем Cloud- based Load Test with Visual Studio Team Services. 66 На следующих шагах выбираем дата-центр, с которого будет генерироваться трафик на тестируемый ресурс, а также максималь- ное количество агентов (пользователей) для константного паттерна, либо, если мы хотим использовать постепенное увеличение нагруз- ки, то необходимо задать соответствующие параметры. На шаге выбора тестов, выбираем единственный тест, который мы записали ранее с помощью Fiddler, он и будет эмулировать «ре- альную» нагрузку на тестируемый ресурс. 67 После завершения создания запускаем тест, в процессе выпол- нения которого студия будет показывать некоторые ключевые мет- рики, такие как производительность и полоса пропускания, а также строить графики в реальном времени. Рис. 12. Процесс работы теста в облаке После завершения теста также можно посмотреть сохранен- ный веб отчет в VSTS: 68 Рис. 13. Web отчет на Visual Studio Team Services портале Анализ результатов Самый важный момент – это обработка и анализ полученных результатов теста. Для рассматриваемой задачи требовалось оце- нить производительность приложения, работающего на различных конфигурация Azure Web Apps B2 и B3 тарифах. Для этого мы запускали «записанный» тест повторно для при- ложения на разных конфигурациях и фиксировали полученные ре- зультаты в Excel документе. В итоге получился вот такой отчет: Рис. 14. Результирующий отчет тестирования Проанализировав полученные данные, удалось выяснить пре- дельную нагрузку которое может выдержать наше приложение – |