в чем разница между функциональным и нефункциональным тестированием

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестирование методом черного ящика (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 нету.

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

Резюме

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

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

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

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

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

Источник

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

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

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

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

Функциональные тесты базируются на функциях и особенностях, а также на взаимодействии с другими системами и могут быть представлены на всех уровнях тестирования: компонентном или модульном (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)

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

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

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

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

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

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

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

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

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

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

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 основных типа регрессионного тестирования:

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

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

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

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

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

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

Источник