1. Уровни тестирования
1.1. Модульное тестирование
1.1.1. его еще часто называют юнит-тесты это такое тестирование когда проверяют какой-то маленький кусочек программы, какую-то маленькую логику, можно себе представить например корзину заказов и клик по кнопке заказать. После того как вы нажали заказать что-то должно произойти например, там должна отправиться информация. Этот маленький кусочек который заберет информацию ту которую вы ввели и куда-то отправит, это определенная логика, маленькое действие и таких модулей, где-то они будут больше, где то они будут меньше но в программе их очень, очень много. Фактически каждый модуль это определенный определенный набор кода в программе, который писал разработчик и ОН же обычно пишет на это свои свои юнит-тесты, то есть модульным тестированием занимается разработчик при разработке своих частей кода.
1.2. Интеграционное тестирование
1.2.1. модули должны как-то между собой взаимодействовать. Это могут быть модули на сервере, модули в базе данных, UI и все эти модули должны между собой как-то взаимодействовать. Вот это взаимодействие между ними и есть интеграционное тестирование, то есть некая интеграция, причем интеграция может быть не только на уровне модулей, но и например на уровне одной программы с другой программой. Довольно легко себе представить интеграцию программы на примере: вот то есть сайты-агрегаторы объявлений, которые собирают объявления с разных сайтов и размещают их на своем, то есть существует какой-то определенный канал интеграции, который собирает информацию, причем с каждым сайтом своя интеграция. И уже на сайте агрегаторе собирается вся информация с РАЗНЫХ сервисов. Именно интеграция является очень часто самым уязвимым местом в программе, проверять ее бывает довольно сложно и довольно часто нужно неплохо понимать техническую часть чтобы разобраться в каких-то интеграционных вещах. Потому что нажать прямо на интеграцию мы не можем, так как это этой некий путь. То есть мы в одном модуле что-то нажимаем, а в другом модуле, мы смотрим, что пришло и пришло ли туда кудадолжно было прийти. В обратную сторону работает точно также. Интеграции этот такой процесс, который является первым кандидатом на автоматизацию.
1.3. Системное тестирование
1.3.1. Полноценное тестирование всей системы, всего функционала
1.4. Приемочное тестирование
1.4.1. После системного тестирования мы хотим сдать продукт заказчику и заказчик должен провести приемку продукта. Он не будет проводить полное системное тестирование, скорее всего он пройдет по критически важныи для него узлам и убедится , что они работают. Обычно на этом этапе подготавливается приемочный акт, где согласовываются конкретные сценарии тестов, которые мы будем проходить.
2. По ожидаемому поведению
2.1. Позитивное
2.1.1. Проверяем продукт на выполнение функций в идеальных условиях, задуманных изначально (пример - правильный ввод логина/пароля)
2.2. Негативное
2.2.1. Когда мы пытаемся придумать сценарии, чтобы поломать программу. То есть убеждаемся , что в случае не стандартного поведения пользователя программа правильно отработала. (пример - неправильный ввод логина/пароля)
3. Направления тестирования
3.1. Статическое
3.1.1. по своей сути , это работа по предотвращению дефектов. Первое что мы делаем это тестируем требования. Второе - обзор архитектуры проекта, то есть изучение документации по архитектуре. Можем так же проверить дизайн/макет проекта/приложения. Так же можно сделать проверку полей в базе данных. Можно так же подготовить тестовые данные, с которыми мы будем дальше работать, но уже в динамическом тестировании. Чем более мы опытны и компетентны, тем больше мы можем сделать на этапе статического тестирования
3.2. Динамическое
3.2.1. поиск самих дефектов и возможное их устранение. То есть на этом этапе мы можем что-то сделать и сравнить ожидаемый результат с фактическим.
4. По степении удаленности
4.1. Альфа тестирование
4.1.1. Штатные тестировщики играют с целью нахождения багов. Проводится продолжительное время
4.2. Бета тестирование
4.2.1. Тестировщиками являются простые люди-игроки, которые играя выявляют различные баги. На этом этапе производитель игры уже пытается отбивать вложенные деньги и предлагает различные "плюшки" игрокам за деньги. По времени - от недели до месяца чаще всего.
5. Связанные с изменениями
5.1. Дымовое тестирование
5.1.1. проверка критически важного функционала. В зависимости от вашего продукта вы должны понимать, какой функционал должен быть критически важным. В идеале вы должны сделать проверку "насквозь", т. е. от начала до конца. Допустим если это интернет магазин, то пройти обычный путь покупателя от захода на сайт до осуществления покупки. Дымовые тесты многими считаются самыми высокоприоритетными тестами, потому что если проект не прошел дымовой тест, то дальше он не тестируется.
5.2. Регрессионное тестирование
5.2.1. допустим внесли в проект новую доработку, и нам нужно проверить ВЕСЬ СТАРЫЙ функционал, на то что он не поломался с доработкой
5.3. Тестирование сборки
5.3.1. тестирование ВСЕГО функционала новой сборки продукта
5.4. Санитарное тестирование
5.4.1. тестривание отдельной части продукта, например критически важно места, без работы которого может не работать весь продукт или той части которая часто выходит из строя
6. Методы тестирования
6.1. Черный ящик
6.1.1. Это пользовательское тестирование, то есть мы не имеем никакого доступ к внутренностям программы и действуем, как обычный пользователь
6.2. Белый ящик
6.2.1. Выполняют когда есть доступ к кодовой базе и при соответствующей технической подготовке тестировщика
6.3. Серый ящик
6.3.1. Пример: тестирование сайта с помошь devtools. Или допустим у нас есть доступ к базе данных. То есть если у нас есть доступ к какой-то технической составляющей продукта, которой нет у простого пользователя, то справедливо такое тестирование можно назвть серым ящиком
7. Виды тестирования по объектам
7.1. Функциональное
7.1.1. Функциональное тестирование
7.1.1.1. по сути функциональное тестирование это поведение вашего продукта, то что он умеет делать это и будет относиться к функциональному виду, в самом таком простом понятном виде
7.1.2. GUI тестирование элемента интерфейса
7.1.2.1. есть какая-то кнопка, когда вы наводите на нее курсор, она например меняет свой цвет. То есть у нее есть какое-то поведение, функция, она что-то делает и вот именно вот эти изменения при наведении курсора, при клике куда-то, то есть какие-то именно функциональные особенности вашего графического элемента, можно отнести к функциональному тестированию Просто его цвет размер и так далее это будет не функциональный, а уже другой вид
7.1.3. Безопасность
7.1.3.1. если функционал вашего продукта это безопасность, например антивирус, то это будет относиться к функциональному
7.2. Нефункциональное
7.2.1. Безопасность
7.2.1.1. Безопасность
7.2.1.1.1. здесь выделяем безопасность вашего продукта для детей и для экологии ну то есть вот в таком вот виде
7.2.1.2. Защищенность
7.2.1.2.1. защищенность данном случае я имею ввиду защищенность данных в вашем приложении, то есть это возможно наличие SSL сертификата на вашем сайте или например защиту от SSL инъекций
7.2.2. Тестирование интерфейса (UI)
7.2.2.1. Интерфейс соответствует дизайну
7.2.2.1.1. Нет искажений изображений
7.2.2.1.2. Внешний вид каждого элемента интерфейса
7.2.2.1.3. Общий внешний вид каждого экарана приложения
7.2.2.2. Внешний вид и профессиональность исполнения
7.2.2.3. Соблюдение единого стиля
7.2.3. Юзабилити тестирования
7.2.3.1. Как быстро пользователь достигнет цели
7.2.3.1.1. как быстро он сделает клик, как быстро он купит продукт, насколько это большой путь и чем больше путь тем хуже, да то есть если он слишком большой его нужно упрощать
7.2.3.2. Как долго вспоминать то, чему научился
7.2.3.3. Размер кнопок (удобно ли попадать)
7.2.3.4. Часто ли пользователю нужно выбирать
7.2.3.4.1. Один из принципов юзабилити: выбирать нужно как можно меньше
7.2.3.5. Большие ли списки
7.2.3.6. Порог вхождениям
7.2.3.6.1. Насколько быстро научиться новичку
7.2.3.6.2. Насколько быстро поймет опытны пользователь
7.2.4. Локализация(языковые, культурные, религиозные особенности)
7.2.4.1. Текст
7.2.4.1.1. Смысловая нагрузка
7.2.4.1.2. Синтаксис
7.2.4.1.3. Грамматика
7.2.4.1.4. Пунктуация
7.2.4.1.5. Наличие текста
7.2.4.2. Функционал
7.2.4.2.1. Формат даты
7.2.4.2.2. Формат времени
7.2.4.2.3. Валюта
7.2.4.2.4. Региональные настройки
7.2.4.2.5. Часовой пояс
7.2.4.2.6. Календарь (буддийский, японский, григорианский)
7.2.4.2.7. Начало недели
7.2.4.2.8. Формат бумаги
7.2.4.2.9. Система мер
7.2.4.2.10. Особенности имен
7.2.4.2.11. Сортировка
7.2.4.3. Регионльные особенности
7.2.4.3.1. Толкование текста, символов, знаков
7.2.4.3.2. Контроль символики и цветов
7.2.4.3.3. Правовые
7.2.4.3.4. Перевод на поддерживаемые языки
7.2.4.4. Контент
7.2.4.4.1. Аудио, видео, изображения
7.2.4.4.2. Текст
7.2.4.4.3. Документация
7.2.5. Интернационализация
7.2.5.1. это более обширное понятие, то есть интернационализация подразумевает, что заранее предусмотрены такие вещи, что например когда вы будете делать локализацию под другую страну, вам не нужно ничего глобально перерабатывать. Ну например если у вас есть поле с текстом где текст читается слева направо, куда его можно вместить именно слева направо вы легко локализуете свой продукт под большинство стран, но если вы захотите локализовать его например под Японию или Китай, где возможно тексты уже нужно по-другому размещать, то есть возможно сверху вниз, с другой стороны, тогда нужно формочку в которой находится текст переработать, по другому как-то расположить. Когда мы говорим именно про интернационализацию, это значит что мы заранее подумали о том,что эту формочку нужно сделать такой, что при локализации под другие страны, нам не нужно будет ничего перерабатывать, а только локализовывать.
7.2.6. Конфигурационное
7.2.6.1. подразумевает разную конфигурацию каждого из браузеров. Допустим открываем браузер хром, он запускается, все смотрится хорошо и у этого браузера есть разные конфигурации. Или например разные конфигурации операционных систем
7.2.7. Совместимости
7.2.7.1. Кроссбраузерное тестирование
7.2.7.1.1. то есть у вас есть сайт, который должен открываться на разных браузерах: опера, сафари, mozilla, google chrome... не важно. Вам нужно протестировать, что действительно в каждом браузере когда вы открываете сайт, он выглядит так как он должен выглядеть
7.2.8. Производительности
7.2.8.1. Нагрузочное
7.2.8.1.1. допустим у вас есть сайт и вы делаете нагрузку на него с помошью обращений к нему в течении часа(пример :10 000 в час)
7.2.8.2. Стрессовое
7.2.8.2.1. выдержит ли сайт 100 000 обращений в час
7.2.8.3. Стабильности(надежности)
7.2.8.3.1. к примеру, проверяете в течении длительного времени может ли ваш сайт стабильно работать (должны знать, что во время какой-нибудь рекламной акции ваш сайт не будет падать, а будет стабильно держаться)
7.2.8.4. Масштабируемости
7.2.8.4.1. допустим вы хотите масштабировать ваш продут, для этого нужно провести тестирование. К примеру добавляете процессор, увеличиваете оперативную память, и смотрите как сейчас работает продукт и на сколько процентов освободились мощности. И благодаря этому видите,что вам нужно сделать для необходимого уровня масштабируемости
7.2.8.5. Объемами
7.2.8.5.1. тестирование на передачу больших объемов информации (пример: многогигабайтный файл, фильм и т.д.)
7.2.8.6. Конкурентное
7.2.8.6.1. допустим в данный ваш сайт загружен на 100%, кто-то слушает музыку, смотрит фильмы, но при этом регистрируются новые пользователи. И тут мы смотрим, как при этом начинают распределяться ресурсы. Кокнкуренция в данном примере, между процессами происходящими на сайте.
7.2.9. Тестриование доступности
7.2.9.1. Проверяем можем ли мы использовать функционал продукта только с помошью клавиатуры, или допустим как отображается сайт в режиме для слабовидящих людей
7.2.10. Тестирование на отказ и восстановление (помехоустойчивость)
7.2.10.1. допустим ваш продукт это игра на телефоне. Во время игры пошел вызов на телефон, при этом игра не должна упасть.
7.2.11. Тестирование документации
7.2.11.1. Проверяем насколько верно написана документация
7.2.12. Инсталяционное
7.2.12.1. Проверяем как устанавливатся приложение