Тестирование методом черного ящика (Black Box Testing)
Тестирование методом черного ящика (black box testing): Тестирование, функциональное или нефункциональное, без знания внутренней структуры компонента или системы (ISTQB).
Тестирование на основе спецификации (specification-based testing): Тестирование, основным базисом которого являются внешние вводы и выводы элемента тестирования, обычно на основе спецификации, а не ее реализация в исходном коде или исполнимом программном обеспечении. (ГОСТ 56920)
Другие названия: Behavioral Testing, Specification-Based Testing, Input-Output Testing, непрозрачный ящик (opaque-box), закрытый ящик (closed-box), тестирование на основе спецификации (specification-based testing) или тестирование с глазу на глаз (eye-to-eye testing).
Тестирование методом «черного ящика» - это стратегия, в которой тестирование основано исключительно на требованиях и спецификациях, при этом мы не знаем, как устроена внутри тестируемая система и работаем исключительно с внешними интерфейсами тестируемой системы или компонента. Тестирование черного ящика может быть применено на всех уровнях - модульном, интеграционном, системном и приемочном.
Functional Testing: этот тип касается функциональных требований или спецификаций приложения (functional requirements or specifications). Здесь различные действия или функции системы тестируются путем предоставления входных данных и сравнения фактического выхода с ожидаемым выходом. Например, когда мы тестируем раскрывающийся список, мы нажимаем на него и проверяем, что он раскрывается и все ожидаемые значения отображаются. Вот несколько основных типов функционального тестирования:
Smoke Testing;
Sanity Testing;
Integration Testing;
System Testing;
Regression Testing;
User Acceptance Testing;
Non-Functional Testing: Помимо функциональности требований, есть несколько нефункциональных аспектов, которые необходимо протестировать, чтобы улучшить качество и производительность приложения. Несколько основных типов нефункционального тестирования включают:
Usability Testing;
Load Testing;
Performance Testing;
Compatibility Testing;
Stress Testing;
Scalability Testing;
Преимущества Black box testing:
Тестировщику не обязательно иметь технический опыт. Важно проводить тестирование, оказываясь на месте пользователя и думая с его точки зрения;
Тестирование можно начинать после завершения разработки проекта / приложения. И тестировщики, и разработчики работают независимо, не мешая друг другу;
Это более эффективно для больших и сложных приложений;
Дефекты и несоответствия можно выявить на ранней стадии тестирования;
Недостатки Black box testing:
Без каких-либо технических или программных знаний есть вероятность пропустить возможные условия тестируемого сценария;
В оговоренное время есть вероятность протестировать не все входные и выходные значения;
Полный Test Coverage невозможен для больших и сложных проектов;
Парадигмы тестирования методом черного ящика (Paradigms of Black Box Software Testing)
Парадигма создает основное направление мышления - она дает понимание и направление для дальнейших исследований или работы. Парадигма тестирования будет определять типы тестов, которые (для человека, работающего в рамках этой парадигмы) актуальны и интересны. Список парадигм:
Domain driven
Ключевые идеи:
«Попробуйте диапазоны и варианты»;
«Разделите мир на классы»;
Основной вопрос или цель:
Стратегия стратифицированной выборки. Разделите большое пространство возможных тестов на подмножества. Выберите лучших представителей из каждого набора;
Примеры кейсов:
Анализ эквивалентности простого числового поля;
Тестирование совместимости принтеров;
Сильные стороны:
Нахождение ошибок с наибольшей вероятностью с помощью относительно небольшого набора тестов;
Интуитивно понятный подход, хорошо обобщает;
Слепые зоны:
Ошибки, выходящие за рамки границ, или в очевидных особых случаях;
Кроме того, фактические домены часто остаются неизвестными;
Stress driven
Ключевые идеи:
«Сокруши продукт»;
«Проведи его через отказы;
Основной вопрос или цель:
Узнать о возможностях и слабых сторонах продукта, проведя его через отказ и за его пределами. Что сбои в экстремальных случаях говорят нам об изменениях, необходимых в работе программы в нормальных случаях?
Примеры кейсов:
Большие объемы данных, подключения устройств, длинные цепочки транзакций;
Условия нехватки памяти, сбои устройств, вирусы и другие проблемы;
Сильные стороны:
Выявление слабых мест, в т.ч. дыр в безопасности;
Слепые зоны:
Слабости, которые не становятся более заметными из-за стресса;
Specification driven
Ключевые идеи:
«Проверяйте каждое требование»;
Основной вопрос или цель:
Проверяйте соответствие (conformance) продукта каждому заявлению в каждой спецификации, документе с требованиями и т. д.;
Примеры кейсов:
Матрица прослеживаемости, отслеживает тестовые случаи, связанные с каждым элементом спецификации;
Сильные стороны:
Критическая защита от гарантийных претензий, обвинений в мошенничестве, потери доверия со стороны клиентов;
Слепые зоны:
Любые проблемы, не указанные в спецификациях или плохо решенные в спецификациях;
Risk driven
Ключевые идеи:
«Сначала найди наибольшие ошибки»;
Основной вопрос или цель:
Расставьте приоритеты при тестировании с точки зрения относительного риска различных областей или проблем, которые мы могли бы проверить;
Примеры кейсов:
Переформулированный анализ классов эквивалентности;
Тестируйте в порядке частоты использования;
Стресс-тесты, тесты на обработку ошибок, тесты безопасности, тесты для поиска прогнозируемых или предполагаемых ошибок;
Образец из списка предсказанных ошибок;
Сильные стороны:
Оптимальная приоритезация (при условии, что мы правильно идентифицируем и расставляем по приоритетам риски);
Тесты высокой мощности;
Слепые зоны:
Риски, которые не были идентифицированы или которые на удивление более вероятны;
Random / statistical testing
Ключевые идеи:
«Объемное тестирование с новыми кейсами»;
Основной вопрос или цель:
Пусть компьютер создает, выполняет и оценивает огромное количество тестов;
Примеры кейсов:
Валидация функции или подсистемы (например, тестирование эквивалентности функций) на основе оракулов (Oracle-driven);
Стохастическое (переход между состояниями) тестирование для выявления конкретных сбоев (ассерты, утечки и т. д.);
Оценка статистической надежности;
Частичный или эвристический оракул, чтобы найти некоторые типы ошибок без общей проверки;
Сильные стороны:
Регрессия не зависит каждый раз от одного и того же старого теста;
Частичные оракулы могут быстро и дешево находить ошибки в молодом коде;
Меньше вероятность пропустить невидимые извне внутренние оптимизации;
Может обнаруживать сбои, возникающие из-за длинных сложных цепочек, которые было бы трудно создать в соответствии с запланированными испытаниями;
Слепые зоны:
Нужно уметь отличать pass от failure. Слишком много людей думают: «Not crash = not fail»;
Кроме того, эти методы часто охватывают многие типы рисков, но затемняют необходимость в других тестах, которые не поддаются автоматизации;
Function Testing
Ключевые идеи:
«Модульное тестирование черного ящика»;
Основной вопрос или цель:
Тщательно проверяйте каждую функцию по очереди;
Примеры кейсов:
Таблица, тестируйте каждый элемент по отдельности;
База данных, тестируйте каждый отчет по отдельности;
Сильные стороны:
Тщательный анализ каждого протестированного элемента;
Слепые зоны:
Упускает взаимодействия, пропускает исследование преимуществ предлагаемые программой;
Regression Testing
Ключевые идеи:
«Повторить тестирование после изменений»;
Основной вопрос или цель:
Управляйте рисками, связанными с тем, что (а) исправление ошибки не устраняет ошибку или (б) исправление (или другое изменение) имело побочный эффект (side effect);
Примеры кейсов:
Регрессия ошибок, регрессия старых исправлений, общая функциональная регрессия;
Наборы автоматизированной регрессии графического интерфейса;
Сильные стороны:
Обнадеживает, укрепляет доверие, удобен для регуляторов;
Слепые зоны:
Все, что не вошло в регрессионную серию. Кроме того, поддержание этого стандартного списка может быть очень дорогостоящим;
Scenario / use case / transaction flow
Ключевые идеи:
«Делай что-нибудь полезное и интересное»;
«Делайте одно за другим»;
Основной вопрос или цель:
Сложные случаи, отражающие реальное использование;
Примеры кейсов:
Оценивайте продукт на предмет соответствия бизнес-правилам, данным о клиентах и продукции конкурентов;
Тестирование жизненного цикла / Life history testing (Hans Buwalda’s “soap opera testing”);
Варианты использования (Use cases) - это более простая форма, часто основанная на возможностях продукта и пользовательской модели, а не на естественном наблюдении за системами такого типа;
Сильные стороны:
Сложные, реалистичные события. Может помогать справляться в ситуациях, которые слишком сложны для моделирования;
Выявляет сбои, которые происходят (развиваются) с течением времени;
Слепые зоны:
Отказ одной функции может сделать этот тест неэффективным;
Необходимо хорошо подумать, чтобы добиться хорошего покрытия;
User testing
Ключевые идеи:
Стремитесь к реализму;
Давайте попробуем это с настоящими людьми (для разнообразия);
Основной вопрос или цель:
Выявить сбои, которые могут возникнуть по вине человека, то есть сбои в общей системе человек / машина / программное обеспечение;
Примеры кейсов:
Бета-тестирование;
Собственные эксперименты с использованием стратифицированной выборки целевого рынка;
Сильные стороны:
Проблемы дизайна более достоверны;
Может продемонстрировать, что некоторые аспекты продукта непонятны или приводят к высокому проценту ошибок при использовании;
Внутренние тесты можно контролировать с помощью логов, видео, отладчиков и других инструментов;
Внутренние тесты могут быть сосредоточены на областях / задачах, которые, по вашему мнению, являются (или должны быть) спорными;
Слепые зоны:
Покрытие не гарантировано (серьезные пропуски бета-тестирования, других пользовательских тестов);
Тестовые примеры могут быть плохо спроектированы, тривиальны, вряд ли выявляют малозаметные ошибки;
Бета-тестирование стоит денег;
Exploratory testing
Ключевые идеи:
«Интерактивное, одновременное исследование, разработка тестов и тестирование»;
Основной вопрос или цель:
ПО поступает тестировщику без документации. Тестировщик должен одновременно узнавать о продукте и о тестовых примерах / стратегиях, которые позволят выявить продукт и его дефекты;
Примеры кейсов:
Полное тестирование test-it-today;
Сторонние компоненты;
Горилла-тестинг;
Сильные стороны:
Продуманная стратегия получения результата в неизвестности;
Стратегия выявления несоответствия ожиданиям клиентов;
Слепые зоны:
Чем меньше мы знаем, тем больше рискуем упустить.
Источники:
Last updated