Типы тестирования

16 января, 2021

В статье разберем типы тестирования и их особенности, приведем несколько примеров 🙂

Типы тестирования
Типы тестирования

Что такое типы тестирования?

Тип тестирования — набор активностей, направленных на проверку качества системы, которые основываются на конкретных целях.

К целям относятся:

  1. Оценка функциональных характеристик качества.
    Например, завершенность и правильность работы системы.
  2. Оценка нефункциональных характеристик качества.
    Например, скорость работы или удобство использования системы.
  3. Оценка внутренней структуры и архитектуры системы на предмет соответствия спецификациям.
    Например, проверить соответствие реализации алгоритма заданному заданию.
  4. Оценка влияния исправлений или изменений на систему.
    Например, проверить, была ли исправлена найденная ранее ошибка или посмотреть, не “сломало” ли добавление нового функционала уже работающую логику.

Для каждой их перечисленных выше целей существует отдельный тип тестирования.

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

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

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

Другими словами, оно проверяет что делает система

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

  1. меню сайта (открывается / закрывается / ссылки)
  2. работу слайдеров
  3. отправку форм
  4. правильность показа сообщений / отзывов / информации на сайте
  5. и т.д. и т.п.

Функциональные тесты пишутся, основываясь на функциональных требованиях, которые можно найти в спецификациях, бизнес-требованиях, user story, use case и т.п.


Иногда, можно слышать фразу “проверить функционал приложения”. Имеется ввиду как раз этот тип тестирования 🙂


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

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

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

Значит, покрытие функциональности тестами равно:

(57 / 100) * 100% = 57%.

Нефункциональное тестирование (Non-Functional Testing)

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

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

Другими словами это проверка насколько хорошо работает система.

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

  • нагрузочное тестирование (Performance / Load Testing)
  • стрессовое тестирование (Stress Testing)
  • тестирование установки (Installation testing)
  • тестирование удобства пользования (Usability Testing)
  • тестирование на отказ и восстановление (Failover and Recovery Testing)
  • тестирование конфигурации (Configuration Testing)
  • кроссплатформенное тестирование (Cross Planform Testing)

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

  1. Правильность отображения сайта в разных браузерах / на разных устройствах
  2. Правильность отображения сайта при разных расширениях экрана
  3. Скорость загрузки страниц / скорость работы сайта
  4. Удобство использования
  5. Безопасность
  6. И т.д. и т.п.

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


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

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

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


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

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

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

Значит, покрытие функциональности тестами равно:

(23 / 30) * 100% = 77%.

Тестирование методом черного ящика (Black box testing)

К тестированию методом черного ящика относятся все активности тестирования, не связанные с проверкой внутренней структуры (кода).

К таким активностям относятся как функциональное, так и нефункциональное тестирование.

У вас может возникнуть вопрос:

Почему «черного ящика»? Откуда появилось это название?

Ответ:

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

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

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

Тестирование методом белого ящика (White Box Testing)

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

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

Этот метод тестирования подразумевает, что у тестировщика есть доступ «внутрь» системы и он может увидеть, как «физически» работает система.

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

Ведь на самом деле — какая разница какого цвета ящик — вы все равно не увидите, что внутри, если он будет покрашен!

«Метод прозрачного ящика» — более правильное название и оно встречается в англоязычной литературе, наряду с clear box testing, glass box testing, transparent box testing and structural testing.

Знайте, имеется ввиду одно и тоже!

Анализ и тестирование кода — дело сложное и рутинное.

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

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

Тем не менее, какими бы полезными и быстрыми не были автоматические инструменты, они не смогут найти неточности в логике работы

С точки зрения кода (структуры, правильности написания, форматирования…) все может быть идеально, но с точки зрения логики работы — нет 🙂

Например, в коде невозможно найти следующую неточность используя анализаторы кода (линтеры, Linters, IDE):

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

Активировать кнопку “Купить”, после выбора трех товаров.

Разработчик ошибается и активирует ее после выбора двух товаров.

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

Но в мире не существует инструментов, которые смогут понять, что число 2 в каком-то конкретном месте это ошибка. Для инструмента — это просто число, будь то 2, 3, или 100500 🙂

Из-за нюанса с логическими ошибками в коде тестирование условно делится на 2 части: автоматизированную и ручную проверку.

Автоматизированная проверка — оценивают качество кода, а ручная проверка — правильность реализации логики.

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

Тестирование, связанное с изменениями

Тестирование, связанное с изменениями

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

Его разделяют на 2 под-типа: подтверждающее и регрессионное.

Подтверждающее тестирование (Retesting)

Производят после исправления дефектов, используя тесты, которые приводили к возникновению отклонения. 

Основная цель тестирования — удостовериться, что дефект исправлен, и система работает в соответствии с требованиями.


Иногда возникают ситуации, когда исправление одного дефекта “показывает” другой, который был “недоступен” из-за первого 🙂

Разработчики не очень любят исправлять допущенные ошибки, по этому делают правки “торопясь” и могут допускать новые ошибки.. 

Поэтому при подтверждающем тестировании нужно быть очень внимательным!

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

Изменения, внесенные на этапе поддержки жизненного цикла ПО, иногда могут непреднамеренно “ломать” старый функционал. 

Например, вы добавили кнопку в меню на сайте и на телефонах оно перестало помещаться в экран 🙂 

Или, вы убрали поле из формы заказа, а на это поле была “завязана” логика отправки email клиенту. Теперь без убранного поля — смысла в email нету.


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

Резюме

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

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


Хотим отдельно заметить, что все типы тестирования могут применяться на всех уровнях тестирования

Это не обязательно, но чем больше типов применяется на конкретном уровне — тем качественнее будет продукт 🙂


Если вам интересна тема тестирования, и вы хотели бы получать актуальную информацию по этой теме  подписывайтесь на наш телеграм канал, там интересно: статьи, тесты, опросы, нет спама! 🙂 

Удачи!

🔥 Присоединяйся к 4,014
тестировщикам в Телеграм!