Высокоуровневое тестирование

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

Разработка ПО в

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

кафедра ВСиС Самощенков Г.А.

Высокоуровневое тестирование

общие цели, которые должен реализовать разрабатываемый продукт;
кафедра ВСиС Самощенков Г.А.
Процесс

разработки ПО

Клиент

Требования

2) Перевод в формулировки конкретных целей путём оценки их осуществимости, а также временных и денежных затрат; при этом устраняются противоречия между требованиями и устанавливаются необходимые приоритеты и компромиссы;

Цели

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

Внешняя спецификация

др.), а не обычное приложение, то следующий шаг – проектирование

системы. На данном этапе систему разбивают на отдельные программы, компоненты или подсистемы и описывают их интерфейсы.

кафедра ВСиС Самощенков Г.А.

Процесс разработки ПО

Проект системы

5) Проектирование структуры программы или программ путём определения функции каждого модуля, иерархической структуры модулей, а также интерфейсов модулей.

Проект структуры программы

6) Разработка точной спецификации, определяющей функции и интерфейсы каждого модуля.

Спецификация интерфейсов модулей

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

Код

нужна программа;
Цели устанавливают, что именно и насколько хорошо должна делать

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

кафедра ВСиС Самощенков Г.А.

Процесс разработки ПО

и преобразования информации) появляются большинство ошибок.

Три подхода к уменьшению

количества ошибок на данных этапах:
1) Повысить качество разработки каждого этапа;

кафедра ВСиС Самощенков Г.А.

Процесс разработки ПО

разработки, отдельной стадии верификации результатов

интерфейсов модулей
Вер.
Вер.
Вер.
Вер.
Вер.
Вер.
Вер.
Приёмочное тестирование
Системное тестирование
Функциональное тестирование
Интеграционное тестирование
Модульное тестирование
Тестирование установки

процессы разработки, т.е. фокусировать каждый процесс тестирования на вполне определенном

этапе преобразования информации в другую форму и, таким образом, на определённом классе ошибок.
Цикл тестирования структурно встраивается в модель цикла разработки, т.е. на каждом этапе возможно установить взаимно однозначное соответствие между процессами разработки и тестирования. Например:
Цель модульного теста – найти расхождения между характеристиками модулей программы и спецификации их интерфейсов;
Цель функционального теста – продемонстрировать, что программа не соответствует внешним спецификациям;

кафедра ВСиС Самощенков Г.А.

Процесс разработки ПО

и локализацию ошибок. Т.е. мы изначально уверены, что ошибки присутствуют.

В случае, если тестировщик уверен, что ошибок нет, то тестирование будет изначально не полным.
Преимущества 3-го подхода в том, что он позволяет избежать избыточного ненужного тестирования и в то же время исключает возможность пропуска большого числа классов ошибок.
Недостатки такого подхода – использование возможно лишь на крупных проектах, для которых присутствует контрактная документация, ТЗ, возможно широкое применение.
Для небольших программ зачастую достаточно функционального тестирования.

кафедра ВСиС Самощенков Г.А.

Процесс разработки ПО

программы и внешней спецификацией.
Внешняя спецификация – это точное описание поведения

программы с точки зрения конечного пользователя.
Выполняется в рамках стратегии «черного ящика»;
Ожидается, что выполнено модульное тестирование;
Выполнению предшествует анализ спецификации с целью составления наборов тестов;

кафедра ВСиС Самощенков Г.А.

Функциональное тестирование

первоначально сформулированными для неё целями.
Системное тестирование не ограничивается только системами.

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

кафедра ВСиС Самощенков Г.А.

Системное тестирование

внешней спецификации;
Нельзя использовать внешнюю спецификацию для основания системного тестирования, поскольку

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

кафедра ВСиС Самощенков Г.А.

Системное тестирование

взаимодействия с различными частями системы (операционной системой, оборудованием либо связи

между различными системами).
Два уровня:
Компонентный интеграционный уровень. Проверяется взаимодействие между компонентами системы после проведения модульного тестирования.
Системный интеграционный уровень. Проверяется взаимодействие между разными системами после проведения системного тестирования.

кафедра ВСиС Самощенков Г.А.

Интеграционное тестирование

и затем тестируются. После чего собирается следующий уровень модулей для

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

кафедра ВСиС Самощенков Г.А.

Интеграционное тестирование

вместе в виде законченной системы или ее основной части, и

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

кафедра ВСиС Самощенков Г.А.

Интеграционное тестирование

которого выявить ошибки в процессе установки программы.
Не входит в этап

разработки ПО;
Опытный разработчик всегда сам выполняет предварительное приёмочное тестирование.