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

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

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

Функциональное тестирование (Functional testing) — Тестирование ПО, направленное на проверку того, что компонент либо система соответствует функциональным требованиям.

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

Функциональность (Functionality) — Способность программного продукта обеспечивать функции, которые соответствуют установленным и предполагаемым потребностям, при использовании ПО в определенных условиях.

Простыми словами функциональное тестирование — это тестирование логики работы функций, т.е. ЧТО должна делать система или компонент.

Функциональное тестирование не включает в себя никакие другие подвиды тестирования!

Нефункциональное тестирование (Non-functional teting) — Тестирование атрибутов компонента или системы, не относящихся к функциональности, то есть надежность, эффективность, практичность, сопровождаемость и переносимость, удобство, доступность и т.д.

Почему у функционального тестирования нет подвидов?

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

Функциональное тестирование проверяет первую характеристику — функциональную пригодность.

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

Характеристи качества(Product Quality — ISO/IEC 25010)

Функциональное и нефункциональное тестирование может проводиться на любых уровнях и комбинироваться с другими группами тестов. Например, можно проводить функциональное тестирование при помощи техники исследовательского тестирования (Exploratory testing) или в рамках регрессионного тестирования проводить GUI тестирование при помощи техники свободного тестирования (Ad-hoc), методом серого ящика на уровнях интеграционного тестирования и тестирования критического пути.

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

Тестирование графического интерфейса (GUI testing) — анализ соответствия графического пользовательского интерфейса программы спецификациям, макетам, прототипам, стандартам.

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

Тестирование инсталляции (Installation testing) — Тестирование, направленное на проверку процессов установки, удаления, восстановления, обновления, лицензирования.

Тестирование безопасности (Safety testing) — Тестирование программного продукта с целью с целью определить его безопасность.

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

Тестирование защищенности (Security testing) — Тестирование с целью оценить защищенность программного продукта.

Защищенность (Security) — Свойства программного продукта, отражающие его способность не допускать неавторизированный доступ, случайный или умышленный, к программам и данным.

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

Тестирование производительности (Performance testing) — Процесс тестирования с целью определить производительность программного продукта.

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

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

Тестирование интернационализации (Internationalization testing) — Анализ приложения и его интерфейса на способность быть переведённым.

Тестирование локализации (Localization testing) — Анализ приложения и его сопроводительной документации на корректность в конкретной переведённой среде.

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

Тестирование кроссбраузерности (Cross browser testing) — Вид тестирования совместимости, направленный на анализ работы приложения в разных браузерах либо разных версиях одного браузера.

Тестирование кроссплатформенности (Cross platform testing) — Анализ работы одного и того же приложения на разных операционных системах\платформах.

Источник

Виды тестирования программного обеспечения

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

Виды Тестирования ПО можно разделить на несколько групп:

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

Первым, непосредственно, является Функциональное тестирование (Functional testing).

Направленное на проверку реализуемости функциональных требований. Иными словами — проверка способности ПО решать задачи, необходимые пользователям. Функциональные тесты могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). При этом, что делает ПО и какие задачи решает определяется Функциональными Требованиями.

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

Вторым из распространенных видов является Тестирование безопасности (Security and Access Control Testing).

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

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

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

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

Говоря о функциональном тестировании не стоит забывать и про Тестирование взаимодействия (Interoperability Testing).

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

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

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

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

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

Тестирование производительности (Performance and Load Testing).
Данный вид подразумевает собой автоматизированное тестирование, имитирующее работу определенного количества пользователей на ресурсе.
У него также есть свои виды:

Вторым видом нефункционального тестирования является Тестирование Установки (Installation testing).

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

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

Тестирование Удобства Пользования (Usability Testing), будет следующим видом, который мы рассмотрим.

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

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

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

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

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

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

В таких случаях принято использовать:

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

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

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

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

В заключении

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

Источник

Функциональное тестирование против нефункционального тестирования

Функциональное тестирование против нефункционального тестирования

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

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

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

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

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

Ниже приведены 10 основных отличий функционального тестирования от нефункционального тестирования.

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

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

Мотив:

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

Методы испытаний / суб-тесты:

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

Критерии для тестирования:

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

Ошибки, ошибки и дефекты :

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

Функциональное тестирование и Сравнительная таблица нефункционального тестирования

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

Источник

Собеседования

Требования к тестировщику ч.3: термины и определения

Подробно все базовые определения и понятия тестирования, а также разновидности и классы тестирования будут разобраны на примерах в отдельном разделе. В этой же статье будут рассмотрены только основные моменты, на которые стоит обратить особое внимание и сфокусироваться при подготовке к собеседованию: «Что такое тестирование ПО?» «Чем тестированеие отличается от QA?» «Что такое валидация и верификация и какая между ними разница?» «Какие бывают виды и типы тестирования?»

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

2. Многие интервьюеры интересуются, в чем отличие тестирования от QA. При ответе на этот вопрос лучше всего вспомнить и описать общую картину процесса обеспечения качества продукта. Есть 3 основных уровня:

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

3. Часто на интервью встречаются вопросы про различие верификации и валидации продукта:

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

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

В данном вопросе главное – суметь объяснить на примерах назначения и различия видов тестирования. Очень важно помнить и понимать, что все эти виды и типы тестирования не обязательно являются взаимоисключающими, их нельзя перечислить в один ряд через запятую. Это скорее взгляд с разных точек зрения на то, как тестировать и что тестировать. Поэтому, например, функциональное тестирование может быть: в рамках белого и черного ящика; можно проводить его вручную, а можно использовать автоматизацию; мы можем проверять позитивные или негативные функциональные сценарии; можно проверять функционал проходя по тестовым сценариям или без них и т.д. С остальными видами дело обстоит также.

Источник

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

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

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

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

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

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

Функциональное тестирование (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 нету.

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

Резюме

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

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

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

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

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

Источник