Тестирование ПО разделяют на функциональное и нефункциональное. Обсудим, что такое функциональное тестирование, как его принято выполнять, и чем оно отличается от нефункционального.
Содержание
- Что такое функциональное тестирование простыми словами?
- Для чего предназначено?
- Преимущества
- Как выполняется
- В чем разница между функциональным и нефункциональным тестированием?
- Какие существуют типы ФТ
- Лучшие практики
- Инструменты
- Практический пример
Что такое функциональное тестирование простыми словами?
Функциональное тестирование проверяет пригодность приложения (сайта) — делает ли приложение (сайт) то, что должно?
Словами посложнее: тестирование, проверяющее ПО на соответствие функциональным требованиям.
Итак, задача функционального тестирования — проверить, что все функции приложения работают как положено, то есть как прописано в функциональных требованиях.
В функциональном тестировании проверяется каждая функция, путем ввода значений и проверки вывода: соответствует ли функция функциональным спецификациям, то есть совпадает ли результат с ожидаемым от этой функции.
Часто упоминаемые подтипы функционального тестирования — санитарное тестирование и интеграционное тестирование. Функциональное тестирование проверяет пользовательский интерфейс, API, базы данных и пр.; может быть как ручным, так и автоматизированным.
Что делает функциональное тестирование?
Функциональное тестирование сосредоточено на проверке:
- Ключевых функций
- А также правильности обработки ошибок (то есть, выдает ли система сообщения об ошибках при их возникновении)
Преимущества
- Позволяет убедиться, что в продукте нет «фундаментальных» ошибок
- Продукт отвечает требованиям
- Качество продукта выше
- Пользователи удовлетворены
Как выполняется
Рассмотрим ход функционального тестирования, упрощенно:
- Создать наборы тестовых данных.
- Выполнить тест-кейсы.
- Сравнить полученный и ожидаемый результат.
В более подробном изложении:
- Тщательно ознакомиться с функциональными спецификациями. Что будет тестироваться? Главная функция приложения, его сообщения, условия при которых возникают ошибки, общая юзабельность приложения.
- Создать тестовые данные на основе готовых требований к продукту.
- Оценка ожидаемых (приемлемых) выводов в ответ на значения тестовых данных. Какие должны быть выводы (результаты), в соответствии с требованиями.
- Выполнение тест-кейсов.
- Сравнение полученного вывода с ожидаемым. Здесь получим ответ, работает ли приложение, как положено.
В чем разница между функциональным и нефункциональным?
Функциональное тестирование сосредоточено на функциональных аспектах приложения, а нефункциональное — на нефункциональных. В задачи нефункционального тестирования входит проверка таких вещей как производительность, надежность, масштабируемость.
Нефункциональное тестирование проводится после функционального, как менее приоритетное.
Функциональное тестирование — это о том, что софт делает, а нефункциональное — как хорошо он это делает.
Функциональное тестирование фокусируется на «механике», а нефункциональное — на «результатах».
Примеры функционального тестирования: юнит-тестирование, smoke-тестирование и другие (ниже список).
Примеры нефункционального тестирования: тестирование производительности, тестирование совместимости, нагрузочное тестирование:
Типы
Какие бывают типы (категории) функционального тестирования?
- Юнит-тестирование
- Smoke-тестирование
- Sanity-тестирование
- Регрессионное тестирование
- Интеграционное тестирование и другие:
Лучшие практики
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.
- Ad-hoc (здесь подробнее)
Когда пользователь залогинился и что-то делает, администратор удаляет его экаунт.
***
