Тестирование черного ящика реферат
Обновлено: 05.07.2024
- Для учеников 1-11 классов и дошкольников
- Бесплатные сертификаты учителям и участникам
Особенности тестирования черного ящик а
Тестирование черного ящика позволяет получить сочетание входных данных, обеспечивающих полную проверку всех функциональных требований к программе. Программный продукт при функциональном тестировании рассматривается как черный ящик, поведение которого можно определить только путем исследования его входов и соответствующих выходов. При таком подходе желательно иметь :
набор, образуемый входными данными, который приводит к аномалиям поведения программы;
набор, образуемый такими входными данными, которые демонстрируют дефекты программы.
Любой способ тестирования черного ящика должен:
выявить такие входные данные, которые с высокой вероятностью приводят к аномалиям поведения программы;
сформулировать такие ожидаемые результаты, которые с высокой вероятностью выявляют наличие дефектов.
Во многих случаях определение таких тестовых вариантов основывается на предыдущем опыте тестировщиков. Они используют свои знания и понимания в области определения для идентификации тестовых вариантов, которые эффективно обнаруживают дефекты.
Принцип черного ящика не альтернативен принципу белого ящика. Скорее это дополняющий подход, который обнаруживает другой класс ошибок.
Тестирование черного ящика обеспечивает поиск следующих категорий ошибок:
некорректных или отсутствующих функций ;
ошибок во внешних структурах данных или в доступе к внешней базе данных;
ошибок характеристик аппаратных устройств ;
ошибок инициализации и завершения.
Подобная категория ошибок не позволяет выявить тестирование белого ящика.
В отличие от тестирования белого ящика, которое выполняется на ранней стадии тестирования программного обеспечения, тестирование черного ящика применяется на поздних стадиях тестирования. При тестировании черного ящика пренебрегают управляющей структурой программы и концентрируют внимание на информационной области определения программной системы.
Технология тестирования черного ящика ориентирована на решение следующих задач:
Сокращение необходимого количества тестовых вариантов из-за проверки нестатических, а динамических аспектов системы;
Выявление классов ошибок, а не отдельных ошибок.
Краткое описание документа:
Тенденция развития информационных систем приводит к возрастанию их сложности. Современные крупные проекты характеризуются следующими особенностями:
- сложность описания, требующая тщательного моделирования и анализа данных и процессов;
- наличие тесно взаимодействующих компонентов;
- отсутствие прямых аналогов ограничивает возможность использования типовых решений;
- необходимость интеграций существующих и разрабатываемых приложений;
- функционирование в неоднородной среде различных аппаратных программных платформ;
- разнородность отдельных групп разработчиков по уровню квалификации и традициям использования тех или иных инструментальных средств;
- существенная временная протяженность проекта, которая обусловлена, во-первых, ограниченными возможностями коллектива разработчиков, во-вторых, степенью готовности подразделений и организаций к внедрению информационной системы.
- подготовка к ЕГЭ/ОГЭ и ВПР
- по всем предметам 1-11 классов
Курс повышения квалификации
Дистанционное обучение как современный формат преподавания
Курс повышения квалификации
Инструменты онлайн-обучения на примере программ Zoom, Skype, Microsoft Teams, Bandicam
- Курс добавлен 31.01.2022
- Сейчас обучается 25 человек из 18 регионов
Курс повышения квалификации
Педагогическая деятельность в контексте профессионального стандарта педагога и ФГОС
- ЗП до 91 000 руб.
- Гибкий график
- Удаленная работа
Дистанционные курсы для педагогов
Свидетельство и скидка на обучение каждому участнику
Найдите материал к любому уроку, указав свой предмет (категорию), класс, учебник и тему:
5 601 818 материалов в базе
Материал подходит для УМК
Самые массовые международные дистанционные
Школьные Инфоконкурсы 2022
Свидетельство и скидка на обучение каждому участнику
Другие материалы
Вам будут интересны эти курсы:
Оставьте свой комментарий
- 16.04.2018 591
- DOCX 17 кбайт
- 3 скачивания
- Оцените материал:
Настоящий материал опубликован пользователем Нечай Александр Анатольевич. Инфоурок является информационным посредником и предоставляет пользователям возможность размещать на сайте методические материалы. Всю ответственность за опубликованные материалы, содержащиеся в них сведения, а также за соблюдение авторских прав несут пользователи, загрузившие материал на сайт
Если Вы считаете, что материал нарушает авторские права либо по каким-то другим причинам должен быть удален с сайта, Вы можете оставить жалобу на материал.
Автор материала
40%
- Подготовка к ЕГЭ/ОГЭ и ВПР
- Для учеников 1-11 классов
Московский институт профессиональной
переподготовки и повышения
квалификации педагогов
Дистанционные курсы
для педагогов
663 курса от 690 рублей
Выбрать курс со скидкой
Выдаём документы
установленного образца!
Учителя о ЕГЭ: секреты успешной подготовки
Время чтения: 11 минут
Минобрнауки и Минпросвещения запустили горячие линии по оказанию психологической помощи
Время чтения: 1 минута
Инфоурок стал резидентом Сколково
Время чтения: 2 минуты
В приграничных пунктах Брянской области на день приостановили занятия в школах
Время чтения: 0 минут
Минпросвещения России подготовит учителей для обучения детей из Донбасса
Время чтения: 1 минута
В Белгородской области отменяют занятия в школах и детсадах на границе с Украиной
Время чтения: 0 минут
Каждый второй ребенок в школе подвергался психической агрессии
Время чтения: 3 минуты
Подарочные сертификаты
Ответственность за разрешение любых спорных моментов, касающихся самих материалов и их содержания, берут на себя пользователи, разместившие материал на сайте. Однако администрация сайта готова оказать всяческую поддержку в решении любых вопросов, связанных с работой и содержанием сайта. Если Вы заметили, что на данном сайте незаконно используются материалы, сообщите об этом администрации сайта через форму обратной связи.
Все материалы, размещенные на сайте, созданы авторами сайта либо размещены пользователями сайта и представлены на сайте исключительно для ознакомления. Авторские права на материалы принадлежат их законным авторам. Частичное или полное копирование материалов сайта без письменного разрешения администрации сайта запрещено! Мнение администрации может не совпадать с точкой зрения авторов.
При тестировании методами черного ящика важно участие пользователей, поскольку именно они лучше всего знают, каких результатов следует ожидать от бизнес-функций. Ключом к успешному завершению системного тестирования является корректность данных. Поэтому на фазе создания данных для тестирования крайне важно, чтобы конечные пользователи предоставили как можно больше входных данных. Тестирование при… Читать ещё >
Тестирование на основе черного ящика ( реферат , курсовая , диплом , контрольная )
Тестирование на основе стратегии черного ящика возможно лишь при наличии установленных открытых интерфейсов, таких как интерфейс пользователя или программный интерфейс приложения (API).
Если тестирование на основе стратегии белого ящика исследует внутреннюю работу программы, то методы тестирования черного ящика сравнивают поведение приложения с соответствующими требованиями. Кроме того, эти методы обычно направлены на выявление трех основных видов ошибок: функциональности, поддерживаемой программным продуктом; производимых вычислений; допустимого диапазона или области действия значений данных, которые могут быть обработаны программным продуктом. На этом уровне тестировщики не исследуют внутреннюю работу компонентов программного продукта, тем не менее они проверяются неявно.
Группа тестирования изучает входные и выходные данные программного продукта. В этом ракурсе тестирование с помощью методов черного ящика рассматривается как синоним тестирования на уровне системы, хотя методы черного ящика могут также применяться во время модульного или компонентного тестирования.
При тестировании методами черного ящика важно участие пользователей, поскольку именно они лучше всего знают, каких результатов следует ожидать от бизнес-функций. Ключом к успешному завершению системного тестирования является корректность данных. Поэтому на фазе создания данных для тестирования крайне важно, чтобы конечные пользователи предоставили как можно больше входных данных.
Тестирование при помощи методов черного ящика направлено на получение множеств входных данных, которые наиболее полно проверяют все функциональные требования системы. Это не альтернатива тестированию по методу белого ящика. Этот тип тестирования нацелен на поиск ошибок, относящихся к целому ряду категорий, среди них:
по курсу: ПРОГРАММНАЯ ИНЖЕНЕРИЯ
Оглавление
по курсу: ПРОГРАММНАЯ ИНЖЕНЕРИЯ 1
Достоинства метода 5
Недостатки метода 6
Интеграционное тестирование.
Функциональное тестирование.
Стресс-тестирование.
Usability-тестирование.
Тестирование производительности.
Приемочное тестирование.
Регрессионное тестирование.
делаем репрезентативную выборку тестов, в которой используются все функции ПО;
выбираем тесты, сосредоточенные на программных компонентах/функциях, которые подверглись изменениям;
используем дополнительные тестовые примеры, уделяя основное внимание функциям, на которые с наибольшей вероятностью повлияли изменения.
Beta-тестирование.
идентификацию непредвиденных ошибок (так как бета-тестеры используют ПО нестандартно);
широкий набор окружений для проверки, который трудно обеспечить иными методами (разные операционные системы, разные настройки, разные версии браузеров);
снижение расходов (так как работа бета-тестеров, как правило, не оплачивается).
2. Анализ граничных значений.
Техника, которая включает в себя определение границ входных значений и выбор в качестве тестовых данных значений, находящихся на границах, внутри и вне границ. Многие системы имеют тенденцию вести себя некорректно при граничных значениях, поэтому оценка значений границ приложения очень важна. При проверке мы берем следующие величины: минимум, (минимум-1), максимум, (максимум+1), стандартные значения. Например, в том же случае -99 3. Тестирование таблицы переходов.
4. Тестирование по сценариям использования.
Эта техника используется при написании тестов для индивидуального сценария пользователя с целью проверки его работы.
Достоинства метода
Недостатки метода
Заключение
2. Функциональное тестирование.
Используя этот метод, тестировщик проверяет, выполняет ли программное обеспечение все заявленные функции и требования клиента в полном объеме согласно документации.
3. Стресс-тестирование.
Предположим, что у нас есть букмекерская онлайн-контора, в документации к которой заявлена возможность одновременной регистрации 1000 пользователей. В этом случае стрессовым тестированием будет непрерывный поток автоматизированных регистраций (как минимум, 1000 регистраций в минуту) на протяжении 12 часов.
5. Тестирование производительности.
Таким видом тестирования мы можем проверить: есть ли утечки памяти, насколько быстро система работает и выдает обратную связь, не потребляет ли наше ПО слишком много трафика и не создает ли избыточное количество подключений.
7. Регрессионное тестирование.
Проводится на протяжении всего цикла разработки. Цель такого тестирования – проверить работоспособность нового кода и выяснить, не привел ли он к ошибкам или поломкам в старом функционале.
- делаем репрезентативную выборку тестов, в которой используются все функции ПО;
- выбираем тесты, сосредоточенные на программных компонентах/функциях, которые подверглись изменениям;
- используем дополнительные тестовые примеры, уделяя основное внимание функциям, на которые с наибольшей вероятностью повлияли изменения.
- идентификацию непредвиденных ошибок (так как бета-тестеры используют ПО нестандартно);
- широкий набор окружений для проверки, который трудно обеспечить иными методами (разные операционные системы, разные настройки, разные версии браузеров);
- снижение расходов (так как работа бета-тестеров, как правило, не оплачивается).
- неправильно реализованные функции приложения или сервиса;
- ошибки в пользовательском интерфейсе;
- ошибки в функциональных спецификациях.
1. Эквивалентное разбиение.
Эта техника включает в себя разделение входных значений на допустимые и недопустимые разделы и выбор репрезентативных значений из каждого раздела в качестве тестовых данных. Она может быть использована для уменьшения количества тестовых случаев. Допустим, у нас есть целая переменная N в диапазоне от -99 до 99: позитивными классами эквивалентности будут [-99, -10], [-9, -1], 0, [1, 9], [10, 99], а недействительными (негативными) – 99, пустое значение, нечисловые строки.
2. Анализ граничных значений.
Техника, которая включает в себя определение границ входных значений и выбор в качестве тестовых данных значений, находящихся на границах, внутри и вне границ. Многие системы имеют тенденцию вести себя некорректно при граничных значениях, поэтому оценка значений границ приложения очень важна. При проверке мы берем следующие величины: минимум, (минимум-1), максимум, (максимум+1), стандартные значения. Например, в том же случае -99
4. Тестирование по сценариям использования.
Эта техника используется при написании тестов для индивидуального сценария пользователя с целью проверки его работы.
Достоинства метода
Недостатки метода
Подведем итоги
Тестирование методом черного ящика базируется на том, что все тесты основываются на спецификации системы или ее компонентов. Система представляется как "черный ящик", поведение которого можно определить только посредством изучения ее входных и соответствующих выходных данных. Другое название этого метода – функциональное тестирование – связано с тем, что испытатель проверяет не реализацию ПО, а только его выполняемые функции [2,3].
На рисунке 3 показана модель системы, тестируемая методом черного ящика. Этот метод также применим к системам, организованным в виде набора функций или объектов. Испытатель подставляет в компонент или систему входные данные и исследует соответствующие выходные данные. Если выходные данные не совпадают с предсказанными, значит, во время тестирования ПО успешно обнаружена ошибка (дефект).
Основная задача испытателя – подобрать такие входные данные, чтобы среди них с высокой вероятностью присутствовали элементы множества 1е. Во многих случаях выбор тестовых данных основывается на предварительном опыте испытателя. Однако дополнительно к этим эвристическим знаниям можно также использовать систематический метод выбора входных данных, обсуждаемый в следующем разделе [2,3].
Рисунок 3 – Тестирование методом черного ящика
1.3 Структурное тестирование
Метод структурного тестирования (рисунок 4) предполагает создание тестов на основе структуры системы и ее реализации. Такой подход иногда называют тестированием методом "белого ящика", "стеклянного ящика" или "прозрачного ящика", чтобы отличать его от тестирования методом черного ящика [3].
Рисунок 4 – Структурное тестирование
Как правило, структурное тестирование применяется к относительно небольшим программным элементам, например к подпрограммам или методам, ассоциированным с объектами. При таком подходе испытатель анализирует программный код и для получения тестовых данных использует знания о структуре компонента. Например, из анализа кода можно определить, сколько контрольных тестов нужно выполнить для того, чтобы в процессе тестирования все операторы выполнились, по крайней мере, один раз 4.
1.4 Тестирование ветвей
Это метод структурного тестирования, при котором проверяются все независимо выполняемые ветви компонента или программы. Если выполняются все независимые ветви, то и все операторы должны выполняться, по крайней мере, один раз. Более того, все условные операторы тестируются как с истинными, так и с ложными значениями условий. В объектно-ориентированных системах тестирование ветвей используется для тестирования методов, ассоциированных с объектами.
Количество ветвей в программе обычно пропорционально ее размеру. После интеграции программных модулей в систему, методы структурного тестирования оказываются невыполнимыми. Поэтому методы тестирования ветвей, как правило, используются при тестировании отдельных программных элементов и модулей [2,3].
При тестировании ветвей не проверяются все возможные комбинации ветвей программы. Не считая самых тривиальных программных компонентов без циклов, подобная полная проверка компонента оказывается нереальной, так как в программах с циклами существует бесконечное число возможных комбинаций ветвей. В программе могут быть дефекты, которые проявляются только при определенных комбинациях ветвей, даже если все операторы программы протестированы (т.е. выполнились) хотя бы один раз.
Метод тестирования ветвей основывается на графе потоков управления программы. Этот граф представляет собой скелетную модель всех ветвей программы. Граф потоков управления состоит из узлов, соответствующих ветвлениям решений, и дуг, показывающих поток управления. Если в программе нет операторов безусловного перехода, то создание графа – достаточно простой процесс. При построении графа потоков все последовательные операторы (операторы присвоения, вызова процедур и ввода-вывода) можно проигнорировать. Каждое ветвление операторов условного перехода (if-then-else или case) представлено отдельной ветвью, а циклы обозначаются стрелками, концы которых замкнуты на узле с условием цикла. На рисунке 5 показаны циклы и ветвления в графе потоков управления программы бинарного поиска [3].
Рисунок 5 – Граф потоков управления бинарного поиска
Цель структурного тестирования – удостовериться, что каждая независимая ветвь программы выполняется хотя бы один раз. Независимая ветвь программы – это ветвь, которая проходит, по крайней мере, по одной новой дуге графа потоков. В терминах программы это означает ее выполнение при новых условиях. С помощью трассировки в графе потоков управления программы бинарного поиска можно выделить следующие независимых ветвей [3].
Если все эти ветви выполняются, можно быть уверенным в том, что, во-первых, каждый оператор выполняется, по крайней мере, один раз и, во-вторых, каждая ветвь выполняется при условиях, принимающих как истинные, так и ложные значения.
Количество независимых ветвей в программе можно определить, вычислив цикломатическое число графа потоков управления программы 1. Дипломатическое число С любого связанного графа G вычисляется по формуле
С (G) = количество дуг - количество узлов + 2
Для программ, не содержащих операторов безусловного перехода, значение цикломатического числа всегда больше количества проверяемых условий. В составных условиях, содержащих более одного логического оператора, следует учитывать каждый логический оператор. Например, если в программе шесть операторов if и один цикл while, то цикломатическое число равно 8. Если одно условное выражение является составным выражением с двумя логическими операторами (объединенными операторами and или or), то цикломатическое число будет равно 10. Цикломатическое число программы бинарного поиска равно 4.
После определения количества независимых ветвей в программе путем вычисления цикломатического числа разрабатываются контрольные тесты для проверки каждой ветви. Минимальное количество тестов, требующееся для проверки всех ветвей программы, равно цикломатическому числу [3,4].
Проектирование контрольных тестов для программы бинарного поиска не вызывает затруднений. Однако, если программы имеют сложную структуру ветвлений, трудно предсказать, как будет выполняться какой-либо отдельный контрольный тест. В таких случаях используется динамический анализатор программ для составления рабочего профиля программы.
Динамические анализаторы программ – это инструментальные средства, которые работают совместно с компиляторами. Во время компилирования в сгенерированный код добавляются дополнительные инструкции, подсчитывающие, сколько раз выполняется каждый оператор программы. Чтобы при выполнении отдельных контрольных тестов увидеть, какие ветви в программе выполнялись, а какие нет, распечатывается рабочий профиль программы, где видны непроверенные участки [3].
1.5 Тестирование сборки
После того как протестированы все отдельные программные компоненты, выполняется сборка системы, в результате чего создается частичная или полная система. Процесс интеграции системы включает сборку и тестирования полученной системы, в ходе которого выявляются проблемы, возникающие при взаимодействии компонентов. Тесты, проверяющие сборку системы, должны разрабатываться на основе системной спецификации, причем тестирование сборки следует начинать сразу после создания работоспособных версий компонентов системы.
Во время тестирования сборки возникает проблема локализации выявленных ошибок. Между компонентами системы существуют сложные взаимоотношения, и при обнаружении аномальных выходных данных бывает трудно установить источник ошибки. Чтобы облегчить локализацию ошибок, следует использовать пошаговый метод сборки и тестирования системы. Сначала следует создать минимальную конфигурацию системы и ее протестировать. Затем в минимальную конфигурацию нужно добавить новые компоненты и снова протестировать, и так далее до полной сборки системы [2,3,4].
В примере на рисунке 6 последовательность тестов T1, Т2 и ТЗ сначала выполняется в системе, состоящей из модулей А и В (минимальная конфигурация системы). Если во время тестирования обнаружены дефекты, они исправляются. Затем в систему добавляется модуль С. Тесты T1, T2 и ТЗ повторяются, чтобы убедиться, что в новой системе нет никаких неожиданных взаимодействий между модулями А и В. Если в ходе тестирования появились какие-то проблемы, то, вероятно, они возникли во взаимодействиях с новым модулем С. Источник проблемы локализован, таким образом упрощается определение дефекта и его исправление. Затем система запускается с тестами Т4. На последнем шаге добавляется модуль D и система тестируется еще раз выполняемыми ранее тестами, а затем новыми тестами Т5 [3,4].
Рисунок 6 – Тестирование сборки
Конечно, на практике редко встречаются такие простые модели. Функции системы могут быть реализованы в нескольких компонентах. Тестирование новой функции, таким образом, требует интеграции сразу нескольких компонентов. В этом случае тестирование может выявить ошибки во взаимодействиях между этими компонентами и другими частями системы. Исправление ошибок может оказаться сложным, так как в данном случае ошибки влияют на целую группу компонентов, реализующих конкретную функцию. Более того, при интеграции нового компонента может измениться структура взаимосвязей между уже протестированными компонентами. Вследствие этого могут выявиться ошибки, которые не были выявлены при тестировании более простой конфигурации 3.
Читайте также: