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

Обновлено: 05.07.2024

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

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

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

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

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

Функциональное тестирование как правило может проводиться на всех уровнях тестирования (Уровни тестирования ПО).

Также функциональное тестирование достаточно часто попадает под разделения понятий (По признакам позитивности сценариев):

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

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

Имитация реального пользователя, взгляд глазами этого пользователя;
При правильном подходе или множестве тестировщиков, большое покрытие разнообразными функциональными тестами;

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

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

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

велика вероятность при проверки функциональности упустить различные логические ошибки в ПО;
вероятность избыточного тестирования.

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

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

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

Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования: компонентном, интеграционном, системном, приемочном. Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).

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

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

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

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

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

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

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

Преимущества:

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

Недостатки:

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

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

Вывод

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

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

Бизнес многих современных компаний довольно сильно зависит от работы информационных систем, которые применяются для обслуживания клиентов, поддержки работы бэк-офиса, ведения управленческого учета и ряда других задач. Досадные ошибки в ИТ-приложениях или некорректное выполнение функций может привести к финансовым или репутационным потерям. Так, в марте 2011 года технологический сбой в ИТ-решении нарушил работу практически всех отделений и банкоматов банка ВТБ24, а двумя годами раньше из-за неполадок в компьютерной системе была парализована деятельность почти трети московских филиалов Сбербанка. Какие шаги нужно предпринять, чтобы снизить риски появления подобного рода проблем при использовании информационных систем?

Один из возможных вариантов – применить комбинированный подход: использовать методологию непрерывной интеграции (continuous integration, CI) при разработке ИТ-решения в сочетании с традиционными инструментами функционального тестирования.

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

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

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

Как построить процесс непрерывной интеграции?

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

Этапы процесса непрерывной интеграции

Создание исходного кода

Программный код будущей информационной системы может создаваться несколькими группами специалистов, причем находиться они могут в различных офисах компании-разработчика. Для повышения качества и эффективности совместной работы над кодом часто используются специальные ИТ-решения – системы контроля версий (Version Control System, VCS). К числу наиболее распространенных из них относятся open source-приложения Subversion (SVN) и Git. Подобные системы позволяют программистам составлять код, реализуя новый функционал, и при этом не мешать друг другу. Кроме того, всегда есть возможность посмотреть и проанализировать историю кода, в любой момент вернуться к предыдущему удачному варианту.

Жизненный цикл ветки кода

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

Компиляция и компоновка

Команда программистов, как правило, одновременно ведет сразу несколько потоков разработки, периодически изменяя или даже удаляя их. С точки зрения эффективности для объединения результатов работы программистов рационально применять специальный инструмент - планировщик, который позволит создавать, хранить и автоматически запускать задачи по сборке программного кода. В качестве примера планировщиков можно привести решения CruiseControl, TeamCity, Hudson (и его наследник Jenkins) и другие.

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

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

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

Кроме того, это позволяет избежать задержек в работе в том случае, если в проекте участвуют команды, которые находятся в различных регионах и часовых поясах и работают посменно. Без использования CI программист, написав свою часть кода и не получив подтверждения (нотификации) по электронной почте об отсутствии ошибок, спокойно уходит домой. Но его коллеги, которые в этот момент в другом регионе только начинают свой рабочий день, будут вынуждены потратить свое время на выявление дефектов и их исправление. Сроки разработки системы увеличатся. В случае когда разработка ведется в рамках непрерывной интеграции, подобные ситуации исключены.

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

Подготовка установочного пакета

Скомпилированный код должен быть запакован соответствующим образом: это может быть zip-архив, установочная программа Windows или пакет для Unix/Linux дистрибутива. Для хранения готового пакета чаще всего используется файл-сервер (FTP, NFS, общая папка в сети и т.д.), который может быть как локальным (размещен в компании-разработчике системы), так и удаленным (например, располагаться у заказчика).

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

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

Автоматическая установка и подготовка к тестированию

Итак, программный код скомпилирован, запакован и установлен. Что дальше? Функциональное тестирование.

Как провести функциональное тестирование?

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

Анализ требований

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

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

Разработка функциональных тест-кейсов

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

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

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

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

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

В дальнейшем результаты автоматизированных тестов анализируются, определяются дефекты, которые привели к получению отрицательных результатов. Если в проекте используется гибкая модель разработки программного обеспечения, то найденные ошибки немедленно устраняются, и процесс тестирования запускается снова. В иных случаях дефекты регистрируются в системе для фиксации ошибок (bag tracking system) и исправляются после завершения всего тестирования.

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

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

Анализ результатов тестирования и обратная связь с заказчиком

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

Подведение итогов

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

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

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

Владислав Жидков, руководитель отдела автоматизированной сборки проектов, Дмитрий Змитраченок, руководитель группы технической поддержки, Ольга Полстюк, старший специалист по тестированию программного обеспечения, EPAM Systems

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

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

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

Тестирование black box проводится без знания внутренних механизмов работы системы и опирается на внешние проявления ее работы. При этом тестировании проверяется поведение ПО при различных входных данных и внутреннем состоянии систем. В случае тестирования white box создаются тест-кейсы, основанные преимущественно на коде системы ПО. Также существует расширенный тип black-box тестирования, включающего в себя изучение кода, — так называемый grey box (серый ящик).

Ключевые преимущества

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

Протестируем системы любой сложности: поисковые, биллинговые, процессинговые, SAP и многие другие

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

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

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

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

Инструменты

Управление тестированием ведется в специализированных системах: HP ALM, IBM Rational Quality Manager, MS Team Foundation Server. В зависимости от нужд и возможностей клиента мы используем альтернативные системы отслеживания ошибок: Atlassian Jira, Redmine.

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

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

Тестирование взаимодействий между компонентами системы и между несколькими системами.

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

Проверка соответствия ПО требованиям, заявленным в спецификации

Проверка документов на соответствие принятым стандартам, а также соответствие определенным характеристикам

Выявление дефектов в работе графического интерфейса

Оценка плотности покрытия системы тестами

Тестирование процесса инсталляции/деинсталляции программного обеспечения

Проверка работы ПО на различных программных и аппаратных окружениях

Ручное тестирование полностью имитирует фактическое использование системы конечным пользователем

Тестирование системы ведения единого регистра населения

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

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

Функциональное тестирование и доработка АБС на базе Case Platform

Проведено ручное и автоматизированное функциональное тестирование, оказана поддержка тестирования разработчиков, помощь в доработке, конфигурации и внедрении ПО. По результатам работы отмечено повышение качества и улучшение производительности АБС.

Тестирование CRM-системы

Провести тестирование функционала CRM при взаимодействии со смежными системами.

Была протестирована интеграционная цепочка из трех ESB-сервисов по получению информации о пластиковых картах клиентов банка.

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

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

Разработана система функционального тестирования для автоматизации smoke-тестов. Расширен объем проверок за счет включения в систему регрессионных тестов. Дополнительно разработаны сценарии для подготовки и получения тестовых данных.

Тестирование мобильного приложения Smart Bank

В качестве инструментария был выбран продукт HP Application Lifecycle Management 11.0. Тестирование проводилось на устройствах, работающих на платформах iOS и Android.

Проверка функций переводов между картами, корректности расчета комиссии, привязки банковских карт типа VISA, MasterCard, Maestro.

При тестировании устройств на ОС iOS была использована Over-The-Air платформа TestFlight и iPhone Configuration Utility, тестирование ОС Android проводилось с помощью программы Android SDK.

Ручное функциональное тестирование системы ЕРИБ

Повысить надежность системы, обеспечивающей выполнение банковских операций.

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

Функциональное тестирование системы Oracle Siebel CRM

В задачи проекта входили: анализ требований, подготовка тест-кейсов, поддержка тестирования разработчиков, внутреннее системное тестирование (включая интеграционное), приемочное тестирование.

Читайте также: