Тестирование Web-ориентированных приложений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Katalon Studio - это автоматизированная тестовая платформа, которая предлагает полный набор функций для внедрения полностью автоматизированных тестовых решений для Web, API и мобильных устройств. Созданная на основе открытых источников Selenium и Appium, Katalon Studio позволяет командам быстро запускать автоматизацию тестирования, уменьшая усилия и знания, необходимые для обучения и интеграции этих фреймворков для задач по автоматизации тестирования.

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

Unified Functional Testing (UFT), ранее QuickTest Professional (QTP) - один из самых популярных коммерческих инструментов для автоматизации функциональных тестов. UFT предлагает полный набор функций, охватывающих большинство функциональных задач автоматического тестирования на десктопных, мобильных и веб-платформах.