Лекции по дисциплине _Тестирование информационных систем_ (2). Лекции на специальности спо базовой подготовки 09. 02. 07 Информационные системы и программирование Ульяновск 2021
 Скачать 65.19 Kb.
|
|
Тема 3.2 Тестирование web-приложений Особенности тестирования web-приложений Тестирование веб-приложений – это комплекс услуг, который может включать в себя различные виды тестирования ПО. Основная цель любого тестирования, в том числе и тестирования веб-приложений, – обнаружить все ошибки в программном обеспечении и разработать рекомендации по их предотвращению в будущем. Функциональное тестирование – процесс оценки поведения приложения, позволяющий определить, все ли разработанные функции ведут себя так, как нужно. Для корректной работы продукта все процессы должны работать так, как это предусмотрено в требованиях: от разграничения прав доступа при авторизации до корректного выхода из системы. Функциональное тестирование может быть выполнено с использованием заранее подготовленных тестовых сценариев или методами исследовательского тестирования. Тестирование совместимости – это процесс оценки поведения приложения в различных браузерах, операционных системах, на устройствах с разным разрешением экрана. Проверка совместимости продукта со всеми последними версиями браузеров Chrome, Firefox, MS Edge, Safari и ОС Windows 7, 8 и 10 является примером данного вида тестирования. Тестирование производительности – комплекс проверок, направленный на определение лимитов производительности приложения. После проведения тестирования специалисты предоставят отчет, который будет содержать следующую информацию: Статистические данные по времени отклика с сервера для наиболее важных операций; Диаграммы, показывающие зависимость производительности приложения от количества пользователей, одновременно работающих в программе; Данные о максимально возможном числе пользователей, при котором система справляется с нагрузкой; Информация об устойчивости системы и ее способности выдерживать постоянную нагрузку; Статистика ошибок; Выводы об эффективности системы в целом, ошибках ее производительности; Рекомендации по повышению производительности системы. Тестирование безопасности и тестирование на проникновение позволяет определить, как и при каких обстоятельствах приложение может быть взломано. Анализ и оценка уровня защищенности приложения – зона ответственности инженеров по тестированию безопасности. Локализованный продукт всегда дает больше возможностей для бизнеса. Процесс проверки качества локализации называется тестированием локализации. Аспекты, качество которых проверяют специалисты по тестированию локализации: Перевод содержимого страницы и элементов пользовательского интерфейса; Формат данных и времени; Обозначение денежных единиц; Цветовые схемы, символы, значки и другие графические элементы, которые могут быть по-разному истолкованы в различных регионах; Правовые нормы, которые следует учитывать. Цель тестирования соответствия – установить, соответствует ли приложение юридическим нормам и стандартам, которым подчиняется ваш бизнес. Примером тестирования соответствия является проверка выполнения рекомендаций Руководства по обеспечению доступности веб-контента (WCAG). Учет требований данного Руководства помогает сделать веб-продукт доступным для людей с ограниченными возможностями. Тестирование пользовательского интерфейса. Графический интерфейс пользователя (Graphical user interface, GUI) –разновидность пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки, значки, списки и т. п.), представленные пользователю на дисплее, исполнены в виде графических изображений. Проверяется в целом общий вид приложения и в отдельности формы, расположенные на странице. Общие проверки: Вид элементов при уменьшении окна браузера + появление скрола Правильность написания текста + текст должен быть выровнен Правильность перемещения фокуса в окне (Tab / Tab+Shift) Выбранные элементы выделяются Неизменяемые поля выглядят одинаково и отличаются от редактируемых Желательно не использовать двойной клик Проверка наличия нужных нотификейшенов Унификация дизайна (цвет, шрифт, размер) При необходимости должны быть тултипы Изменение вида элемента при ховере на него Если формы дублируются, то должны быть одинаковые названия Дополнительные проверки для веб-форм Основные моменты при проверке GUI: расположение, размер, цвет, ширина, длина элементов; возможность ввода букв или цифр реализуется ли функционал приложения с помощью графических элементов размещение всех сообщений об ошибках, уведомленией (а также шрифт, цвет, размер, расположение и орфография текста) читабелен ли использованный шрифт переходит ли курсор из текстового в поинтер при наведении на активные элементы, выделяются ли выбранные элементы выравнивание текста и форм качество изображений проверить расположение и отображение всех элементов при различных разрешениях экрана, а также при изменении размера окна браузера (проверить, появляется ли скролл) проверить текст на орфографические, пунктуационные ошибки появляются ли тултипы (если есть необходимость) унификация дизайна (цвета, шрифты, текст сообщений, названия кнопок и т.д.) Наиболее распространенные баги: курсор не переходит в поинтер при наведении на активный элемент орфографические и грамматические ошибки не ровное расположение полей ввода в формах, самих форм неправильное отображение элементов при смене размера окна браузера и масштаба страницы изменение размера текста при смене языка неровное расположение форм разные шрифты выбранные элементы не отличаются от не выбранных Ручное тестирование Ручное тестирование (manual testing) — часть процесса тестирования на этапе контроля качества в процессе разработки программного обеспечения. Оно производится тестировщиком без использования программных средств, для проверки программы или сайта путём моделирования действий пользователя. В роли тестировщиков могут выступать и обычные пользователи, сообщая разработчикам о найденных ошибках. Сегодня есть множество фреймворков для тестирования, поддерживающих практически все существующие языки. Казалось бы — можно брать и автоматизировать. Но даже сейчас ручные тесты важны. Одно из объяснений их необходимости заключается в том в том, что при ручном тестировании функционала мы можем гораздо быстрее получить информацию о состоянии продукта, который анализируем, о качестве разработки. Кроме того, при автоматизации предварительно разработанные кейсы часто приходится менять и актуализировать, а на написание автотестов требуется определённое время. При этом в процессе разработки может прийти обратная связь от заказчика, когда он увидит в готовом продукте какую-то функцию, которую решит изменить до релиза — и, если вы уже подготовили для неё программные тесты, их придётся переписать. Обновление кейсов, автотестов и их проверка отнимут ценное время, которое можно было бы использовать на само обновление этой фичи. Всё это означает, что главная цель ручных тестов — предварительно убедиться в том, что заявленный функционал работоспособен, не имеет ошибок и выдаёт ожидаемые, запланированные результаты. Без них нельзя быть уверенным в том, что можно работать дальше. Особенно это актуально для функций, на реализацию которых завязана последующая разработка. В таком случае возня с созданием автотестов на эти фичи становится блокирующим фактором для всей разработки продукта, сдвигая сроки и срывая дедлайны. Момент, когда кейсы придёт пора автоматизировать, всё равно рано или поздно наступит — но не стоит стремиться приблизить его искусственно в погоне за тотальным исключением ручного труда. Тема 3.3 Организация тестирования информационных систем Основные этапы тестирования Тестирование программного продукта позволяет на протяжении всего жизненного цикла ПО гарантировать, что программные проекты отвечают заданным параметрам качества. Главная цель тестирования - определить отклонения в реализации функциональных требований, обнаружить ошибки в выполнении программ и исправить их как можно раньше в процессе выполнения проекта. На протяжении всего жизненного цикла разработки ПО применяются различные типы тестирования для гарантии того, что промежуточные версии отвечают заданным показателям качества. При этом применяются автоматические и ручные тесты. Модульное тестирование предназначено для проверки правильности функционирования методов классов ПО. Модульные тесты пишутся и исполняются разработчиками в процессе написания кода. Модульное тестирование применяется как для проверки качества кода приложения, так и для проверки объектов баз данных. Исследовательское тестирование предназначено для тестирования, при котором тестировщик не имеет заранее определенных тестовых сценариев и пытается интуитивно исследовать возможности программного продукта и обнаружить и зафиксировать неизвестные ошибки. Интеграционное тестирование используется для проверки корректности совместной работы компонентов программного продукта. Функциональное тестирование предполагает проверку конкретных требований к ПО и проводится после добавление к системе новых функций. Нагрузочное тестирование предназначено для проверки работоспособности программного продукта при предельной входной нагрузке. Регрессионное тестирование применяется при внесении изменений в программное обеспечение с целью проверки корректности работы компонентов системы, которые потенциально могут взаимодействовать с измененным компонентом. Комплексное тестирование предназначено для тестирования функциональных и нефункциональных требований всей системы программного продукта. Приемочное тестирование представляет собой функциональные испытания, которые должны подтвердить то, что программный продукт соответствует требованиям и ожиданиям пользователей и заказчиков. Приемочные тесты пишутся бизнес-аналитиками, специалистами по контролю качества и тестировщиками. Функциональное тестирование Существуют 2 основных принципа тестирования программ: 1) функциональное тестирование (тестирование черного ящика); 2) структурное тестирование (тестирование белого ящика). При тестировании черного ящика известны функции программы и исследуется работа каждой функции на всей области определения. Функциональные тесты базируются на функциях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном, интеграционном, системном и приемочном. Функциональные виды тестирования рассматривают внешнее поведение системы, т.е. функции, которые описывают, «что» система делает. Функциональное тестирование основывается на знании о поведении системы, которое описывается в проектной документации. Цель функционального тестирования – подтвердить, что программный продукт реализован в соответствии с функциональными требованиями. Тестирование функциональности может проводиться в двух аспектах: ● требования ● бизнес-процессы Тестирование в перспективе «требования» использует спецификацию функциональных требований к системе как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал. Тестирование в перспективе «бизнес-процессы» использует знание этих самых бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этой перспективе тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases). Тестирование взаимодействия (Interoperability Testing) - это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами, и включающее в себя тестирование совместимости и интеграционное тестирование Тестирование безопасности – это вид тестирования, используемый для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным. Принципы безопасности программного обеспечения: Общая стратегия безопасности основывается на трех основных принципах: Конфиденциальность – это сокрытие определенных ресурсов или информации. Под конфиденциальностью можно понимать ограничение доступа к ресурсу некоторой категории пользователей, или другими словами, при каких условиях пользователь авторизован получить доступ к данному ресурсу. Целостность - существует два основных критерия при определении понятия целостности: 1. Доверие. Ожидается, что ресурс будет изменен только соответствующим способом определенной группой пользователей. 2. Повреждение и восстановление. В случае когда данные повреждаются или неправильно меняются авторизованным или не авторизованным пользователем, вы должны определить на сколько важной является процедура восстановления данных. Доступность представляет собой требования о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс, тем выше уровень доступности должен быть. Структурное тестирование Структурное тестирование основывается на детальном изучении логики программы и подборе тестов, обеспечивающих максимально возможное число проверяемых операторов, логических ветвлений и условий. Его еще называют «тестирование по маршрутам». Под маршрутом понимают последовательности операторов программы, которые выполняются при конкретном варианте исхоных данных. При построении тестов используют следующие критерии: - покрытие операторов путем выбора набора данных, обеспечивающего выполнение каждого оператора в программе по крайней мере один раз. - покрытие условий путем подбора наборов данных, обеспечивающих в узлах ветвления с более чем одним условием принятие каждым условием значения "истина" или "ложь" хотя бы по одному разу. - комбинаторное покрытие условий путем подбора тестов, обеспечивающих в узлах ветвления с более чем одним условием перебор всех возможных сочетаний значений условий в одном узле ветвления. Считают, что программа проверена полностью, если с помощью тестов удается осуществить выполнение программы по всем возможным маршрутам передач управления. Однако нетрудно видеть, что даже в программе среднего уровня сложности число неповтояющихся маршрутов может быть очень велико и, следовательно, полное или исчерпывающее тестирование маршрутов, как правило, невозможно. При тестировании белого ящика объектом тестирования является не внешнее, а внутреннее поведение программы. Проверяется корректность построения всех элементов программы и правильность их взаимодействия друг с другом. При этом обычно анализируются управляющие связи элементов, реже информационные. Тестирование по принципу белого ящика характеризуется степенью, в которой тесты выполняют логику, т.е. исходный текст программы. Обычно тестирование белого ящика основано на анализе управляющей структуры программы. Программа считается полностью проверенной, если проведено исчерпывающее тестирование маршрутов графа управления. В этом случае формируются тестовые варианты, в которых: 1) гарантируется проверка всех независимых маршрутов программы; 2) проверяются ветви TRUE и FALSE для всех логических решений; 3) выполняются все циклы в пределах их границ и диапазонов; 4) анализируется правильность внутренних структур данных. Тестирование покрытия программного кода Покрытие – это часть структуры программы, которая была охвачена тестированием, выраженная в процентах. Существует несколько различных способов измерения покрытия: покрытие операторов — каждая ли строка исходного кода была выполнена и протестирована; покрытие условий — каждая ли точка решения (вычисления истинно ли или ложно выражение) была выполнена и протестирована; покрытие путей — все ли возможные пути через заданную часть кода были выполнены и протестированы; покрытие функций — каждая ли функция программы была выполнена; покрытие вход/выход — все ли вызовы функций и возвраты из них были выполнены. покрытие значений параметров — все ли типовые и граничные значения параметров были проверены. Полная система тестов позволяет утверждать, что система реализует всю функциональность, указанную в требованиях, и, что еще более важно – не реализует никакой другой функциональности. Степень покрытия программного кода тестами – важный количественный показатель, позволяющий оценить качество системы тестов, а в некоторых случаях – и качество тестируемой программной системы. Одним из наиболее часто используемых методов определения полноты системы тестов является определение отношения количества тест-требований, для которых существуют тестовые примеры, к общему количеству тест-требований, — т.е. в данном случае речь идет о покрытии тестовыми примерами тест-требований. В качестве единицы измерения степени покрытия здесь выступает процент тест-требований, для которых существуют тестовые примеры, называемый процентом покрытых тест-требований. Покрытие требований позволяет оценить степень полноты системы тестов по отношению к функциональности системы, но не позволяет оценить полноту по отношению к ее программной реализации. Одна и та же функция может быть реализована при помощи совершенно различных алгоритмов, требующих разного подхода к организации тестирования. Для более детальной оценки полноты системы тестов при тестировании стеклянного ящика анализируется покрытие программного кода, называемое также структурным покрытием. Во время работы каждого тестового примера выполняется некоторый участок программного кода системы, при выполнении всей системы тестов выполняются все участки программного кода, которые задействует эта система тестов. В случае, если существуют участки программного кода, не выполненные при выполнении системы тестов, система тестов потенциально неполна (т.е. не проверяет всю функциональность системы), либо система содержит участки защитного кода или неиспользуемый код (например, "закладки" или задел на будущее использование системы). Таким образом, отсутствие покрытия каких-либо участков кода является сигналом к переработке тестов или кода (а иногда – и требований). К анализу покрытия программного кода можно приступать только после полного покрытия требований. Полное покрытие программного кода не гарантирует того, что тесты проверяют все требования к системе. Одна из типичных ошибок начинающего тестировщика – начинать с покрытия кода, забывая про покрытие требований. Тестирование скорости загрузки системы Хорошая скорость загрузки страницы — 0.35–0.38 секунд. Такие результаты показывают сайты в топе выдачи. Чтобы посчитать это время, нужно измерить так называемую «скорость ответа сервера» — как быстро он реагирует на запрос клиента (браузера). Вебмастеры измеряют скорость загрузки с помощью различных сервисов — платных и бесплатных. Google PageSpeed Insights бесплатно измеряет скорость загрузки и на мобильных, и на стационарных устройствах. Рейтинг определяется по 100-балльной шкале: чем больше баллов, тем лучше. Если ваш сайт получил более 85, значит, все хорошо. Не стремитесь получить 100 баллов. Это не удается даже сервисам Google. Яндекс.Вебмастер Посмотреть скорость ответа сервера на запрос робота «Яндекса» можно с помощью инструмента webmaster.yandex.ru. Он покажет время ответа в миллисекундах: Если код ответа — «200 ОК», с сайтом все в порядке. Если какой-то другой («404 Not Found», «301 Moved Permanently»), у вас проблемы. Как и у Google, у «Яндекса» это бесплатный сервис, которым можно пользоваться без регистрации и глубокого понимания бекенда. Pingdom Сервис pingdom.com предоставляет более подробную информацию для тестирования сайтов, чем перечисленные выше. Кроме оценки общей скорости сайта, Pingdom покажет, с какой скоростью загружается каждый элемент страницы. Если на сайте возникли неполадки, Pingdom пришлет уведомление. Есть приложения для Android и iOS, чтобы вы следили за скоростью ресурсов в режиме реального времени. Сервис собирает статистику скорости за период времени и предоставляет подробный отчет об ошибках. Самый большой минус Pingdom — то, что сервис платный. Sitespeed.ru Еще один популярный инструмент в рунете — sitespeed.ru. Интерфейс простой и понятный: пишешь URL, запускаешь тест, получаешь результат. Сервис дает подробное описание, как справиться с каждой проблемой сайта. Еще одна любопытная функция — каскадная диаграмма загрузки сайта: вы видите, сколько времени загружается каждый объект: скорость загрузки сайта speedtest. Если оставить почту на сайте, вам пришлют красивый подробный отчет по результатам тестирования. И все это абсолютно бесплатно. GTmetrix позволяет легко определить производительность вашего сайта. Просто вставьте URL на главную страницу и получите данные о скорости загрузки и рекомендации, как исправить ошибки. Тестировать скорость можно из нескольких регионов. Кроме того, сервис анализирует эффективность ресурса на мобильных устройствах. До трех URL можно мониторить бесплатно. Больше сайтов можно подключить на премиум-тарифах (от $14,95 в месяц). Они включают и другие интересные возможности, например, брендированные отчеты о скорости сайта и запись видео с загрузкой, чтобы увидеть узкие места в режиме реального времени. YSlow YSlow анализирует веб-страницы и определяет, что идет не так по правилам Yahoo для высокопроизводительных сайтов. Это расширение, которое можно установить на популярные браузеры: Firefox, Chrome, Opera, Safari. Сервис бесплатный сервис и с открытым кодом. YSlow оценивает веб-страницу, обобщает компоненты и статистику, предлагает улучшения и предоставляет инструменты для анализа производительности. WebPagetest — еще один бесплатный проект с открытым исходным кодом. Его особенность — широкий выбор локаций, гаджетов и браузеров для тестирования. Можно подобрать параметры, которые лучше всего соответствуют вашей целевой аудитории: оценка скорости загрузки сайта WebPagetest. По результатам тестирования получаем огромный отчет прямо на странице сервиса. Тестирование функциональных требований. Комплексное тестирование Комплексное тестирование — процесс поиска несоответствия системы ее исходным целям. В процессе тестирования участвует система, описание целей продукта и вся документация, поставляемая вместе с системой. Следующие 15 пунктов дают некоторое представление о том, какие виды тестов могут понадобиться. 1. Тестирование стрессов. Как правило, системы функционируют нормально при слабой или умеренной нагрузке, но выходят из строя при большой нагрузке и в стрессовых ситуациях реальной среды. Тестирование стрессов представляет собой попытки подвергнуть систему крайнему «давлению», например, попытку одновременно подключить к системе большое количество терминалов, насытить банковскую систему мощным потоком входных сообщений. 2. Тестирование объема представляет собой попытку предъявить системе большие объемы данных в течение более длительного времени, чем п. 1. На вход компилятора следует подать огромную программу (например, программу обработки текстов). Очередь заданий операционной системы следует заполнить до предела. Цель — показать, что система не может обрабатывать данные в количествах, указанных в их спецификациях. 3. Тестирование конфигурации. Система должна быть проверена со всяким аппаратным устройством, которое она обслуживает, или со всякой программой, с которой она должна взаимодействовать. Если сама программная система допускает несколько конфигураций, должна быть тестирована каждая из них. 4. Тестирование совместимости. Как правило, разрабатываемые системы не являются совершенно новыми; они представляют собой улучшение прежних версий или замену устаревших. Тогда на систему накладывается дополнительное требование совместимости, в соответствии с которым взаимодействие пользователя с прежней версией должно полностью сохраниться и в новой системе. 5. Тестирование защиты. К большинству систем предъявляются определенные требования по обеспечению защиты от несанкционированного доступа. Цель тестирования защиты — нарушить секретность в системе. Один из методов — нанять профессиональную группу «взломщиков», т. е. людей с опытом разрушения средств обеспечения защиты в системах. Одним из путей разработки подобных тестов является изучение известных проблем защиты в этих системах и генерация тестов, которые позволяют проверить, как решаются аналогичные проблемы в тестируемой системе. 6. Тестирование требований к памяти. При проектировании многих систем ставятся цели, определяющие объем основной и вторичной памяти, которую системе разрешено использовать при различных условиях. С помощью специальных тестов нужно попытаться показать, что система этих целей не достигает. 7. Тестирование производительности. Определяются такие характеристики, как время отклика и уровень пропускной способности при определенной нагрузке и конфигурации оборудования. Проверка системы в этих случаях сводится к демонстрации того, что данная программа не удовлетворяет поставленным целям. 8. Тестирование настройки. Тестирование процесса настройки системы очень важно, поскольку зачастую покупатель оказывается не в состоянии даже настроить новую систему. 9. Тестирование надежности/готовности заключается в попытке доказать, что система не удовлетворяет исходным требованиям к надежности (среднее время между отказами, количество ошибок, способность к обнаружению, исправлению ошибок и/или устойчивость к ошибкам и т. д.). Например, в систему можно намеренно внести ошибки (как аппаратные, так и программные), чтобы тестировать средства обнаружения, исправления и обеспечения устойчивости. 10. Тестирование средств восстановления. Можно намеренно ввести в операционную систему программные ошибки, чтобы проверить, восстановится ли она после их устранения. Неисправности аппаратуры, ошибки в данных (помехи в линиях связи и неправильные значения указателей в базе данных) можно намеренно создать или промоделировать для анализа реакции на них системы. 11. Тестирование удобства обслуживания. Все документы, описывающие внутреннюю логику, следует проанализировать глазами обслуживающего персонала, чтобы понять, как быстро и точно можно указать причину ошибки, если известны только некоторые се симптомы. 12. Тестирование публикаций. Все комплексные тесты следует строить только на основе документации для пользователя. Любые примеры, приведенные в документации, следует оформить как тест и подать на вход программы. 13. Тестирование психологических факторов. Эта сторона не так важна, как другие, однако мелкие недостатки могут быть обнаружены и устранены при тестировании системы. Например, может оказаться, что ответы или сообщения системы плохо сформулированы или ввод команды пользователя требует постоянных переключений регистров. 14. Тестирование удобства установки. 15. Тестирование удобства эксплуатации. Не все из перечисленных 15 пунктов применимы к тестированию всякой системы (например, когда тестируется отдельная прикладная программа), но тем не менее это перечень вопросов, которые разумно иметь в виду. По своей природе комплексные тесты никогда не сводятся к проверке отдельных функций системы. Они часто пишутся в форме сценариев, представляющих ряд последовательных действий пользователя. Тестирование граничных условий Граничные значения — это те места, в которых один класс эквивалентности переходит в другой. Техника анализа граничных значений - это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Граничное тестирование также может включать тесты, проверяющие поведение системы на входных данных, выходящих за допустимый диапазон значений. При этом система должна определённым (заранее оговоренным) способом обрабатывать такие ситуации. Например, с помощью исключительной ситуации или сообщения об ошибке. !!!Граничные значения очень важны и их обязательно следует применять при написании тестов, т.к. именно в этом месте чаще всего и обнаруживаются ошибки. На каждой границе диапазона следует проверить по три значения: граничное значение; значение перед границей; значение после границы. Цель этой техники — найти ошибки, связанные с граничными значениями. Алгоритм использования техники граничных значений: выделить классы эквивалентности; определить граничные значения этих классов; нужно понять, к какому классу будет относиться каждая граница; нужно провести тесты по проверке значения до границы, на границе и сразу после границы. Количество тестов для проверки граничных значений будет равен количеству границ, умноженному на 3. Рекомендуется проверять значения вплотную к границе. К примеру, есть диапазон целых чисел, граница находится в числе 100. Таким образом, будем проводить тесты с числом 99 (до границы), 100 (сама граница), 101 (после границы). Тестирование утечки памяти Все программы в рамках популярных ОС представляют собой определенным образом структурированный набор данных и инструкций. ОС знает, как работать с этими наборами данных и инструкций, и делает это в некотором заведенном порядке. В рамках ОС для этого есть объект - процесс, который подгрузит приготовленные разработчиком инструкции и данные, будет определенным образом выделять под них время процессора, порождать другие объекты ядра ОС, которые тоже что-то делают. Сами инструкции так же могут взаимодействовать с разными сущностями операционной системы, файловой системой, порождать потоки, с периферией, выводить что-то на экран, взаимодействовать при работе с оперативной памятью. Все эти ресурсы, или многие из них - разделяемые. Например, вывод на экран, т.к. экран один. Или работа с памятью, т.к. ее конечное количество. И все это делается через API ОС напрямую, или через какие-то обертки над этим API ОС. И раз память можно выделять, ее следует и освобождать, т.е. уведомлять ОС, что этот участок памяти "свободен", и может быть отдан любому другому процессу под его нужды. Контроль за тем, нужна ли программе еще та или иная память остается на усмотрение программы, ОС этим, естественно, не управляет. И раз управление выделенной памятью находится на стороне программы, программа может быть построена так, что иногда будет уведомлять ОС о том, чтобы выделить ей какую-то память, но не уведомлять об освобождении. В цикле это приводит к тому, что со временем объем используемой программой памяти начинает бесконечно расти. Явный признак - наличие ошибки OutOfMemoryError в Java или OutOfMemoryException в .NET. Ее можно найти в логах сервера или приложения, либо сообщение о нем будет выведено на экран. В разных языках программирования название ошибки может выглядеть иначе, но смысл её будет прежним - Недостаточно памяти для завершения операции. Утечка памяти может воспроизвестись по-разному, в зависимости от того в какой части системы она поселилась, а также самой реализации приложения. Иногда причина возникновения OutOfMemoryError - это недостаточное выделение памяти приложению. Допустим для загрузки всех объектов в память требуется 128Мб, а приложению выделили только 64Мб. Если же с конфигурацией все в порядке, а размер используемой памяти постоянно увеличивается, то это реальный memory leak. Для начала, как и с любым багом его нужно локализовать, т.е. определить в каких случаях, какая операция вызывает эту проблему. И уже потом её решать. Наиболее сложно отлавливаемый memory leak - это тот, который кушает мало и воспроизводится очень долго. Подобная утечка памяти определима только при запуске длительных тестов (тестов стабильности). |