Тестирование белого ящика реферат

Обновлено: 05.07.2024

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

Тестирование белого и черного ящиков в одном предложении

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

Это и есть основной смысл и главное отличие между двумя подходами. Но в этой статье мы копнем глубже. Вот, что мы рассмотрим:

Какие цели у тестирования белого и черного ящиков?
В чем отличия между подходами?
Какой подход выбрать для проекта?

Давайте открывать ящики и смотреть, что там внутри!

Что такое тестирование черного ящика?

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

Тестирование черного ящика делится на:

Функциональное тестирование – проверка функциональности приложения (“Что приложение делает?”)
Нефункциональное тестирование – проверка производительности, безопасности, usability (“Как приложение работает?”)

В тестирование черного ящика также входит и так называемое тестирование на основе опыта (Experience-based testing). QA проверяет приложение, основываясь на интуиции и опыте тестирования других похожих проектов.

Какая цель у тестирования черного ящика?

Главная цель – проверить, что приложение разработано в соответствии с требованиями, соответствует ожиданиям клиента и не содержит ошибок.

Проводя тестирование черного ящика, нужно получить ответы на следующие вопросы:

Работают ли все функции приложения правильно?
Совпадает ли внешний вид приложения с макетами?
Выполняются ли пользовательские сценарии?
Корректны ли данные?

Как проводить тестирование черного ящика?

Проведение такого тестирования требует подготовки – вот, что нужно сделать заранее:

Провести анализ требований и спецификаций
Узнать о приложении в целом
Подготовить тест-кейсы
Подготовить тестовые данные (в том числе и для негативных сценариев)

Когда всё вышеперечисленное сделано, QA выполняет тест-кейсы и делает детальный отчет с результатами, сообщает о найденных ошибках и повторно тестирует после исправления багов разработчиками.

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

Как подготовить данные и тест-кейсы для тестирования черного ящика?

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

Вот основные техники для разработки тест-кейсов для функционального тестирования:

Граничные значения

Граничные значения это входные или выходные данные (которые пользователь может вводить в поля), которые находятся в непосредственной близости от классов эквивалентности.

Классы эквивалентности

Классы эквивалентности это наборы входных данных, обработка которых приводит к одному и тому же результату.

Давайте отойдем от теории и попробуем понять, что это, на примере:

Представьте, что вам нужно протестировать поле “возраст” в форме приложения, предназначенного для людей от 20 до 30 лет. Поле принимает значения типа integer. Какие здесь будут классы эквивалентности и граничные значения?

Классы эквивалентности:

20-30 – позитивный тест
От минус бесконечности до 19 и от 31 до плюс бесконечности – негативный тест

Граничные значения: 19, 20, 21, 29, 30, 31

20, 21, 29, 30 – позитивный тест
19, 31 – негативный тест

Таблица решений (Decision table)

Таблица решений показывает возможные комбинации входных данных и ожидаемых результатов. Используется для создания тест-кейсов.

Давайте рассмотрим ее на примере.

Вы тестируете онлайн магазин предлагает скидки и бесплатную доставку. Если вы размещаете заказ на сумму больше 10000 рублей, вы получаете 10% скидку. Если делать заказ на сумму больше 15000 рублей – 15% скидку. Если на сумму больше 20000 рублей – 20% скидку и бесплатную доставку. Таблица решений будет выглядеть следующим образом:

Условия скидки	Т1	Т2	Т3	Т4
Заказы до 10 000 рублей	Да
Заказы больше 10 000 рублей	Да
Заказы больше 15 000 рублей	Да
Заказы больше 20 000 рублей	Да
Размер скидки	Т1	Т2	Т3	Т4
10%	Нет	Да	Нет	Нет
15%	Нет	Нет	Да	Нет
20%	Нет	Нет	Нет	Да
Бесплатная доставка	Нет	Нет	Нет	Да

Преимущества тестирования черного ящика

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

Недостатки тестирования черного ящика

Требования или спецификация могут быть неточными и/или непонятными, поэтому могут быть трудности с написанием тест-кейсов.
Может быть сложно протестировать все части приложения.

Перейдем к тестированию белого ящика:

Что такое тестирование белого ящика?

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

Два основных метода проведения тестирования белого ящика:

Statement coverage testing – покрытие операторов. Во время тестирования покрывают код так, чтобы во время тестирования каждый оператор выполнился хотя бы один раз.
Decision/Branch coverage testing – покрытие решений. Код покрывается тестами так, чтобы во время тестирования выполнились все ветки всех условных операторов.

Как подготовиться к тестированию белого ящика?

Есть много инструментов, библиотек и фрейворков для тестирования белого ящика. Мы сфокусируемся на JEST – библиотеке для тестирования JavaScript кода. То, что мы выбрали эту библиотеку не говорит о том, что она лучшая – просто на ней удобнее показывать примеры (прим.ред. – вот материал нашего читателя с подборкой best practices для Unit-тестирования фронтенда)

Рассмотрим JavaScript функцию:

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

Чтобы легче понять все ветвления внутри функции, используем code2flow. Он поможет преобразовать код в граф:

Теперь мы можем приступить к написанию первого теста.

Как проводить тестирование белого ящика?

Покрытие операторов (Statement coverage testing)

Нужно подобрать входные данные и вызвать функцию таким образом, чтобы каждый из операторов выполнился хотя бы один раз. Для 100% покрытия достаточно сделать 2 теста и вызвать функцию со следующими параметрами:

Coverage-отчет выглядит следующим образом:

Покрытие решений (Decision coverage testing)

Из coverage-отчета на предыдущем изображении понятно, что строки 4, 9, 16 не покрыты. Чтобы покрыть их, нужно добавить тесты, которые при выполнении функции пойдут по веткам, содержащим эти непокрытые строки. Тестовые данные будут выглядеть следующим образом:

Тест будет выглядеть следующим образом:

Теперь наш coverage-отчет полностью зеленый:

Преимущества тестирования белого ящика

Очень большая точность
Просто автоматизировать
Позволяет определить, где в коде произошла ошибка
Для выполнения тестирования не нужен UI

Недостатки тестирования белого ящика

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

Что лучше? Белый или черный ящик использовать?

Мир тестирования не черный и не белый – он серый 🙂 Поэтому здесь нет правильного ответа и нет лучшего подхода.

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

WHITE BOX TESTING — это тестирование внутренней структуры, дизайна и кодирования программного решения. В этом типе тестирования код виден тестеру. Основное внимание уделяется проверке потока входных и выходных данных через приложение, улучшению дизайна и удобства использования, усилению безопасности. Тестирование белого ящика также известно как тестирование Clear Box, тестирование Open Box, структурное тестирование, тестирование прозрачного бокса, тестирование на основе кода и тестирование Glass Box. Это обычно выполняется разработчиками.

Это одна из двух частей подхода Box Testing к тестированию программного обеспечения. Его аналог, тестирование Blackbox , включает тестирование с точки зрения внешнего или конечного пользователя. С другой стороны, тестирование Whitebox основано на внутренней работе приложения и вращается вокруг внутреннего тестирования.

В этом уроке вы узнаете

Что вы проверяете в White Box Testing?

Тестирование белого ящика включает тестирование программного кода для следующего:

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

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

Нажмите здесь, если видео не доступно

Как вы проводите тестирование белого ящика?

Чтобы дать вам упрощенное объяснение тестирования белого ящика, мы разделили его на два основных этапа . Вот что делают тестеры при тестировании приложения с использованием техники тестирования белого ящика:

ШАГ 1) ПОНИМАТЬ ИСТОЧНИК КОД

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

Шаг 2) СОЗДАТЬ ИСПЫТАТЕЛЬНЫЕ ДЕЛА И ИСПОЛНИТЬ

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

Пример тестирования WhiteBox

Рассмотрим следующий фрагмент кода

Целью тестирования WhiteBox является проверка всех ветвей решений, циклов, операторов в коде.

Чтобы выполнить утверждения в приведенном выше коде, тестовые случаи WhiteBox будут

Методы испытаний белой коробки

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

Доступны автоматизированные инструменты для анализа покрытия кода. Ниже приведены несколько методов анализа покрытия

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

Покрытие ветвления — этот метод проверяет все возможные пути (если-еще и другие условные циклы) программного приложения.

Помимо вышесказанного, существует множество типов покрытия, таких как покрытие условий, покрытие нескольких условий, покрытие пути, покрытие функций и т. Д. Каждый метод имеет свои преимущества и пытается протестировать (охватить) все части программного кода. Используя покрытие Statement и Branch, вы обычно достигаете 80-90% покрытия кода, что является достаточным.

Типы тестирования белого ящика

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

Тестирование на утечки памяти : утечки памяти являются основными причинами медленной работы приложений. Специалист по обеспечению качества, имеющий опыт в обнаружении утечек памяти, необходим в тех случаях, когда у вас медленно работает программное приложение.

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

Лекции

Лабораторные

Справочники

Эссе

Вопросы

Стандарты

Программы

Дипломные

Курсовые

Помогалки

Графические

Доступные файлы (1):

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

Кафедра геоинформационных систем

по лабораторной работе № 1.

^ Цель работы: разработка программы идентифицирующую треугольник по двум сторонам и углу протестировав обнаружить ошибки (если таковы имеются).

Задание: идентифицировать треугольник по двум сторонам и углу (остроугольный \ прямоугольный \ тупоугольный \ равносторонний \ равнобедренный).

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

Приведем типовые задачи этих лабораторных работ, составленные на основе [1, 3].

1) На основе текста программы формируется потоковый граф.

2) Определяется цикломатическая сложность потокового графа.

3) Определяется базовое множество независимых линейных путей.

4) Подготавливаются тестовые варианты, инициирующие выполнение каждого пути.

5) Реальные результаты каждого тестового варианта сравниваются с ожидаемыми результатами.

1) Даны две точки и . Определить, какая из них находится ближе к началу координат. Учесть случай, что точки могут находиться одинаково близко к началу координат.

2) Даны два угла треугольника (в градусах). Определить, существует ли такой треугольник. Если да, то будет ли он прямоугольным.

3) Даны действительные числа и . Меньшее из этих двух чисел заменить их полусуммой, а большее — их удвоенным произведением. В случае, если числа равны, то производить замену не требуется.

4) Определить, делителем каких из чисел , , является число .

5) Даны три числа , , . Проверить, будут ли они сторонами треугольника. Если да, то вычислить площадь этого треугольника.

6) Вычислить значение функции:

7) Дано действительное число и целое число . Вычислить (учесть случай деления на 0, а также случай, когда введено ):

9) Дана строка. Подсчитать в ней количество вхождений букв 'r', 'k' и 't'.

1) Строится ограничение для каждого условия.

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

3) Строится ограничивающее множество для каждого условия (с применением константных формул).

4) Для каждого элемента ограничивающих множеств разрабатывается тестовый вариант.

5) Реальные результаты каждого тестового варианта сравниваются с ожидаемыми результатами.

1) Пользователь вводит два числа, и . Необходимо вычислить и вывести на экран значение по следующему принципу:

а) Если одновременно и , тогда вычисляется как .

б) Иначе, если , то вычисляется как произведение и .

в) Иначе вычисляется как .

2) Пользователь вводит два числа, и . Необходимо вычислить и вывести на экран значение по следующему принципу:

а) Если одновременно и , тогда вычисляется как среднее геометрическое модулей и .

б) Иначе, если , то вычисляется как сумма и .

в) Иначе вычисляется как .

1) Проанализировать конструкцию циклов и определиться с методикой тестирования.

2) Разработать тестовые варианты.

3) Реальные результаты каждого тестового варианта необходимо сравнить с ожидаемыми результатами.

Массив в каждой задаче должен быть организован как псевдодинамический, т. е. реализуемый следующим образом:

1) объявляется массив, состоящий из 5 элементов;

2) пользователь вводит реальное количество элементов массива;

3) дальнейшая работа с массивом ограничивается заданной пользователем размерностью (элементы массива генерируются случайным образом).

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

2) Упорядочить по возрастанию элементы каждой строки прямоугольной матрицы. Измененную матрицу вывести на экран.

3) Дана прямоугольная матрица. Определить и вывести на экран количество элементов данной матрицы, которые больше суммы остальных элементов в своем столбце.

4) Найти наибольший и наименьший элементы прямоугольной матрицы и поменять их местами. Измененную матрицу вывести на экран.

5) Дана прямоугольная матрица. Найти в каждой строке матрицы максимальный и минимальный элементы и поменять их с первым и последним элементом строки соответственно. Измененную матрицу вывести на экран.

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