Описанные ниже техники — тестирование белого ящика и тестирование чёрного ящика — предполагают, что код исполняется, и разница состоит лишь в той информации, которой владеет тестировщик. В обоих случаях это динамическое тестирование.
При статическом тестировании программный код не выполняется — анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. В некоторых случаях анализируется не исходный, а промежуточный код (такой как байт-код или код на MSIL).
Также к статическому тестированию относят тестирование требований, спецификаций, документации.
После внесения изменений в очередную версию программы, регрессионные тесты подтверждают, что сделанные изменения не повлияли на работоспособность остальной функциональности приложения. Регрессионное тестирование может выполняться как вручную, так и средствами автоматизации тестирования.
Тестовые сценарии
Тестировщики используют тестовые сценарии на разных уровнях: как в модульном, так и в интеграционном и системном тестировании. Тестовые сценарии, как правило, пишутся для проверки компонентов, в которых наиболее высока вероятность появления отказов или вовремя не найденная ошибка может быть дорогостоящей.
Тестирование «белого ящика» и «чёрного ящика»
В зависимости от доступа разработчика тестов к исходному коду тестируемой программы различают «тестирование (по стратегии) белого ящика» и «тестирование (по стратегии) чёрного ящика».
При тестировании белого ящика (также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого программного обеспечения. Это типично для модульного тестирования, при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода или мутационное тестирование.
При тестировании чёрного ящика, тестировщик имеет доступ к программе только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идёт правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе. Обычно в данном виде тестирования критерий покрытия складывается из покрытия структуры входных данных, покрытия требований и покрытия модели (в тестировании на основе моделей).
При тестировании серого ящика разработчик теста имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется.
Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.
Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. То есть, тестировщик может продолжать работу по тестированию белого ящика, хотя программа уже «бета-стадии», но в этом случае он не является частью «бета-тестирования».
Покрытие кода
Покрытие кода, по своей сути, является тестированием методом белого ящика. Тестируемое программное обеспечение собирается со специальными настройками или библиотеками или запускается в особом окружении, в результате чего для каждой используемой (выполняемой) функции программы определяется местонахождение этой функции в исходном коде. Этот процесс позволяет разработчикам и специалистам по обеспечению качества определить части системы, которые при нормальной работе используются очень редко или никогда не используются (такие как код обработки ошибок и т. п.). Это позволяет сориентировать тестировщиков на тестирование наиболее важных режимов.
Тестировщики могут использовать результаты теста покрытия кода для разработки тестов или тестовых данных, которые расширят покрытие кода на важные функции.
Как правило, инструменты и библиотеки, используемые для получения покрытия кода, требуют значительных затрат производительности и/или памяти, недопустимых при нормальном функционировании ПО. Поэтому они могут использоваться только в лабораторных условиях.
Тестирование чёрного ящика или поведенческое тестирование — стратегия (метод) тестирования функционального поведения объекта (программы, системы) с точки зрения внешнего мира, при котором не используется знание о внутреннем устройстве тестируемого объекта. Под стратегией понимаются систематические методы отбора и создания тестов для тестового набора. Стратегия поведенческого теста исходит из технических требований и их спецификаций[1].
Под «чёрным ящиком» понимается объект исследования, внутреннее устройство которого неизвестно. Понятие «чёрный ящик» предложено У. Р. Эшби. В кибернетике оно позволяет изучать поведение систем, то есть их реакций на разнообразные внешние воздействия и в то же время абстрагироваться от их внутреннего устройства.
Манипулируя только лишь со входами и выходами, можно проводить определенные исследования. На практике всегда возникает вопрос, насколько гомоморфизм «чёрного» ящика отражает адекватность его изучаемой модели, то есть как полно в модели отражаются основные свойства оригинала.
Описание любой системы управления во времени характеризуется картиной последовательности её состояний в процессе движения к стоящей перед нею цели. Преобразование в системе управления может быть либо взаимно-однозначным и тогда оно называется изоморфным, либо только однозначным, в одну сторону. В таком случае преобразование называют гомоморфным.
«Чёрный» ящик представляет собой сложную гомоморфную модель кибернетической системы, в которой соблюдается разнообразие. Он только тогда является удовлетворительной моделью системы, когда содержит такое количество информации, которое отражает разнообразие системы. Можно предположить, что чем большее число возмущений действует на входы модели системы, тем большее разнообразие должен иметь регулятор.
В настоящее время известны два вида «чёрных» ящиков. К первому виду относят любой «чёрный» ящик, который может рассматриваться как автомат, называемый конечным или бесконечным. Поведение таких «чёрных» ящиков известно. Ко второму виду относятся такие «чёрные» ящики, поведение которых может быть наблюдаемо только в эксперименте. В таком случае в явной или неявной форме высказывается гипотеза о предсказуемости поведения «чёрного» ящика в вероятностном смысле. Без предварительной гипотезы невозможно любое обобщение, или, как говорят, невозможно сделать индуктивное заключение на основе экспериментов с «чёрным» ящиком. Для обозначения модели «чёрного» ящика Н. Винером [2] предложено понятие «белого» ящика. «Белый» ящик состоит из известных компонентов, то есть известных X, Y, δ, λ. Его содержимое специально подбирается для реализации той же зависимости выхода от входа, что и у соответствующего «чёрного» ящика. В процессе проводимых исследований и при обобщениях, выдвижении гипотез и установления закономерностей возникает необходимость корректировки организации «белого» ящика и смены моделей. В связи с этим при моделировании исследователь должен обязательно многократно обращаться к схеме отношений «чёрный» — «белый» ящик.
Рассмотрим, как изучается и исследуется поведение «черного» ящика второго вида. Предположим, что дана некоторая система управления, внутреннее строение которой неизвестно.
Другой способ исследования заключается в подаче на входы некоторых стандартных последовательностей. Этот способ особенно привлекателен, потому что позволяет сравнивать поведение нескольких «черных» ящиков с условием выбора таких, которые будут соответствовать предъявляемым требованиям.
Исследование систем управления связано с понятиями «вероятностный автомат», «вероятностная система», что требует изучения их вероятностных свойств. Для этих целей можно построить матрицу вероятностей (табл. 2), в которой для каждого входа x_i и каждого выхода y_i указывается условная вероятность p_i, что y_i возникает в ответ на x_i [7], приведенной в табл. 2.
Разработка методов построения математических моделей «черного» ящика является одной из важных кибернетических проблем. При условии наличия математической модели «черного» ящика появляется возможность отнести его к какому-либо одному классу, все системы которого изоморфны по поведению.
Создание математического описания «черного» ящика является своего рода искусством. В некоторых случаях удается сформировать алгоритм, в соответствии с которым «черный» ящик реагирует на произвольный входной сигнал. Для большинства же случаев делаются попытки установить дифференциальные уравнения, которые связывают реакцию «черного» ящика с его входами или, как говорят, с его входными стимулами.
Для науки метод «чёрный» ящик имеет весьма большое значение. С его помощью в науке были сделаны очень многие выдающиеся открытия. Например, ученый Гарвей еще в XVII веке предугадал строение сердца. Он моделировал работу сердца насосом, позаимствовав идеи из совершенно другой области современных ему знаний — гидравлики. Практическая ценность метода «чёрный» ящик заключается во-первых, в возможности исследования очень сложных динамических систем, и, во-вторых, в возможности замены одного «ящика» другим. Окружающая действительность и биология дают массу примеров выявления строения систем методом «чёрного» ящика.
В этом методе программа рассматривается как чёрный ящик. Целью тестирования ставится выяснение обстоятельств, в которых поведение программы не соответствует спецификации. Для обнаружения всех ошибок в программе необходимо выполнить исчерпывающее тестирование, то есть тестирование на всевозможных наборах данных. Для большинства программ такое невозможно, поэтому применяют разумное тестирование, при котором тестирование программы ограничивается небольшим подмножеством всевозможных наборов данных. При этом необходимо выбирать наиболее подходящие подмножества, подмножества с наивысшей вероятностью обнаружения ошибок.
Уменьшает более чем на одно число других тестов, которые должны быть разработаны для разумного тестирования.
Покрывает значительную часть других возможных тестов, что в некоторой степени свидетельствует о наличии или отсутствии ошибки до и после ограниченного множества тестов.
Эквивалентное разбиение.
Анализ граничных значений.
Анализ причинно-следственных связей.
Предположение об ошибке.
Рассмотрим подробнее каждый из этих методов:
Эквивалентное разбиение
Основу метода составляют два положения:
Исходные данные необходимо разбить на конечное число классов эквивалентности. В одном классе эквивалентности содержатся такие тесты, что если один тест из класса эквивалентности обнаруживает некоторую ошибку, то и любой другой тест из этого класса эквивалентности должен обнаруживать эту же ошибку.
Каждый тест должен включать, по возможности, максимальное количество классов эквивалентности, чтобы минимизировать общее число тестов.
Разработка тестов этим методом осуществляется в два этапа: выделение классов эквивалентности и построение теста.
Классы эквивалентности выделяются путём выбора каждого входного условия, которые берутся с помощью технического задания или спецификации и разбиваются на две и более группы. Для этого используется следующая таблица:
Входное условие Правильные классы эквивалентности Неправильные классы эквивалентности
' ' '
Выделение классов эквивалентности является эвристическим способом, однако существует ряд правил:
Если входное условие описывает область значений, например «Целое число принимает значение от 0 до 999», то существует один правильный класс эквивалентности и два неправильных.
Если входное условие описывает число значений, например «Число строк во входном файле лежит в интервале (1..6)», то также существует один правильный класс и два неправильных.
Если входное условие описывает множество входных значений, то определяется количество правильных классов, равное количеству элементов в множестве входных значений. Если входное условие описывает ситуацию «должно быть», например «Первый символ должен быть заглавным», тогда один класс правильный и один неправильный.
Если есть основание считать, что элементы внутри одного класса эквивалентности могут программой трактоваться по-разному, необходимо разбить данный класс на подклассы. На этом шаге тестирующий на основе таблицы должен составить тесты, покрывающие собой все правильные и неправильные классы эквивалентности. При этом составитель должен минимизировать общее число тестов.
Определение тестов:
Каждому классу эквивалентности присваивается уникальный номер.
Если еще остались не включенные в тесты правильные классы, то пишутся тесты, которые покрывают максимально возможное количество классов.
Если остались не включенные в тесты неправильные классы, то пишут тесты, которые покрывают только один класс.
Анализ граничных значений
Граничные условия — это ситуации, возникающие на высших и нижних границах входных классов эквивалентности.
Анализ граничных значений отличается от эквивалентного разбиения следующим:
Выбор любого элемента в классе эквивалентности в качестве представительного осуществляется таким образом, чтобы проверить тестом каждую границу этого класса.
При разработке тестов рассматриваются не только входные значения (пространство входов), но и выходные (пространство выходов).
Метод требует определённой степени творчества и специализации в рассматриваемой задаче.
Существует несколько правил:
Построить тесты с неправильными входными данными для ситуации незначительного выхода за границы области значений. Если входные значения должны быть в интервале [-1.0 .. +1.0], проверяем −1.0, 1.0, −1.000001, 1.000001.
Обязательно писать тесты для минимальной и максимальной границы диапазона.
Использовать первые два правила для каждого из входных значений (использовать пункт 2 для всех выходных значений).
Если вход и выход программы представляет упорядоченное множество, сосредоточить внимание на первом и последнем элементах списка.
Анализ граничных значений, если он применён правильно, позволяет обнаружить большое число ошибок. Однако определение этих границ для каждой задачи может являться отдельной трудной задачей. Также этот метод не проверяет комбинации входных значений.
Анализ причинно-следственных связей
Этапы построения теста:
Спецификация разбивается на рабочие участки.
В спецификации определяются множество причин и следствий. Под причиной понимается отдельное входное условие или класс эквивалентности. Следствие представляет собой выходное условие или преобразование системы. Здесь каждой причине и следствию присваивается номер.
На основе анализа семантического (смыслового) содержания спецификации строится таблица истинности, в которой последовательно перебираются всевозможные комбинации причин и определяются следствия для каждой комбинации причин.
Таблица снабжается примечаниями, задающими ограничения и описывающими комбинации, которые невозможны. Недостатком этого подхода является плохое исследование граничных условий.
Предположение об ошибке
Тестировщик с большим опытом выискивает ошибки без всяких методов, но при этом он подсознательно использует метод предположения об ошибке. Данный метод в значительной степени основан на интуиции. Основная идея метода состоит в том, чтобы составить список, который перечисляет возможные ошибки и ситуации, в которых эти ошибки могли проявиться. Потом на основе списка составляются тесты.
Тестирование по стратегии белого ящика — тестирование кода на предмет логики работы программы и корректности её работы с точки зрения компилятора того языка, на котором она писалась.
Тестирование по стратегии белого ящика, также называемое техникой тестирования, управляемой логикой программы, позволяет проверить внутреннюю структуру программы. Исходя из этой стратегии тестировщик получает тестовые данные путем анализа логики работы программы.
Техника Белого ящика включает в себя следующие методы тестирования:
Критерии покрытия операторов подразумевает выполнение каждого оператора программы по крайней мере один раз Другими словами,Такое выполнение программы при тестировании, при котором каждый оператор в программе должен быть выполнен хотя бы один раз.
Рассмотрим пример:
void func(int a, int b, float x) {
if ((a > 1) && (b == 0)) x = x/a; // пути с (истина) и b (ложь)
if (a == 2 || x > 1) x++; // пути e (истина) и d (ложь)
}
Чтобы выполнить каждый оператор не менее одного раза, нужно составить единственный тест со следующими значениями входных данных (a = 2 b = 0 x = 3).
Данный подход обладает недостатками. Вот, например, если в условии x > 1 программист допускает ошибку и пишет x < 1 или x > - 1, то с помощью нашего теста эта ошибка не будет обнаружена.
В соответствии с этим критерием необходимо составить такое число тестов, при которых каждое условие в программе примет как истинное значение, так и ложное значение.
Данный критерий является более эффективным по сравнению с предыдущими.
Записывается число тестов , достаточное для того, чтобы все возможные результаты каждого условия в решении были выполнены по крайней мере один раз.
Однако этот критерий не всегда приводит к выполнению каждого оператора по крайней мере один раз. Поэтому к этому критерию добавляется дополнительное условие, каждый оператор должен быть выполнен хотя бы один раз.
Если после составления тестов у нас останутся не покрытые операторы, то мы должны дополнить свой набор тестов таким образом чтобы каждый оператор выполняется не менее одного раза.
В соответствии с этим критерием необходимо составить тесты так, чтобы результаты каждого условия выполнялись хотя бы один раз, результаты каждого решения так же выполнялись хотя бы один раз, и каждый оператор должен быть выполнен хотя бы один раз.
Хотя метод и является достаточно мощным и позволяет находить достаточно большое количество ошибок, он имеет и недостатки:
не всегда можно проверить все условия
невозможно проверить условия, которые скрыты другими условиям
метод обладает недостаточной чувствительностью к ошибкам в логических выражениях
Этот критерий требует, чтобы все возможные комбинации результатов условий в каждом решении, а также каждый оператор выполнился по крайней мере один раз. В нашем примере должны быть покрыты восемь комбинаций:
а > 1, b = 0.
a > 1, b ≠ 0.
а ≤ 1, b = 0.
a ≤ l, b ≠ 0.
а = 2, x > 1.
a = 2, x ≤ l.
а ≠ 2, x > 1.
a ≠ 2, x ≤ l.
При этом условие на значение х налагает второй оператор if. Поскольку х может быть изменено до выполнения второго оператора, то значения, необходимые для проверки, следует восстановить, исходя из логики программы для того, чтобы найти соответствующие входные значение.
Для покрытия этих восьми комбинаций достаточно 4 теста.
a = 2; b = 0; x = 4 a—-c—-e
a = 0; b = 0; x = 0 a—-b—-d
a = 2; b = 1; x = 0 a—-b—-e
a = 0; b = 1; x = 2 a—-b—-e
(Заметим, что эти 4 теста не покрывают всех путей, они пропускают путь а—-с—-d.)
Таким образом, для программ, содержащих только одно условие на каждое решение, минимальным является критерий набора тестов которого:
вызывает выполнение всех результатов каждого решения, по крайней мере, один раз
выполняет каждый оператор по крайней мере один раз.
Для программ содержащих более одного условия минимальный критерий состоит из набора тестов, вызывающих выполнение всех возможных комбинаций результатов условий и выполняющий каждый оператор минимум один раз.
Давайте вспомним, в чем же основное отличие черного и белого ящиков. Эти методы отличаются способом работы с приложением:
• При черном ящике мы работаем только с функциональностью, используя поток входных и выходных данных, не влезая в структуру и код самого приложения. Образно говоря, мы работаем с черным ящиком, в который засовываем входные данные, он с ними что-то делает (мы не знаем, как именно) и получаем данные на выходе.
Тестирование «черного ящика» направлено на проверку поведения программного обеспечения и его внешних проявлений. Оно нацелено на проверку ожидаемого поведения приложения или программы с точки зрения конечного пользователя.
Для тестирования «белого ящика» необходимы знания структуры данных, логики ПО, алгоритмов работы программы, архитектуры программного кода. Данный анализ проводится с точки зрения разработчика.
Тестирование «белого ящика» и тестирование «черного ящика» являются неотъемлемой частью всего процесса тестирования программного обеспечения. По отдельности, они не дают предельно хороших результатов для сбалансированной работы компании по тестированию.
Тестирование «черного ящика» может быть менее эффективным при поиске ошибок, связанных с потоком данных на уровне исходного кода. А тестирование «белого ящика» менее эффективно в нахождении макро-уровневых ошибок в операционной системе, а также ошибок совместимости.
При работе с белым ящиком, нас не так интересуют входные и выходные данные, как то, что приложение делает с ними. Мы тестируем внутреннее устройство программы: операторы, решения, условия и т.д.
Недавно мы уже рассматривали тестирование черного и белого ящика, выяснили для чего они предназначены, их особенности и в чем разница между ними. Но методы тестирования делятся не только на «Инь» и «Ян». Сегодня мы поговорим о методе, основанном как на черном, так и на белом ящиках. И, как это не странно, поговорим мы о сером ящике.
Тестирование «серого ящика» - это сочетание тестирования «черного» и «белого ящика». Тестирование «серого ящика» используется для оценки проекта в рамках взаимодействия его индивидуальных компонентов.
Анализируя эти методы, можно прийти к выводу, что мы либо имеем доступ к устройству программы, либо не имеем. Каким же может быть средний вариант? Тестирование серым ящиком и есть тем самым средним вариантом.
По сути, тестируя серым ящиком – мы тестируем черным ящиком, но только при этом мы знаем внутреннюю структуру и принцип работы приложения. Знания о внутреннем устройстве программы, позволяют нам более точно подбирать входящие значения и проверять выходящие, тем самым покрывать тестами более обширную область возможных дефектов.
Знаниями для тестировщика при тестировании серым ящиком служит не только личный опыт работы с приложениями. Вся необходимая информация о работе и реализации каждого функционала содержится в документации (спецификация требований и т.п.), к которой доступ имеет любой тестировщик.
Ввиду особенностей метода серого ящика, существует ряд как преимуществ, так и недостатков. К преимуществам можно отнести:
• Наличие в методе положительных качеств и черного, и белого ящиков.
• Серый ящик основан на функциональной спецификации и архитектурном построении приложения, а не на исходном коде и двоичных файлах.
• Тестировщик сам разрабатывает сценарии тестирования, которые проверяют обработку типов данных, исключений и т.д.
• Несмотря на все преимущества, перечисленные выше, данный метод разграничивает тестирование тестировщиком и разработчиком.
К недостаткам можно отнести:
• Так как, тестировщик не имеет доступа к исходному коду и двоичным файлам, при тестировании серым ящиком возможно лишь частичное покрытие кода.
• В распределённых приложениях трудно связать выявления багов. Но, при этом, серый ящик наилучшим образом подходит для тестирования Web-приложений, так как при черном и белом ящиках более сложно определить проблемы, связанные с непрерывным потоком данных. Web-приложения состоят из множества элементов, как на программном, так и аппаратном уровне. Эти компоненты должны быть проверены в контексте разработки системы для оценивания их взаимодействия и функциональности.
Тестирование «серого ящика» наиболее подходит для тестирования веб-приложений, потому что для него необходимы высокоуровневая разработка, операционное окружение и условия совместимости.
Во время проведения анализа черного или белого ящика более сложно определить проблемы, связанные с непрерывным потоком данных. Специфические контекстные проблемы тестирования веб сайтов легче всего найти во время проверки серого ящика.
Веб-приложения состоят из множества элементов, как на программном, так и аппаратном уровне. Эти компоненты должны быть проверены в контексте разработки системы для оценивания их взаимодействия и функциональности.
Для тестирования «серого ящика» используются инструменты, нацеленные на понимание свойств приложения и окружения, с которым оно взаимодействует. Такой подход может быть использован для проверки «черного ящика» с целью увеличения продуктивности тестирования и производительности анализа багов.
С другой стороны, проверка «серого ящика» - это использование неполной или предполагаемой информации о структуре или дизайне для дальнейшей концентрации или расширения анализа «черного ящика».
Помните, что тестирование программного обеспечения более эффективно с хорошим пониманием поведения системы и ее архитектуры, процесса разработки продукта, требований приложения, типов ошибок.
Сам принцип тестирования серым ящиком является ничем иным, как расширенным тестированием черным ящиком, однако наличие понимания архитектуры программы позволяет поднести процесс тестирования на новый качественный уровень, что позволяет отнести серый ящик к отдельному методу.
http://dou.ua/forums/topic/13389/
