Тестирование по требованиям или тестирование «черного ящика» подразумевает неиспользование сведений о структуре исходного кода. Все тестовые примеры составляются только на основе требований, т.е. мы не видим, что находится внутри SUT и как оно работает. Единственное, что доступно — это то, что SUT должно делать, внешние эффекты поведения программного обеспечения.
При тестировании «черного ящика» удобно использовать методы трех, пяти или семи точек. При тестировании по требованиям используется понятие «покрытие» требований тестами. Тест покрывает требования, если он полностью проверяет выполнение каждого отдельного требования. При этом возможны как случаи, когда для проверки одного требования необходимо несколько тестовых примеров, так и случаи, когда достаточно одного тестового примера для проверки нескольких требований.
Рассмотрим, например, следующее требование к функции умножения двух целых чисел.
Если входное значение хотя бы одного множителя выходит за гра-ницы диапазона [15 . 1500], то функция должна вернуть значение 0, в противном случае функция должна вернуть значение произведения двух множителей.
Тестирование методом черного, белого и серого ящиков
Для тестирования этого требования (если быть точнее, то двух требований) необходимо проверить значения множителей как из диа-пазона [15 . 1500], так и вне его.
Тесты для проверки значений из диапазона могут выглядеть, например, следующим образом.
В табл. 7.1 представлены все комбинации двух входов, каждый из которых принимает по три различных значения (метод трех точек), так как диапазон [15 . 1500] с точки зрения сложения чисел не имеет критических точек, кроме своих концов.
| Входы | Действия | Ожидаемый выход | |
| Множитель 1 | Множитель 2 | ||
| 15 | 15 | Вызов функции | 225 |
| 15 | 700 | Вызов функции | 10500 |
| 15 | 1500 | Вызов функции | 22500 |
| 700 | 15 | Вызов функции | 10500 |
| 700 | 700 | Вызов функции | 490000 |
| 700 | 1500 | Вызов функции | 1050000 |
| 1500 | 15 | Вызов функции | 22500 |
| 1500 | 700 | Вызов функции | 1050000 |
| 1500 | 1500 | Вызов функции | 2250000 |
| 14 | 14 | Вызов функции | |
| 1501 | 14 | Вызов функции | |
| 14 | 1501 | Вызов функции | |
| 14 | 700 | Вызов функции | |
| 700 | 14 | Вызов функции | |
| 1501 | 700 | Вызов функции | |
| 700 | 1501 | Вызов функции | |
Для проверки поведения функции за границами диапазона стоит проверить, например, значения 14 и 1501 для каждого входа.
Черный, белый, серый ящик. Методы тестирования / Урок 11 / Тестировщик с нуля
Необходимо отметить, что не всегда можно покрыть все требования по тем же причинам, по которым невозможно добиться полноты тестирования, поэтому не всегда возможно доказать правильность работы программы. Кроме того, некоторые требования могут быть так сформулированы, что их нельзя протестировать. Например, требования могут касаться алгоритмов работы (а алгоритмы не видны при тестировании «черного ящика») или каких-нибудь внутренних переменных, не доступных извне. Некоторые требования вообще могут оказаться некорректными при тестировании, хотя могли быть интуитивно понятны при разработке, например требование «программа должна иметь дружественный интерфейс» протестировать невозможно. Для исключения таких ситуаций необходимо уже на этапе составления требований формулировать их как можно более конкретно и однозначно.
Метод тестирования «черного ящика» выявляет все несоответствия между требованиями к ПО и поведением самого ПО.
7.4. Тестирование. Метод «белого ящика»
Тестирование по коду или тестирование «белого ящика» основывается на проверке кода SUT, когда в ходе выполнения SUT проверяется выполнение каждого блока кода. При тестировании «белого ящика» основная задача — это выполнение всего кода для проверки работоспособности всех его ветвей. При этом ставится задача покрытия кода тестами и рассматриваются разные уровни покрытия. Один из уровней покрытия (покрытие операторов) — это выполнение всех операторов, т.е. при выполнении всех тестовых примеров в итоге должны выполниться все операторы (не в каждом тестовом примере, а по результатам выполнения всех тестовых примеров).
Например, для написанного ниже фрагмента программы, где A, B и C рассматриваются как входные значения:
X = 0; if ((A<=B) || (A>C)) X = 5;
достаточно одного тестового примера (ТП1: A=1, B=2, C=3). В этом случае выполнятся все операторы. Но если программист допустил ошибку и неверно написал условие, например так:
if ((A<=B) || (A>B)) X = 5;
то тогда код будет работать неверно (переменной X всегда будет присваиваться значение 5), хотя показанный выше тестовый пример приведет к выполнению всех операторов и не выявит ошибки.
Для выявления таких ошибок требуется выполнить другой уровень покрытия — по условиям.
Покрытие по условиям требует проверок всех условий на TRUE/FALSE, т.е. каждое условие в ходе тестирования должно проверяться на оба возможных значения. Для покрытия по условиям приведенного примера кода необходимо уже два тестовых примера:
Эти тестовые примеры позволяют найти ошибку.
Существуют и другие виды покрытия [11, 12, 13].
Не все блоки кода всегда удается покрыть тестами. Это может быть связано с защитным программированием (когда входные значения функции проверяются на корректность, но передаются ей только корректные данные, так как передающая функция тоже проверяет их корректность); операторами выхода (закрывающая скобка «>» после оператора exit ); мертвым кодом (код, который заведомо никогда не выполняется).
Проверка таких блоков кода и анализ их «безопасности» может происходить без выполнения самого кода, в этом случае группа экспертов читает и анализирует программный код, делая выводы о существовании или несуществовании ошибок. Результаты подобного анализа могут установить причины появления непокрытого кода.
Одной из причин может быть несовершенство тест-плана. Другой — пробелы в требованиях. И в том и в другом случае сам тестируемый код может не требовать изменений, но должны быть дописаны новые требования или изменены уже существующие и/или расширен тест-план. В обоих случаях процесс верификации повторяется.
Источник: intuit.ru
Русские Блоги
Тестирование белого ящикаДизайн сценария использованияОдин из важнейших критериев оценки — охват кода. Когда дело доходит до освещения, каждый чувствует себя хорошо знакомым, но каковы общие покрытия? Каковы преимущества и недостатки каждого? Как мы можем свободно использовать его в дизайне сценария использования тестирования белого ящика? Сегодня я резюмирую несколько распространенных покрытий, их преимущества и недостатки.
В тестировании белого ящика существует шесть распространенных типов покрытия: покрытие предложений, покрытие решений, покрытие условий, покрытие решений / условий, покрытие комбинаций и покрытие пути. Давайте посмотрим, что это за разные типы покрытия.
Один, покрытие выписки (покрытие выписки)
Покрытие заявления,Как следует из названияЭто для операторов кода. Его смысл разработан намиПрецедентУбедитесь, что каждый оператор в программе выполняется хотя бы один раз. Обычно покрытие операторов считается «самым слабым покрытием», потому что оно рассматривает только покрытие операторов выполнения в коде без учета различных условий и ветвей, поэтому трудно найти проблемы в коде в реальном использовании. Приведи очень простой пример:
public int foo(int a,int b)
Это функция для нахождения частного двух чисел. Если мы разработаем следующий тестовый пример:
TestCase: a = 2, b = 1
В это время мы обнаружим, что покрытие кода функции достигло 100%, и разработанный случай может успешно пройти тест. Но, очевидно, у этой функции есть очевидная ошибка: когда b = 0, будет выброшено исключение.
Во-вторых, покрытие решений (Decision Coverage)
Покрытие решений также называется покрытием ветвей (Branch Coverage), что означает, что разработанный тестовый пример должен гарантировать, что каждая ветвь в тестируемой программе выполняется хотя бы один раз. Например, есть следующая блок-схема:
Для этого рисунка мы хотим достичь покрытия решений, мы можем разработать следующий случай:
TestCase1: a = 1, b = 1 (путь: ab)
TestCase2: a = -1, b = -1 (путь: acd)
TestCase3: a = 2, b = -1 (путь: ace)
Покрытие суждений сильнее, чем покрытие утверждений, и могут быть обнаружены некоторые проблемы, которые не могут быть обнаружены посредством покрытия утверждений. Но часто некоторые условия оценки состоят из нескольких логических условий. Оценка ветвления эквивалентна оценке окончательного результата всей комбинации, так что значение каждого условия будет игнорироваться, что приведет к пропуску части тестового пути.
В-третьих, покрытие условий (покрытие условий)
Условное покрытие отличается от покрытия ветвей.Тестовый пример, разработанный для условного покрытия, требует, чтобы каждое условие в каждом суждении получало возможное значение, то есть каждое условие имело по крайней мере одно истинное значение и одно ложное значение.
Все же возьмем приведенную выше блок-схему в качестве примера для иллюстрации. На рисунке выше присутствуют 4 условия:
Чтобы достичь цели условного покрытия, сценарии использования, которые мы разрабатываем, должны иметь в точке а:
Эти ситуации возникают, и в точке c:
Такие ситуации возникают. Теперь вы можете разработать следующие варианты использования:
TestCase1: a = 1, b = 1 (путь: ab)
TestCase1: a = -1, b = -1 (путь: acd)
TestCase1: a = -1, b = 0 (путь: ace)
TestCase1: a = 1, b = -1 (путь: ace)
Вообще говоря, покрытие условий сильнее, чем покрытие решений, потому что покрытие условий заставляет каждое условие в решении получить другой результат, который не может быть гарантирован. Однако условное покрытие также ошибочно, поскольку оно может гарантировать только то, что каждое условие получит другой результат, но не принимает во внимание результат суждения, поэтому иногда условное покрытие не гарантирует покрытия суждения.
4. Покрытие решений / условий
Покрытие условий суждения, грубо говоря, заключается в том, что разработанные нами тестовые примеры могут обеспечить выполнение всех возможных значений каждого условия в суждении хотя бы один раз (покрытие условий), а все результаты самого суждения должны быть выполнены хотя бы один раз (покрытие суждения). Нетрудно обнаружить, что покрытие условий суждения удовлетворяет как охвату суждения, так и охвату условий, что компенсирует их соответствующие недостатки, но покрытие условий суждения не учитывает комбинацию условий.
Пять, комбинированное покрытие (комбинированное покрытие условий ветвления)
Комбинированное покрытие также называется условным комбинированным покрытием. Это означает, что разрабатываемые нами тестовые примеры должны включать все возможные комбинации различных условий в каждом решении хотя бы один раз. Очевидно, что тестовые примеры, которые удовлетворяют охвату комбинацией условий, должны удовлетворять охвату суждения, охвату условий и охвату условий суждения.
Для упомянутой выше блок-схемы при выполнении покрытия условной комбинации мы можем разработать следующие варианты использования:
TestCase1: a = 1, b = 1 (путь: ab)
TestCase1: a = -1, b = -1 (путь: acd)
TestCase1: a = -1, b = 0 (путь: ace)
TestCase1: a = 1, b = -1 (путь: ace)
Покрытие комбинации условий может одновременно удовлетворять охвату суждения, условия и условия суждения, и охват относительно велик, но количество тестовых примеров, охватываемых комбинацией, относительно велико.
Шесть, покрытие пути
Покрытие путей означает, что разработанные нами тестовые примеры могут охватывать все возможные пути выполнения в программе. Этот метод покрытия может полностью покрыть программу тестовыми примерами, что превышает охват пяти упомянутых выше методов. Так обязательно ли этот метод лучший? Конечно, об этом нельзя сказать однозначно, и его минусы тожеОчевидный： Из-за необходимости охватить все возможные пути, нам нужно разработать очень большое количество более сложных тестовых случаев, количество вариантов использования будет экспоненциально расти. Таким образом, теоретически покрытие пути — это наиболее полное покрытие тестового примера, но на самом деле покрытие пути во многих случаях не очень удобно.
Выше кратко описаны принципы, а также плюсы и минусы нескольких различных методов логического покрытия. В реальных условиях для корректного использования метода покрытия кода тестирования белого ящика необходимо начать с анализа кода и исследования кода, по результатам которого можно выбрать один из вышеперечисленных методов или комбинацию нескольких методов. Создавайте эффективные тестовые примеры, чтобы максимально полно охватить каждый логический путь в коде.
Источник: russianblogs.com
Жизнь — это движение! А тестирование — это жизнь 🙂
Тестирование черного ящика — это когда мы не знаем, как система устроена внутри. У нас нет доступа к коду или мы не умеем его читать. Поэтому ориентируемся только на внешнее поведение или ТЗ.
Это начинающий автомобилист. Заглянуть под капот? Ой, там слишком страшно, будем верить приборам и точка.
Это основной вид тестирования, с которого все начинают. Перед тем, как залезть в код, стоит научиться писать тесты на основе сценариев использования и знаний про тест-дизайн и классы эквивалентности.
Если я сейчас открою любой сайт:
- http://software-testing.ru/
- http://www.ozon.ru
- http://users.bugred.ru/
И начну его тестировать: «А что, если платьюшко именно красное поискать? А красное с белым? А книгу по автору? А если спецсимволы вбить?», и так далее → это как раз тестирование черного ящика. Доступа к коду у меня нет, я просто проверяю, как программа работает.
У меня либо есть ТЗ (как в случае Users, вот тех задание), либо его нету, как в случае интернет-магазина или форума. Составляю тесты, выполняю через интерфейс, типичный black box.
Плюсы такого подхода — так как вы не знаете код, то не верите ничему на слово. Все проверяете по ТЗ, каждое слово. А бывает такое, что разработчик упустил в требованиях какое-то условие и просто его не сделал, или сделал, но не так, как надо. Если читать сам код, то все работает правильно. Но это не совсем то, что было нужно.
Белый ящик (white box testing)
Тестирование белого ящика — это когда у нас есть доступ к коду, и мы его тестируем. Читаем сам код (статическое тестирование), запускаем в дебаге, пишем автотесты.
Если сравнивать с автомобилистом, то тут уже не новичок, а прошаренный. Сломалось что-то? Нафиг приборы, сразу лезем под капот, где все устройство чуть ли не наизусть уже знаем. Роемся там, ищем причину.
Самостоятельно освоить белый ящик трудновато, обычно с ним сталкиваются уже на реальной работе. Но можете поискать проекты с открытым исходным кодом и тестировать их.
Как пример открытого проекта — Folks, его можно скачать, запустить, и даже написать свои автотесты, прогон которых как раз и будет тестированием самого кода, белого ящика. User interface у folks нет и не будет, так что тестирование черного ящика там недоступно.
Плюсы подхода — можно писать меньше тестов. Мы ведь знаем, что тут и тут будет работать одинаково, видим по коду. Но иногда настолько углубляемся в код, что читаем именно его, а не ТЗ, и можем пропустить какие-то баги (см плюсы черного ящика)
Серый ящик (gray box testing)
Тестирование серого ящика — это совмещение. Мы смотрим в код и понимаем, как он устроен. А потом открываем само приложение и проверяем, как этот код отображается уже в нем, но ориентируемся уже больше на ТЗ.
На примере автомобилиста это самый распространенный сценарий. Чтобы получить права, мы должны пройти специальный курс, на котором рассказывается, как устроена машина внутри → это знание кода, white box. Но потом мы начинаем кататься на своей машине и в основном ориентируемся на приборы → user interface, black box. При этом мы трактуем показания приборов на основе знаний кода.
Если говорить про тестирование, то это любое тестирование системы через интерфейс, когда у вас есть доступ к коду, но нет знаний разработчика. Да, вы можете подсмотреть в коде какие-то простейшие вещи: какой тип данных у этого значения, какие настройки у полей итд. Но вот потроха сложных методов остаются за гранью )))
В итоге мы вроде знаем, как это все устроено, но частично. Поэтому перепроверяем по черному ящику, где-то напишем чуть больше тестов для перестраховки. Вообще самый оптимальный метод тестирования: вы и в коде баги можете найти, и по ТЗ проверить!
Главное, чтобы доступ к коду дали, хотя бы частичный ツ
Хотя есть и другая версия — знание высокоуровневой структуры приложения: модулей, баз, например, но без доступа к коду. Или знание алгоритма, но опять же без доступа к собственно коду. Например, по псевдокоду.
Но смысл один: мы что-то из кода знаем, а что-то нет.
См также:
White/Black/Grey Box-тестирование — тоже хорошая статья на эту тему!
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Источник: okiseleva.blogspot.com