Этот критерий требует, чтобы все возможные комбинации результатов условий в каждом решении, а также каждый оператор выполнился по крайней мере один раз. В нашем примере должны быть покрыты восемь комбинаций:
1. а 1, b = 0.
2. a 1, b ? 0.
3. а ? 1, b = 0.
4. a ? l, b ? 0.
5. а = 2, x 1.
6. a = 2, x ? l.
7. а ? 2, x 1.
8. a ? 2, x ? l.
При этом условие на значение x налагает второй оператор if. Поскольку x может быть изменено до выполнения второго оператора, то значения, необходимые для проверки, следует восстановить, исходя из логики программы для того, чтобы найти соответствующие входные значение.
Для покрытия этих восьми комбинаций достаточно 4 теста.
1. a = 2; b = 0; x = 4 a—-c—-e
2. a = 0; b = 0; x = 0 a—-b—-d
3. a = 2; b = 1; x = 0 a—-b—-e
4. a = 0; b = 1; x = 2 a—-b—-e
Заметим, что эти 4 теста не покрывают всех путей, они пропускают путь а—с—d.
Таким образом, для программ, содержащих только одно условие на каждое решение, минимальным является критерий набора тестов, который:
1. вызывает выполнение всех результатов каждого решения, по крайней мере, один раз
2. выполняет каждый оператор по крайней мере один раз.
Для программ, содержащих более одного условия, минимальный критерий состоит из набора тестов, вызывающих выполнение всех возможных комбинаций результатов условий и выполняющий каждый оператор минимум один раз.
Структурные критерии
Структурные критерии используют модель программы в виде белого ящика, что предполагает знание исходного текста программы или спецификации программы в виде потокового графа управления. Структурная информация понятна и доступна разработчикам подсистем и модулей приложения, поэтому данный класс критериев часто используется на этапах модульного и интеграционного тестирования (Unit testing, Integration testing).
Структурные критерии базируются на основных элементах УГП, операторах, ветвях и путях.
- Условие критерия тестирования команд (критерий С0) — набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза. Это слабый критерий, он, как правило, используется в больших программных системах, где другие критерии применить невозможно.
- Условие критерия тестирования ветвей(критерий С1) — набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза. Это достаточно сильный и при этом экономичный критерий, поскольку множество ветвей в тестируемом приложении конечно и не так уж велико. Данный критерий часто используется в системах автоматизации тестирования.
- Условие критерия тестирования путей (критерий С2) — набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раза. Если программа содержит цикл (в особенности с неявно заданным числом итераций), то число итераций ограничивается константой (часто — 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 (ложь)
}
Тестовый набор из одного теста, удовлетворяет критерию команд (C0):
(a=2, b=0, x=5) покрывает все операторы трассы (1-2-3-4-5-6)
Тестовый набор из двух тестов, удовлетворяет критерию ветвей (C1):
(a=2, b=0, x=5), (a=3, b=1, x=5) добавляет 1 тест к множеству тестов для С0 и трассу 1-2-4-6. Трасса 1-2-3-4-5-6 проходит через все ветви достижимые в операторах if при условии true, а трасса 1-2-4-6 через все ветви, достижимые в операторах if при условии false.
Тестовый набор из четырех тестов, удовлетворяет критерию путей (C2):
(a=2, b=0, x=5), (a=3, b=1, x=5),(a=3, b=0, x=2), (a=2, b=1, c=5)
Критерий путей С2 проверяет программу более тщательно, чем критерии — C1, однако даже если он удовлетворен, нет оснований утверждать, что программа реализована в соответствии со спецификацией.
(a=2, b=0, x=5), (a=3, b=1, x=5), (a=3, b=0, x=2), (a=2, b=1, x=5)
Если вместо а1 будет a?1, то тесты не выявят эту ошибку.
Аналогично, если вместо ((a==2) || (x1)) будет (( a==2) (x1)).
Структурные критерии не проверяют соответствие спецификации, если оно не отражено в структуре программы. Поэтому при успешном тестировании программы по критерию C2 мы можем не заметить ошибку, связанную с невыполнением некоторых условий спецификации требований.
Серый ящик
По сути, тестируя серым ящиком мы тестируем черным ящиком, но только при этом мы знаем внутреннюю структуру и принцип работы приложения. Знания о внутреннем устройстве программы, позволяют нам более точно подбирать входящие значения и проверять выходящие, тем самым покрывать тестами более обширную область возможных дефектов.
Знаниями для тестировщика при тестировании серым ящиком служит не только личный опыт работы с приложениями. Вся необходимая информация о работе и реализации каждого функционала содержится в документации (спецификация требований и т.п.), к которой доступ имеет любой тестировщик.
Ввиду особенностей метода серого ящика, существует ряд как преимуществ, так и недостатков.
К преимуществам можно отнести:
• Наличие в методе положительных качеств и черного, и белого ящиков.
• Серый ящик основан на функциональной спецификации и архитектурном построении приложения, а не на исходном коде и двоичных файлах.
•Тестировщик сам разрабатывает сценарии тестирования, которые проверяют обработку типов данных, исключений и т.д.
Несмотря на все преимущества, перечисленные выше, данный метод разграничивает тестирование тестировщиком и разработчиком.
Кнедостаткамможно отнести:
• при тестировании серым ящиком возможно лишь частичное покрытие кода, так как тестировщик не имеет доступа к исходному коду и двоичным файлам.
Но при этом серый ящик наилучшим образом подходит для тестирования Web-приложений, так как при черном и белом ящиках сложнее определить проблемы, связанные с непрерывным потоком данных. Web-приложения состоят из множества элементов, как на программном, так и аппаратном уровне. Эти компоненты должны быть проверены в контексте разработки системы для оценивания их взаимодействия и функциональности.
Сам принцип тестирования серым ящиком является ничем иным, как расширенным тестированием черным ящиком, однако наличие понимания архитектуры программы позволяет поднести процесс тестирования на новый качественный уровень, что позволяет отнести серый ящик к отдельному методу.
Заключение
В данной работе:
- изучено тестирование по стратегии белого и серого ящиков;
- рассмотрены методы тестирования данных стратегий белого ящика;
Таким образом, ни структурное, ни функциональное тестирование не может быть исчерпывающим. Чтобы увеличить процент обнаружения ошибок при проведении функционального и структурного тестирования используют средства автоматизации тестирования.
Литература
1. Теория тестирования программного обеспечения [Электронный ресурс]. – Режим доступа: http://alexproger.narod.ru
2. Тестирование по стратегии белого ящика [Электронный ресурс]. – Режим доступа: https://ru.wikipedia.org
3. Тестирование серого ящика [Электронный ресурс]. – Режим доступа:http://tpl-it.wikispaces.com
4. Тестирование методом cерого ящика [Электронный ресурс]. – Режим доступа: http://qalight.com.ua
5. Лекция 3: Критерии выбора тестов [Электронный ресурс]. – Режим доступа: http://www.intuit.ru
