1. По степени автоматизации
1.1. Ручное
1.2. Автоматизированное
2. По уровню детализации
2.1. Модульное (компонентное,юнит)
2.2. Интеграционное
2.3. Системное
3. По степени важности тестируемых функций
3.1. Дымовое
3.1.1. Тестирование, которое направлено на проверку самой главной, самой важной, самой ключевой функциональности, неработоспособность которой делает бессмысленной саму идею использования приложения (или иного объекта, подвергаемого дымовому теcтированию).
3.2. Тестирование критического пути
3.2.1. Тестирование, направленное на исследование функциональности, используемой типичными пользователями в типичной повседневной деятельности.
3.3. Расширенное тестирование
3.3.1. Проверка всей (остальной) функциональности, заявленной в требованиях.
4. По степени формализации
4.1. На основе тест-кейсов
4.1.1. формализованный подход, в котором тестирование производится на основе заранее подготовленных тест-кейсов, наборов тест-кейсов и иной документации. Это самый распространённый способ тестирования, который также позволяет достичь максимальной полноты исследования приложения за счёт строгой систематизации процесса, удобства применения метрик и широкого набора выработанных за десятилетия и проверенных на практике рекомендаций.
4.2. Свободное (интуитивное)
4.2.1. полностью неформализованный подход, в котором не предполагается использования ни тест-кейсов, ни чек-листов, ни сценариев — тестировщик полностью опирается на свой профессионализм и интуицию (experience-based testing) для спонтанного выполнения с приложением действий, которые, как он считает, могут обнаружить ошибку. Этот вид тестирования используется редко и исключительно как дополнение к полностью или частично формализованному тестированию в случаях, когда для исследования некоторого аспекта поведения приложения (пока?) нет тест-кейсов.
4.3. Исследовательское
4.3.1. частично формализованный подход, в рамках которого тестировщик выполняет работу с приложением по выбранному сценарию, который, в свою очередь, дорабатывается в процессе выполнения с целью более полного исследования приложения. Ключевым фактором успеха при выполнении исследовательского тестирования является именно работа по сценарию, а не выполнение разрозненных бездумных операций. Существует даже специальный сценарный подход, называемый сессионным тестированием (session-based test-ing). В качестве альтернативы сценариям при выборе действий с приложением иногда могут использоваться чек-листы, и тогда этот вид тестирования называют тестированием на основе чек-листов
5. По привлечению конечных пользователей
5.1. Альфа-тестирование
5.2. Бета-тестирование
5.3. Гамма-тестирование
6. По запуску кода на исполнение
6.1. Статическое
6.1.1. Статическое тестирование отличается от динамического тем, что производится без запуска программного кода продукта. Тестирование осуществляется путем анализа программного кода (code review) или скомпилированного кода. Анализ может производиться как вручную, та помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в проду Также к статическому тестированию относится тестирования спецификации и прочей документации.
6.2. Динамическое
6.2.1. В отличии от статического, динамическое тестирование производится путем запуска продукта и проверки его функционала. Проверка осуществляется с помощью ручного или автоматического выполнения заранее подготовленного набора тестов
7. По доступу к коду и архитектуре приложения
7.1. Метод белого ящика
7.2. Метод черного ящика
7.3. Метод серого ящика
8. По принципам работы с приложением
8.1. Позитивное
8.2. Негативное
9. По целям и задачам
9.1. Позитивное
9.1.1. это тестирование с применением сценариев, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. С его помощью мы можем определить, что система делает то, для чего и была создана. Например, умножение на калькуляторе цифр 3 и 5.
9.2. Негативное
9.2.1. в рамках которого применяются сценарии, которые соответствуют внештатному поведению тестируемой системы. Это могут быть, например, исключительные ситуации или неверные данные. Прежде всего негативное тестирование направлено на проверку устойчивости системы к различным воздействиям, валидации неверных данных, обработки исключительных ситуаций. Сценарии позитивного тестирования, в свою очередь, направлены на проверку работы системы с теми типами данных, для которых она разрабатывалась.
9.3. Функциональное
9.3.1. это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает ПО, какие задачи оно решает.
9.4. Нефункциональное
9.4.1. это тестирование свойств, которые не относятся к функциональности системы. Данные свойства определяются нефункциональными требованиями, которые характеризуют продукт с таких сторон, как: Надежность (реакция системы на непредвиденные ситуации). Производительность (Работоспособность системы под разными нагрузками). Удобство (Исследование удобности работы с приложением с точки зрения пользователя). Масштабируемость (Требования к горизонтальному или вертикальному масштабированию приложения). Безопасность (Защищенность пользовательских данных). Портируемость (Переносимость приложения на различные платформы). И много других качеств. Данные свойства системы можно исследовать, используя следующие виды тестирования: Тестирование установки (Installation testing) – проверка успешности установки приложения, его настройки и удаления. Снижает риски потери пользовательских данных, потери работоспособности приложения и пр. Тестирование удобства использования (Usability testing) – характеризует систему с точки зрения удобства использования конечного пользователя. Конфигурационное тестирование (или тестирование портируемости) – исследование работоспособности программной системы в условиях различных программных конфигураций. Тестирование на отказ и восстановление (Failover and Recovery Testing) – исследование программной системы на предмет восстановления после ошибок, сбоев. Оценивание реакции защитных свойств приложения.
9.5. Инсталяционное
9.5.1. Под ним подразумевают уровень корректности установки некоего программного продукта в искусственно созданной среде с целью выявления степени ее готовности к эксплуатации.
9.6. Регрессионное
9.6.1. это вид тестирования направленный на проверку изменений, сделанных в приложении или окружающей (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что существующая ранее функциональность работает как и прежде. Регрессионными могут быть как функциональные, так и нефункциональные тесты.
9.7. Повторное
9.7.1. тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок
9.8. Приёмочное
9.8.1. Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью: • определения удовлетворяет ли система приемочным критериям; • вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.
9.9. Тестирование удобства пользователя
9.9.1. это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Сюда также входит: User eXperience (UX) — ощущение, испытываемое пользователем во время использования цифрового продукта, в то время как User interfa это инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».
9.10. Тестирование безопасности
9.10.1. оценка уязвимости программного обеспечения к различным атакам.
9.11. Тестирование совместимости
9.11.1. это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) интеграционное тестирование
9.12. Исчерпывающее
9.12.1. это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.
9.13. Тестирование надежности
9.13.1. Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
9.14. Тестирование отказоустойчивости
9.14.1. проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестир продукта.
9.15. Тестирование производительности
9.15.1. по другому - объемное тестирование (Volume Testing). Задачей объемного тестирования является получение оценки производительности при увелич объемов данных в базе данных приложения