Что такое функциональное тестирование простыми словами?
Функциональное тестирование проверяет пригодность приложения (сайта) — делает ли приложение (сайт) то, что должно?
Словами посложнее: тестирование, проверяющее ПО на соответствие функциональным требованиям.
Итак, задача функционального тестирования — проверить, что все функции приложения работают как положено, то есть как прописано в функциональных требованиях.
В функциональном тестировании проверяется каждая функция, путем ввода значений и проверки вывода: соответствует ли функция функциональным спецификациям, то есть совпадает ли результат с ожидаемым от этой функции.
Часто упоминаемые подтипы функционального тестирования — санитарное тестирование и интеграционное тестирование. Функциональное тестирование проверяет пользовательский интерфейс, API, базы данных и пр.; может быть как ручным, так и автоматизированным.
Тестировщик с нуля / Урок 7 / Функциональное тестирование
Что делает функциональное тестирование?
Функциональное тестирование сосредоточено на проверке:
- Ключевых функций
- А также правильности обработки ошибок (то есть, выдает ли система сообщения об ошибках при их возникновении)
Преимущества
- Позволяет убедиться, что в продукте нет «фундаментальных» ошибок
- Продукт отвечает требованиям
- Качество продукта выше
- Пользователи удовлетворены
Как выполняется
Рассмотрим ход функционального тестирования, упрощенно:
- Создать наборы тестовых данных.
- Выполнить тест-кейсы.
- Сравнить полученный и ожидаемый результат.
В более подробном изложении:
- Тщательно ознакомиться с функциональными спецификациями. Что будет тестироваться? Главная функция приложения, его сообщения, условия при которых возникают ошибки, общая юзабельность приложения.
- Создать тестовые данные на основе готовых требований к продукту.
- Оценка ожидаемых (приемлемых) выводов в ответ на значения тестовых данных. Какие должны быть выводы (результаты), в соответствии с требованиями.
- Выполнение тест-кейсов.
- Сравнение полученного вывода с ожидаемым. Здесь получим ответ, работает ли приложение, как положено.
В чем разница между функциональным и нефункциональным?
Функциональное тестирование сосредоточено на функциональных аспектах приложения, а нефункциональное — на нефункциональных. В задачи нефункционального тестирования входит проверка таких вещей как производительность, надежность, масштабируемость.
Нефункциональное тестирование проводится после функционального, как менее приоритетное.
Функциональное тестирование — это о том, что софт делает, а нефункциональное — как хорошо он это делает.
Функциональное тестирование фокусируется на «механике», а нефункциональное — на «результатах».
Примеры функционального тестирования: юнит-тестирование, smoke-тестирование и другие (ниже список).
Примеры нефункционального тестирования: тестирование производительности, тестирование совместимости, нагрузочное тестирование:
Типы
Какие бывают типы (категории) функционального тестирования?
Лучшие практики
1. Создавать тест-кейсы как можно раньше.
Создавать тест-кейсы можно, не ожидая готовности модулей или всего приложения. Лучше писать их заранее, когда пользовательские требования самые “свежие” на начальных этапах. Всегда можно внести изменения потом.
2. Автоматизация
Функциональное тестирование не самая простая задача в QA. Продуманная автоматизация тест-кейсов позволяет закончить тесты раньше, что дает экономию времени и денег. Все тест-кейсы автоматизировать не получится, это невозможно, поэтому это делается только с важными тест-кейсами. Обычно автоматизируются часто повторяемые тесты, которые “принимают” разные данные; а также те, которые особенно уязвимы к человеческим ошибкам.
3. Понимать, как мыслит конечный пользователь
Нужно понимать, какие пользователи будут у приложения, и подстраиваться под них. Нужно понимать, как пользователь работает с приложением, какими функциями пользуется активно, а какими не очень.
4. Приоритеты
Нужно выделить наиболее используемые функции, то есть присвоить им приоритет, и разумеется тестировать их в первую очередь и с большей отдачей. Немыслима ситуация, когда главная функция приложения не покрыта тестированием во всех деталях.
5. Частое тестирование
Нужно подготовить чеклист автоматизации и придерживаться его, регулярно выполняя. Порядок в автоматизации помогает найти больше багов.
6. DDT-методика (Data Driven Testing)
Подробнее здесь.
Инструменты
Selenium
Инструмент №1 в QA “в целом”. Функциональное тестирование веб-приложений и десктопа. Подробнее о Selenium: раз, два, три, четыре.
SoapUI
Вероятно, самый часто используемый (по крайней мере, на Западе)) инструмент для SOAP- и REST-тестирования. Открытый инструмент с приятным интерфейсом и enterprise-функциональностью. Быстро создает и выполняет автоматизированные функциональные, регрессионные и нагрузочные тесты.
Watir
Странное “арабское” название означает на самом деле “Web Application Testing in Ruby”. Открытый инструмент для тестирование веб-приложений — не только написанных на Ruby. Поддерживает почти все браузеры.
Практический пример — функциональное тестирование сайта
Ситуация:
Портал, в который пользователь залогинивается со своим именем-паролем. На странице логина — два соответствующих поля, и две кнопки Login и Cancel.
При успешном входе страница перенаправляет пользователя на главную страницу портала. Кнопка Cancel отменяет логин.
Спецификации:
- В поле User ID (имя) должно быть не менее 6 и не более 10 символов, среди них могут быть буквы включая прописные, цифры, и специальные символы (только подчеркивание, дефис и точка). Поле не может быть оставлено пустым. Первый символ должен быть буквой или цифрой, но не спецсимволом.
- В поле пароля должно быть не менее 6 и не более 8 символов, допускаются буквы включая прописные, цифры, и специальные символы (подчеркивание, дефис и точка). Поле не может быть пустым.
Этот юзкейс можно протестировать следующими техниками функционального тестирования:
Поскольку здесь поле User ID может принимать максимум 10 символов, оно должно вести себя одинаково всякий раз когда вводится больше 10 символов.
Поскольку здесь поле User ID требует как минимум 6 символа, проверяют, как система отвечает, когда введено меньше чем 6.
Когда пользователь залогинился и что-то делает, администратор удаляет его экаунт.
Источник: testengineer.ru
Лекция 12. Методы функционального тестирование программных продуктов
Структурное тестирование, несмотря на высокую степень формализации, никогда не сможет полностью заменить функциональное, так как в процессе проектирования программы некоторые входные условия могут быть упущены.
Функциональное тестирование – это тестирование, проводимое для проверки соответствия программной системы или программного модуля специфицированным функциональным требованиям.
При функциональном тестировании игнорируются внутренние механизмы работы программы или программной системы; все внимание фокусируется только на выходных значениях, генерируемых в ответ на выбранные входные значения и условия выполнения.
При функциональном тестировании графовые модели используются весьма редко, а если и используются, то не отражают внутреннюю логику работы программы.
Рассмотрим наиболее широко применяемые методы функционального тестирования, или тестирования по принципу «черного ящика».
1. Метод эквивалентного разбиения
Цель – выбрать минимальное подмножество тестов, обеспечивающих наибольшую вероятность обнаружения ошибок.
Правильно выбранный тест этого подмножества должен обладать двумя свойствами:
- включать как можно больше входных условий с тем, чтобы минимизировать общее число тестов;
- разбивать входные данные программы на конечное число классов эквивалентности так, чтобы можно было предположить, что если один тест класса эквивалентности обнаруживает ошибку, то следует ожидать, что и все другие тесты этого класса эквивалентности будут обнаруживать ту же самую ошибку и, наоборот, если тест не обнаруживает ошибки, то следует ожидать, что ни один тест этого класса не будет обнаруживать ошибки (в том случае, когда некоторое подмножество класса эквивалентности не попадает в пределы другого класса эквивалентности, так как классы эквивалентности могут пересекаться).
Разработка тестов методом эквивалентного разбиения осуществляется в два этапа:
- выделение классов эквивалентности;
- построение тестов.
1.1. Выделение классов эквивалентности
Классы эквивалентности выделяются путем выбора каждого входного условия (предложение спецификации) и разбиения его на две или более групп.
Различают два типа классов эквивалентности:
- правильные классы эквивалентности, представляющие правильные входные данные программы;
- неправильные классы эквивалентности, представляющие ошибочные входные данные.
Выделение классов эквивалентности представляет собой взначительной степени эвристический процесс. Однако существует ряд правил, которые следует выполнять:
- Если входное условие описывает область значений (например, 1I100), то задается один правильныйкласс эквивалениности (1I100) и два неправильных( X< 1и X>100).
- Если входное условие описывает число значений(например, число элементов последовательности Nне должно превышать 10), то определяется один правильныйкласс эквивалентности (N10) и два неправильных(Nи N>10).
- Если входное условие описывает множество входных значенийи есть основание полагать, что каждое значение программа трактует особо (например, цветможет принимать значения: красный,желтый,зеленый), то определяется правильныйкласс эквивалентности для каждого значения и один неправильный класс эквивалентности – значение, не принадлежащее множеству (например, белый).
- Если входное условие описывает ситуацию “должнобыть” (например, первым символом идентификаторадолжна бытьбуква), то определяется один правильныйкласс эквивалентности (первый символ – буква) и один неправильный класс эквивалентности (первый символ – не буква).
- Если есть основание считать, что различные элементы класса эквивалентности трактуютсяпрограммой неодинаково, то данный класс эквивалентности разбивается на меньшие классы эквивалентности.
Источник: studfile.net
Home
Тестирование функциональности является основным видом тестирования, потому что программа в первую очередь должна работать правильно, и только после этого можно говорить о том, насколько она быстрая или удобная
Как разобраться с плавающими багами |
18.04.2022 00:00 | |
Плавающие баги раздражают не только тестировщиков, но и остальную команду. Возможно, вам повезло, и вы поймали такой баг до того, как он дошел до бета-тестировщиков – или же вы пытаетесь разобраться, что тут, черт возьми, произошло, потому что пользователи сообщили о баге, но вы не можете его воспроизвести. Ниже – ряд идей, как быть с плавающими багами. |
SQA Days-24: функциональное тестирование |
21.01.2019 00:00 | |
Публикуем подборку докладов с конференции SQA Days 24, посвященную функциональному тестированию. |
Самодельные аддоны к браузерам на службе тестировщика |
30.05.2018 14:13 | |
Оригинальная публикация Аддоны к браузерам вряд ли пригодятся в автоматизации тестирования web-систем, но при ручном тестировании они могут оказаться полезны. К примеру, можно заполнять элементы на выбранной странице, исходя из своих условий и входных данных. Ниже рассмотрено создание такого аддона для Firefox и Chrome без претензий на красоту кода. Задача: разработать аддон для Firefox и расширение для Chrome со следующей функциональностью: 1. В тулбаре появляется кнопка (иконка). 2. При нажатии на эту кнопку анализируется URL активной страницы (вкладки). Если URL – один из заранее заданных URLs, то при нажатии на кнопку тулбара скрипт берет пару “пользователь-пароль” из опций в зависимости от URL и заполняет поля ввода логина и пароля на странице. Далее скрипт нажимает кнопку логина. |
|
Подробнее. |
Особенности тестирования «черного ящика» |
24.11.2017 00:00 | |
Что такое «черный ящик» согласно терминологии ISTQB?Black-box тестирование – это функциональное и нефункциональное тестирование без доступа к внутренней структуре компонентов системы. Метод тестирования «черного ящика» – процедура получения и выбора тестовых случаев на основе анализа спецификации (функциональной или нефункциональной), компонентов или системы без ссылки на их внутреннее устройство.
|
Николай Алименков: TDD c помощью функциональных тестов на WebDriver |
21.02.2012 16:03 | |
По традиции, мы публикуем лучшие, по мнению участников, выступления с наших онлайн-конференций. Сегодня мы предлагаем ознакомиться с докладом «диверсанта», пришедшего на нашу конференцию Auto ConfeTс той стороны баррикад» — более разработчика, чем тестировщика, Николая Алименкова. Не секрет, что разработчики тоже пишут тесты, для себя, и даже придумали специальный подход к разработке, направляемый тестами — TDD (Test-Driven Development). Николай предложил перенести эту идею с уровня модульного тестирования на уровень разработки пользовательского интерфейса. Насколько удачно это получилось — судите сами. |
Алексей Баранцев: Кроссбраузерное тестирование |
20.02.2012 09:46 | |
Несколько дней назад завершилась онлайн-конференция Auto ConfeTQA 2012. А тем временем мы предлагаем посмотреть рассказ Алексея Баранцева о кроссбраузерном тестировании с прошлогодней «конфетки» — конференции ConfeThttps://www.software-testing.ru/library/testing/functional-testing» target=»_blank»]www.software-testing.ru[/mask_link] |