Основная идея в тестировании системы как черного ящика состоит в том, что все материалы, которые доступны тестировщику, – требования на систему, описывающие ее поведение, и сама система, работать с которой он может, только подавая на ее входы некоторые внешние воздействия и наблюдая на выходах некоторый результат. Все внутренние особенности реализации системы скрыты от тестировщика, – таким образом, система представляет собой "черный ящик", правильность поведения которого по отношению к требованиям и предстоит проверить.
С точки зрения программного кода черный ящик может представлять с собой набор классов (или модулей) с известными внешними интерфейсами, но недоступными исходными текстами.
Основная задача тестировщика для данного метода тестирования состоит в последовательной проверке соответствия поведения системы требованиям. Кроме того, тестировщик должен проверить работу системы в критических ситуациях – что происходит в случае подачи неверных входных значений. В идеальной ситуации все варианты критических ситуаций должны быть описаны в требованиях на систему и тестировщику остается только придумывать конкретные проверки этих требований. Однако в реальности в результате тестирования обычно выявляется два типа проблем системы.
· Несоответствие поведения системы требованиям
· Неадекватное поведение системы в ситуациях, не предусмотренных требованиями.
Отчеты об обоих типах проблем документируются и передаются разработчикам. При этом проблемы первого типа обычно вызывают изменение программного кода, гораздо реже – изменение требований. Изменение требований в данном случае может потребоваться из-за их противоречивости (несколько разных требований описывают разные модели поведения системы в одной и той же самой ситуации) или некорректности (требования не соответствуют действительности).
Проблемы второго типа однозначно требуют изменения требований ввиду их неполноты – в требованиях явно пропущена ситуация, приводящая к неадекватному поведению системы. При этом под неадекватным поведением может пониматься как полный крах системы, так и вообще любое поведение, не описанное в требованиях.
Тестирование черного ящика называют также тестированием по требованиям, т.к. это единственный источник информации для построения тест-плана.
Тестирование стеклянного (белого) ящика
При тестировании системы как стеклянного ящика тестировщик имеет доступ не только к требованиям к системе, ее входам и выходам, но и к ее внутренней структуре – видит ее программный код.
Доступность программного кода расширяет возможности тестировщика тем, что он может видеть соответствие требований участкам программного кода и определять тем самым, на весь ли программный код существуют требования. Программный код, для которого отсутствуют требования, называют кодом, не покрытым требованиями. Такой код является потенциальным источником неадекватного поведения системы. Кроме того, прозрачность системы позволяет углубить анализ ее участков, вызывающих проблемы – часто одна проблема нейтрализует другую, и они никогда не возникают одновременно.
Тестирование моделей
Тестирование моделей находится несколько в стороне от классических методов верификации программного обеспечения. Причина прежде всего в том, что объект тестирования – не сама система, а ее модель, спроектированная формальными средствами. Если оставить в стороне вопросы проверки корректности и применимости самой модели (считается, что ее корректность и соответствие исходной системе могут быть доказаны формальными средствами), то тестировщик получает в свое распоряжение достаточно мощный инструмент анализа общей целостности системы. На модели можно создать такие ситуации, которые невозможно создать в тестовой лаборатории для реальной системы. Работая с моделью программного кода системы, можно анализировать его свойства и такие параметры системы, как оптимальность алгоритмов или ее устойчивость.
Однако тестирование моделей не получило широкого распространения именно из-за трудностей, возникающих при разработке формального описания поведения системы. Одно из немногих исключений – системы связи, алгоритмический и математический аппарат которых достаточно хорошо проработан.
Анализ программного кода (инспекции)
Во многих ситуациях тестирование поведения системы в целом невозможно – отдельные участки программного кода могут никогда не выполняться, при этом они будут покрыты требованиями. Примером таких участков кода могут служить обработчики исключительных ситуаций. Если, например, два модуля передают друг другу числовые значения и функции проверки корректности значений работают в обоих модулях, то функция проверки модуля-приемника никогда не будет активизирована, т.к. все ошибочные значения будут отсечены еще в передатчике.
В этом случае выполняется ручной анализ программного кода на корректность, называемый также просмотрами или инспекциями кода. Если в результате инспекции выявляются проблемные участки, то информация об этом передается разработчикам для исправления наравне с результатами обычных тестов.
Работа тестера
Тестер призван обеспечить отличное качество программного продукта, включая и самые ранние этапы его разработки.
Условно можно разделить тестеров на альфа-тестеров и бета-тестеров. Альфа – это те, кто работает над программой совместно с программистами (командой), начиная с рождения продукта. Бета-тестеры, как правило, являются конечными "оценщиками". Они находят ошибки в бета-версиях программ, чтобы к моменту выхода релиза продукт был в идеальном состоянии и не вызывал у пользователей неудобств.
Основа работы бета-тестера – не только отыскать ошибку в программе, но и суметь ее подробно описать.
Вопросы
1. Как называется процесс, при котором выполняется интенсивное использование программной системы с целью выявления максимального числа ошибок в его работе, для их устранения перед выходом продукта на рынок?
1:бета-тестирование
2:альфа-тестирование
3:Тестирование «белого ящика»
4:сквозное тестирование
2. Как называется деятельность, направленная на обнаружение и исправление ошибок в программной системе:
1:отладка
2:тестирование
3:рефакторинг
4:демонстрация
3. Что означает положительный результат при тестировании программных систем:
1:ошибки найдены
2:ошибки исправлены
3:ошибки не найдены
4:есть замечания
4. Как называется тестирование, при котором выявляется, что сделанные изменения не повлияли на функциональность предыдущей версии:
1:Регрессионное тестирование
2:Системное тестирование
3:Тестирование «белого ящика»
4:Тестирование «черного ящика»
5. Как называется тестирование, при котором разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО:
1:Тестирование «белого ящика»
2:Тестирование «черного ящика»
3:Системное тестирование
4:Регрессионное тестирование
