Мы, как тестировщики, знаем о различных видах тестирования ПО, таких как функциональное тестирование, нефункциональное тестирование, автоматизированное тестирование, Agile-тестирование, а также их подвидах и т.д.
Каждый из нас сталкивался с несколькими видами тестирования на своем пути. Возможно, о некоторых вы только слышали, а с другими уже удалось поработать, но не все QA знают обо всех существующих видах тестирования.
Каждый вид тестирования имеет свои особенности, преимущества и недостатки. В этом руководстве мы рассмотрим практически все виды тестирования, которые мы обычно используем в повседневных задачах.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туторилов, задач по автоматизации и книг по QA.
Содержание:
Различные виды тестирования ПО
На схеме представлена высокоуровневая классификация видов тестирования ПО.
Далее мы рассмотрим каждый вид тестирования в деталях с примерами.
Функциональное тестирование
Существует четыре основных типа функционального тестирования.
1. Unit-тестирование
Unit-тестирование (модульное тестирование) – это вид тестирования ПО, которое проводится для отдельного блока или компонента продукта с целью проверки его исправлений. Как правило, модульное тестирование проводится разработчиком на этапе разработки приложения. Каждый метод, функция, процедура или объект в модульном тестировании может рассматриваться как отдельный блок. Разработчики часто используют инструменты автоматизации тестирования, такие как NUnit, Xunit, JUnit для выполнения таких тестов.
Unit-тестирование важно, потому что мы можем найти больше дефектов на уровне unit-тестов.
Например, есть простое приложение калькулятор. Разработчик может написать модульный тест, чтобы проверить, может ли пользователь ввести два числа и получить правильную сумму для функции сложения.
a. Тестирование “белого ящика“
Тестирование “белого ящика” – это метод тестирования, при котором внутренняя структура или код приложения видны и доступны тестировщику. В этой технике легко найти лазейки в реализации приложения или ошибки в бизнес-логике. Покрытие утверждений и покрытие решений/ветвей являются примерами методов тестирования “белого ящика”.
b. Gorilla тестирование
Gorilla тестирование – это метод тестирования, при котором тестировщик и/или разработчик тщательно проверяет модуль приложения во всех аспектах. Горилла-тестирование проводится для проверки надежности вашего приложения.
Например, тестировщик тестирует веб-сайт компании по страхованию домашних животных, которая предоставляет услуги по покупке страхового полиса, бирки для животного и пожизненной подписки. Тестировщик может сосредоточиться на каком-либо одном модуле, допустим, на модуле страхового полиса, и тщательно протестировать его с помощью положительных и отрицательных тестовых сценариев.
2. Интеграционное тестирование
Интеграционное тестирование – это вид тестирования ПО, при котором два или более модулей приложения логически объединяются вместе и тестируются как единое целое. Этот вид тестирования направлен на поиск дефектов в интерфейсе, взаимодействии и потоках данных между модулями. При интеграции модулей в общую систему используется подход “сверху вниз” или “снизу вверх”.
Этот вид тестирования проводится при интеграции модулей одной системы или между разными системами. Например, пользователь покупает билет на самолет на сайте какой-либо авиакомпании. При покупке билета пользователь может видеть детали рейса и информацию об оплате, но детали рейса и обработка платежа – это две разные системы. Интеграционное тестирование должно быть проведено при интеграции сайта авиакомпании и системы обработки платежей.
а. Тестирование “серого ящика”
Как следует из названия, тестирование “серого ящика” представляет собой комбинацию тестирования “белого ящика” и тестирования “черного ящика”. Тестировщики имеют частичные знания о внутренней структуре или коде приложения.
3. Системное тестирование
Системное тестирование – это вид тестирования, при котором QA оценивает всю систему на соответствие заданным требованиям.
a. Сквозное тестирование (End to End тестирование)
Оно включает в себя тестирование приложения в ситуации, которая имитирует реальное использование, например, взаимодействие с базой данных, использование сетевых коммуникаций или взаимодействие с другим оборудованием, приложениями или системами, если это необходимо.
Например, QA тестирует веб-сайт страхования домашних животных. Сквозное тестирование включает в себя тестирование покупки страхового полиса, чипа, добавления другого питомца, обновления информации о кредитной карте на счетах пользователей, обновления информации об адресе пользователя, получения электронных писем с подтверждением заказа и документов полиса.
b. Тестирование “черного ящика”
Тестирование “черного ящика” – это техника тестирования ПО, при которой тестирование проводится без знания внутренней структуры, дизайна или кода тестируемой системы. QA должны сосредоточиться только на входных и выходных данных при разработке и выполнении тест-кейсов.
c. Smoke тестирование (дымовое тестирование)
Smoke-тестирование проводится для проверки того, что основные и критические функции тестируемой системы работают нормально на очень высоком уровне.
Всякий раз, когда команда разработчиков предоставляет новую сборку, команда QA проверяет ее и убеждается в отсутствии серьезных проблем. Команда также убеждается, что сборка стабильна, и далее проводится уже более детальное тестирование.
Например, QA тестирует сайт страхования домашних животных. Покупка страхового полиса, добавление другого питомца, предоставление котировок – все это основные и критически важные функции приложения. Smoke тестирование для этого сайта проверяет, что все эти функциональные возможности работают нормально, прежде чем проводить углубленное тестирование.
Санитарное тестирование проводится для проверки работоспособности новой функциональности или исправления ошибок. Этот вид тестирования проводится на стабильной сборке. Оно относится к подмножеству регрессионного тестирования.
Например, QA тестирует сайт страхования домашних животных. Изменилась скидка на покупку полиса для второго питомца. Тогда санитарное тестирование проводится только для модуля покупки страхового полиса.
e. Тестирование удачного пути (Happy path тестирование)
Цель тестирования удачного пути заключается в успешном тестировании приложения на положительных сценариях. Оно не ищет негативные или ошибочные условия. Основное внимание уделяется только корректным и положительным входным данным, с помощью которых приложение генерирует ожидаемый результат.
f. Monkey тестирование
Monkey тестирование проводится тестировщиком, предполагая, что приложение использует обезьяна, т.е. значения будут введены обезьяной без каких-либо знаний или понимания приложения.
Цель Monkey тестирования – проверить, не произойдет ли сбой приложения или системы при предоставлении случайных входных значений/данных. Monkey тестирование проводится случайным образом, сценарии тестирования не составляются, и нет необходимости знать
о полной функциональности системы.
4. Приемочное тестирование
Приемочное тестирование – это вид тестирования, при котором клиент/бизнес/заказчик тестирует ПО с помощью бизнес-сценариев в реальном времени.
Клиент принимает ПО только тогда, когда все его функциональности и возможности работают так, как ожидается. Это последняя фаза тестирования, после которой программный продукт выпускается в эксплуатацию. Его также называют пользовательским приемочным тестированием.
Альфа-тестирование – это вид приемочного тестирования, проводимого командой организации для выявления как можно большего количества дефектов перед релизом ПО для клиентов.
Например, сайт страхования домашних животных находится в стадии пользовательского приемочного тестирования. Команда альфа-тестировщиков будет выполнять сценарии в реальном времени, такие как покупка страхового полиса, покупка годовой подписки, изменение адреса, передача права собственности на животное таким же образом, как пользователь использовал бы реальный сайт. Команда может использовать тестовые данные для кредитной карты для обработки сценариев, связанных с оплатой.
Бета-тестирование – это вид тестирования ПО, которое проводится клиентами/заказчиками. Оно проводится в реальной среде перед выпуском продукта на рынок для реальных конечных пользователей.
Бета-тестирование проводится для того, чтобы убедиться, что в программном продукте нет серьезных сбоев, и он удовлетворяет бизнес-требованиям с точки зрения конечного пользователя. Бета-тестирование считается успешным, если клиент принимает разработанное ПО.
Обычно такое тестирование проводится конечными пользователями. Это окончательное тестирование, проводимое перед релизом приложения для коммерческих целей. Обычно бета-версия выпускаемого продукта ограничивается определенным количеством пользователей в конкретной области.
Таким образом, конечный пользователь использует ПО и делится отзывами с компанией. После этого компания принимает необходимые меры, прежде чем выпустить ПО в эксплуатацию по всему миру.
c. Эксплуатационное приемочное тестирование
Эксплуатационное приемочное тестирование системы проводится системными администраторами или техническими экспертами в production окружении. Цель эксплуатационного приемочного тестирования – убедиться, что системные администраторы могут обеспечить нормальную работу системы для пользователей в режиме реального времени.
Основное внимание при проведении эксплуатационного приемочного тестирования уделяется следующим моментам:
- Тестирование резервного копирования и восстановления.
- Установка, удаление, обновление ПО.
- Процесс восстановления в случае стихийного бедствия.
- Управление пользователями.
- Техническое обслуживание ПО.
Нефункциональное тестирование
Существует четыре основных вида нефункционального тестирования.
1. Тестирование безопасности
Это вид тестирования, выполняемый специальной командой. Любой взлом системы может привести к негативным последствиям.
Тестирование безопасности проводится для проверки того, насколько программное обеспечение, приложение или веб-сайт защищены от внутренних и/или внешних угроз. Это тестирование включает в себя проверку того, насколько ПО защищено от вредоносных программ, вирусов, насколько безопасны и надежны процессы авторизации и аутентификации.
Также проверяется, как ведет себя ПО при любой хакерской атаке и внедрении вредоносных программ и как поддерживается безопасность данных после такой хакерской атаки.
а. Тестирование на проникновение
Тестирование на проникновение или Pen testing – это вид тестирования безопасности, выполняемый в виде санкционированной кибератаки на систему с целью выявления слабых мест системы с точки зрения безопасности.
Тестирование на проникновение выполняется внешними подрядчиками, обычно известными как этичные хакеры. Поэтому его также называют этичным хакерством. Подрядчики выполняют различные операции, такие как SQL-инъекции, манипуляции с URL, повышение привилегий, истечение срока действия сессии, и предоставляют отчеты организации.
Примечания: Не проводите Pen-тесты на своем ноутбуке/компьютере. Всегда берите письменное разрешение на проведение пен-тестов.
2. Тестирование производительности
Тестирование производительности – это проверка стабильности и времени отклика приложения путем нагрузки.
Стабильность в этом контексте означает способность приложения выдерживать нагрузку. Время отклика – это то, насколько быстро приложение становится доступным для пользователей. Тестирование производительности проводится с помощью инструментов Loader.IO, JMeter, LoadRunner и т.д.
a. Нагрузочное тестирование
Нагрузочное тестирование – это тестирование стабильности и времени отклика приложения путем создания нагрузки, которая равна или немного меньше расчетного количества пользователей приложения.
Например, ваше приложение обрабатывает 100 пользователей одновременно со временем отклика 3 секунды, тогда нагрузочное тестирование может быть проведено путем приложения нагрузки, равной или меньшей 100 пользователям. Цель – проверить, что приложение отвечает в течение 3 секунд для всех пользователей.
b. Стресс-тестирование
Стресс-тестирование – это тестирование стабильности и времени отклика приложения путем создания нагрузки, превышающей расчетное количество пользователей приложения.
Например, ваше приложение одновременно обслуживает 1000 пользователей со временем отклика 4 секунды, тогда стресс-тестирование можно провести, применив нагрузку более 1000 пользователей. Протестируйте приложение с 1100, 1200, 1300 пользователями и обратите внимание на время отклика. Цель состоит в том, чтобы проверить стабильность приложения под нагрузкой.
c. Тестирование масштабируемости
Тестирование масштабируемости – это тестирование стабильности и времени отклика приложения путем создания нагрузки, превышающей расчетное количество пользователей приложения.
Например, ваше приложение обрабатывает 1000 пользователей одновременно со временем отклика 2 секунды, тогда тестирование масштабируемости может быть проведено путем приложения нагрузки более 1000 пользователей и постепенного увеличения количества пользователей, чтобы выяснить, где именно приложение дает сбой.
Допустим, мое приложение дает следующее время отклика:
- 1000 пользователей -2 сек
- 1400 пользователей -2 сек
- 4000 пользователей -3 сек
- 5000 пользователей -45 сек
- 5150 пользователей – сбой – Это точка, которую необходимо определить при тестировании масштабируемости.
d. Объемное тестирование (Flood тестирование)
Объемное тестирование – это тестирование стабильности и времени отклика приложения путем передачи большого объема данных в базу данных. По сути, проверяется способность базы данных обрабатывать большое количество данных.
e. Тестирование на выносливость (Soak тестирование)
Тестирование на выносливость – это тестирование стабильности и времени отклика приложения путем непрерывного создания нагрузки в течение длительного периода времени, чтобы убедиться, что приложение работает нормально.
Например, автомобильные компании проводят тестирование на выносливость, чтобы убедиться, что пользователи могут управлять автомобилями в течение нескольких часов без каких-либо проблем.
3. Юзабилити-тестирование
Юзабилити-тестирование – это тестирование приложения с точки зрения пользователя для проверки внешнего вида и удобства использования.
Например, есть мобильное приложение для биржевой торговли, и тестировщик проводит юзабилити-тестирование. Тестировщики могут проверить такие сценарии: легко ли управлять мобильным приложением одной рукой или нет, должна ли полоса прокрутки быть вертикальной, цвет фона приложения должен быть черным, а цена акции отображаться красным или зеленым цветом.
Основная идея юзабилити-тестирования такого приложения заключается в том, что как только пользователь открывает приложение, он должен получить представление о бизнес-ценности продукта.
а. Исследовательское тестирование
Исследовательское тестирование – это неформальное тестирование, проводимое командой QA. Целью такого тестирования является изучение приложения и поиск дефектов, существующих в приложении. Тестировщики используют знания о предметной области для тестирования приложения. Для руководства исследовательским тестированием используются различные концепции.
b. Кроссбраузерное тестирование
Кроссбраузерное тестирование – это тестирование приложения на различных браузерах, операционных системах, мобильных устройствах, чтобы оценить его внешний вид и производительность.
Зачем нам нужно кроссбраузерное тестирование? Ответ: разные пользователи используют разные операционные системы, разные браузеры и разные мобильные устройства. Цель компании – увеличить юзабилити приложения независимо от этих устройств.
Инструмент Browser stack предоставляет все версии всех браузеров и всех мобильных устройств для тестирования приложения. В целях обучения можно использовать бесплатную пробную версию, предоставляемую компанией Browser Stack на несколько дней.
c. Тестирование доступности
Цель тестирования доступности – определить, доступно ли программное обеспечение или приложение для людей с ограниченными возможностями.
Здесь под ограниченными возможностями подразумевается глухота, дальтонизм, умственная отсталость, слепота, пожилой возраст и другие группы особенностей. Проводятся различные проверки, такие как размер шрифта для инвалидов по зрению, цвет и контрастность для дальтоников и т.д.
4. Тестирование на совместимость
Это вид тестирования, при котором проверяется, как ПО ведет себя и работает в различных средах, веб-серверах, аппаратных средствах и сетевом окружении.
Тестирование на совместимость гарантирует, что ПО может работать на различных конфигурациях, различных базах данных, различных браузерах и их версиях. Тестирование на совместимость выполняет команда QA.
Другие виды тестирования
Ad-hoc тестирование (интуитивное тестирование)
Само название говорит о том, что это тестирование проводится неформально, то есть без привязки к тест-кейсам, а также без какого-либо плана или документации для этого вида тестирования.
Цель такого тестирования – найти дефекты и сломать приложение, выполнив любой сценарий приложения или используяю произвольную функциональность.
Ad-hoc тестирование – это неформальный способ поиска дефектов, который может быть выполнен любым участником проекта. Сложно выявить дефекты без тест-кейсов, но иногда в ходе этого тестирования обнаруживаются дефекты, которые не покрываются существующими тест-кейсами.
Бэкенд тестирование
При вводе данных через интерфейс приложения они сохраняются в базе данных, при этом тестирование так и называется тестированием базы данных или бэкенд-тестированием.
Существуют различные базы данных, такие как SQL Server, MySQL, Oracle и т.д. Тестирование базы данных включает в себя тестирование структуры таблиц, схем, хранимых процедур, структур данных и так далее. При бэкэнд-тестировании графический интерфейс не задействован, тестировщики напрямую подключены к базе данных с соответствующим доступом, и они могут легко проверить данные, выполнив несколько запросов.
Во время тестирования бэкэнда могут быть выявлены такие проблемы, как потеря данных, взаимная блокировка, повреждение данных и т.д., и эти проблемы очень важно устранить до того, как система будет запущена на production.
Тестирование совместимости браузеров
Это подтип тестирования на совместимость (которое описано ниже), и выполняется командой тестирования.
Тестирование на совместимость с браузерами проводится для веб-приложений и гарантирует, что ПО может работать в различных браузерах и операционных системах. Этот тип тестирования также проверяет, работает ли веб-приложение на всех версиях всех браузеров или нет.
Тестирование на обратную совместимость
Это вид тестирования, который проверяет, работает ли вновь разработанное или обновленное ПО с более старой своей версией или нет.
Тестирование на обратную совместимость проверяет, работает ли новая версия ПО с форматом файлов, созданных более старой версией ПО: также ли оно хорошо работает с таблицами данных, файлами и структурами данных, созданными более старой версией этого ПО. Если какое-либо ПО обновлено, то оно должно хорошо работать поверх своей предыдущей версии.
Тестирование граничных значений
Этот метод тестирования проверяет поведение приложения при определенных входных данных.
Тестирование граничных значений проводится для проверки наличия дефектов при вводе граничных значениях. Тестирование граничных значений используется для тестирования различных диапазонов чисел. Для каждого диапазона существует верхняя и нижняя граница, и тестирование проводится на этих граничных значениях.
Если для тестирования требуется диапазон чисел от 1 до 500, то тестирование граничных значений выполняется на значениях 0, 1, 2, 499, 500 и 501.
Тестирование ветвей
Это тестирование также известно как тестирование покрытия ветвей или тестирование покрытия решений. Это вид тестирования “белого ящика”, выполняемый на уровне модульных тестов. Оно проводится для того, чтобы убедиться, что каждый возможный путь от точки принятия решения выполняется хотя бы один раз для 100% покрытия теста.
Пример:
Read number A, B
If (A>B) then
Print(“A is greater”)
Else
Print(“B is greater”)
Здесь есть две ветви, одна для if, а другая для else. Для 100% покрытия нам нужны 2 тестовых случая с разными значениями A и B.
Test case 1: A=10, B=5 It will cover the if branch.
Test case 2: A=7, B=15 It will cover the else branch.
Сравнительное тестирование
Сравнение сильных и слабых сторон продукта с его предыдущими версиями или другими аналогичными продуктами называется сравнительным тестированием.
Эквивалентное разделение
Это метод тестирования и разновидность тестирования “черного ящика”. Во время этого тестирования выбирается набор групп и несколько значений или чисел для тестирования. Подразумевается, что все значения из этой группы генерируют один и тот же результат.
Целью такого тестирования является удаление избыточных тест-кейсов в пределах определенной группы, которые генерируют одинаковые выходные данные, но не приводят к каким-либо дефектам.
Предположим, что приложение принимает значения от -10 до +10, тогда, используя разделение по эквивалентности, для тестирования будут выбраны нулевое, одно положительное и одно отрицательное значения. Таким образом, эквивалентное разбиение для этого тестирования – это от -10 до -1, 0 и от 1 до 10.
Тестирование на основе опыта (предугадывание ошибок)
Предугадывание ошибок – это метод тестирования в режиме реального времени. Оно включает в себя сценарии, основанные на опыте тестировщиков.
Этот вид тестирования также известен как тестирование на основе опыта, поскольку он использует знания QA о том, как приложение работало в прошлом, как сломать приложение, какие дефекты часто встречаются в приложениях данного типа.
Тестирование графического интерфейса пользователя
Целью данного тестирования является проверка графического интерфейса пользователя (GUI) в соответствии с бизнес-требованиями. Ожидаемый графический интерфейс приложения указан в документе детального проектирования и макетах экранов графического интерфейса.
Тестирование GUI включает в себя проверку размеров кнопок и полей ввода, присутствующих на экране, выравнивание всего текста, таблиц и содержимого в таблицах.
Также проверяется меню приложения. После выбора различных меню и пунктов меню проверяется, что страница не изменяет размеры, а выравнивание остается неизменным после наведения курсора мыши на меню или подменю.
Инкрементное интеграционное тестирование
Инкрементное интеграционное тестирование – это подход к тестированию “снизу вверх”, то есть непрерывное тестирование приложения при добавлении новой функциональности.
Функциональности приложения и модули должны быть достаточно независимыми, чтобы их можно было тестировать отдельно. Это делается разработчиками или тестировщиками.
Тестирование инсталляции/деинсталляции
Тестирование инсталляции проводится для проверки того, что программное приложение установлено правильно и работает в соответствии с ожиданиями. Тестирование инсталляции – это фаза тестирования, предшествующая первому взаимодействию пользователей с реальным приложением. Тестирование инсталляции также называется “тестированием внедрения”.
Тестирование деинсталляции проводится для подтверждения того, что все компоненты или элементы ПО корректно удаляются из системы.
Такой вид тестирование может проверять полную, частичную или обновленную инсталляцию/деинсталляцию на различных операционных системах в различных аппаратных или программных средах.
Мутационное тестирование
Мутационное тестирование – это вид тестирования “белого ящика”, при котором изменяется исходный код ПО и проверяется, могут ли существующие тест-кейсы выявить эти дефекты в системе.
Изменения в исходном коде программы очень минимальны, поэтому они влияют не на все приложение, а только на конкретную область, на которую оказывается воздействие, и соответствующие тест-кейсы должны быть способны выявить эти ошибки в системе.
Негативное тестирование
Идея тестировщика для некоторых проверок заключается в том, чтобы “сломать систему/приложение”, и это достигается с помощью негативного тестирования.
Техники негативного тестирования выполняются с использованием некорректных входных данных. Проверяется, валидирует ли система ошибку недопустимого ввода и ведет ли она себя так, как ожидается.
Тестирование восстановления
Это вид тестирования, который проверяет, насколько хорошо приложение или система восстанавливается после сбоев или аварий.
Тестирование восстановления определяет, сможет ли система продолжить работу после сбоев. Предположим, что приложение получает данные через сетевой кабель и вдруг этот сетевой кабель был отключен.
Через некоторое время содинение с сетевым кабелем восстанавливают; тогда система должна начать получать данные с того места, где она потеряла соединение из-за отключения сетевого кабеля.
Регрессионное тестирование
Регрессионное тестирование – это тестирование неизменных функциональностей приложения, чтобы убедиться, что любые исправления ошибок, добавление новых функциональностей, удаление или обновление существующих функциональностей не влияют на работу приложения.
Определение области регрессии является важной частью регрессионного тестирования. Чтобы определить область регрессии, тестировщик должен выяснить область приложения, в которой произошли изменения, и оценить влияние этих изменений на все приложение. Сложно охватить весь набор регрессионных тестов в каждом релизе, поэтому для этого используются средства автоматизации тестирования.
Тестирование на основе рисков
При тестировании на основе рисков функциональные возможности или требования тестируются на основе их приоритетности. Тестирование на основе риска включает в себя тестирование высококритичных функциональностей, которые имеют наибольшее влияние на бизнес-показатели и в которых вероятность отказа очень высока.
Решения о приоритете основываются на потребностях бизнеса, поэтому сначала выполняется тестирование высокоприоритетных функциональных возможностей, а затем тестирование функциональностей среднего и низкого приоритета.
Функциональность с низким приоритетом может быть протестирована или не протестирована в зависимости от имеющегося времени. Тестирование с учетом риска проводится, если не хватает времени для тестирования всех областей ПО, когда оно должно быть внедрено в срок без каких-либо задержек.
Этот подход применяется только после обсуждения и одобрения клиента и руководства организации.
Статическое тестирование
Статическое тестирование – это вид тестирования, который проводится без выполнения какого-либо кода. Обзоры, ревью и аудиты – это различные методы проведения статического тестирования. Под статическим тестированием понимаются такие действия, как просмотр документов с требованиями, спецификации требований заказчика, высокоуровневого и низкоуровневого дизайна, синтаксиса кода, стандартов именования и т. д.
Статическое тестирование также проводится для тест-кейсов, планов тестирования, тестовых сценариев. Оно проводится для как можно раннего предотвращения дефектов на начальных стадиях. Именно поэтому статическое тестирование является экономически эффективным.
Например, QA тестирует сайт страхования домашних животных. Логика расчета его стоимости описана в документации с требованиями. В рамках статического тестирования QA могут просмотреть код разработчика для расчета стоимости страхования и сравнить его с требованиями, чтобы предотвратить потенциальный дефект, связанный с этими расчетами.
Тестирование уязвимостей
Тестирование, которое включает в себя выявление слабых мест в ПО, оборудовании и сети, известно как тестирование на уязвимость. В вредоносных программах хакер может получить контроль над системой, если она уязвима к таким видам атак, вирусам и червям.
Необходимо проверить, проходят ли эти системы тестирование на уязвимость перед производством. Оно может выявить критические дефекты и недостатки в системе безопасности.
Заключение
В данной статье упомянуты самые используемые виды тестирования ПО, но это далеко не полный их список.
Существует более чем 100+ видов тестирования, но мы не используем их во всех типах проектов. Поэтому мы рассмотрели некоторые общие виды тестирования ПО, которые чаще всего используются в жизненном цикле тестирования.
Существуют альтернативные определения или процессы, используемые в различных организациях, но основная концепция везде одинакова. Эти виды тестирования, процессы и методы их реализации постоянно меняются по мере изменения проекта и требований.
Перевод статьи «Types of Software Testing: Different Testing Types with Details».