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

Отличия в тестировании методами черного и белого ящика.

Тестирование методом «черного ящика»

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

Основная задача тестировщика для данного метода тестирования состоит в последовательной проверке соответствия поведения системы требованиям.

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

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

Отчеты об обоих типах проблем документируются и передаются разработчикам.

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

Анализ метода «Black box» тестирование

Где используется метод «черного ящика»?

Техники тестирования «черным ящиком»

Анализ граничных значений.

Тестирование таблицы переходов. 4. Тестирование по сценариям использования.

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

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

Тестировщику не нужна дополнительная квалификация.

Тестирование проходит «с позиции пользователя».

Составлять тест-кейсы можно сразу после подготовки спецификации

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

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

При отсутствии четкой и полной спецификации проектировать тесты и тест-сценарии оказывается затруднительно.

Метод «черного ящика» является эффективным при различных видах тестирования, но следует помнить, что некоторые ошибки невозможно найти, используя только этот метод (например, ошибки во внутренней структуре кода).

Проведение «black-box» тестирования увеличивает уверенность в том, что приложение надежно работает на широком диапазоне входных данных, так как набор тестовых данных зависит только от спецификации, а не от особенностей внутренней реализации продукта.

Метод «черного ящика» выгодно применять, если вы ищете:

 неправильно реализованные функции приложения или сервиса;  ошибки в пользовательском интерфейсе;  ошибки в функциональных спецификациях.

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

Для реализации наиболее полной проверки рекомендуется использовать методы

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

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

Тестирование приложения методом «черного ящика» по сценариям пользователя.

Часть1 Тестирование треугольника.

Цель работы : получить навыки тестирования методом «черного ящика», используя технику тестирования по сценариям пользователя .

Задание 1. Создать приложение для определения вида треугольника и вычисления его периметра и площади. При создании использовать шаблон Windows Forms.

Требования к приложению .

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

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

Вычислять площадь треугольника.

Вычислять периметр треугольника.

Ограничения:

При оставлении любого поля для ввода пустым должно обрабатываться исключение;

При заполнении любого поля для ввода некорректными данными должно обрабатываться исключение;

Сторонами треугольника могут быть только целые числа.

Три числа не могут быть определены как стороны треугольника, если: — если хотя бы одно из них меньше или равно 0; — сумма двух из них меньше третьего.

Задание 2 . Составить спецификацию переменных.

Имя переменной в программе

Назначение переменной в программе

Источник: xn--j1ahfl.xn--p1ai

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

Книга «A Practitioner’s Guide to Software Test Design» Lee Copeland была опубликована в 2003 году.
С тех пор она надежно закрепилась в списке книг, которые обязательно должен прочитать любой тестировщик. Её стоит прочитать в оригинале. Читается очень приятно: язык не сложный, стиль легкий. По ходу книги автор слегка иронизирует над собой, своими учениками, читателями и в целом над сферой нашей деятельности.

Далее приводится не перевод, а скорее подробный конспект раздела “Техники тестирования методом черного ящика”, в котором содержится описание применения техник тест-дизайна.

Ко мне в руки книга попала по совету бывшего коллеги, за что ему отдельное спасибо.

To be most effective and efficient test case must be designed, not just slapped together.

Классы эквивалентности (Equivalence Class Testing)

Техника

1. Определить классы эквивалентности.
2. Создать тест-кейсы для каждого класса эквивалентности.

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

Любые данные в рамках класса эквивалентны, это означает что если один тест-кейс в кассе эквивалентности обнаружил/не обнаружил дефект, то все остальные тест-кейсы внутри этого класса эквивалентности обнаружат/не обнаружат тот же самый дефект.

Альтернативный подход — использование классов эквивалентности не для входов, а для выходов. Разделить варианты выходов на классы эквивалентности, определить какие входные значения могут инициировать такие выходы. Преимущество в том, что проверяется каждый возможный вариант выхода. Недостаток в том, что внутри класса эквивалентности по выходу, может прятаться несколько классов эквивалентности по входу.

При наличии нескольких переменных:

1. валидные классы нескольких переменных объединяются в один тест-кейс;
2. невалидные классы тестируются отдельно.

Let your designers and programmers know when they have helped you. They’ll appreciate the thought and may do in again.

Граничные значения (Boundary Value Testing)

Техника

1. Определить классы эквивалентности
2. Определить границы каждого класса эквивалентности
3. Создать тест-кейсы для каждого граничного значения, выбирая по одной точке непосредственно на границе, выше и ниже границы.

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

Значения определяются типом. Если граница 5, то для поля, где вводятся целые числа тестируются точки 4 и 6, а для поля, где вводятся суммы в рублях и копейках тестируются точки 4,99 и 5,01.

При наличии нескольких переменных:

1. минимальные значения валидных границ объединяются в один тест-кейс;
2. максимальные значения валидных границ объединяются в другой тест-кейс;
3. невалидные границы тестируются отдельно, как и в случае с невалидными классами.

Boundary value testing focuses on the boundaries because that is where so many defects hide.

Таблица принятия решений (Decision Table Testing)

Техника

1. Определить все условия
2. Составить все возможные комбинации условий
3. Убрать лишние комбинации. Удаляются те, в которых изменение значений никак не влияет на получаемый результат (Don’t care — DC)
4. Определить действия
5. Создать тест-кейсы для каждой комбинации

Таблица принятия решений — представляет связь составных условий и результирующих действий.

Если условие представляет из себя диапазон значений, то дополнительно создаются тесты для проверки значений выше и ниже граничного.

2 3 =8 комбинаций	Rule 1	Rule 2	Rule 3	Rule 4	Rule 5	Rule 6	Rule 7	Rule 8
Conditions
Допустимый код акции	N	N	N	N	Y	Y	Y	Y
Допустимое количество	N	N	Y	Y	N	N	Y	Y
Достаточно средств	N	Y	N	Y	N	Y	N	Y
Actions
Купить	N	N	N	N	N	N	N	Y

Внимательно посмотрев на таблицу, можно заметить, что в правилах 1, 2, 3, 4, если код акции недопустимый, то проверка остальных условий не имеет смысла. Правила 5 и 6 могут быть объединены, т.к. условие проверки средств никак не влияет на результат. Условия, которые не оказывают влияние на результат помечаются как “DC”. Таблица преобразуется:

4 комбинации	Rule 1	Rule 2	Rule 3	Rule 4
Conditions
Допустимый код акции	N	Y	Y	Y
Допустимое количество	DC	N	Y	Y
Достаточно средств	DC	DC	N	Y
Actions
Купить	N	N	N	Y

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

Famous Software Tester Mick Jagger gives excellent advice regarding this “You can’t always get what you want, but if you try sometimes, you just might find, you get what you need.”

Попарное тестирование

Техника

1. Определить параметры (variables)
2. Определить количество значений для каждого параметра (choices for variable)
3. Построить массив, содержащий колонки для каждого параметра и значения в колонках, которые содержать все сочетания значений этих параметров друг с другом.
4. Сопоставить полученный ортогональный массив с целью тестирования.
5. Построить тест-кейсы.

Опытным путем было определено, что большинство дефектов это или одиночные дефекты (single-mode defects), или парные дефекты (double-mode defects), т.е. проявляющиеся при сочетании одного параметра всего лишь с одним другим параметром, при том что значение остальных параметров не имеет значения.

Если количество комбинаций значений переменных велико, не стоит пытаться протестировать все возможные комбинации, лучше сосредоточиться на тестировании всех пар значений переменных.
Два подхода попарного тестирования (pairwise testing): метод ортогонального массива (orthogonal arrays) и метод всех пар (allpair algorithm).

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

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

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

Нужно учитывать, что могут возникнуть ограничения связанные с тем, что некоторые сочетания параметров никогда не будут иметь места.

There is no underlying “software defect physics” that guarantees pairwise testing will be of benefit. There is only one way to know — try it.

Диаграмма переходов состояний

Техника

Состояние (State) — Условие в котором система ожидает одно или несколько событий.Состояние помнит что было получено на вход и определяет ответную реакцию, которая должна произойти. Это событие может быть приводить в новое состояние и/или инициировать новое действие. Состояние обычно отражает значение некоторой переменной в системе. Изображается в форме круга.

Переход (Transition) — Представляет переход из текущего состояния в новое, в результате выполнения какого-то действия. Изображается в виде стрелки.

Событие (Event) — Событие, ставшее причиной изменения состояния. Обычно событие поступает в систему из внешнего мира посредством некоторого интерфейса. Иногда это событие инициируется внутри самой системы например такие как срабатывание таймера, снижение ниже какого-то уровня. Считается, что событие происходит моментально.

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

Действие (Action) — Операция, инициированная в результате смены состояния. Зачастую это некоторый ответ системы. Помните, что действие происходит при переходе между состояниями. Состояния сами по себе статичны. Указывается через слеш в подписи к стрелке перехода после события.

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

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

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

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

Может быть выбран один из 4 вариантов создания тест-кейсов:

1. Создать наборы тест-кейсов так, чтобы все состояния были пройдены хотя бы по одному разу. В одном тест-кейсе может быть описан переход через несколько состояний. Это довольно слабый уровень тестового покрытия.
2. Создать наборы тест-кейсов так, чтобы все события были инициированы хотя бы по одному разу. Тест-кейсы, которые покрывают все события в то же время покрывают и все состояния. Снова слабый уровень тестового покрытия.
3. Создать наборы тест-кейсов так, чтобы все пути были пройдены хотя бы по одному разу. Такой способ хорош с точки зрения тестового покрытия, однако практически не осуществим. Если диаграмма имеет циклы, то количество возможных путей может оказаться бесконечным.
4. Создать наборы тест-кейсов так, чтобы все переходы были выполнены хотя бы по одному разу. Этот способ обеспечивает хороший уровень тестового покрытия, поэтому рекомендуется использовать именно его.

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

And now for something completely different. Monty Python

Варианты использования (Use Case Testing)

Техника

Use case — это сценарии, описывающие то как actor (обычно человек, но может быть и другая система) пользуется системой для достижения определенной цели. Варианты использования описываются с точки зрения пользователя, а не системы. Внутренние работы по поддержанию работоспособности системы не являются частью варианта использования.

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

Рекомендации по созданию тест-кейсов на основе вариантов использования

1. Начать с валидных данных и наиболее частых сценариев.
2. Проверить граничные значения и невалидные значения (с использованием ранее рассмотренных техник).
3. Редко используемые сценарии, крайне важные для системы (так называемая “Остановка ядерного реактора” Shut Down The Nuclear Reactor)
4. Тесты на каждое ветку-альтернативу (Extension) каждого шага
5. Попробовать выполнить операцию в непривычном порядке
6. Извратить предусловие, если это действительно может произойти
7. Если транзакция имеет циклы, запустите ее в цикле, и не один-два раза — будьте жестче
8. Найти очень долгий и извилистый путь и пройдите по нему
9. Если ожидается, что транзакция будет выполняться в логичном порядке, попробовать выполнить ее в обратном порядке (например заполнить поля не сверху вниз, а снизу вверх)
10. Создать тесты на защиту от дурака

Шаблон описания вариантов использования

Use Case Component	Description
Use Case Number or Identifier (Номер или идентификатор)	Уникальный идентификатор
Use Case Name (Наименование)	В форме предложения, содержащего глагол в активной форме (что сделать?). Например, Авторизоваться, Создать заказ
Goal in Context (Цель и контекст)	Более детальное описание цели, если это необходимо. Например, Создать заказ от имени организации.
Scope (Границы)	Корпорация (общий)|Система|Подсистема
Level (Уровень)	Общая|Частная|Подфункция
Primary Actor (Основной исполнитель	Роль или описание основного пользователя
Preconditions (Предусловия)	Состояние, в котором система должна находится до начала варианта использования
Success End Conditions (В случае успеха)	Состояние, в которое должна перейти система в случае удачного завершения варианта использования
Failed End Conditions (В случае провала)	Состояние, в которое должна перейти система в случае НЕудачного завершения варианта использования
Trigger (Условие срабатывания)	Действие, инициирующее запуск этого варианта использования
Main Success Scenario (Основной сценарий)	Шаги и действия
Extensions (Дополнительные условия)

If you don’t try strange things. you know the users will.

• Тестирование IT-систем
• Анализ и проектирование систем

Источник: habr.com

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

Тестирование методом «черного ящика» – это простая технология, которая может оказать значительный эффект на качество кода. В статье [15] показывается преднамеренное внедрение случайных неправильные данные в приложение и неверные результаты работы.

Также объясняется использование технологий создания безопасного кода: контрольных сумм, хранилищ данных XML и проверки кода, которые защищают программы от случайных данных. Кроте того, демонстрируется технология защиты, а именно упражнение по имитации подходов взломщиков кода: поврежденные файлов, которые могут вызвать сбой какой-либо программной системы, например Microsoft Word.

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

При тестировании методом «черного ящика» вы атакуете программу случайными неверными данными (которые называются искажением (fuzz)), а затем ждете и смотрите, что сломалось. Хитрость такого метода заключается в том, что тестирование нелогично. Вместо того, чтобы пытаться угадать, какие данные могут спровоцировать ошибку (как обычно поступают люди, занимающиеся тестированием), автоматизированный тест просто выдает программе как можно более случайный «мусор». Ошибки, определяемые подобным тестированием, обычно шокируют программистов, поскольку ни один логически мыслящий человек не мог их даже ожидать.

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

Тестирование по методу «черного ящика» реализовать довольно просто:

1. Подготовьте корректный файл, предназначенный для ввода в программу;
2. Замените некоторые части этого файла случайными данными;
3. Откройте файл в программе;
4. Посмотрите, что идет не так.

Случайные данные можно менять любыми способами. Например, можно менять не просто часть файла, а весь файл заменить случайными данными. Можно ограничить содержимое файла лишь ASCII–текстом либо ненулевыми байтами. Главное – это подать приложению побольше случайных данных и посмотреть, что будет.

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

Хотя тестирование по методу «черного ящика» обычно требует некоторого ручного написания кода, существуют инструментальные средства, которые могут помочь в этом. Например, Листинг 1 демонстрирует простой Java-класс,™ который случайным образом модифицирует определенную длину файла. Обычно меняют файл где-нибудь после первых нескольких байт, поскольку программы имеют тенденцию определять ошибку в самом начале данных, а не потом. (Ищутся ошибки, которые программа не проверяет, а не те, с которыми она справляется.)

Листинг

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

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

Тестирование по методу «черного ящика» может обнаружить наличие ошибок в программе. Оно не доказывает, что таких ошибок в программе нет. Однако проведение такого тестирования значительно повышает уверенность в том, что приложение надежно и безопасно по отношению к непредвиденным входным данным. Если тестирование программы по этому методу проводилось в течение 24 часов и она по-прежнему работает, то вряд ли дальнейшие атаки подобного рода вызовут ошибку. (Заметьте: это не невозможно, а просто менее вероятно.) Если тестирование все-таки обнаружило ошибки в программах, их надо исправить. Вместо того, чтобы исправлять случайно обнаруженные ошибки по мере их появления, более продуктивным может быть фундаментальное исправление формата файла на предмет разумного использования контрольных сумм, XML, очистки памяти и/или форматов файлов на базе грамматики.

Тестирование по методу «черного ящика» является важным средством нахождения в программах реальных ошибок. Все программисты, которые настроены на обеспечение безопасности и надежности своих программ, должны пользоваться этим средством.

Источник: tstu.ru