- PVSM.RU - https://www.pvsm.ru -
Тестирование не только подтверждает качество программного продукта, но и позволяет разработчику совершенствовать его.
Почти каждое программное приложение требует хотя бы одной строки кода или последовательности сложных процедур. Поэтому разработчик должен провести множество тестов, чтобы гарантировать правильную работу кода и выполнение его предназначения.
Тестирование по стратегии чёрного и белого ящика — два вида тестирования, часто выполняемых разработчиками на этом этапе.
В статье мы расскажем о тестировании по стратегии чёрного ящика (black box testing), а также о фундаментальных сходствах и отличиях чёрного и белого ящика.
Тестирование по стратегии чёрного ящика, часто называемое функциональным тестированием — это методика, изучающая функциональность ПО без необходимости знания внутренней структуры кода.
Она может применяться на всех уровнях тестирования ПО, но в основном используется на высоких уровнях.
Тестирование по стратегии чёрного ящика — это процесс тестирования системы и её поведения вне зависимости от её внутренней структуры, архитектуры и реализации.
Тестировщик осуществляет ввод, а вывод рассматривается как часть этой методики тестирования ПО.
Это позволяет определять реакцию системы на ожидаемые и неожиданные действия пользователя, время реакции, сложности юзабилити и проблемы с надёжностью.
Тестирование по стратегии чёрного ящика — действенная методика, поскольку она обеспечивает сквозное выполнение системы.
Аналогично тому, как конечным пользователям не важно то, как спроектирована или структурирована система, и они ожидают подходящий ответ на свои запросы, тестировщик может воссоздать действия пользователя, чтобы определить, выполняет ли система свои обещания.
При тестировании по стратегии чёрного ящика исследуются все отдельные компоненты, например, интерфейс пользователя и UX, веб-сервер или сервер приложения, база данных, зависимости и интегрированные системы.
Этот тип тестирования также называют тестированием opaque box, closed box, specification-based и eye-to-eye.
Эта методика тестирования разделяется на следующие типы:
Функциональное тестирование в первую очередь сосредоточено на критически важных функциях ПО, а также на интеграции между ключевыми компонентами и системой в целом.
В этой методологии задействуется дымовое тестирование (smoke testing)/санитарное тестирование (sanity testing), интеграционное тестирование и системное тестирование для проверки уникальных функций и возможностей ПО.
Типичный пример такого тестирования — проверка того, что выполнить вход могут только пользователи с правильными учётными данными.
Нефункциональное тестирование выполняется уровнем выше функций и возможностей. Вместо того, чтобы определять, может ли ПО выполнить операцию, оно исследует, как ПО выполняет это действие.
Этот тип тестирования исследует юзабилити и понимание системы, производительность при пиковых нагрузках, совместимость с соответствующими браузерами и устройствами, а также уязвимость к угрозам безопасности.
Функциональные части программы подвергаются регрессионному тестированию, чтобы проверить, демонстрирует ли новая версия регрессию, или ухудшение своих возможностей.
Это тестирование выполняется для того, чтобы определить, работает ли конкретная функция в новой версии и не снизилась ли производительность ранее эффективного действия.
Тестирование по стратегии чёрного ящика содержит следующие методики:
В качестве альтернативы тестированию всех возможных входящих данных тестеры могут «разделять» их на группы, а затем тестировать только одну «выборку» из каждой группы.
Например, если система запрашивает дату рождения пользователя и выдаёт одинаковый ответ для всех пользователей младше 18 лет и другой ответ для пользователей от 18 лет и старше, то тестировщикам достаточно протестировать одну дату рождения в группе «младше 18» и одну дату в группе «старше 18».
Тестировщики легко могут выявить уникальное поведение систем в диапазоне рядом с заданным граничным значением. Например, в поле допускается ввод чисел только от 0 до 99. Граничные значения (-100, 99 и 100) позволяют тестировщикам удобным образом убедиться в правильной проверке вводимых данных.
Многие системы предоставляют пользователям результаты на основании неких входящих данных. Обнаружив такие «правила», или множества условий, тестеры могут определить влияние каждого правила и создать соответствующие тестовые случаи.
При переходе из одного состояния в другое системы возвращают множество ответов. Классическим примером является система логина, позволяющая пользователям выполнять аутентификацию, однако блокирующая аккаунт после заданного количества неудачных попыток.
Если тестировщики выявят механизм смены состояний, они могут создать тестовые случаи, проверяющие систему, когда она выполняет переходы между состояниями.
Например, если система блокирует аккаунт после пяти безуспешных попыток входа, тестовый случай может исследовать, что произойдёт при шестой попытке.
В этой методике выполняется тестирование на частые ошибки, которые делают разработчики при создании схожих систем. Например, тестировщики могут исследовать, предусмотрел ли разработчик обработку значений null в поле, текста в числовом поле или чисел в текстовом поле, а также очистку входящих данных (например, можно ли передать входящие данные пользователя, содержащие исполняемый код, что влияет на безопасность системы).
Исчерпывающее угадывание ошибок включает в себя тестирование на известные уязвимости ПО, которые могут повлиять на тестируемую систему.
Тестировщики работают только с графическим интерфейсом приложения (GUI). Поэтому они не исследуют на ошибки исходный код.
Тестерам не нужно понимать код, поэтому возможен аутсорс тестирования ПО по стратегии чёрного ящика.
Тесты проводятся с точки зрения конечных пользователей.
Так как тестировщик не знаком с кодом, у него нет предвзятого мнения о функциональности кода.
Процедура тестирования может дублироваться, а какие-то пути могут быть полностью упущены.
Когда проектировщики ПО уже исполнили тесты, они уже могут быть необязательны.
Так как у тестировщика отсутствуют знания кодинга, некоторые функции и возможности приложения могут оказаться непроверенными.
Чтобы гарантировать соответствие программы высочайшим стандартам качества, тестеры должны быть уверены в том, что тестируют.
Тестирование по стратегии чёрного ящика — важная часть арсенала тестировщика, но она не должна быть единственной. Такое тестирование может сделать свой вклад в обеспечение уверенности в качестве проекта. Тем не менее, если существуют незадокументированные требования, black box testing не должно использоваться для определения приоритетов багов.
Telegram-канал с полезностями [1] и уютный чат [2]
Автор:
ru_vds
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testing/380816
Ссылки в тексте:
[1] Telegram-канал с полезностями: https://inlnk.ru/dn6PzK
[2] уютный чат: https://inlnk.ru/ZZMz0Y
[3] Источник: https://habr.com/ru/post/700858/?utm_source=habrahabr&utm_medium=rss&utm_campaign=700858
Нажмите здесь для печати.