Классификация видов тестирования ПО

Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
Классификация видов тестирования ПО создатель Mind Map: Классификация видов тестирования ПО

1. Тестирование точки входа (Entry point testing)

2. Тестирование на совместимость (Compatibility testing)

2.1. Мобильные устройства

2.1.1. • Насколько безопасно приложение? • Как приложение работает в нормальных условиях? • Как ведёт себя приложение, когда одновременно подключается слишком много пользователей? • Может ли приложение восстановиться после любой аварии? • Может ли приложение вести себя одинаково в любой среде? • Насколько легко перенести приложение в другую систему? • Легко ли понять документы/руководство пользователя, прилагаемые к приложению?

2.2. Персональные компьютеры

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

4. По степени автоматизации

4.1. Ручное тестирование (Manual testing)

4.2. Автоматизированное тестирование (Automated testing)

5. По функциональности

5.1. Функциональное тестирование (Functional testing) - имитация фактического использования системы; проверка реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. Ф.т. выполнятеся на всех уровнях тестирования

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

5.1.2. Интеграционное тестирование (Integration testing) - проверка взаимодействия между компонентами системы.

5.1.3. Дымовое тестирование (Smoke testing) - рассматривает внешнее поведение системы/продукта

5.1.4. Системное тестирование (System testing)

5.1.4.1. Позитивное (Positive)

5.1.4.2. Негативное (Negative)

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

5.1.6. Тестирование мобильных приложений - обеспечение качества систем, которое ориентировано на программы, предназначенные для той или иной платформы (Android, iOS и многие другие).

5.1.7. Тестирование установки (Installation testing) - проверка процесса инсталляции/деинсталляции программ.

5.2. Нефункциональное тестирование (Non-functional testing)

5.2.1. Тестирование безопасности (Security testing) - обнаружение уязвимостей, угроз, рисков в программном приложении и предотвращение вредоносных атак

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

5.2.1.2. Сканирование безопасности- выявление слабых сторон сети и системы, а затем предоставление решения для снижения этих рисков

5.2.1.3. Оценка рисков - анализ рисков безопасности, выявление приоритетов безопасности и соответствия; рекомендации по контролю и мерам для снижения рисков

5.2.1.4. Аудит безопасности - внутренняя проверка приложений и операционных систем на наличие уязвимостей. Аудит также может быть выполнен путём построчной проверки кода.

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

5.2.1.5.1. Что если в момент пиковых нагрузок будет совершена хакерская атака?

5.2.1.6. Этический взлом

5.2.1.6.1. Выдержит ли система имитацию хакерской атаки?

5.2.1.7. Оценка состояния - сочетает в себе сканирование безопасности, этический взлом и оценку рисков, чтобы показать общее состояние безопасности организации

5.2.2. Тестирование установки (Installation testing) - проверка успешности установки приложения, его настройки и удаления

5.2.3. Тестирование производительности (Performance testing) - автоматизированное тестирование скорости, ёмкости/вместимости, масштабируемости, стабильности

5.2.3.1. Тестирование стабильности - проверка работоспособности приложения при длительном тестировании со средним уровнем нагрузки; или стабильность работы портала при вводе большого количества данных в пиковое время

5.2.3.2. Объемное тестирование - оценка производительности при увеличении объёма данных в базе данных приложения и определение количества пользователей, одновременно работающих с приложением; н-р, проведение объемного тестирования музыкального веб-сайта

5.2.3.3. Стресс-тестирование - оценка работы приложения и системы в целом в условиях стресса, а также оценка снижения производительности и способности системы к регенерации

5.2.3.4. Нагрузочное тестирование (Load testing) - оценка поведения компонента или системы при различных нагрузках, обычно в условиях низких, типичных (стандартных) и максимальных (пиковых) нагрузок.

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

5.2.4.1. Простота и структура навигации

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

5.2.4.3. Восприятие графических элементов и цветового дизайна

5.2.4.4. Восприятие текстового контента и шрифтового оформления текста

5.2.5. Конфигурация тестирования (или тестирование портируемости) - исследование работоспособности программной системы в условиях различных программных конфигураций

5.2.6. Тестирование на отказ и восстановление (Failover and Recovery testing) - исследование программной системы на предмет восстановления после ошибок, сбоев. Оценивание реакции защитных свойств приложения

6. По целям

6.1. Подтверждении или опровержении двух моментов

6.1.1. 1. Всё работает стабильно в тестовых условиях, приближенных к реальности. 2. Можно переходить к более глубоким тестам.

6.1.1.1. Дымовое тестирование (Smoke testing)

6.2. Проверка соответствия функциональных требований ПО (с т.з. заказчика) его реальным характеристикам

6.2.1. Функциональное тестирование (Functional testing)

6.3. Повышение удовлетворенности клиентов

6.3.1. Нефункциональное тестирование (Non-functional testing}

6.3.1.1. Отвечает на вопросы «насколько хорошо» или «с каким качеством» продукт должен выполнять свою функцию

6.3.1.1.1. Надежность

6.3.1.1.2. Простота и удобство в использовании

6.3.1.1.3. Производительность

6.4. Определение готовности продукта

6.4.1. Приёмочное тестирование (Acceptance testing)

7. По уровню доступа к коду

7.1. Белый ящик (White box) - функциональное тестирование с доступом к системному коду

7.1.1. Н-р, т.к. как Google использует алгоритм/модели обработки естественного языка BERT и сделал BERT с открытым исходным кодом, мы можем посмотреть на код программы и разработать тестовые сценарии на основе понимания программного кода системы Google Open Sources Альберт НЛП - ZMax Home Industry

7.1.1.1. Тестирование и покрытие операторов

7.1.1.2. Тестирование и покрытие условий

7.1.1.3. Ценность тестирования операторов и условий

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

7.2.1. Н-р: Поиск в Google путем смешивания слов с одинаковым значением и, замена их синонимами - проверяется релевантность результатов поиска.

7.3. Черный ящик (Black box) - функциональное тестирование без доступа к системному коду, без знания внутренних механизмов системы

7.3.1. Эквивалентное разбиение

7.3.2. Анализ граничных значений

7.3.3. Тестирование с помощью таблиц альтернатив

7.3.4. Тестирование с помощью сценариев использования

7.3.5. Другие методы и техники

7.4. Техника предугадывания ошибки - Методы, основанные на опыте разработчиков, тестировщиков и пользователей для проектирования, реализации и выполнения тестов. Их, как правило, совмещают с методами чёрного и белого ящиков.

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

7.4.1.1. Предположение об ошибках

7.4.1.2. Исследовательское тестирование

7.4.1.3. Тестирование на основе чек-листа

8. По уровю изолированности частей

8.1. Компонентное тестирование (Unit testing)

8.1.1. модули

8.1.2. блоки

8.1.3. программы

8.1.4. функции

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

9. По уровням тестирования

9.1. Старт

9.2. Компонентное тестирование (Unit testing)

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

9.4. Системное тестирование (System testing) - выполняется на полной, интегрированной системе, с целью проверки соответствия всей системы исходным требованиям

9.5. Приёмочное тестирование (Acceptance testing) - вид комплексного тестирования на этапе сдачи готового продукта; тестируется, как правило, только основной функционал

9.5.1. Оперативное тестирование - тестирование системы на способность выполнять свою роль в операционной среде в соответствии с бизнес-моделью (проводится до приёмочных испытаний)

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

9.5.3. Полевые испытания

9.5.3.1. Альфа-тестирование - проводимого независимой командой тестирования

9.5.3.2. Бета-тестирование - выполняется реальными пользователями продукта

10. По степени важности

10.1. Дымовое тестирование (Smoke testing) - облегченное тестирование с помощью минимального набора тестов

10.2. Углубленное тестирование

11. По изменениям

11.1. Дымовое тестирование (Smoke testing)

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

11.2. Санитарное тестирование (Sanity testing)

11.2.1. Для проверки новых функций/исправленных ошибок. Это тестирование охватывает только конкретный компонент всей системы

11.3. Регрессионное тестирование (Regression testing)

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

11.3.1.1. Регрессия на уровне модуля (При необходимости изолированного тестирования кода)

11.3.1.2. Частичная реграессия (Для проверки нормальной работы кода)

11.3.1.3. Полная регрессия (Для проверки любых изменений в продукте из-за изменённого кода)