Что такое функциональное тестирование?
В этом разделе вы присоединитесь к команде Tailspin по мере определения функциональных тестов для конвейера. Функциональные тесты проверяют, выполняет ли каждая функция программного обеспечения то, что она должна.
Команда сначала определяет, что охватывает функциональный тест. Они изучают некоторые типы функциональных тестов. Затем они решают первый тест добавить в свой конвейер.
Еженедельное собрание
Команда имеет еженедельную встречу. Энди демонстрирует конвейер выпуска. Команда наблюдает за успешным перемещением сборки по конвейеру с одного этапа на другой. Наконец, веб-приложение становится промежуточным.
Амита: Я так рад конвейеру. Это делает мою жизнь гораздо проще. Для одной из них я автоматически получаю выпуск, развернутый в тестовой среде. Это означает, что мне не нужно вручную скачивать и устанавливать артефакты сборки на тестовых серверах. Это значительный экономия времени.
Кроме того, модульные тесты, которые Мара и Энди написали исключить все ошибки регрессии, прежде чем я получаю выпуск. Это устраняет основной источник разочарования. Я не тратю время на поиск и документирование ошибок регрессии.
Но я беспокоюсь, что все мое тестирование все еще вручную. Процесс медленный, и мы не можем показать ничего для управления, пока я не закончим. Это трудно, потому что тестирование важно. Тестирование гарантирует, что пользователи получают правильный интерфейс. Но давление на то, чтобы обеспечить быстрее.
Энди: Я уверен, что мы можем помочь вам. Какие тесты занимают большую часть времени?
Амита: Я думаю, что тесты пользовательского интерфейса выполняются. Я должен щелкнуть каждый шаг, чтобы убедиться, что я получаю правильный результат, и я должен сделать это для каждого браузера, который мы поддерживаем. Это очень много времени. И по мере роста сложности веб-сайта тестирование пользовательского интерфейса не будет практическим в долгосрочной перспективе.
Мара: тесты пользовательского интерфейса считаются функциональными тестами.
Тим: В отличие от чего, нефункциональные тесты?
Мара: Точно. И нефункциональные тесты — это то, что вы, в частности, заботитесь о.
Тим: Хорошо, я смущен.
Что такое функциональные и нефункциональные тесты?
Мара: Функциональные тесты проверяют, что каждая функция программного обеспечения делает то, что она должна. Как программное обеспечение реализует каждую функцию, не важно в этих тестах. Важно, что программное обеспечение работает правильно. Вы предоставляете входные данные и убедитесь, что выходные данные являются ожидаемыми. Вот как Амита проверяет пользовательский интерфейс. Например, если она выбирает верхнего игрока на панели лидеров, она ожидает увидеть профиль этого игрока.
Нефункциональные тесты проверяют характеристики, такие как производительность и надежность. Пример нефункционального теста — проверка количества пользователей, которые могут одновременно войти в приложение. Нагрузочное тестирование является еще одним примером нефункционального теста. Эти проблемы производительности и надежности — это то, о чем вы заботитесь, Тим.
Тим: Они действительно. Мне нужно немного подумать об этом. Я мог бы добавить некоторые автоматизации в конвейер тоже, но я не уверен, что я хочу сделать. Какие типы автоматических тестов можно выполнять?
Мара: Сейчас давайте сосредоточимся на функциональном тестировании. Это вид тестирования, который Амита делает. И это звучит как область, где мы хотим улучшить.
Какие функциональные тесты можно запускать?
Существует множество функциональных тестов. Они зависят от функциональных возможностей, необходимых для тестирования, и времени или усилий, которые обычно требуются для выполнения.
В следующих разделах представлены некоторые часто используемые функциональные тесты.
Тестирование дыма
Тестирование дыма проверяет самые основные функциональные возможности приложения или службы. Эти тесты часто выполняются перед более полными и исчерпывающими тестами. Тесты дыма должны выполняться быстро.
Например, предположим, что вы разрабатываете веб-сайт. Тест дыма может использоваться curl для проверки доступности сайта, и получение домашней страницы создает состояние HTTP 200 (ОК). Если при выборе домашней страницы создается другой код состояния, например 404 (не найден) или 500 (внутренняя ошибка сервера), вы знаете, что веб-сайт не работает. Вы также знаете, что нет причин для выполнения других тестов. Вместо этого вы диагностируете ошибку, исправите ее и перезапустите тесты.
Модульное тестирование
Вы работали с модульными тестами в ходе тестов качества выполнения в конвейере сборки с помощью модуля Azure Pipelines .
Короче говоря, модульное тестирование проверяет наиболее фундаментальные компоненты программы или библиотеки, такие как отдельная функция или метод. Вы указываете необходимые входные данные и связанные с ними ожидаемые результаты. Средство выполнения теста выполняет каждый тест и проверяет, соответствуют ли фактические результаты ожидаемым результатам.
Например, предположим, у вас есть функция, которая выполняет арифметическую операцию, которая включает разделение. Можно указать несколько значений, которые вы ожидаете, что пользователи ввели. Вы также указываете значения пограничного регистра, такие как 0 и -1. Если вы ожидаете, что определенные входные данные создают ошибку или исключение, можно убедиться, что эта функция создает эту ошибку.
Тесты пользовательского интерфейса, которые будут выполняться позже в этом модуле, являются модульными тестами.
Тестирование интеграции
Тестирование интеграции проверяет, работает ли несколько компонентов программного обеспечения для формирования полной системы. Например, система электронной коммерции может включать веб-сайт, базу данных продуктов и систему оплаты. Вы можете написать тест интеграции, который добавляет элементы в корзину покупок, а затем приобретает элементы. Тест проверяет, может ли веб-приложение подключиться к базе данных продуктов, а затем выполнить заказ.
Модульные тесты и тесты интеграции можно объединить для создания многоуровневой стратегии тестирования. Например, можно запустить модульные тесты на каждом из компонентов перед выполнением тестов интеграции. Если все модульные тесты проходят, можно перейти к тестам интеграции с большей уверенностью.
Тестирование регрессии
Регрессия возникает, когда существующее поведение изменяется или прерывается после добавления или изменения функции. Тестирование регрессии помогает определить, влияет ли код, конфигурация или другие изменения на общее поведение программного обеспечения.
Тестирование регрессии важно, так как изменение одного компонента может повлиять на поведение другого компонента. Например, предположим, что вы оптимизируете базу данных для повышения производительности записи. Производительность чтения этой базы данных, которая обрабатывается другим компонентом, может неожиданно удалиться. Падение производительности чтения — это регрессия.
Для тестирования регрессии можно использовать различные стратегии. Обычно эти стратегии зависят от количества выполняемых тестов, чтобы убедиться, что новая функция или исправление ошибок не нарушает существующую функциональность. Однако при автоматизации тестов регрессия может включать только выполнение всех модульных тестов и тестов интеграции при каждом изменении программного обеспечения.
Тестирование санности
Тестирование санности включает тестирование каждого основного компонента программного обеспечения, чтобы убедиться, что программное обеспечение, как представляется, работает и может пройти более тщательное тестирование. Вы можете думать о ментагентных тестах как менее тщательной, чем регрессионные тесты или модульные тесты, но тесты санности более широки, чем тесты дыма.
Несмотря на то, что тестирование работоспособности может быть автоматизировано, оно часто выполняется вручную в ответ на изменение функции или исправление ошибок. Например, средство тестирования программного обеспечения, проверяющее исправление ошибок, также может убедиться, что другие функции работают, введя некоторые типичные значения. Если программное обеспечение, как ожидается, работает должным образом, оно может пройти более тщательный тестовый проход.
Тестирование пользовательского интерфейса
Тестирование пользовательского интерфейса проверяет поведение пользовательского интерфейса приложения. Тесты пользовательского интерфейса помогают убедиться, что последовательность или порядок взаимодействия с пользователем приводит к ожидаемому результату. Эти тесты также помогают убедиться, что устройства ввода, такие как клавиатура или мышь, влияют на пользовательский интерфейс правильно. Вы можете запустить тесты пользовательского интерфейса, чтобы проверить поведение собственного приложения Windows, macOS или Linux. Кроме того, можно использовать тесты пользовательского интерфейса, чтобы убедиться, что пользовательский интерфейс работает должным образом в веб-браузерах.
Модульный тест или тест интеграции может убедиться, что пользовательский интерфейс получает данные правильно. Но тестирование пользовательского интерфейса помогает убедиться, что пользовательский интерфейс отображается правильно и что результат работает должным образом для пользователя.
Например, тест пользовательского интерфейса может проверить, отображается ли правильная анимация в ответ на нажатие кнопки. Второй тест может проверить правильность отображения той же анимации при изменении размера окна.
В этом модуле вы работаете с тестами пользовательского интерфейса, закодированных вручную. Но вы также можете использовать систему записи и воспроизведения для автоматического создания тестов пользовательского интерфейса.
Тестирование удобства использования
Тестирование удобства использования — это форма ручного тестирования, которая проверяет поведение приложения с точки зрения пользователя. Тестирование удобства использования обычно выполняется командой, которая создает программное обеспечение.
В то время как тестирование пользовательского интерфейса фокусируется на том, работает ли функция должным образом, тестирование удобства использования помогает убедиться, что программное обеспечение интуитивно понятно и соответствует потребностям пользователя. Другими словами, тестирование удобства использования помогает проверить, является ли программное обеспечение "пригодным для использования".
Например, у вас есть веб-сайт, содержащий ссылку на профиль пользователя. Тест пользовательского интерфейса может убедиться, что ссылка присутствует и что она открывает профиль пользователя при щелчке ссылки. Тем не менее, если люди не могут легко найти эту ссылку, они могут стать разочарованы, когда они пытаются получить доступ к своему профилю.
Приемочное тестирование пользователями
Тестирование принятия пользователей (UAT), например тестирование удобства использования, фокусируется на поведении приложения с точки зрения пользователя. В отличие от тестирования удобства использования, UAT обычно выполняется реальными конечными пользователями.
В зависимости от программного обеспечения пользователям может потребоваться выполнить определенные задачи. Или они могут быть разрешены для изучения программного обеспечения без выполнения определенных рекомендаций. Для пользовательского программного обеспечения UAT обычно происходит непосредственно с клиентом. Для более общего программного обеспечения команды могут запускать бета-тесты . В бета-тестах пользователи из разных географических регионов или с определенными интересами получают ранний доступ к программному обеспечению.
Отзывы от тестировщиков могут быть прямыми или косвенными. Прямые отзывы могут появиться в виде словесных комментариев. Непрямая обратная связь может прийти в виде измерения языка тела тестировщиков, движения глаз или времени, необходимого для выполнения определенных задач.
Мы уже рассмотрели важность написания тестов. Но просто подчеркнуть это, вот короткое видео, где Abel Wang, Cloud Advocate at Microsoft, объясняет, как обеспечить качество в плане DevOps.
Спросите Абель
Что выбирает команда?
Тим: Все эти тесты звучат важно. Что мы должны решить сначала?
Энди: У нас уже есть рабочие модульные тесты. Мы еще не готовы выполнить приемочное тестирование пользователей. Основываясь на том, что я слышу, я думаю, что мы должны сосредоточиться на тестировании пользовательского интерфейса. Сейчас это самая медленная часть нашего процесса. Амита, вы согласны?
Амита: Да, я согласен. У нас по-прежнему осталось некоторое время на этом собрании. Энди или Мара, вы хотите помочь мне запланировать автоматизированный тест пользовательского интерфейса?
Мара: Абсолютно. Но давайте получим несколько предварительных сведений из пути. Я хотел бы обсудить, какое средство мы должны использовать и как мы будем запускать тесты.
Какие средства можно использовать для написания тестов пользовательского интерфейса?
Мара: Когда речь идет о написании тестов пользовательского интерфейса, каковы наши варианты? Я знаю, что есть много. Некоторые средства открытый код. Другие предлагают платную коммерческую поддержку. Вот несколько вариантов, которые приходят к виду:
- Драйвер приложений Windows (WinAppDriver): WinAppDriver помогает автоматизировать тесты пользовательского интерфейса в приложениях Windows. Эти приложения можно записать в универсальная платформа Windows (UWP) или Windows Forms (WinForms). Нам нужно решение, которое работает в браузере.
- Selenium: Selenium — это переносимая платформа программного тестирования с открытым кодом для веб-приложений. Он работает в большинстве операционных систем и поддерживает все современные браузеры. Тесты Selenium можно написать на нескольких языках программирования, включая C#. На самом деле можно использовать пакеты NuGet, которые упрощают запуск Selenium в качестве тестов NUnit. Мы уже используем NUnit для модульных тестов.
- SpecFlow: SpecFlow предназначен для проектов .NET. Он вдохновлен инструментом под названием Cucumber. Как SpecFlow, так и Cucumber поддерживают разработку на основе поведения (BDD). BDD использует средство синтаксического анализа естественного языка под названием Gherkin, чтобы помочь как техническим командам, так и нетехническим командам определять бизнес-правила и требования. Вы можете объединить SpecFlow или Cumber с Selenium для создания тестов пользовательского интерфейса.
Энди смотрит на Амиту.
Энди: Я знаю, что эти варианты новые для вас, так что вы думаете, если мы выбрали Selenium? У меня есть опыт работы с ним, и он поддерживает языки, которые я уже знаю. Selenium также предоставит нам автоматическую поддержку для нескольких браузеров.
Амита: Конечно. Лучше, если у одного из нас есть опыт.
Разделы справки выполнять функциональные тесты в конвейере?
В Azure Pipelines вы выполняете функциональные тесты так же, как и любой другой процесс или тест. Спросите себя:
- На каком этапе будут выполняться тесты?
- В какой системе будут выполняться тесты? Будут ли они выполняться на агенте или в инфраструктуре, где размещено приложение?
Давайте присоединимся к команде, как они отвечают на эти вопросы.
Мара: Одна вещь, о которой я рада, заключается в том, что теперь мы можем протестировать в среде, которая похожа на рабочую среду, где приложение на самом деле работает. Функциональные тесты, такие как тесты пользовательского интерфейса, имеет смысл в этом контексте. Мы можем запустить их на этапе тестирования конвейера.
Амита: Я согласен. Мы можем поддерживать тот же рабочий процесс, если мы запускаем автоматические тесты пользовательского интерфейса на том же этапе, в котором я выполняю тесты вручную. Автоматические тесты помогут нам сэкономить время и позволит мне сосредоточиться на удобствах использования.
Тим: Амита тестирует веб-сайт с своего ноутбука Windows, потому что большинство наших пользователей посещают сайт. Но мы создадим linux, а затем развернем службу приложение Azure в Linux. Как мы обработаем это?
Мара: Большой вопрос. У нас также есть выбор о том, где мы запускаем тесты. Мы можем запустить их:
- На агенте: агент Майкрософт или агент, на котором мы размещаем
- В тестовой инфраструктуре: локально или в облаке
Наш существующий этап тестирования включает в себя одно задание. Это задание развертывает веб-сайт для Служба приложений из агента Linux. Мы можем добавить второе задание, которое запускает тесты пользовательского интерфейса из агента Windows. Агент Windows, размещенный корпорацией Майкрософт, уже настроен для запуска тестов Selenium.
Энди: Опять же, давайте придерживаемся того, что мы знаем. Давайте будем использовать агент Windows, размещенный корпорацией Майкрософт. Позже мы можем выполнять те же тесты от агентов, которые работают под управлением macOS и Linux, если требуется дополнительное покрытие тестов.
План
Мара: ОК. Вот что мы собираемся делать:
- Запуск тестов пользовательского интерфейса Selenium из агента Windows, размещенного корпорацией Майкрософт
- Получение веб-содержимого из приложения, работающего на Служба приложений, на этапе тестирования
- Выполнение тестов во всех браузерах, которые мы поддерживаем.
Энди: Я буду работать с Амитой на этом. Амита, давайте встретимся завтра утром. Я хотел бы сделать немного исследований, прежде чем мы встречаемся.
Амита: Отлично! Вы увидите тебя.
Создание функционального плана тестирования
Мы видели, как команда решит, как они будут реализовывать свои первые функциональные тесты. Если ваша команда только начинает включать функциональные тесты в свой конвейер (или даже если вы уже делаете это), помните, что вам всегда нужен план.
Во многих случаях, когда кто-то просит участников группы о плане тестирования производительности, это часто для них ответить со списком инструментов, которые они будут использовать. Однако список инструментов не является планом. Кроме того, необходимо выяснить, как будут настроены среды тестирования. Необходимо определить используемые процессы и определить, как выглядит успешно или сбой.
Убедитесь, что план:
- Учитывает ожидания бизнеса.
- Учитывает ожидания целевых пользователей.
- Определяет используемые метрики.
- Определяет ключевые показатели эффективности, которые вы будете использовать.
Тестирование производительности должно быть частью планирования прямо с самого начала. Если вы используете историю или канбан-доску, вы можете рассмотреть вопрос о том, где вы можете спланировать стратегию тестирования. В рамках планирования итерации должны быть выделены пробелы в стратегии тестирования. Кроме того, важно выяснить, как вы будете отслеживать производительность после развертывания приложения, а не только измерять производительность перед выпуском.