Вид тестирования при котором выполняется минимальный набор тестов для выявления явных ошибок - Исправление ошибок и поиск оптимальных решений проблем

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

Модульное тестирование(Unit-testing) —
уровень тестирования, на котором
тестируется минимально возможный для
тестирования компонент, например,
отдельный класс или функция. На этом
уровне применяются методы «белого
ящика». В современных проектах модульное
тестирование («юнит-тестинг») осуществляется
разработчиками.

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

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

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

Интеграционное тестирование(Integration
testing) – уровень тестирования, на котором
отдельные программные модули объединяются
и тестируются в группе. Обычно
интеграционное тестирование проводится
после модульного тестирования (юнит-тесты
для модулей должны быть выполнены и
найденные ошибки исправлены).

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

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

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

Системное тестирование(System
testing)— это
тестирование программного обеспечения,
выполняемое на полной, интегрированной
системе, с целью проверки соответствия
системы исходным требованиям. Системное
тестирование относится к методам
тестирования «чёрного ящика», и, тем
самым, не требует знаний о внутреннем
устройстве системы.

Системное
тестирование
выполняется через внешние интерфейсы
программного обеспечения и тесно связано
с тестированием
пользовательского
интерфейса
(или через пользовательский интерфейс),
проводимым при помощи имитации действий
пользователей над элементами этого
интерфейса. Частными случаями этого
вида тестирования
являются тестирование
графического
пользовательского интерфейса
(Graphical User Interface, GUI) и пользовательского
интерфейса Web-приложений (WebUI).
Системное тестирование выполняется
инженерами по тестированию.

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

Рис.14. Уровни тестирования

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

Примеры статического
тестирования:

Обзоры
(Reviews)

Инспекции
(Inspections)

Сквозные
просмотры (Walkthroughs)

Аудиты
(Audits)

Также
к статическому тестированию относят
тестирование требований, спецификаций,
документации.

Динамическое
тестирование
(Dynamic
testing)–
тестирование, в ходе которого тестируемая
программа (код) выполняется (запускается).

Альфа-тестирование—
тестирование в процессе разработки

Бета-тестирование— тестирование
выполняется пользователями (end-users)

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

Регрессионное
тестирование (Regression
testing)
– тестирование функциональности,
которая была уже протестирована до
внесения какого-либо изменения.

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

Обычно используемые
методы регрессионного тестирования
включают повторные прогоны предыдущих
тестов.

Определение успешности регрессионных
тестов (IEEE 610-90 “Standard Glossary of Software
Engineering Terminology”) гласит: “повторное
выборочное тестирование системы или
компонент для проверки сделанных
модификаций не должно приводить к
непредусмотренным эффектам”. На практике
это означает, что если система успешно
проходила тесты до внесения модификаций,
она должна их проходить и после внесения
таковых. Основная проблема регрессионного
тестирования заключается в поиске
компромисса между имеющимися ресурсами
и необходимостью проведения таких
тестов по мере внесения каждого изменения.
В определенной степени, задача состоит
в том, чтобы определить критерии
“масштабов” изменений, с достижением
которых необходимо проводить регрессионные
тесты.

«Смок-тест»
(Smoke
Testing,
«дымовое
тестирование») в
тестировании означает минимальный
набор тестов на явные ошибки. Дымовой
тест обычно выполняется самим
программистом; не проходящую этот тест
программу не имеет смысла отдавать на
более глубокое тестирование.

***История.

Первое свое
применение этот термин получил у
печников, которые, собрав печь, закрывали
все заглушки, затапливали её и смотрели,
чтобы дым шёл только из положенных мест.

Повторное «рождение»
термина произошло в радиоэлектронике.
Подключив в первый раз собранное
устройство к источнику питания,
радиолюбитель, пристально разглядывая
каждый участок печатной платы, проводит
так называемый «Smoke Test» — наблюдает,
задымится или нет, потому что очень
часто из-за досадных ошибок, допущенных
при монтаже схемы, она оказывалась
неработоспособна и отдельные её части
выходили из строя из-за перегрева (часто
с выделением дыма).

5.1.3
Виды тестирования

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

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

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

Тестирование производительности(perfomance testing)

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

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

Стрессовое тестирование (stress
testing)

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

Нагрузочное тестирование (load
testing)

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

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

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

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

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

Процесс тестирования
фиксируется в протоколе (логе) и/или на
аудио- и видеоустройства — с целью
последующего более детального анализа.

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

Наблюдение
за тем, как
люди взаимодействуют с продуктом,
нередко позволяет найти для него более
оптимальные решения. Если при тестировании
используется модератор, то его задача
— держать респондента сфокусированным
на задачах (но при этом не „помогать“
ему решать эти задачи).

Основную трудность
после проведения процедуры
юзабилити-тестирования нередко
представляют большие объёмы и
беспорядочность полученных данных.
Поэтому для последующего анализа важно
зафиксировать:

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

Перемещение курсора и нажатия на
клавиши мыши;
Использование клавиатуры;
Переходы между экранами (браузера или
другой программы).

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

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

Существует
еще один подход к usability-тестированию:
Для решения задачи предложенной
пользователю разрабатывается «идеальный»
сценарий решения этой задачи. Как
правило, это сценарий, на который
ориентировался разработчик. При
выполнении задачи пользователями
регистрируются их отклонения от
задуманного сценария для последующего
анализа. После нескольких итераций
доработки программы и последующего
тестирования можно получить
удовлетворительный интерфейс с точки
зрения пользователя.

Тестирование интерфейса пользователя(UI testing)

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

проверяем, как приложение обрабатывает
ввод с клавиатуры и «мышки» и как
отображаются элементы графического
интерфейса (текст, кнопки, меню, списки
и прочие элементы).

Тестирование безопасности (security
testing)

— оценка уязвимости программного
обеспечения к различным атакам.

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

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

Тестирование локализации (localization
testing)

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

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

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

и др.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

Источник

Функциональные виды
Нефункциональные виды
Общий список

Сначала картинки

Важнейшие типы и виды тестирования, в простой форме:

Более подробно и на английском:

Еще более сложная классификация (кликабельно):

Еще один вариант:

Виды тестирования удобно делить на две группы: функциональное и нефункциональное.

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

Функциональное тестирование — виды

Быстрое определение: это тестирование основных, «рабочих» функций приложения/сайта; ради этих функций приложение, собственно, создавалось.

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

Тестируется работоспособность в целом и каждая функция отдельно: выполнены ли требования, достигнут ли целевой результат?

В «функциональную группу» входят такие виды (типы):

Юнит-тестирование (модульное)
Интеграционное
Сквозное (E2E, end-to-end)
Smoke (смок-тестирование)
Санитарное (sanity)
Регрессионное
Приемочное (приемка пользователями)
Системное
Тестирование интерфейса

Функциональные тесты могут выполняться вручную, или могут вполне успешно автоматизироваться.

Часто применяемые инструменты функционального тестирования, с которые тестировщик должен уметь работать (или хотя бы ознакомиться поверхностно):

UFT (ранее известный как QTP)
Selenium
JUnit
SoapUI
Watir

Selenium — инструмент тестировщика №1, овладеть им — кажется, решающий момент в трудоустройстве, по крайней мере сейчас, в 2023 году. Стремящийся стать QA-джуном должен знать (как минимум), о чем спрашивают на собеседовании по Selenium.

Далее рассмотрим типы нефункционального тестирования.

Нефункциональное тестирование — виды

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

Обычно такое тестирование делают после функционального, как менее приоритетное (но тоже важное). Оно может значительно улучшить качество приложения, объективно и субъективно, возвысить его над конкурентами, а не только «отполировать внешний вид», как было принято в предыдущие десятилетия. Нефункциональное — это не о том, работает ли софт или нет, это о том, КАК он работает и как он выглядит.

Автоматизация применяется, и очень широко, поскольку нефункциональные тесты весьма сложны и длительны. Чаще всего автоматизируется тестирование производительности.

Виды (типы) нефункционального тестирования:

Тестирование производительности
Нагрузочное
Безопасности
Тестирование на отказ
Совместимости
Юзабилити-тестирование
Масштабируемости
Объемное тестирование
Стресс-тестирование
Удобства сопровождения
Совместимости
Общей эффективности
Надежности
Выносливости
Тестирование восстановления после катастрофического отказа
Тестирование локализации и интернационализации

Далее перечислены основные типы (виды) тестирования (без деления на функциональные/нефункциональные).

Типы тестирования: общий список

Юнит-тестирование

Другое название, менее распространенное, но более интуитивное — «модульное тестирование». Также встречается название «компонентное тестирование».

Проверка по отдельности каждого модуля (юнита). Она требует знания языка программирования, на котором написан код приложения, а также хорошего знания его архитектуры, «внутренностей». По этой причине, в большинстве случаев юнит-тесты пишут разработчики — создатели приложения.

Интеграционное тестирование

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

Часто используемые инструменты юнит- и интеграционного тестирования:

Jasmine
Mocha

Сквозное тестирование

E2E-тестирование это подтип функционального, проверка всей системы «из конца в конец», end-to-end, поэтому такое название. Таких тестов еще меньше количественно, но они еще сложнее чем интеграционные и тем более модульные (и требуют больше опыта от тестировщика).

Инструменты, которые нужно освоить, чтобы претендовать на позицию E2E-QA:

Cucumber
Protractor
Jasmine
Karma
SpecFlow

Тестирование интерфейса

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

Инструменты GUI-тестирования:

Monkey test for Android
Saucelabs
Protractor

Тестированию GUI посвящен отдельный большой материал.

Тестирование доступности

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

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

Более подробно о таком специфическом типе тестирования — отдельный материал.

Альфа-тестирование

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

Альфа-тестирование проводят в девелоперском окружении (а не в реальном пользовательском). Для имитации пользовательского окружения создается виртуальное окружение.

Бета-тестирование

Бета-тестирование проводится после альфа-, и перед запуском продукта. Для бета-тестирования нужно реальное пользовательское окружение. Выбирается ограниченное количество реальных пользователей-«добровольцев» (клиентов), которые, не будучи специалистами в QA, тестируют продукт на свое усмотрение. Затем они дают фидбек, и конструктивную критику, после чего разработчики, при необходимости, вносят изменения в так называемую бета-версию продукта. Далее исправленный и доработанный продукт поступает на релиз, то есть становится доступен всем пользователям.

Ad-hoc-тестирование

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

Хотя искать баги без тест-кейсов может быть сложно, опытный тестировщик легко находит баги таким «свободным поиском», и нередко быстрее, чем «формализованным» способом.

Отдельный материал по ad-hoc.

Тестирование совместимости

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

Например, Windows-приложение должно быть совместимым со всеми распространенными версиями ОС Windows. Если это веб-приложение, оно должно без проблем открываться во всех распространенных браузерах. Android-приложение нужно протестировать во всех распространенных в данный момент версиях ОС Android.

Тестирование обратной совместимости

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

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

Кроссбраузерное тестирование

Или тестирование совместимости браузеров. Проверка, может ли веб-приложение (сайт) без проблем открываться во всех распространенных версиях браузеров.

Такое тестирование, ввиду его трудоемкости, автоматизируют, применяя такие инструменты:

CrossBrowserTesting
LambdaTest
Browsershots
Experitest
Turbo Browser Sandbox
Ranorex Studio
Browsera

Большой материал по автоматизации такого тестирования.

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

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

WebLOAD
LoadView
NeoLoad
LoadNinja
Appvance
LoadRunner
Apache JMeter
Loadster
LoadImpact
Testing Anywhere
SmartMeter.io
Tricentis Flood
Rational Performance Tester
LoadComplete

Нагрузочное тестирование

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

Часто применяемые нагрузочные инструменты:

LoadRunner
WebLoad
JMeter

Подробный обзор бесплатных инструментов нагрузочного тестирования — здесь.

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

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

Регрессионное тестирование

Если система корректируется в процессе создания (что неизбежно), если в ее модули/функции вносятся изменения, то обязательно проверяют, не повлияли ли эти правки на функционирование системы.

Статья о проблемах с «регрессами» — здесь.

Agile-тестирование

Специфический тип QA-тестирования командой, работающей «по эджайлу», то есть с соблюдением так называемого манифеста Agile, и с учетом точки зрения пользователей в первую очередь.

Инструменты Agile QA:

JIRA
PractiTest
JunoOne
VersionOne
TestRail
SoapUI

Тестирование API

Как и юнит-тестирование, этот тип относится к так называемому «code level testing», то есть имеет дело непосредственно с исходным кодом приложения. Разница с юнит- в том, что юнит-тесты обычно делают разработчики, а API тестирует QA-команда.

Тестирование черного ящика

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

Тестирование белого ящика

Проверка приложения со знанием его исходного кода и архитектуры.

О черном и белом ящиках, которые ждут Junior QA — здесь.

Тестирование безопасности

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

Arachni
Iron Wasp
Nogotofail
SQLMap
W3af
Wapiti
Wfuzz
Zed Attack Proxy

Юзабилити-тестирование

Оценка (и последующая коррекция) общего удобства пользования приложением/сайтом. Насколько приложение юзабельно, то есть «дружественно к пользователю»?

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

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

Инструменты проверки юзабилити:

Optimizely
Qualaroo
Crazy Egg
Usabilla
Clicktale
Five Second Test
Chalkmark
UXtweak

Тестирование масштабируемости

Легко ли масштабировать приложение? То есть, легко ли, и быстро ли, расширяются его возможности в программном и аппаратном измерении? Что произойдет, если количество пользователей, объемы данных, количество транзакций — возрастут в разы? Или десятки, сотни раз.

Тестирование надежности

Насколько приложение надёжное, «выносливое»? Сколько времени оно сумеет проработать «без единого отказа», и при каких условиях происходит отказ? Что провоцирует ошибки в приложении?

Например, нужно не допустить ситуации, когда важная личная информация пользователей хранится в базе данных под управлением нашего приложения, и затем, после нескольких месяцев работы, эта информация удаляется, внезапно и бесповоротно, из-за каких-то ошибок в коде приложения, вовремя не выявленных. Выявлять и устранять подобные ошибки — задача тестирования надежности (reliability testing).

Приемочное тестирование

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

***

Подробнее об основных инструментах автоматизации тестирования можно почитать здесь — а также оценить «портрет среднего тестировщика» в 2022-2023.

Бесплатная подписка на телеграм-канал, посвященный только и исключительно автоматизации — здесь. А официальный канал TestEngineer — здесь.

Источник

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

Функциональные.
Нефункциональные.
Связанные с изменениями.

Далее мы постараемся более подробно рассказать о каждом отдельном виде тестирования, его назначении и использовании при тестировании программного обеспечения.

Функциональные виды тестирования

Функциональные тесты базируются на функциях и особенностях, а также на взаимодействии с другими системами и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing), приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов.

Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функционтальности компонента или системы в целом.

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

Тестирование функциональности может проводиться в двух аспектах:

Требования.
Бизнес-процессы.

Тестирование в аспекте «требования» использует спецификацию функциональных требований к системе, как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.

Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этом аспекте тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

Преимущества функционального тестирования:

имитирует фактическое использование системы.

Недостатки функционального тестирования:

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

Достаточно распространенной является автоматизация функционального тестирования.

2. Тестирование безопасности (Security and Access Control Testing)

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

Принципы безопасности программного обеспечения

Общая стратегия безопасности основывается на трех основных принципах:

Конфиденциальность.
Целостность.
Доступность.

Конфиденциальность

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

Целостность

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

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

Доступность

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

3. Тестирование взаимодействия или Interoperability Testing

Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing).

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

Нефункциональные виды тестирования

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

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

Тестирование производительности ( Performance testing ).

Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:

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

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

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

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

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

Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.
Может производиться определение количества пользователей, одновременно работающих с приложением.

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

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

В англоязычной терминологии вы можете так же найти еще один вид тестирования — Load Testing — тестирование реакции системы на изменение нагрузки (в пределе допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.

2. Тестирование Установки (Installation Testing)

Тестирование установки направленно на проверку успешной инсталляции и настройки, а также на обновление или удаление программного обеспечения.

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

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

В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого часто пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll-back) к предыдущей версии (в случае неудачи). Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя — это потеря репутации и большого количества средств, например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование установки можно назвать одной из важнейших задач по обеспечению качества программного обеспечения.

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

Иногда мы сталкиваемся с непонятными или нелогичными приложениями, многие функции и способы использования которых часто не очевидны. После такой работы редко возникает желание использовать приложение снова, и мы ищем более удобные аналоги. Для того, чтобы приложение было популярным, ему мало быть функциональным – оно должно быть еще и удобным. Если задуматься, интуитивно понятные приложения экономят нервы пользователям и затраты работодателя на обучение. Значит, они более конкурентоспособные! Поэтому тестирование удобства использования, о котором пойдет речь далее, является неотъемлемой частью тестирования любых массовых продуктов.

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

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

Производительность, эффективность ( efficiency) — сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д. (меньше — лучше).
Правильность ( accuracy) — сколько ошибок сделал пользователь во время работы с приложением (меньше — лучше).
Активизация в памяти ( recall ) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени (повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя).
Эмоциональная реакция ( emotional response ) – как пользователь себя чувствует после завершения задачи — растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция — лучше).

Уровни проведения

Проверка удобства использования может проводиться как по отношению к готовому продукту, посредством тестирования черного ящика (black box testing), так и к интерфейсам приложения (API), используемым при разработке — тестирование белого ящика (white box testing). В этом случае проверяется удобство использования внутренних объектов, классов, методов и переменных, а также рассматривается удобство изменения, расширения системы и интеграции ее с другими модулями или системами. Использование удобных интерфейсов (API) может улучшить качество, увеличить скорость написания и поддержки разрабатываемого кода и, как следствие, улучшить качество продукта в целом.

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

Советы по улучшению удобства пользования:

Для дизайна удобных приложений полезно следовать принципам «пока-йока» или fail-safe. У нас это более известно как «защита от дурака». Простой пример: если поле требует цифровое значение,то логично ограничить пользователю диапазон ввода только цифрами – будет меньше случайных ошибок.
Для повышения юзабилити существующих приложений можно использовать цикл Демминга (Plan-Do-Check-Act), собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения.

Заблуждения о тестировании удобства пользования:

Тестирование пользовательского интерфейса = Тестирование удобства пользования

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

Тестирование удобства пользования можно провести без участия эксперта

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

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

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

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

Тестирование на отказ и восстановление очень важно для систем, работающих по принципу “24×7”. Если Вы создаете продукт, который будет работать, например,в интернете, то без проведения данного вида тестирования Вам просто не обойтись, т.к. каждая минута простоя или потеря данных, в случае отказа оборудования, может стоить вам денег, потери клиентов и репутации на рынке.

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

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

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

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

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

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

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

Стоит заметить, что тестирование на отказ и восстановление – это весьма специфичное тестирование. Разработка тестовых сценариев должна производиться с учетом всех особенностей тестируемой системы. Принимая во внимание довольно жесткие методы воздействия, стоит также оценить целесообразность проведения данного вида тестирования для конкретного программного продукта.

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

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

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

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

Примечание: В ISTQB Syllabus вообще не говорится о таком виде тестирования, как конфигурационное. Согласно глоссарию, данный вид тестирования рассматривается там как тестирование портируемости(portability testing: The process of testing to determine the portability of a software product.).

Связанные с изменениями виды тестирования

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

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

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

«При вводе в эксплуатацию нового оборудования («железа») считалось, что тестирование прошло удачно, если из установки не пошел дым.»

В области же программного обеспечения дымовое тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что, после сборки кода (нового или исправленного), устанавливаемое приложение стартует и выполняет основные функции.

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

Аналогами дымового тестирования являются Build Verification Testing и Acceptance Testing, выполняемые на функциональном уровне командой тестирования, по результатам которых делается вывод о том, принимается или нет установленная версия программного обеспечения в тестирование, эксплуатацию или на поставку заказчику.

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

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

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

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

Сам по себе термин «регрессионное тестирование», в зависимости от контекста использования, может иметь разный смысл. Сэм Канер, к примеру, описал 3 основных типа регрессионного тестирования:

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

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

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

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

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

Отличие санитарного тестирования от дымового (Sanity vs Smoke testing)

В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование — это одно и тоже. Мы же полагаем, что эти виды тестирования имеют «векторы движения»- направления в разные стороны. В отличии от дымового (Smoke testing), санитарное тестирование (Sanity testing) направлено вглубь проверяемой функции, в то время как дымовое — направлено вширь, для покрытия тестами как можно большего функционала в кратчайшие сроки.

Источник

Completing a software project is not sufficient, we also need to test it. But exactly why should we care about testing a software application?

Software testing is about checking if the software works properly and if it meets the written requirements specifications.

The basic goals of software tests are to eliminate bugs and to enhance various aspects of the software, such as performance, user experience, security, and so on. A great deal of testing can amazingly improve the overall quality of the software, which will lead to great customer satisfaction.

But is software testing essential? What if we don’t do this?

Nowadays, software applications are used everywhere — hospitals, traffic, shops, business organizations, etc. So not testing the software at all is dangerous. It’s dangerous in the sense that it can cause severe harm, such as security breach, loss of money, and even deaths in some cases. Delivering or launching an application without testing it very well will cause many small or big problems for the users.

Looking to learn Software Testing? Udemy’s The Complete 2023 Software Testing Bootcamp online course will surely prove to a great starting point for you.

Types of Software Testing

Software testing is generally classified into two main broad categories: functional testing and non-functional testing. There is also another general type of testing called maintenance testing.

1. Functional Testing

Functional testing involves the testing of the functional aspects of a software application. When you’re performing functional tests, you have to test each and every functionality. You need to see whether you’re getting the desired results or not.

There are several types of functional testing, such as:

Unit testing
Integration testing
End-to-end testing
Smoke testing
Sanity testing
Regression testing
Acceptance testing
White box testing
Black box testing
Interface testing

Functional tests are performed both manually and using automation tools. For this kind of testing, manual testing is easy, but you should use tools when necessary.

Some tools that you can use for functional testing are Micro Focus UFT (previously known as QTP, and UFT stands for Unified Functional Testing), Selenium, JUnit, soapUI, Watir, etc.

2. Non-functional Testing

Non-functional testing is the testing of non-functional aspects of an application, such as performance, reliability, usability, security, and so on. Non-functional tests are performed after the functional tests.

With non-functional testing, you can improve your software’s quality to a great extent. Functional tests also improve the quality, but with non-functional tests, you have the opportunity to make your software even better. Non-functional testing allows you to polish the software. This kind of testing is not about whether the software works or not. Rather, it’s about how well the software runs, and many other things.

Non-functional tests are not generally run manually. In fact, it’s difficult to perform this kind of tests manually. So these tests are usually executed using tools.

There are several types of non-functional testing, such as:

Performance testing
Security testing
Load testing
Failover testing
Compatibility testing
Usability testing
Scalability testing
Volume testing
Stress testing
Maintainability testing
Compliance testing
Efficiency testing
Reliability testing
Endurance testing
Disaster recovery testing
Localization testing
Internationalization testing

Note that explaining all the types of software testing is beyond the scope of this article.

Different Types of Software Testing

This article explains only some of the most common types of software testing.

1. Unit Testing

Testing each component or module of your software project is known as unit testing. To perform this kind of testing, knowledge of programming is necessary. So only programmers do this kind of tests, not testers.

You have to do a great deal of unit testing as you should test each and every unit of code in your project.

2. Integration testing

After integrating the modules, you need to see if the combined modules work together or not. This type of testing is known as integration testing. You need to perform fewer integration tests than unit tests.

Some good tools for unit and integration testing are Jasmine, Mocha, etc.

3. End-to-end Testing

End-to-end testing is the functional testing of the entire software system. When you test the complete software system, such testing is called end-to-end testing. You need to perform fewer end-to-end tests than integration tests.

Cucumber, Protractor, Jasmine, Karma, SpecFlow, etc. are some great end-to-end testing tools.

4. User Interface Testing

User interface testing involves the testing of the application’s user interface. The aim of UI tests is to check whether the user interfaces have been developed according to what is described in the requirements specifications document.

By running UI tests, you can make the application’s user interfaces more user-friendly and appealing to the eyes.

Some great automated user interface testing tools are Monkey test for Android, Saucelabs, and Protractor.

5. Accessibility testing

Testing whether your software is accessible to disabled people or not is termed as accessible testing. For this type of tests, you need to check if disabled people such as those who are color blind, blind, and deaf can use your application.

The right choice of color and contrast need to be made to make your software accessible to color-blind people.

6. Alpha testing

Alpha testing is a kind of testing to look for all the errors and issues in the entire software. This kind of test is done at the last phase of app development and is performed at the place of the developers, before launching the product or before delivering it to the client to ensure that the user/client gets an error-free software application.

Alpha testing is run before the beta testing, which means that after performing alpha testing, you need to run beta testing.

Alpha testing is not performed in the real environment. Rather, this kind of tests is done by creating a virtual environment that resembles a real environment.

7. Beta testing

As said earlier, beta testing takes place after alpha testing. Beta testing is done before the launch of the product. It is carried out in a real user environment by a limited number of actual customers or users, in order to be certain that the software is completely error-free and it functions smoothly. After collecting feedback and constructive criticism from those users, some changes are made to make the software better.

So when the software is under beta testing, it is called beta version of the software. After this testing is complete, the software is released to the public.

As the name suggests, ad-hoc testing is a kind of testing that is performed in an ad-hoc manner, without using any test cases, plans, documentation, or systems. Unlike all other types of testing, this kind of testing is not carried out in a systematic manner.

Although finding errors can be difficult without using test cases, there are technical issues that are easily detected through an ad-hoc test, but are hard to find through other testing approaches that use test cases.

This informal type of software testing can be executed by any person involved with the project.

9. Compatibility testing

Compatibility testing involves compatibility checking of the software with different operating systems, web browsers, network environments, hardware, and so on. It checks whether the developed software application is working fine with different configurations.

To give you a few examples, if the software is a Windows app, it should be checked whether it is compatible with different versions of the Windows operating system. If it’s a web application, it is tested whether the app is easily accessible from different versions of the widely-used web browsers. And if it’s an Android app, it should be checked whether it is working well with all the commonly used versions of the Android operating system.

10. Backward compatibility testing

Backward compatibility testing is carried out to test if a brand new or an updated version of an application is compatible with the previous versions of the environments (such as operating systems and web browsers) on which the software runs. Sometimes, some application is updated specifically to match the standard and style of a newer, more modern environment. In that case, support for backward compatibility is necessary.

Backward compatibility testing ensures that all those who are using the older versions of a particular environment can use your software.

11. Browser compatibility testing

As the name says, browser compatibility testing checks a web application for browser compatibility. More specifically, it is tested whether the web app can easily be accessed from all versions of the major web browsers.

It is a specific form of compatibility testing, while compatibility testing checks for general compatibility.

Some popular tools to check browser compatibility include CrossBrowserTesting.com, LamdaTest, Browsershots, Experitest, Turbo Browser Sandbox, Ranorex Studio, Browsera, etc.

12. Performance testing

Performance tests are run to check if the software’s performance is good or not. There are performance testing tools that analyze your app’s performance and show you the performance issues. By fixing those issues, you’ll be able to increase the performance of your software application.

Some great performance testing tools, also known as load testing tools, for web applications are WebLOAD, LoadView, NeoLoad, LoadNinja, Appvance, LoadRunner, Apache JMeter, Loadster, LoadImpact, Testing Anywhere, SmartMeter.io, Tricentis Flood, Rational Performance Tester, LoadComplete, etc.

13. Load testing

Load testing is one kind of performance testing that tests how much load a system can take before the software performance begins to degrade. By running load tests, we can know the capacity of taking load of a system.

You can run load tests using tools like LoadRunner, WebLoad, JMeter, etc.

14. Recovery testing

Recovery testing involves the checking of whether the application can recover from crashes and how well it recovers. In this kind of tests, testers observe how well the software can come back to the normal flow of execution. Crashes can happen anytime. Even if your software is of exceptional quality, crashes may happen. You don’t know when they may take place and annoy the users.

So you have to implement mechanisms that will recover the software application quickly and that will make the application run smoothly again.

15. Regression testing

If you need to make changes in any component, module, or function, you have to see if the whole system functions properly after those modifications. Testing of the whole system after such modifications is known as regression testing.

16. Agile testing

Carried out by the QA team, Agile testing is a type of testing that is conducted according to the rules of agile methodology. This kind of testing is done from the actual customers’ viewpoint.

Some useful tools that you can use for Agile testing are JIRA, PractiTest, JunoOne, VersionOne, TestRail, SoapUI, etc.

17. API testing

Just like unit testing, API testing is also a code-level testing type. The basic difference between unit testing and API testing is that unit testing is performed by the development team whereas API testing is handled by the QA team.

18. Black box testing

Performed by the QA team of a company, black box testing is a testing technique that involves the checking of the application’s functionality without having any technical knowledge of the application, like the knowledge of the code’s logic, how the code works, knowledge of the internal structure, etc.

19. White box testing

Performed by the development team, white box testing is a testing method that requires a good understanding of the application’s code. It requires great knowledge of the app’s internal logic.

20. Security testing

Security tests are performed to ensure the security of your application, in order that security breaches can be prevented. Security experts run this kind of tests to see how much your software is secure from attacks and to find security issues so that the app’s security can be strengthened.

The top website security testing tools include Grabber, Arachni, Iron Wasp, Nogotofail, SQLMap, W3af, Wapiti, Wfuzz, Zed Attack Proxy, etc.

21. Usability testing

Testing the user-friendliness of an app is known as usability testing. It involves the checking of how much usable or user-friendly the app is. It is tested whether any user can easily use your software without getting stuck.

One of the best ways to test the usability of your software is to invite a few people to use your software. See if they can do certain things in your app without taking any help from you.

Take a look at these useful usability testing tools: Optimizely, Qualaroo, Crazy Egg, Usabilla, Clicktale, Five Second Test, Chalkmark, UXtweak.

22. Scalability testing

Scalability testing verifies whether the software is scalable or not. In other words, it checks if your app performs well when the number of users, amount of data, or the number of transactions increases significantly. A software application that is not scalable may cause great business loss.

23. Reliability testing

Reliability testing is a type of software testing that verifies if the software is reliable or not. In other words, it checks whether the software runs error-free and that one can rely on it.

For example, if a user’s important information stored in the database of the software gets suddenly deleted after a few months because of some error in the code, we can say that the software is not reliable.

24. Acceptance testing

The client who will purchase your software will perform acceptance testing (also known as User Acceptance Testing) to see if the software can be accepted or not by checking whether your software meets all the client’s requirements and preferences. If your software doesn’t meet all the requirements or if your client doesn’t like something in the app, they may request you to make changes before accepting the project.

Final words

This article explained several types of software testing. Keep in mind that you don’t need to perform all of these tests mentioned in this post for your software project. What kinds of tests you should run depends on the type of software you’re building and other factors.

Besides performing tests, measuring the effectiveness of the tests is also important, and test coverage tells the effectiveness of your tests. Istanbul is a good tool for measuring test coverage, used for JavaScript software projects.

There can be undetected errors in your application even after it’s launched, which will annoy the users and will cause problems for them. Real-time error-checking tools such as Sentry and Newrelic will automatically find errors and notify you, so you don’t need to tell your users to report bugs.

You can also use automated code grading tools. Automated code grading tools like sonarqube and codebeat help you amazingly improve the quality of your code by showing issues in your application. These tools will help you fix bugs in less time. After analyzing your code, these tools give you useful reports with valuable information required for code quality enhancement.

You can use programs called linters to check if the code of your software project meets the specified coding convention rules. A linter actually saves you a lot of time as manually checking the code written by several developers is a very time-consuming process.

You can find linters for almost any programming language. Take a look at these popular linters: TypeScript TSlint, JavaScript ESLint, Sass/SCSS sass-lint, Python pylint/flake8, Bash ShellCheck, Go golang lint, etc. Code editors such as Visual Studio Code let you configure linting.

People are also reading:

Best Software Testing Courses
Best Software Testing Certifications
Best Automation Testing Tools
Best Penetration Testing Certifications
What is Software Testing Life Cycle?
Manual Testing Interview Questions
What is Selenium IDE?
What is Selenium WebDriver?
Best Selenium Testing Interview Questions
What is Selenium?
Best Web Development IDE
Security Testing Tools
Software Testing Tools
Best Blockchain Courses

Источник

Completing a software project is not sufficient, we also need to test it. But exactly why should we care about testing a software application?

Software testing is about checking if the software works properly and if it meets the written requirements specifications.

But is software testing essential? What if we don’t do this?

Looking to learn Software Testing? Udemy’s The Complete 2023 Software Testing Bootcamp online course will surely prove to a great starting point for you.

Types of Software Testing

Software testing is generally classified into two main broad categories: functional testing and non-functional testing. There is also another general type of testing called maintenance testing.

1. Functional Testing

There are several types of functional testing, such as:

Unit testing
Integration testing
End-to-end testing
Smoke testing
Sanity testing
Regression testing
Acceptance testing
White box testing
Black box testing
Interface testing

Functional tests are performed both manually and using automation tools. For this kind of testing, manual testing is easy, but you should use tools when necessary.

Some tools that you can use for functional testing are Micro Focus UFT (previously known as QTP, and UFT stands for Unified Functional Testing), Selenium, JUnit, soapUI, Watir, etc.

2. Non-functional Testing

Non-functional tests are not generally run manually. In fact, it’s difficult to perform this kind of tests manually. So these tests are usually executed using tools.

There are several types of non-functional testing, such as:

Performance testing
Security testing
Load testing
Failover testing
Compatibility testing
Usability testing
Scalability testing
Volume testing
Stress testing
Maintainability testing
Compliance testing
Efficiency testing
Reliability testing
Endurance testing
Disaster recovery testing
Localization testing
Internationalization testing

Note that explaining all the types of software testing is beyond the scope of this article.

Different Types of Software Testing

This article explains only some of the most common types of software testing.

1. Unit Testing

You have to do a great deal of unit testing as you should test each and every unit of code in your project.

2. Integration testing

Some good tools for unit and integration testing are Jasmine, Mocha, etc.

3. End-to-end Testing

Cucumber, Protractor, Jasmine, Karma, SpecFlow, etc. are some great end-to-end testing tools.

4. User Interface Testing

By running UI tests, you can make the application’s user interfaces more user-friendly and appealing to the eyes.

Some great automated user interface testing tools are Monkey test for Android, Saucelabs, and Protractor.

5. Accessibility testing

The right choice of color and contrast need to be made to make your software accessible to color-blind people.

6. Alpha testing

Alpha testing is run before the beta testing, which means that after performing alpha testing, you need to run beta testing.

Alpha testing is not performed in the real environment. Rather, this kind of tests is done by creating a virtual environment that resembles a real environment.

7. Beta testing

So when the software is under beta testing, it is called beta version of the software. After this testing is complete, the software is released to the public.

This informal type of software testing can be executed by any person involved with the project.

9. Compatibility testing

10. Backward compatibility testing

Backward compatibility testing ensures that all those who are using the older versions of a particular environment can use your software.

11. Browser compatibility testing

It is a specific form of compatibility testing, while compatibility testing checks for general compatibility.

Some popular tools to check browser compatibility include CrossBrowserTesting.com, LamdaTest, Browsershots, Experitest, Turbo Browser Sandbox, Ranorex Studio, Browsera, etc.

12. Performance testing

13. Load testing

You can run load tests using tools like LoadRunner, WebLoad, JMeter, etc.

14. Recovery testing

So you have to implement mechanisms that will recover the software application quickly and that will make the application run smoothly again.

15. Regression testing

16. Agile testing

Carried out by the QA team, Agile testing is a type of testing that is conducted according to the rules of agile methodology. This kind of testing is done from the actual customers’ viewpoint.

Some useful tools that you can use for Agile testing are JIRA, PractiTest, JunoOne, VersionOne, TestRail, SoapUI, etc.

17. API testing

18. Black box testing

19. White box testing

Performed by the development team, white box testing is a testing method that requires a good understanding of the application’s code. It requires great knowledge of the app’s internal logic.

20. Security testing

The top website security testing tools include Grabber, Arachni, Iron Wasp, Nogotofail, SQLMap, W3af, Wapiti, Wfuzz, Zed Attack Proxy, etc.

21. Usability testing

One of the best ways to test the usability of your software is to invite a few people to use your software. See if they can do certain things in your app without taking any help from you.

Take a look at these useful usability testing tools: Optimizely, Qualaroo, Crazy Egg, Usabilla, Clicktale, Five Second Test, Chalkmark, UXtweak.

22. Scalability testing

23. Reliability testing

Reliability testing is a type of software testing that verifies if the software is reliable or not. In other words, it checks whether the software runs error-free and that one can rely on it.

24. Acceptance testing

Final words

People are also reading:

Best Software Testing Courses
Best Software Testing Certifications
Best Automation Testing Tools
Best Penetration Testing Certifications
What is Software Testing Life Cycle?
Manual Testing Interview Questions
What is Selenium IDE?
What is Selenium WebDriver?
Best Selenium Testing Interview Questions
What is Selenium?
Best Web Development IDE
Security Testing Tools
Software Testing Tools
Best Blockchain Courses

Источник

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

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

Определение

Тестирование систем и программного обеспечения – процесс исследования, а также испытания приложений. Его цель – это проверка соответствия между реальным поведением ПО с выдвинутыми ранее ожиданиями на конечном наборе тестов. Они выбираются конкретным образом.

Системное тестирование – проверка работоспособности операционных систем. Больше относится к администрированию, чем к разработке контента. Важный процесс, без которого не состоится ни один релиз ОС.

Цели

Тестирование преследует определенные цели. К ним относят:

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

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

Для чего необходим

Тест – процесс проверки чего-либо. В разработке систем он очень важен. Помогает:

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

За счет соответствующего комплекса мероприятий удается повысить уровень доверия к компании-производителю. Выход на рынок качественной системы, лишенной ошибок и неполадок – это верный путь к повышению рейтинга предприятия.

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

Такая проверка помогает снизить стоимость итоговых работ. Связано это с тем, что на ранней стадии системы корректируются дешевле, быстрее и проще. Чем позже удалось найти ошибки, тем дороже обходится их устранение. Это касается даже самых простых программ.

Немного терминологии

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

Качество ПО – совокупность характеристик системы, которые относятся к ее способности удовлетворять установленные и предполагаемые потребности. То, насколько контент соответствует изначальным критериям.
Верификация – процесс оценки системы или ее компонентов. Делается это для того, чтобы проверить, насколько результаты разработки на заданном этапе удовлетворяют начальным требованиям. Показывает, выполняются ли цели и задачи организации на том или ином шаге программирования.
Валидация – соответствие программного продукта или системы ожиданиям, желаниям, потребностям пользователя. То, насколько ПО соответствует явным требованиям (спецификациям).

Также стоит разобраться с фазами жизненного цикла. ЖЦ – это процедуры и процессы, с которыми сталкивается приложение/система на каждой стадии разработки от зарождения первоначальной идеи до релиза и поддержки. Жизненный цикл есть у любого программного обеспечения.

О качестве

Что собой представляет качество ПО, понятно. Данный процесс имеет несколько «видов» контроля (проверок). Каждый предусматривает свои ключевые особенности:

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

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

Принципы организации

Рассматривая основы тестирования ПО и систем, нужно разобраться в принципах изучаемых комплексов мероприятий:

Тестирование указывает на наличие дефектов. Оно может указать на то, что в процессе разработки присутствует тот или иной дефект. А вот доказать отсутствие таких неполадок – нет. Проверка ПО снижает вероятность наличия дефектов, но вот то, что их нет, гарантировать никак не может.
Исчерпывающие проверки системе недостижимы. Полное тестирование с использованием всех комбинаций вводов и предусловий выполнить физически не получится. Исключение – нетривиальные задачи. Вместо исчерпывающего «анализа» нужно использовать оценивание рисков и расстановку приоритетов. Такой подход позволяет сконцентрироваться на более точном получении итогового результата.
Раннее тестирование. Проверки должны начинаться как можно раньше в жизненном цикле программного обеспечения. Это помогает быстрее обнаружить неполадки. Фокусироваться такие тесты должны на конкретных целях.
Скопление дефектов. Разные системные модули содержат различные дефекты – не только по типу, но и по количеству. Плотность скопления неполадок и сбоев в разных частых кода может варьироваться. Условия по тестированию систем должны распределяться пропорционально плотности обнаруженных дефектов. Основная часть критических ошибок приходится на ограниченное число модулей системы.
«Пестицидный» парадокс. При прогоне одних и тех же тестов несколько раз, в конечном итоге набор тестовых сценарием перестанет находить новые дефекты. Чтобы избавиться от этого парадокса, сценарии должны регулярно рецензироваться и изменяться. Новые тесты, формируемые специалистами, обязательно становятся разносторонними. Это помогает охватить все компоненты системы с целью обнаружения большего количества дефектов.
Зависимость от контекста. Тесты выполняются по-разному. Все зависит от того, какой контекст изначально заложен. Пример – программный продукт, для которого на передовой находится безопасность, будет проверяться на работоспособность иначе, чем обычный информационно-новостной портал.
Заблуждение об отсутствии неполадок. При тестировании не всегда обнаруживаются неполадки и ошибки. Это не значит, что система подготовлена на все 100% к релизу. Может получиться так, что дефекты будут критическими и скрытыми. Проект должен не только не иметь неполадок (особенно если речь идет о масштабной разработке), но и быть удобным для использования потребителями.

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

Этапы

Для выполнения тестов и отладки системы, нужно организовывать процессы правильно. Существует некий алгоритм, отражающий этапы тестирования:

Анализ имеющегося продукта. Это – первоначальная идея (задумка) проекта.
Работа с требованиями. На предыдущем этапе происходит формирование технического задания. Теперь предстоит изучить его и доработать, если это необходимо.
Разработка стратегий тестирования и планирование процедур по контролю качества.
Создание тестовой документации. Это – этап, на котором формируется «отчетность» для тестировщиков. Вспомогательные документы, опираясь на которые, специалисты будут грамотно выстраивать процессы.
Тестирование прототипов.
Основной этап проверок. Здесь выявляется полноценная работоспособность приложения, а также соответствие первоначальным требованиям заказчика.
Стабилизация и отладка.
Релиз и эксплуатация.

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

Жизненный цикл

Стадии разработки программного обеспечения – это этапы (шаги), которые проходят команды разработчиков перед тем, как проект станет доступным для широкого круга пользователей. Разработка начинается с первоначального этапа процесса (пре-альфа), продолжается поэтапно. На каждом очередном «шаге» контент будет дорабатываться, модернизироваться. Финальная стадия – выпуск окончательной версии системы или ПО.

Жизненный цикл можно представить похожим на этапы тестирования. Он обычно включает в себя:

непосредственный анализ требований к приложению или системе;
проектирование;
реализацию;
тестирование;
внедрение и поддержку.

Каждая стадия получает свое «имя» или порядковый номер: пре-альфа, альфа, бета, релиз-кандидат, релиз, а также пост-релиз.

Основные требования

Когда с общим представлением тестирования программ удалось ознакомиться, можно приступать к более сложным задачам. Рассматриваемые операции имеют требова ния. Это – спецификации (описания) того, что должно быть реализовано в ходе разработки системы/продукта. Описывают моменты, которые нужно воплотить в жизнь, не отражая техническую детализацию.

Сюда можно отнести следующие критерии:

Корректность. Каждое требование обязательно точно описывает желаемые инструменты и функции.
Проверяемость. Требование формулируется так, чтобы существовали способы однозадачной проверки на факт выполнения.
Полнота. Каждое описание содержит информацию, которой достаточно разработчику для грамотной реализации того или иного функционала.
Недвусмысленность. Сформулированные описания являются понятными. Они трактуются только одним способом. Неоднозначные аббревиатуры и выражения в них отсутствуют.
Непротиворечивость. Описание не должно содержать внутренних противоречий. То же самое касается «несоответствий» техническому заданию и иным документам.
Приоритетность. Приоритет требования представлен количественной оценкой степени важности.
Атомарность. Описание нельзя разделить на более мелкие без потери завершенности. Каждое требование описывает всего одну ситуацию.
Модифицируемость. Указывает на простоту внесения изменений в отдельные описания или их наборы.
Возможность отслеживания. Каждое описание имеет уникальный идентификатор. Он помогает обнаружить требование при необходимости.

Описание не может быть необязательным. Это – явное противоречие самому замыслу требований к тестированию.

Виды

Тестирование программ может быть разным. Классифицировать этот процесс можно по различным признакам. Ниже – основные варианты.
Функциональные типы: функциональное тестирование, проверка пользовательского интерфейса, анализ систем безопасности, тестирование взаимодействия.
Нефункциональное тестирование: все виды проверки производительности (нагрузочное, стрессовое, стабильности или надежности, объемное), проверка установок и удобства пользования, тестирование на отказ и восстановление. Сюда также относят конфигурационные проверки.
Связанные с изменениями: дымовое, регрессионное, повторное тестирование. К данной категории относят проверку сборки и согласованности (исправности) системы.

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

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

Рассматривает заранее указанное поведение. Базируется на анализе спецификаций функциональности компонентом или систем. Позволяет проверить ключевые задачи проекта.

Проверка пользовательского интерфейса

Называется GUI Testing. Позволяет провести функциональную проверку интерфейса. Это – то, что позволяет понять, насколько получившийся контент соответствует изначальной задаче. Сюда относят анализ размера интерфейса, шрифтов, меню и других особенностей.

Тестирование безопасности

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

Проверка работоспособности

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

Нагрузочные проверки

Нагрузочное тестирование. Базируется на автоматизации. Позволяет проверить автоматически, как бизнес-пользователи будут работать на том или ином ресурсе. Это – имитация поведения потенциальной целевой аудитории.

Стрессовые тесты

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

Объемное тестирование

Это – получение оценки производительности. В основе заложено увеличение объемов обрабатываемой в БД информации программы.

Тест надежности

Проводится для того, чтобы удостовериться в работоспособности системы. Предусматриваются ситуации, при которых клиент использует проект длительно. Нагрузка здесь – средняя.

Проверка установок

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

Удобство пользования

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

Отказ и восстановление

Проверяет:

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

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

Конфигурационные проверки

Специальный вид «анализа». Он направлен на проверку работы системы при применении разного рода настроек системы. Пример – разнообразные ОС или драйверах.

Дымовые тесты

Это с точки зрения «анализа процессов» — короткие циклы тестов. Они помогают удостовериться в том, что после сборки код будет работать и выполнять заданные функции. В основном используется при обновлениях и доработках.

Регрессионные тесты

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

Повторные тесты

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

Тесты сборок

Направлены на соответствие выпущенной версии критериям качества в начале тестирования. Это – аналог «дымового» подхода.

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

Узконаправленный «анализ». Его хватает для того, чтобы показать, что конкретная функция работает согласно задумке. Это – подмножество регрессионного тестирования. Позволяет понять, насколько определенная часть системы остается работоспособной после внедрения обновлений в коде или окружающей среде.

Иные виды

Каждый тестировщик говорит о том, что тестирование систем и ПО бывает разным. Способов классификации очень много. Кроме перечисленных вариантов можно выделить:

Статическое тестирование. Код не будет выполняться. Все проверки осуществляются вручную. Направлено на повышение качества итогового продукта.
Динамическое. Это – выполнение кода. Нацелено на функциональное поведение системы, использование памяти, общую производительность. Позволяет подтвердить то, что проект работает согласно задумке.
Ручное тестирование систем. Начинать и организовывать анализ проекта придется вручную. Долгий и затратный процесс.
Автоматизированный вариант. Хотя ручное тестирование до сих пор есть, на передовую выходить автоматизация. Это – проверка работоспособности ПО при помощи специальных приложений и функций.
Позитивные тесты. Здесь применяются только корректные электронные материалы.
Негативные тесты. Проверка системы, при которой используются некорректные данные. Выполнять будут «неправильные» операции.
Модульный подход. Проверка логически выделенного и изолированного компонента системы.
Интеграционный вариант. Проверяет, насколько несколько модулей системы хорошо взаимодействуют друг с другом и иными частями ПО.

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

О типах

Существует тестирование белого ящика. Это – метод, который предполагает, что внутренняя структура, устройство и реализация известны специалисту. Сюда можно отнести проверки, базирующиеся на анализе внутренней структуры элемента/системы, а также тест-дизайн.

Есть тестирование серого ящика. Метод, предполагающий сочетание «черного» и «белого» ящиков. Внутреннее устройство программы будет известно лишь частично.

Тестирование черного ящика – тест, базирующийся на спецификации. Является тестированием поведения.

Как стать тестировщиком

Стадии тестирования ПО, его ключевые виды и иные особенности рассмотрены. Тестировщик – это специалист, которые проверяет системы и приложения. Обычно непосредственной разработкой такой человек не занимается.

Это важный специалист в любой команде. Чтобы стать тестировщиком, можно изучить специализированную литературу и попрактиковаться на различных мелких проектах. Но лучше всего завершить компьютерные онлайн курсы. Там в сжатые сроки дадут «базу» для погружения в IT-профессию, а также предоставят богатый практический опыт. В конце обучения выдается электронный сертификат, способный подтвердить документально приобретенный спектр знаний, навыков и умений.

P. S. Большой выбор курсов по тестированию есть и в Otus. Есть варианты как для продвинутых, так и для начинающих пользователей.

Источник

I. Виды тестирования по цели

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

Функциональные.
Нефункциональные.
Связанные с изменениями.

Функциональные виды тестирования

Функциональные тесты базируются на функциях и особенностях, а также на взаимодействии с другими системами и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing), приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов.

Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.

Тестирование функциональности может проводиться в двух аспектах:

Требования.
Бизнес-процессы.

Тестирование в аспекте «требования» использует спецификацию функциональных требований к системе, как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.

Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этом аспекте тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

2. Тестирование безопасности (Security and Access Control Testing)

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

Общая стратегия безопасности основывается на трех основных принципах:

Конфиденциальность.
Целостность.
Доступность.

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

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

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

3. Тестирование взаимодействия или Interoperability Testing

Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing).

Нефункциональные виды тестирования

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

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

Тестирование производительности ( Performance testing ).

Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:

Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.

Определение количества пользователей, одновременно работающих с приложением.

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

Исследование производительности на высоких, предельных, стрессовых нагрузках.

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

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

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

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

Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.

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

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

2. Тестирование установки (Installation Testing)

Тестирование установки направленно на проверку успешной инсталляции и настройки, а также на обновление или удаление программного обеспечения.

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

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

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

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

Активизация в памяти ( recall ) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени (повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя).

Эмоциональная реакция ( emotional response ) – как пользователь себя чувствует после завершения задачи — растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция — лучше).

Виды тестирования связанные с изменениями

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

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

Дымовое тестирование (Smoke Testing)
Регрессионное тестирование (Regression Testing)
Тестирование сборки (Build Verification Test)
Санитарное тестирование или проверка согласованности/исправности (SanityTesting)

Дымовой тест (англ. Smoke testing или smoke test, дымовое тестирование) — в тестировании программного обеспечения означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется программистом; не проходившую этот тест программу не имеет смысла отдавать на более глубокое тестирование.

Тестирование сборки (Build Verification Test), как и дымное тестирование, направленно для предварительной проверки разрабатываемого программного продукта перед запуском полномасштабного тестирования по всем параметрам, проводимого командой тестировщиков. Проводится оно для того, чтобы знать – готов ли релиз для такого этапа разработки ПО, как Тестирование или же он еще нуждается в доработке.

Тестирование сборки состоит из набора коротких тестов, которые и определяют готовность сборки.

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

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

Цель санитарного тестирования — проверить «рациональность» системы после изменений, чтобы продолжить более тщательное тестирование.

II. Виды тестирования по степени автоматизации

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

Тем не менее, перед тем как автоматизировать тестирование любого приложения, необходимо сначала выполнить серию тестов вручную. Мануальное тестирование требует значительных усилий, но без него мы не сможем убедиться в том, возможна ли автоматизация в принципе. Один из фундаментальных принципов тестирования гласит: 100% автоматизация невозможна. Поэтому, ручное тестирование – необходимость.

Мифы о ручном тестировании:

– кто угодно может провести ручное тестирование

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

– автоматизированное тестирование мощнее ручного

Полная автоматизация невозможна. Необходимо использовать также и ручное тестирование.

– ручное тестирование – это просто

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

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

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

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

Существует несколько основных видов автоматизированного тестирования:

– автоматизация тестирования кода (Code-driven testing) – тестирование на уровне программных модулей, классов и библиотек (фактически, автоматические юнит-тесты);

– автоматизация тестирования графического пользовательского интерфейса (Graphical user interface testing) – специальная программа (фреймворк автоматизации тестирования) позволяет генерировать пользовательские события – нажатия клавиш, клики мышкой, и отслеживать реакцию программы на эти действия – соответствует ли она спецификации.

– автоматизация тестирования API (ApplicationProgrammingInterface) – программного интерфейса программы. Тестируются интерфейсы, предназначенные для взаимодействия, например, с другими программами или с пользователем. Здесь опять же, как правило, используются специальные фреймворки.

Автоматические тесты – это полноценные программы, просто предназначенные для тестирования.

III. Виды тестирования по запуску кода

Статическое тестирование (static testing) — тестирование без запуска кода на исполнение.

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

Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации.

Можно поделить статическое тестирование на 2 типа:

1. Обзоры (Review)

2. Статический анализ (Static Analysis)

Обзоры

Обзоры (Review) – проверка обычно используется для поиска и устранения ошибок или неясностей в документах. Это могут быть требования, дизайн, тестовые случаи и так далее.

В свою очередь обзоры делятся на:

Неформальные. При неофициальном рассмотрении создатель документов показывает содержание документов аудитории. Каждый присутствующий высказывает свое мнение, что позволяет выявить недостатки на ранней стадии.
Сквозные просмотры (Walkthroughs). Выполняются опытным человеком или экспертом для проверки отсутствия дефектов, с целью предупреждения возникновения проблем на этапе разработки или тестирования.
Экспертная оценка. Означает проверку документов для выявления и исправления дефектов. В основном это делается в команде.
Инспектирование ПО. Это, в большинстве, проверка документа вышестоящим органом, например, проверка требований к программному обеспечению.

Статический анализ

Статический анализ (Static Analysis) – код, написанный разработчиками, анализируется на наличие структурных дефектов, которые могут привести к ошибкам.

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

— неиспользуемые переменные,

— мертвый код,

— бесконечные циклы,

— переменные с неопределенными значениями,

— неправильный синтаксис.

В рамках этого подхода тестированию могут подвергаться:

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

Динамическое тестирование (dynamic testing) — тестирование с запуском кода на исполнение. Запускаться на исполнение может как код всего приложения целиком (системное тестирование), так и код нескольких взаимосвязанных частей (интеграционное тестирование), отдельных частей (модульное или компонентное тестирование) и даже отдельные участки кода.

Основная идея этого вида тестирования состоит в том, что проверяется реальное поведение (части) приложения.

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

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

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

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

IV. Виды тестирования по времени проведения

Альфа и Бета тестирование

Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

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

Часто для свободного/открытого ПО стадия альфа — тестированияхарактеризует функциональное наполнение кода, абета — тестирования— стадию исправления ошибок. При этом как правило на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.

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

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

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

Регрессионное тестирование

Регрессио́нное тести́рование (англ. regression testing, от лат. regressio — движение назад) — собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода. Такие ошибки — когда после внесения изменений в программу перестает работать то, что должно было продолжать работать, — называют регрессионными ошибками (англ. regression bugs).

Регрессионное тестирование (по некоторым источникам) включает new bug-fix — проверка исправления найденного ранее дефекта, old bug-fix — проверка, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова, а также side-effect — проверка того, что не нарушилась работоспособность работающей ранее функциональности, если ее код мог быть затронут при исправлении некоторых дефектов в другой функциональности. Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов, а также проверки, не попали ли регрессионные ошибки в очередную версию в результате слияния кода.

Из опыта разработки ПО известно, что повторное появление одних и тех же ошибок — случай достаточно частый. Иногда это происходит из-за слабой техники управления версиями или по причине человеческой ошибки при работе с системой управления версиями. Но настолько же часто решение проблемы бывает «недолго живущим»: после следующего изменения в программе решение перестаёт работать. И наконец, при переписывании какой-либо части кода часто всплывают те же ошибки, что были в предыдущей реализации.

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

Регрессионное тестирование является неотъемлемой частью экстремального программирования. В этой методологии проектная документация заменяется на расширяемое, повторяемое и автоматизированное тестирование всего программного пакета на каждой стадии цикла разработки программного обеспечения.

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

Приемочное тестирование или Приемо-сдаточное испытание (User Acceptance Testing)

Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

определения удовлетворяет ли система приемочным критериям;
вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

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

продукт достиг необходимого уровня качества;
заказчик ознакомлен с Планом Приемочных Работ (Product Acceptance Plan) или иным документом, где описан набор действий, связанных с проведением приемочного тестирования, дата проведения, ответственные и т.д.

Фаза приемочного тестирования длится до тех пор, пока заказчик не выносит решение об отправлении приложения на доработку или выдаче приложения.

V. Виды тестирования по доступу к коду (методы тестирования)

Метод белого ящика

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

Метод черного ящика

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

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

VI. Виды тестирования по позитивности сценария

Позитивное тестирование – это тестирование с применением сценариев, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. С его помощью мы можем определить, что система делает то, для чего и была создана. Например, умножение на калькуляторе цифр 3 и 5.

Негативным называют тестирование, в рамках которого применяются сценарии, которые соответствуют внештатному поведению тестируемой системы. Это могут быть, например, исключительные ситуации или неверные данные. На примере калькулятора, это умножения числа 3 на грушу. Значение “груша” не является валидным для калькулятора.

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

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

Источники:

https://qastart.by/class/vidi-testirovaniya-m/4-vidi-testirivaniya-po-celi
http://www.protesting.ru/testing/testtypes.html
https://qalight.ua/ru/baza-znaniy/ruchnoe-i-avtomatizirovannoe/
https://studfile.net/preview/2426273/page:7/
https://vk.com/@zapiskisedogotestera-vidy-testirovaniya-po-zapusku-koda
https://qalight.ua/ru/baza-znaniy/testirovanie-sborki/
https://intellect.icu/sanitarnoe-testirovanie-ili-proverka-soglasovannosti-ispravnosti-ili-sanity-testing-6092

Источник

Сначала картинки

Функциональное тестирование — виды

Нефункциональное тестирование — виды

Виды (типы) нефункционального тестирования:

Типы тестирования: общий список

Юнит-тестирование

Интеграционное тестирование

Сквозное тестирование

Тестирование интерфейса

Тестирование доступности

Альфа-тестирование

Бета-тестирование

Ad-hoc-тестирование

Тестирование совместимости

Тестирование обратной совместимости

Кроссбраузерное тестирование

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

Нагрузочное тестирование

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

Регрессионное тестирование

Agile-тестирование

Тестирование API

Тестирование черного ящика

Тестирование белого ящика

Тестирование безопасности

Юзабилити-тестирование

Тестирование масштабируемости

Тестирование надежности

Приемочное тестирование

Функциональные виды тестирования

Конфиденциальность

Целостность

Доступность

Нефункциональные виды тестирования

Тестирование производительности ( Performance testing ).

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

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

Уровни проведения

Советы по улучшению удобства пользования:

Заблуждения о тестировании удобства пользования:

Связанные с изменениями виды тестирования

Отличие санитарного тестирования от дымового (Sanity vs Smoke testing)

Table of Contents

Types of Software Testing

1. Functional Testing

2. Non-functional Testing

Different Types of Software Testing

1. Unit Testing

2. Integration testing

3. End-to-end Testing

4. User Interface Testing

5. Accessibility testing

6. Alpha testing

7. Beta testing

9. Compatibility testing

10. Backward compatibility testing

11. Browser compatibility testing

12. Performance testing

13. Load testing

14. Recovery testing

15. Regression testing

16. Agile testing

17. API testing

18. Black box testing

19. White box testing

20. Security testing

21. Usability testing

22. Scalability testing

23. Reliability testing

24. Acceptance testing

Final words

Table of Contents

Types of Software Testing

1. Functional Testing

2. Non-functional Testing

Different Types of Software Testing

1. Unit Testing

2. Integration testing

3. End-to-end Testing

4. User Interface Testing