testirovanie-metodom-chernogo-yashika-black-box-testing.md

Тестирование методом черного ящика (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;
    • Сторонние компоненты;
    • Горилла-тестинг;
  • Сильные стороны:
    • Продуманная стратегия получения результата в неизвестности;
    • Стратегия выявления несоответствия ожиданиям клиентов;
  • Слепые зоны:
    • Чем меньше мы знаем, тем больше рискуем упустить.

Источники:

• Black Box Testing: An In-Depth Tutorial With Examples And Techniques
• Cem Kaner, James Bach - “Paradigms of Black Box Software Testing”