Цель данной книги - помочь читателям стать более квалифицированными и эффективными тестировщиками, помочь выбрать и построить тестовые сценарии, которые обнаружат намного больше дефектов при меньшем количестве используемых ресурсов.
В книге представлено довольно интересное определение тестирования серого ящика. Обычно нам говорят, что это тестирование, когда у нас нет полной информации о системе, но при этом ничего не говорят о методах тестирования серого ящика. У Ли Копланда серый ящик используется для выбора наиболее оптимальных методов тестирования черного ящика. То есть, мы вначале заглядываем в ящик, затем закрываем крышку и далее тестируем как обычный черный ящик.
При этом, тестирование белого ящика является стратегией, при которой тестовый сценарий основан на внутренних путях, структуре и реализации программного обеспечения.
Альтернативой проектированию программного обеспечения на основе требований, в данной книге рассмотрен еще один способ проектирования, названный оборонительным, который принимает любое входное значение и затем его обрабатывает. В случае, если значение не валидное, программа выдает сообщение об ошибке, иначе происходит обработка этого входного параметра.
Если разработчики не используют ни один из этих методов, и вообще не задумываются о взаимодействии модулей, ни на основе требований, ни с помощью обработки возможных ошибок, то главным источником ошибок будет интеграционное тестирования взаимодействия этих модулей.
В книге описано также множество примеров использования техники классов эквивалентности и техники граничных значений, показано, как тривиальные ошибки в программах и неправильно подобранный набор тестов могут привести к пропуску ошибочных вариантов работы программы.
Для сбора требований к системе, представляющих собой набор сложных бизнес-правил, предлагается использовать таблицы решений, на основе которых создаются проверочные тесты. Таблица решений включает действия, которые нужно предпринять при соблюдении каждой комбинации входных условий. При этом сочетание условий для каждого действия должно быть уникальным, иначе их нельзя будет сопоставить, если одному набору условий будет соответствовать несколько действий или ни одного.
На основе таблицы решений мы можем получить полное представление о поведении системы в компактной форме. Поэтому тест-кейсы можно получить непосредственно из таблицы решений. При тестировании правила создается не менее одного тест-кейса. Если входные условия бинарные, то достаточно протестировать по одному сочетанию значений. Если условие является диапазоном значений, то применяется дополнительно метод граничных значений.
Из таблицы решений можно исключать условия, не влияющие на выбор действия. Можно также объединять условия, если действие выполняется при их одновременном выполнении. Таким образом, таблица решений может быть оптимизирована с целью сокращения количества тестов. Но для проектирования тест-кейсов автор книги все-таки советует использовать не оптимизированную таблицу, чтобы избежать ошибок, которые могут быть допущены при оптимизации таблицы.
Конечно, это не все интересное, что можно подчерпнуть из данного учебника по тестированию. Остальной материал рассмотрим в дальнейших публикациях.
Что особенно понравилось в книге, так это доказательство каждого утверждения на основе примеров. Нет ни одной догмы, которая тут же не была бы проверена на корректность утверждения.
Подписывайтесь, чтобы не пропустить дальнейшее обсуждение техник тестирования и другой полезной литературы.