Какой вид тестов используется для выявления проблем с утечками памяти по методу black box
Обновлено: 06.07.2024
Книга "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)
Техника
- Определить классы эквивалентности.
- Создать тест-кейсы для каждого класса эквивалентности.
Классом эквивалентности называется набор данных, который запускает одни и те же модули и должен приводить к одним и тем же результатам.
Любые данные в рамках класса эквивалентны, это означает что если один тест-кейс в кассе эквивалентности обнаружил/не обнаружил дефект, то все остальные тест-кейсы внутри этого класса эквивалентности обнаружат/не обнаружат тот же самый дефект.
Альтернативный подход — использование классов эквивалентности не для входов, а для выходов. Разделить варианты выходов на классы эквивалентности, определить какие входные значения могут инициировать такие выходы. Преимущество в том, что проверяется каждый возможный вариант выхода. Недостаток в том, что внутри класса эквивалентности по выходу, может прятаться несколько классов эквивалентности по входу.
При наличии нескольких переменных:
- валидные классы нескольких переменных объединяются в один тест-кейс;
- невалидные классы тестируются отдельно.
Let your designers and programmers know when they have helped you. They’ll appreciate the thought and may do in again.
Граничные значения (Boundary Value Testing)
Техника
- Определить классы эквивалентности
- Определить границы каждого класса эквивалентности
- Создать тест-кейсы для каждого граничного значения, выбирая по одной точке непосредственно на границе, выше и ниже границы.
Следует помнить, что точка выше или ниже границы может быть экземпляром другого класса эквивалентности, в этом случае дублировать тест не нужно.
Значения определяются типом. Если граница 5, то для поля, где вводятся целые числа тестируются точки 4 и 6, а для поля, где вводятся суммы в рублях и копейках тестируются точки 4,99 и 5,01.
При наличии нескольких переменных:
- минимальные значения валидных границ объединяются в один тест-кейс;
- максимальные значения валидных границ объединяются в другой тест-кейс;
- невалидные границы тестируются отдельно, как и в случае с невалидными классами.
Boundary value testing focuses on the boundaries because that is where so many defects hide.
Таблица принятия решений (Decision Table Testing)
Техника
- Определить все условия
- Составить все возможные комбинации условий
- Убрать лишние комбинации. Удаляются те, в которых изменение значений никак не влияет на получаемый результат (Don’t care — DC)
- Определить действия
- Создать тест-кейсы для каждой комбинации
Таблица принятия решений — представляет связь составных условий и результирующих действий.
Если условие представляет из себя диапазон значений, то дополнительно создаются тесты для проверки значений выше и ниже граничного.
| 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.”
Попарное тестирование
Техника
- Определить параметры (variables)
- Определить количество значений для каждого параметра (choices for variable)
- Построить массив, содержащий колонки для каждого параметра и значения в колонках, которые содержать все сочетания значений этих параметров друг с другом.
- Сопоставить полученный ортогональный массив с целью тестирования.
- Построить тест-кейсы.
Опытным путем было определено, что большинство дефектов это или одиночные дефекты (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 вариантов создания тест-кейсов:
- Создать наборы тест-кейсов так, чтобы все состояния были пройдены хотя бы по одному разу. В одном тест-кейсе может быть описан переход через несколько состояний. Это довольно слабый уровень тестового покрытия.
- Создать наборы тест-кейсов так, чтобы все события были инициированы хотя бы по одному разу. Тест-кейсы, которые покрывают все события в то же время покрывают и все состояния. Снова слабый уровень тестового покрытия.
- Создать наборы тест-кейсов так, чтобы все пути были пройдены хотя бы по одному разу. Такой способ хорош с точки зрения тестового покрытия, однако практически не осуществим. Если диаграмма имеет циклы, то количество возможных путей может оказаться бесконечным.
- Создать наборы тест-кейсов так, чтобы все переходы были выполнены хотя бы по одному разу. Этот способ обеспечивает хороший уровень тестового покрытия, поэтому рекомендуется использовать именно его.
Рекомендуемая стратегия создания тест-кейсов состоит в том, чтобы хотя бы по разу протестировать все переходы между состояниями. В высокорисковых системах, где требуется более надежное тестовое покрытие, возможно создавать тест-кейсы на каждый путь (цепочку переходов) между состояниями.
And now for something completely different. Monty Python
Варианты использования (Use Case Testing)
Техника
Use case — это сценарии, описывающие то как actor (обычно человек, но может быть и другая система) пользуется системой для достижения определенной цели. Варианты использования описываются с точки зрения пользователя, а не системы. Внутренние работы по поддержанию работоспособности системы не являются частью варианта использования.
Хотя бы один тест-кейс должен проверять основной сценарий и хотя бы по одному кейсу должно приходится на альтернативные сценарии.
Для того, чтобы лучше понимать подходы к тестированию программного обеспечения, нужно, конечно же, знать, какие виды и типы тестирования в принципе бывают. Давайте начнем с рассмотрения основных типов тестирования, которые определяют высокоуровневую классификацию тестов.
Самым высоким уровнем в иерархии подходов к тестированию будет понятие типа, которое может охватывать сразу несколько смежных техник тестирования. То есть, одному типу тестирования может соответствовать несколько его видов. Рассмотрим, для начала, несколько типов тестирования, которые отличаются знанием внутреннего устройства объекта тестирования.
Black Box
Summary: Мы не знаем, как устроена тестируемая система.
Тестирование методом «черного ящика», также известное как тестирование, основанное на спецификации или тестирование поведения – техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика – это:
- тестирование, как функциональное, так и нефункциональное, не предполагающее знания внутреннего устройства компонента или системы;
- тест-дизайн, основанный на технике черного ящика – процедура написания или выбора тест-кейсов на основе анализа функциональной или нефункциональной спецификации компонента или системы без знания ее внутреннего устройства.
Почему именно «черный ящик»? Тестируемая программа для тестировщика – как черный непрозрачный ящик, содержания которого он не видит. Целью этой техники является поиск ошибок в таких категориях:
- неправильно реализованные или недостающие функции;
- ошибки интерфейса;
- ошибки в структурах данных или организации доступа к внешним базам данных;
- ошибки поведения или недостаточная производительности системы;
Таким образом, мы не имеем представления о структуре и внутреннем устройстве системы. Нужно концентрироваться на том,что программа делает, а не на том, как она это делает.
Пример:
Тестировщик проводит тестирование веб-сайта, не зная особенностей его реализации, используя только предусмотренные разработчиком поля ввода и кнопки. Источник ожидаемого результата – спецификация.
Поскольку это тип тестирования, то он может включать и другие его виды. Тестирование черного ящика может быть как функциональным, так и нефункциональным. Функциональное тестирование предполагает проверку работы функций системы, а нефункциональное – общие характеристики нашей программы.
Техника черного ящика применима на всех уровнях тестирования (от модульного до приемочного), для которых существует спецификация. Например, при осуществлении системного или интеграционного тестирования, требования или функциональная спецификация будут основой для написания тест-кейсов.
Техники тест-дизайна, основанные на использовании черного ящика, включают:
- классы эквивалентности;
- анализ граничных значений;
- таблицы решений;
- диаграммы изменения состояния;
- тестирование всех пар.
Преимущества:
- тестирование производится с позиции конечного пользователя и может помочь обнаружить неточности и противоречия в спецификации;
- тестировщику нет необходимости знать языки программирования и углубляться в особенности реализации программы;
- тестирование может производиться специалистами, независимыми от отдела разработки, что помогает избежать предвзятого отношения;
- можно начинать писать тест-кейсы, как только готова спецификация.
Недостатки:
- тестируется только очень ограниченное количество путей выполнения программы;
- без четкой спецификации (а это скорее реальность на многих проектах) достаточно трудно составить эффективные тест-кейсы;
- некоторые тесты могут оказаться избыточными, если они уже были проведены разработчиком на уровне модульного тестирования.
Противоположностью техники черного ящика является тестирование методом белого ящика, речь о котором пойдет ниже.
White Box
Summary: Нам известны все детали реализации тестируемой программы.
Тестирование методом белого ящика (также прозрачного, открытого, стеклянного ящика или же основанное на коде или структурное тестирование) – метод тестирования программного обеспечения, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику. Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Точно так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации обязательны для этой техники. Тестирование белого ящика – углубление во внутреннее устройство системы за пределы ее внешних интерфейсов.
Согласно ISTQB: тестирование белого ящика – это:
- тестирование, основанное на анализе внутренней структуры компонента или системы;
- тест-дизайн, основанный на технике белого ящика – процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
Почему «белый ящик»? Тестируемая программа для тестировщика – прозрачный ящик, содержимое которого он прекрасно видит.
Пример:
Тестировщик, который, как правило, является программистом, изучает реализацию кода поля ввода на веб-странице, определяет все предусмотренные (как правильные, так и неправильные) и не предусмотренные пользовательские вводы и сравнивает фактический результат выполнения программы с ожидаемым. При этом ожидаемый результат определяется именно тем, как должен работать код программы.
Тестирование методом белого ящика похоже на работу механика, который изучает двигатель машины, чтобы понять, почему она не заводится.
Техника белого ящика применима на разных уровнях тестирования: от модульного до системного, но, главным образом, применяется именно для реализации модульного тестирования компонента его автором.
Преимущества:
- тестирование может производиться на ранних этапах: нет необходимости ждать создания пользовательского интерфейса;
- можно провести более тщательное тестирование с покрытием большого количества путей выполнения программы.
Недостатки:
- для выполнения тестирования белого ящика необходимо большое количество специальных знаний;
- при использовании автоматизации тестирования на этом уровне поддержка тестовых скриптов может оказаться достаточно накладной, если программа часто изменяется.
Сравнение Black Box и White Box
Grey Box
Summary: Нам известны только некоторые особенности реализации тестируемой системы.
Тестирование методом серого ящика – метод тестирования программного обеспечения, который предполагает комбинацию White Box и Black Box подходов. То есть внутреннее устройство программы нам известно лишь частично. Предполагается, например, доступ ко внутренней структуре и алгоритмам работы ПО для написания максимально эффективных тест-кейсов, но само тестирование проводится с помощью техники черного ящика, то есть с позиции пользователя.
Эту технику тестирования также называют методом полупрозрачного ящика: что-то мы видим, а что-то – нет.
Пример:
Тестировщик изучает код программы с тем, чтобы лучше понимать принципы ее работы и изучить возможные пути ее выполнения. Такое знание поможет написать тест-кейс, который наверняка будет проверять определенную функциональность.
Техника серого ящика применима на разных уровнях тестирования: от модульного до системного, но, главным образом, применяется на интеграционном уровне для проверки взаимодействия разных модулей программы.
BLACK BOX TESTING определяется как методика тестирования, при которой функциональность тестируемого приложения (AUT) тестируется без учета внутренней структуры кода, деталей реализации и знания внутренних путей программного обеспечения. Этот тип тестирования полностью основан на требованиях и спецификациях программного обеспечения. В BlackBox Testing мы просто фокусируемся на входах и выходах программной системы, не заботясь о внутренних знаниях программ.
Вышеупомянутый Black-Box может быть любой программной системой, которую вы хотите протестировать. Например, операционная система, такая как Windows, веб-сайт, такой как Google, база данных, такая как Oracle, или даже ваше собственное приложение. В Black Box Testing вы можете протестировать эти приложения, просто сосредоточившись на входах и выходах, не зная их внутренней реализации кода. Рассмотрим следующий видео-учебник
Нажмите здесь, если видео не доступно
Как сделать BlackBox Testing
Вот общие шаги, которые необходимо выполнить для проведения любого типа тестирования черного ящика.
Типы тестирования черного ящика
Существует много видов тестирования черного ящика, но наиболее важными являются следующие:
- Функциональное тестирование — этот тип тестирования черного ящика связан с функциональными требованиями системы; это делают тестеры программного обеспечения.
- Нефункциональное тестирование. Этот тип тестирования черного ящика связан не с тестированием конкретной функциональности, а с нефункциональными требованиями, такими как производительность, масштабируемость, удобство использования.
- Регрессионное тестирование — Регрессионное тестирование проводится после того, как исправления кода, обновления или любое другое обслуживание системы для проверки того, что новый код не затронул существующий код.
Инструменты, используемые для тестирования черного ящика:
Инструменты, используемые для тестирования черного ящика, во многом зависят от типа тестирования черного ящика, которое вы делаете.
- Для функциональных / регрессионных тестов вы можете использовать — QTP , Selenium
- Для нефункциональных тестов вы можете использовать — LoadRunner , Jmeter
Методы испытаний черного ящика
Ниже приводятся известные стратегии тестирования среди множества используемых в тестировании черного ящика.
- Тестирование класса эквивалентности: используется для минимизации количества возможных тестовых случаев до оптимального уровня при сохранении разумного охвата тестами.
- Тестирование граничных значений: Тестирование граничных значений ориентировано на значения на границах. Этот метод определяет, является ли определенный диапазон значений приемлемым для системы или нет. Это очень полезно для уменьшения количества тестовых случаев. Это наиболее подходит для систем, где вход находится в определенных диапазонах.
- Тестирование таблицы принятия решений: таблица решений помещает причины и их последствия в матрицу. В каждом столбце есть уникальная комбинация.
Сравнение тестирования черного ящика и белого ящика:
| Тестирование черного ящика | Тестирование белого ящика |
|---|---|
| основное внимание при тестировании черного ящика уделяется проверке ваших функциональных требований. | White Box Testing (модульное тестирование) проверяет внутреннюю структуру и работу вашего программного кода |
| Тестирование черного ящика дает абстракцию от кода и фокусируется на тестировании поведения программной системы. | Для проведения тестирования White Box необходимо знание основного языка программирования. Современные системы программного обеспечения используют различные языки программирования и технологии, и невозможно знать все из них. |
| Тестирование черного ящика облегчает тестирование связи между модулями | Тестирование белого ящика не облегчает тестирование связи между модулями |
Жизненный цикл тестирования и разработки программного обеспечения (SDLC)
Тестирование черного ящика имеет собственный жизненный цикл, называемый жизненным циклом тестирования программного обеспечения ( STLC ), и он относится к каждому этапу жизненного цикла разработки программного обеспечения.
Black Box Testing - это метод тестирования программного обеспечения, при котором внутренняя структура, дизайн или реализация предмета, который необходимо проверить, неизвестен тестировщику.
Что такое тестирование программного обеспечения?
Тестирование программного обеспечения - это процедура оценки системы с целью обнаружения ошибок. Он выполняется для проверки соответствия системы указанным требованиям. Тестирование измеряет общее качество системы с точки зрения ее правильности, полноты, удобства использования, производительности и других функциональных и нефункциональных атрибутов.
Тестирование черного ящика - это метод тестирования программного обеспечения, который фокусируется на анализе функциональности программного обеспечения, а не на внутренних системных механизмах. Тестирование черного ящика было разработано как метод анализа требований, спецификаций и стратегий проектирования высокого уровня клиента. Тестировщик программного обеспечения черного ящика выберет действительный и недействительный входной набор и условия выполнения кода, а также проверит правильные выходные ответы. Тестирование черного ящика также упоминается как функциональное тестирование или тестирование закрытого типа.
Например, поисковая система приложения. В поисковой системе пользователь вводит текст в строку поиска браузера. Поисковая система затем находит и извлекает соответствующие выходные данные пользователя. Что происходит за кулисами, пользователю неизвестно. Таким образом, внутренняя реализация не понимает его.
Преимущества тестирования черного ящика включают в себя:
- Простота: облегчает тестирование проектов высокого уровня и сложных приложений
- Экономия ресурсов: тестеры сосредоточены на функциональности программного обеспечения.
- Тестовые случаи: Сосредоточение внимания на функциональности программного обеспечения для облегчения быстрой разработки тестовых случаев.
- Обеспечивает гибкость: специальные знания программирования не требуются.
Пример
Тестировщик проверял бы веб-страницы, то есть с помощью щелчков и нажатий клавиш, используя браузер, предоставляя входные данные и не зная внутренних структур, таким образом сверяя выходные данные с ожидаемыми результатами.
Инструменты, используемые для тестирования черного ящика
Инструменты тестирования черного ящика в основном зависят от того, какой тип тестирования черного ящика вы используете.
- Функциональные / регрессионные тесты могут быть выполнены через QTP или Selenium
- Нефункциональные тесты могут быть выполнены через LoadRunner или Jmeter.
Уровни
В Black Box Testing следующие уровни предназначены для тестирования программного обеспечения:
- Интеграционное тестирование
- Тестирование системы
- Приемочное тестирование
Чем выше уровень, тем больше и сложнее будет ящик, и в него вступает больше испытаний черного ящика.
Определение черного ящика
Тестирование черного ящика может быть определено как метод тестирования, в котором тестируется функциональность Application Under Test (AUT), но при этом не учитывается структура внутреннего кода, детали реализации и любые знания о внутренних путях программного обеспечения.
Понимание тестирования черного ящика
Тестирование черного ящика касается всех спецификаций и требований к программному обеспечению. Black Box Testing просто фокусируется на входах и выходах системы программного обеспечения и не беспокоится о внутренних знаниях программного обеспечения.
Как Black Box Testing облегчает работу?
Существует жизненный цикл тестирования программного обеспечения, то есть STLC, который представляет собой «черный ящик» тестирования, относящийся к каждому этапу жизненного цикла разработки программного обеспечения.
- На начальном или первом этапе STLC собраны требования к продукту. Это называется фазой сбора требований.
- Следующим этапом является планирование планирования и анализ этапа тестирования. Результатами этого этапа, как правило, являются типы тестирования, которые должны быть выполнены в соответствии с проектом и планом тестирования для определения рисков и смягчения этих рисков.
- Третий этап - это этап разработки, на котором тестовые случаи, тестовые сценарии подготавливаются с помощью документов с требованиями к программному обеспечению или бизнес-требований.
- Последний этап называется этапом выполнения теста. Как следует из названия, на этом этапе выполняются все тестовые сценарии или сценарии. Все найденные ошибки сообщаются, исправляются и проверяются повторно.
Что вы можете сделать с Black Box Testing?
Некоторые из известных стратегий тестирования, используемых в тестировании черного ящика, описаны ниже:
- Тестирование класса эквивалентности
- Тестирование граничных значений
- Тестирование таблицы решений
- Причинно-следственная проверка
- Тестирование на основе требований
- Тестирование совместимости
Тестирование класса эквивалентности
Этот тип тестирования является предпочтительным, поскольку он помогает минимизировать контрольные примеры до уровня, при котором шансы покрытия требований находятся на оптимальном уровне.
Это делается в следующие два этапа:
1. Идентификация и разбиение на классы эквивалентности. Сначала входные данные разбиваются как минимум на два набора: первый набор содержит список допустимых входных значений, а второй набор содержит список недопустимых входных значений. Например, если есть поле возраста, которое может содержать возраст в диапазоне от 20 до 40, то допустимые входные значения могут быть 21, 25, 30, 39 и т. Д., А недопустимые входные значения могут быть любым значением меньше 20 или больше, чем 40 вроде 10, 15, 45, 55 и т. Д.
2. Создание тестовых случаев - каждому действительному входному классу и недопустимому входному классу присваивается уникальный идентификационный номер, а затем тестовые случаи пишутся с намерением охватить два набора входных классов.
Тестирование граничных значений
Тестирование граничных значений в основном фокусируется на границах значений. Он оценивает, является ли определенный диапазон значений приемлемым для системы или нет. Тестирование граничного значения полезно для уменьшения / минимизации количества тестовых случаев. Тестирование граничного значения наиболее подходит для систем, где входные данные находятся в определенных пределах.
Тестирование таблицы решений
Таблица решений демонстрирует причины и их одновременные эффекты в форме матрицы. При тестировании таблицы решений существует уникальная комбинация в каждом столбце.
Причинно-следственная графика
Причинно-следственный График развивает связь между причинами (логические входы) с соответствующим эффектом (Действия). Они представлены с помощью булевых графов. Шаги должны быть следующими:
- Идентификация входов и выходов.
- Разработка причинно-следственного графика.
- Преобразование графика в таблицу решений.
- Преобразование правил таблицы решений в контрольные примеры.
Тестирование на основе требований
Этот тип тестирования включает проверку того, действительны ли требования, указанные в SRS или спецификации требований к программному обеспечению.
Тестирование на совместимость
Для обеспечения функциональности как продукты, так и инфраструктура зависят от результатов выполнения тестового примера. Независимо от изменений, внесенных в параметры инфраструктуры, продукт по-прежнему должен работать должным образом. Некоторые параметры, в целом влияющие на совместимость программного обеспечения, перечислены ниже:
- Процессоры Pentium 3 или Pentium 4 и количество используемых процессоров
- 32-битная или 64-битная архитектура
- Серверы баз данных или любые другие внутренние компоненты
- Тип операционной системы (Windows, Linux и т. Д.).
Работа с тестированием черного ящика
Ниже приведены основные шаги, необходимые для тестирования черного ящика.
- Во-первых, рассматриваются спецификации и требования системы.
- Во-вторых, тестировщик выбирает логические входные данные, то есть сценарии положительного тестирования, чтобы проверить, правильно ли их обрабатывает SUT или нет. Кроме того, недопустимые входные данные, то есть сценарий отрицательного тестирования, также выбираются для проверки того, что SUT может их обнаружить.
- В-третьих, тестеры затем определяют ожидаемые результаты для всех действительных входных данных.
- В-четвертых, тестер программного обеспечения создает контрольные примеры с выбранными и действительными входными данными.
- В-пятых, созданные контрольные примеры выполняются.
- В-шестых, тестеры программного обеспечения различают фактические результаты с ожидаемыми и проверяют, совпадают ли они.
- Наконец, если таковые обнаружены, они исправлены и повторно протестированы.
преимущества
- Тесты черного ящика всегда выполняются с точки зрения пользователя, поскольку это поможет значительно выявить расхождения.
- Тестеры черного ящика также не должны знать никаких языков программирования.
- Тестерам черного ящика не нужно знать, как реализовано программное обеспечение.
- Тестовые случаи, связанные с черным ящиком, разрабатываются тестерами, как только спецификации находятся в завершенной стадии.
Недостатки
- Поскольку никаких технических или программных знаний не требуется, могут быть случаи, когда можно игнорировать все действительные и возможные условия сценария, который необходимо протестировать.
- Существуют возможности меньшего тестирования и незнания каждого возможного входа и их выходного тестирования из-за ограничений по времени (оговоренное время).
- Полное и законченное тестовое покрытие часто невозможно для сложных и крупных проектов.
Почему мы должны использовать Black Box Testing?
Инструменты тестирования «черного ящика» в основном записывают и воспроизводят. Эти инструменты записывают тестовые случаи в виде сценариев, таких как TSL, JavaScript, VB-сценарий и т. Д. Все эти инструменты в основном используются для регрессионного тестирования, чтобы проверить, не имеет ли предоставленная новая сборка какой-либо дефект в уже работающей функциональности приложения.,
Сфера
Видными и наиболее важными типами тестирования черного ящика являются следующие:
- Функциональное тестирование. Этот тип тестирования черного ящика полностью соответствует функциональным требованиям системы и выполняется тестировщиками программного обеспечения.
- Нефункциональное тестирование. Этот тип тестирования черного ящика касается не тестирования конкретной функциональности, а всех нефункциональных требований, таких как производительность, удобство использования, масштабируемость и многое другое.
- Регрессионное тестирование: Регрессионное тестирование выполняется после исправления кода, любых обновлений кода или любого другого обслуживания системы, чтобы проверить, не повлиял ли новый код на существующую функциональность.
Различия
Black Box Testing - это метод тестирования программного обеспечения, при котором внутренняя структура, дизайн или реализация тестируемого продукта неизвестны тестировщику.
White Box Testing - это метод тестирования программного обеспечения, при котором внутренняя структура, дизайн или реализация тестируемого продукта известны тестировщику.
- Функциональное тестирование
- Нефункциональное тестирование
- Регрессионное тестирование
Вывод:
Все обсуждаемые темы являются основными, а также продвинутыми темами, связанными с тестированием черного ящика и суть всех его методов и методов.
Поскольку вряд ли возможно протестировать все и все вместе с участием человека, и это тоже со 100-процентной точностью, но если уже указанные методы используются очень эффективно, это, без сомнения, повысит качество системы. Поэтому для того, чтобы закончить, тестирование черного ящика - это очень очень эффективный метод выявления дефектов, а также проверки работоспособности системы.
Рекомендуемые статьи
Это было руководство к тестированию черного ящика. Здесь мы обсудили, как Black Box Testing выполняется с помощью примеров и различных методов Black Box Testing с инструментами. Вы также можете просмотреть наши другие предлагаемые статьи, чтобы узнать больше -
Читайте также: