Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Технологии и методы программирования. Учебное пособие-1
.pdf
9. МЕТОДЫ ТЕСТИРОВАНИЯ ПРОГРАММ
Непрерывное повышение сложности функций, реализуемых программами в информационных системах, приводит к увеличению их объема и трудоемкости создания. Соответственно сложности программ еще
быстрее возрастает количество выявляемых и остающихся в них дефектов и ошибок, что отражается на их качестве. Вполне реальна разработка комплексов программ объемом в миллионы строк текста
принципиально не могут быть безошибочными. Поэтому проблема обнаружения и устранения ошибок обостряется по мере увеличения сложности задач, решаемых программами, и грозит катастрофами в информационных системах (ИС), выполняющих критические функции управления крупными, дорогими и особо важными объектами или процессами.
ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
, которые
Тестирование – набор операций, проводимых для обеспечения выявления и/или оценки свойств одного или более элементов тестирования.
Тестирование – процесс эксплуатации системы или компонента
при определенных условиях под наблюдением или с записью результатов, а также проведение анализа определенного аспекта системы или
компонента [89, 90].
Элемент тестирования – артефакт, который является объектом тестирования
граммного обеспечения, документ требований, спецификация проекта,
руководство пользователя.
Средства тестирования – артефакты, произведенные во время процесса тестирования, требуемые для планирования, разработки и выполнения тестирования [90].
. Примеры элементов тестирования: система, элемент про-
91
Тестирование программного обеспечения – проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным
образом. В более широком смысле тестирование программного
обеспечения – это одна из техник контроля качества, включающая
в себя действия по планированию работ, проектированию тестов, выполнению тестирования и анализу полученных результатов,
а также
проверку соответствия между реальным и ожидаемым поведением
программы. Основная роль при этом принадлежит проектированию
тестов.
Контрольный пример (тест) – набор входных данных, условий выполнения и ожидаемых результатов, разработанный для определенной
цели, например для выполнения некоторого пути программы или подтверждения соответствия заданному требованию [91].
УРОВНИ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
В практике тестирования используется метафора «Пирамида тестов», предложенная в [91], которая показывает группировку тестов
программного обеспечения по разным уровням.
Уровни тестирования в пирамиде – это визуализация видов тестирования по модульности. Каждый уровень определяет то, что под-
вергается тестированию: отдельный модуль, группа модулей или
система в целом. Чтобы гарантировать успешную реализацию и
сдачу в эксплуатацию программного продукта, тестирование на разных уровнях должно проводиться на протяжении всего жизненного
цикла разработки и сопровождения.
Возможны разные интерпретации уровней пирамиды тестирования,
одна из которых определена в соответствии с [92] (уровни располагаются снизу вверх).
1. Модульное тестирование – при модульном тестировании прове-
ряется работа тех частей приложения,
которые доступны и могут быть
протестированы по отдельности (модули программ, объекты, классы,
функции и т. д.).
2. Интеграционное тестирование – тестирование, при котором
проверяется взаимодействие модулей, а также интеграция подсистем
в одну общую систему. Для интеграционного тестирования используются компоненты, уже проверенные с помощью модульного тестирования.
92
3. Системное тестирование. Основной его задачей является про-
верка функциональных и нефункциональных требований к системе в целом. Для минимизации рисков, связанных с особенностями
поведения системы в той или иной среде, рекомендуется тестирование
в среде, максимально приближенной к условиям эксплуатации.
4. Приемочное тестирование – методика тестирования, выполняемая для определения того
, соответствует ли программная система требованиям спецификации. Основная цель этого теста – оценить соответствие системы бизнес-требованиям и проверить, соответствует ли она
требуемым критериям для доставки конечным пользователям.
Пирамида в таком виде показывает, что тесты нижнего уровня (модульные) обычно составляют большую часть от общего количества тестов.
КЛАССИФИКАЦИЯ ВИДОВ И ТИПОВ ТЕСТИРОВАНИЯ
В зависимости от признака, положенного в основу классификации,
можно рассматривать различные виды и типы тестирования, которые
выделены в результате разнообразных подходов к тестированию и проверяемых аспектов программного обеспечения, что позволяет лучше
сформировать представления о методах и их применимости в тех или
иных случаях.
Все виды тестирования программного обеспечения в зависимости
от
цели можно условно разделить на следующие группы.
1. Функциональные виды тестирования применяются к функциям, выполняемым программной системой, в том числе во взаимодействии с другими системами. Они могут быть представлены на всех уровнях тестирования: компонентном или модульном, интеграционном, системном и приемочном. Функциональные виды тестирования рассматривают внешнее
поведение системы.
2. Нефункциональные виды тестирования используют тесты, необходимые для определения характеристик программного обеспечения,
которые могут быть измерены различными величинами. Перечень основных видов нефункциональных тестов включает нагрузочное тестирование, стрессовое тестирование, тестирование стабильности или
надежности, объемное тестирование, тестирование установки, тестирование на отказ и восстановление, конфигурационное тестирование.
93
Тестирование установки направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного
обеспечения.
В настоящий момент наиболее распространена установка ПО при
помощи инсталляторов (специальных программ, которые сами по себе
также требуют надлежащего тестирования.
В реальных условиях инсталляторов может не быть. В этом случае пользователю придется самостоятельно
выполнять установку
программного обеспечения, используя документацию в виде инструкций, шаг за шагом описывающих все необходимые действия
и проверки.
Тестирование на отказ и восстановление проверяет тестируемый
продукт с точки зрения способности противостоять возможным сбоям,
возникшим в связи с ошибками программного обеспечения, отказами
оборудования или проблемами связи (например, отказ сети) и
успешно
восстанавливаться. Целью этого вида тестирования является проверка
систем восстановления (или дублирующих основной функционал систем), которые в случае возникновения сбоев обеспечат сохранность
и целостность данных тестируемого продукта.
Тестирование на отказ и восстановление очень важно для систем,
работающих по принципу «24 x 7».
Методика подобного тестирования заключается в моделировании
различных условий сбоя и последующем изучении и оценке реакции защитных систем. В процессе подобных проверок выясняется, была ли достигнута требуемая степень восстановления системы после возникновения сбоя.
Для наглядности рассмотрим некоторые варианты подобного тестирования и общие методы их проведения. Объектом тестирования в
большинстве случаев служат весьма вероятные эксплуатационные проблемы, такие как:
1) отказ электричества на компьютере-сервере;
2) отказ электричества на компьютере-клиенте;
3) незавершенные циклы обработки данных (прерывание работы
фильтров данных, прерывание синхронизации);
4) объявление или внесение в массивы данных невозможных или
ошибочных элементов;
5) отказ носителей данных.
94
Эти ситуации могут быть воспроизведены, как только достигнута
некоторая точка в разработке, когда все системы восстановления или
дублирования готовы выполнять свои функции. Технически реализовать тесты можно следующими путями:
1) моделировать внезапный отказ электричества на компьютере
(обесточить компьютер);
2) моделировать потерю связи с сетью (выключить сетевой кабель,
обесточить сетевое устройство);
3) моделировать
отказ носителей (обесточить внешний носитель
данных);
4) моделировать ситуацию наличия в системе неверных данных
(специальный тестовый набор или база данных).
При достижении соответствующих условий сбоя и по результатам
работы систем восстановления можно оценить продукт с точки зрения
тестирования на отказ. Во всех перечисленных случаях по завершении
процедур восстановления должно быть
достигнуто определенное требу-
емое состояние данных продукта:
1) потеря или порча данных в допустимых пределах;
2) отчет или система отчетов с указанием процессов или транзакций,
которые не были завершены в результате сбоя.
Стоит заметить, что тестирование на отказ и восстановление – это
весьма продуктоспецифичное тестирование. Тестовые сценарии должны
разрабатываться с учетом всех особенностей
тестируемой системы. Принимая во внимание довольно жесткие методы воздействия, стоит также
оценить целесообразность проведения данного вида тестирования для
конкретного программного продукта.
Конфигурационное тестирование – конфигурационным называется тестирование совместимости выпускаемого продукта (программное обеспечение) с различными аппаратными и программными средствами. Основные цели – определение оптимальной конфигурации и
проверка совместимости приложения
с требуемым окружением (обору-
дованием, ОС и т. д.)
3. Виды тестирования, связанные с изменениями ПО – после
проведения необходимых изменений, таких как исправление ошибок,
программное обеспечение должно быть протестировано вновь для подтверждения того факта, что проблема действительно решена.
95
Виды тестирования, которые необходимо проводить для подтверждения работоспособности приложения или правильности исправления
ошибки, следующие.
Дымовое тестирование рассматривается как короткий цикл тестов,
выполняемых для тестирования наиболее важных модулей приложения,
чтобы убедиться в том, что после сборки кода (нового или исправленного) приложение запустится и будет выполнять основные функции.
В случае
отсутствия критических ошибок дымовое тестирование
считается пройденным и приложение передается для проведения полного цикла тестирования, в противном случае принимается решение о
нецелесообразности дальнейшего тестирования и передаче приложения
для доработки.
Регрессионное тестирование – при регрессионном тестировании
выполняются все ранее написанные тесты или же тесты, проверяющие
область, в которой были совершены изменения. Регрессионное
тестирование необходимо для доказательства того, что обнаруженные ошибки
не исправлены или проявились вновь вследствие сделанных изменений,
а также для обнаружения ошибок, вызванных изменениями в уже существующих областях программы, и для проверки влияния новых функций на уже существующие.
Тестирование сборки – тестирование, направленное на определение
соответствия выпущенной версии программного
продукта критериям
качества и принятия решения о дальнейшем тестировании новой версии
или сдаче в эксплуатацию.
Ниже подробно рассмотрены классификации, дающие наиболее раз-
ные срезы процесса тестирования.
4. Виды тестирования, связанные с объектом тестирования
Функциональное тестирование предназначено для проверки
средств, с помощью которых программа решает те или иные задачи.
Функциональное тестирование является
основным типом и подходом,
без которого тестирование продукта невозможно.
Нагрузочное тестирование – определение или сбор показателей
производительности и времени отклика программно-технической системы или устройства на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Основная цель нагрузочного тестирования заключается в том, чтобы,
96
создав определенную ожидаемую в системе нагрузку (например, посредством виртуальных пользователей) и обычно использовав идентичное программное и аппаратное обеспечение, наблюдать за показателями
производительности системы.
Стресс-тестирование – в отличие от нагрузочного тестирования
оценивает надежность и устойчивость системы в условиях превышения
пределов нормального функционирования. Стресс-тестирование особенно необходимо для «критически важного
» ПО. Обычно стресс-тестирование лучше обнаруживает устойчивость, доступность и обработку исключений под большой нагрузкой.
Тестирование интерфейса пользователя. При тестировании интерфейса пользователя проверяются все его элементы на соответствие
спецификациям, требованиям и выполняемым ими функциям.
Тестирование удобства использования (юзабилити) – тестирование удобства и понятности интерфейса, что является очень важным
моментом. Даже самое мощное приложение, созданное с использованием
новейших алгоритмов и технологий, будет проигрывать конкурентам,
если приложением будет неудобно пользоваться. Тестирование юзабилити призвано выявить недостатки в расположении и назначении элементов интерфейса пользователя.
Тестирование безопасности используется для проверки безопасно-
сти системы, а также для анализа рисков, связанных с
обеспечением целостного подхода к защите приложения от атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Тестирование локализации необходимо при условии, если программа будет использоваться в разных странах на разных языках, с разной записью времени и/или даты и т. п. Здесь суть тестирования будет
заключаться в выявлении
ошибок, связанных именно с теми парамет-
рами, на которые может повлиять локализация.
Тестирование совместимости – вид нефункционального тестирования, основной целью которого является проверка корректной работы
продукта в определенном окружении. Окружение может включать
в себя аппаратное обеспечение (компьютеры, сетевые устройства, периферийные устройства т. п.) и программное обеспечение (операционная
система, система
управления базой данных, системные приложения и
утилиты, браузеры и прочее). Этот тип тестирования необходим и очень
эффективен, так как нередко ошибки и сбои в работе обнаруживаются
только в сочетании тестируемого приложения с конкретным окружением.
97
5. Виды тестирования на основе знания системы
Стратегия «черного ящика» – при тестировании «черного ящика»
структура и код тестируемой программы, схема базы данных недоступны для просмотра. Для разработки тестов используются функциональные спецификации на тестируемые объекты.
Стратегия «белого ящика» – при тестировании «белого ящика» те-
сты создаются на основе знания алгоритмов,
логики или программного
кода тестируемой части системы.
6. Виды тестирования по степени изолированности тестируемых
компонентов
Компонентное тестирование (модульное) – проверяет функцио-
нальность тех частей приложения, которые доступны и могут быть протестированы по отдельности (модули программ, объекты, классы, функции и т. п.).
Интеграционное тестирование – одна из фаз тестирования про-
граммного
обеспечения, при которой отдельные программные модули
объединяются и тестируются в комплексе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует
системному тестированию. Целью интеграционного тестирования является проверка соответствия проектируемых единиц функциональным,
приемным требованиям и требованиям надежности. Тестирование этих
проектируемых единиц – объединения, множества или группы модулей – выполняется через их
интерфейс, с использованием тестирования
«черного ящика».
Системное тестирование – основной его целью является проверка
как функциональных, так и нефункциональных требований к системе
в целом, а также выявление неверного использования ресурсов системы, непредусмотренных комбинаций данных пользовательского
уровня, несовместимости с окружением, непредусмотренных сценариев
использования, отсутствующей или неверной функциональности, неудобства использования и
т. п. Для минимизации рисков, связанных
с особенностями поведения системы в той или иной среде, рекомендуется использовать окружение, максимально приближенное к условиям
эксплуатации.
7. Виды тестирования по времени проведения тестирования
Альфа-тестирование – внутреннее приемочное тестирование про-
граммного обеспечения, выполняемое на ранних этапах разработки.
98
Обычно альфа-тестирование проводится силами команды разработчиков продукта. На этом этапе выявляются грубые ошибки в реализации
программного обеспечения, а также проверяются некоторые архитектурные решения. Итогами альфа-теста могут стать изменения функций
программы
Бета-тестирование – одна из стадий цикла тестирования программ-
ного продукта до выпуска финальной версии. На бета-тестирование
передается близкий к конечному вариант приложения. Целью тестирования является выявление максимального числа ошибок в процессе эксплуатации программы. В отличие от альфа-тестирования, которое
обычно проводится силами разработчиков, на этой стадии привлекаются сторонние тестировщики, в том числе из числа будущих пользователей продукта. Бета-тестирование выполняется для
того, чтобы полу-
чить информацию о продукте от его будущих пользователей.
Тест приемки осуществляется при передаче приложения команде
по тестированию на очередной итерации разработки. Тест приемки состоит из проверки основных функций, при неработоспособности которых дальнейшее тестирование невозможно и/или не имеет
смысла.
Тестирования новой функциональности направлено на проверку
возможностей
системы, появившихся в разрабатываемом приложении
после очередной итерации.
Регрессионное тестирование. При регрессионном тестировании
выполняются все ранее написанные тесты или же тесты для проверки
области, в которой были совершены изменения. Регрессионное тестирование необходимо для обнаружения ошибок, вызванных изменениями,
сделанными разработчикам в уже существующих областях программы,
а также для проверки влияния
Тест сдачи – это финальное тестирование приложения перед рели-
1
версии. Включает в себя полную регрессию, тестирование на сов-
зом
новых функций на уже существующие.
местимость, производительность и т. п.
8. Виды тестирования по степени подготовки к тестированию
Тестирование по тест-кейсам является наиболее общим и правиль-
ным для всех видов тестирования, поскольку тест-кейсы создаются
1
Релиз – конечная стадия разработки программного обеспечения. На этом
этапе разработчик признает программное обеспечение стабильным и вносит
в него лишь необходимые исправления, либо не изменяет вовсе.
99
заранее на основе анализа спецификаций или структуры программного
кода, проверяют ту или иную функциональность, не дублируются и позволяют быть уверенным, что на каждой итерации необходимые требования будут однозначно проверены. Ускоренным и упрощенным в плане
создания видом тестирования по тест-кейсам является тестирование по
чек-листам. В этом случае для
тестирования не пишутся тестовые сценарии, а лишь используются чек-листы. Чек-лист в тестировании – это список проверок, которые нужно выполнить на тестируемом ресурсе.
Интуитивное тестирование выполняется без спецификаций и планирования. Необходимость такого тестирования возникает, когда существует дефицит времени, не позволяющий выполнить тщательное тестирование с использованием
тест-кейсов и тест-планов.
Интуитивное тестирование выполняется после проведения формального тестирования приложения. Оно является менее формальным и
неструктурированным. Его эффективность зависит от возможностей тестировщиков, их глубокого понимания тестируемой системы.
9. Виды тестирования по степени автоматизированности
Ручное тестирование – предполагает исполнение тест-кейсов (сце-
нариев тестирования) без помощи каких-либо
программ, автоматизирующих работу. При ручном тестировании можно обнаружить большое
количество ошибок, его можно и нужно применять при тестировании
программ, работающих в специфических устройствах, где автоматизация крайне затруднена или невозможна в принципе. Ручное тестирование применяется также, когда нет времени на автоматизацию, или же в
случаях, когда тестируемые компоненты претерпевают
значительные
изменения от итерации к итерации и слабо развито регрессионное тестирование.
Автоматизированное тестирование – часть процесса тестирования, при котором основные функции и шаги теста, такие как запуск,
инициализация, выполнение, анализ и выдача результата, выполняются
автоматически с помощью инструментов для автоматизированного тестирования (например [92]), что помогает сократить время тестирования
и упростить его процесс. Однако автоматизированное тестирование
имеет свои ограничения и условия применимости.
Целью тестирования является обнаружение ошибок в программе,
а деятельность по тестированию включает:
постановку задачи для теста;
100
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]