Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
трпп_2012.docx
Скачиваний:
63
Добавлен:
30.08.2019
Размер:
727.99 Кб
Скачать

12 Методы тестирования программных продуктов: «стеклянный ящик», «черный ящик»

Тестирование “черного ящика” и тестирование “стеклянного ящика” - являются динамическими. Программа запускается, вводятся данные, и программист или тестировщик анализирует результат. Разница только в том, на какой информации основывается подбор тестов.

При статическом тестировании программный код вообще не выполняется - он тестируется только путем логического анализа. Для статического анализа существует множество инструментальных средств. Самое известное из них - компилятор. Встретив синтаксическую ошибку или недопустимую операцию, компилятор выдает соответствующее сообщение. Ряд полезных сообщений выдает и компоновщик - о повторяющихся именах переменных и других объектов, ссылках на необъявленные переменные и функции.

Статический анализ программы может выполняться и людьми. Они читают исходный код, возможно, обсуждают его, и, как правило, находят достаточно много ошибок.

При тестировании "стеклянного ящика" тестировщик (как правило, это программист) разрабатывает тесты, основываясь на знании исходного кода, к которому он имеет полный доступ. В результате он получает следующие преимущества:

Направленность тестирования. Программист может тестировать программу по частям, разработать специальные тестовые подпрограммы, которые вызывают тестируемый модуль и передают ему интересующие программиста данные. Отдельный модуль гораздо легче протестировать именно как "стеклянный ящик".

Полный охват кода. Программист всегда может определить, какие именно фрагменты кода работают в каждом тесте. Он видит, какие еще ветви кода остались не протестированными, и может подобрать условия, в которых они будут выполнены.

Управление потоком. Программист всегда знает, какая функция должна выполняться в программе следующей и каким должно быть ее текущее состояние. Чтобы выяснить, работает ли программа так, как он думает, программист может включить в нее отладочные команды, отображающие информацию о ходе ее выполнения, или воспользоваться для этого отладчиком.

Отслеживание целостности данных. Программисту известно, какая часть программы должна изменять каждый элемент данных. Отслеживая состояние данных (с помощью того же отладчика), он может выявить такие ошибки, как изменение данных не теми модулями, их неверная интерпретация или неудачная организация. Программист может и самостоятельно автоматизировать тестирование.

Внутренние граничные точки. В исходном коде видны те граничные точки программы, которые скрыты от взгляда "извне". Например, для выполнения определенного действия может быть использовано несколько совершенно различных алгоритмов, и, не заглянув в код, невозможно определить, какой из них выбрал программист. Еще одним типичным примером может быть проблема переполнения буфера, используемого для временного хранения входных данных. Программист сразу может сказать, при каком количестве данных буфер переполнится, и ему не нужно при этом проводить тысячи тестов.

Тестирование, определяемое выбранным алгоритмом. Для тестирования обработки данных, использующей очень сложные вычислительные алгоритмы, могут понадобиться специальные технологии. В качестве классических примеров можно привести преобразование матрицы и сортировку данных. Тестировщику нужно точно знать, какие алгоритмы используются, и обратиться к специальной литературе.

Тестирование "стеклянного ящика" можно рассматривать как часть процесса программирования. Программисты выполняют эту работу постоянно, тестируют каждый модуль после его написания, а затем еще раз после интеграции его в систему.

При тестировании “черного ящика” программа рассматривается как объект, внутренняя структура которого неизвестна.

Тестировщик вводит данные и анализирует результат, но, как именно работает программа, он не знает. Подбирая тесты, специалист ищет интересные с его точки зрения входные данные и условия, которые могут привести к нестандартным результатам. Т.е ищутся ошибки, составляются о них отчеты, затем рассматривается новая версия программы, и снова ищутся ошибки. Находятся старые ошибки, не замеченные на первом этапе, и новые, появившиеся после доработки.

На ранних стадиях тестирования исправленные версии программы могут поступать каждые несколько часов или дней. Поэтому среди специалистов распространена практика не принимать новую версию, пока не будет самым тщательным образом протестирована предыдущая. Такое полное тестирование очередной версии с составлением итогового отчета обо всех известных проблемах и всех найденных в этой версии ошибках называют полным циклом.

Руководители проектов часто рассчитывают ограничиться двумя циклами тестирования: в первом выявить все ошибки, а во втором убедиться, что они исправлены. Но на самом деле для тестирования может понадобиться порядка восьми циклов, а если на каждом из них тестировать программу менее тщательно - тогда от 20 до 30.

Стандартная процедура тестирования “черного ящика”

Планирование. Тестирование программного продукта начинается с планирования: определяется стратегия, разрабатываются серии тестов, распределяются между сотрудниками задания. Начинать планирование можно сразу после того, как команда проектировщиков выработает требования к программному продукту. Однако чаще подробное планирование начинается на первом цикле тестирования, когда перед вами готовый программный продукт.

Приемочное тестирование. При поступлении каждой новой версии программного продукта тестировщики прежде всего проверяют, достаточно ли она стабильна. Если она “обрушивается” при малейшей провокации, проверять её не стоит. Такое первое беглое тестирование называют приемочным или квалификационным.

Лучше всего, если приемочные тесты будут стандартизированы. Тогда их копии можно передать программистам, чтобы те проводили их сами и не сдавали вам программы раньше времени. Это позволит избежать возвратов тестировщиками неработающих программ.

Приемочные тесты должны быть короткими. В них должны проверяться только основные функции и основные данные. Если программа не пройдет даже такой тест, вы с полной уверенностью сможете утверждать, что эта ее версия никуда не годится.

Проверка стабильности программы. Насколько стабильна полученная вами версия программы? Сколько циклов тестирования она выдержит - четыре или 24? В этом случае ваша задача состоит не в поиске ошибок, а в определении самых ненадежных частей программы. Начинается работа с изучения прилагаемого к программе руководства - в нем должны быть описаны все функции программы, а если повезет, еще и приведены простые и наглядные примеры. Проведите еще несколько тестов, на которых, как вам кажется, программа должна сбоить. В конце такого оценочного тестирования у вас должно сложиться определенное представление о том, с чем вы имеете дело: сколько в программе ошибок и насколько тяжело будет ее протестировать.

Функциональное и системное тестирование, сверка и аттестация продукта. Когда программный продукт готов и протестирован, он должен пройти ряд завершающих тестов. Прежде всего, должно быть проведено функциональное тестирование, при котором продукт сверяется с внешней спецификацией.

Затем программа сверяется с опубликованной печатной документацией ‑ пользовательскими (тестирование целостности) и системными (системное тестирование) требованиями. Эти две процедуры носят название аттестационного тестирования.

Разработчик не может предугадать, как заказчик будет реально использовать ПП. Для обнаружения ошибок, которые способен найти только конечный пользователь, используют процесс, включающий альфа- и бета-тестирование.

Альфа-тестирование проводится заказчиком в организации разработчика. Разработчик фиксирует все выявленные заказчиком ошибки и проблемы использования.

Бета-тестирование проводится конечным пользователем в организации заказчика. Разработчик в этом процессе участия не принимает. Фактически, бета-тестирование — это реальное применение ПП в среде, которая не управляется разработчиком. Заказчик сам записывает все обнаруженные проблемы и сообщает о них разработчику. Бета-тестирование проводится в течение фиксированного срока (около года). По результатам выявленных проблем разработчик изменяет ПП и тем самым подготавливает продукт полностью на базе заказчика. На этом этапе с программой работают ее потенциальные пользователи. Они эксплуатируют программу и присылают или высказывают вам свои замечания.

Вопросы для самопроверки:

  1. Определите понятие тестирования.

  2. Что такое тест? Поясните содержание процесса тестирования.

  3. Какие задачи решает тестирование?

  4. Каких задач не решает тестирование?

  5. Какие принципы тестирования вы знаете? В чем их отличие друг от друга?

  6. В чем состоит суть тестирования «черного ящика»?

  7. В чем состоит суть тестирования «стеклянного ящика»?

  8. Каковы особенности тестирования «стеклянного ящика»?

  9. Какие недостатки имеет тестирование «стеклянного ящика»?

  10. Какие достоинства имеет тестирование «стеклянного ящика»?

  11. Каковы особенности тестирования методом «черного ящика»?

  12. Какие категории ошибок выявляет тестирование методом «черного ящика»?

  13. Какие достоинства имеет тестирование методом «черного ящика»?