Парадигмы тестирования методом черного ящика (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”