Особенности тестирования веб-приложений. Функциональное тестирование современных web-приложений

Немного нетривиальная задача мне выпала. Девушка, можно сказать, моя гражданская жена, хочет стать тестировщиком. Сама не особо знает, каким именно, но хочет в IT на начальные позиции. После некоторых раздумий остановились на тестировании интерфейсов веб-приложений, т.к. это, во-первых, тренд (время SPA), который будет только расти, а во-вторых, в вебе огромная свобода в тестировании. Иные виды приложений (мобильные, десктоп), решили отсечь, т.к. входной порог выше (узкие инструменты, менее популярные, более привязывающие к технологии). Иные виды тестирования - тем более. Во-первых, значительную часть тестов, которые "близко к коду" или "близко к критическим фичам", делают программисты, во-вторых, про далекие тесты (вроде нагрузочного, дымового и т.п.) можно забыть на начальном этапе. Сам я с вебом очень давно знаком, фулстек разработчик, как щас говорят. Из технологий: python/js/django/flask/backbone и всякое смежное. В основном пишу модульные тесты (питоний unittest), фронтенд тестил редко, ибо фриланс и проекты не такие большие, но есть опыт с mocha/jasmine + selenium, а также python + selenium для e2e тестирования. Для себя я много что пробую, но все-таки я не тестировщик, просто приходится знать и интересоваться, как оно, плюс есть вещи, где нельзя без тестирования.

Так вот, в общем, имеем мое понимание, как оно устроено и может быть устроено, и практически нулевые знания у девушки. У нее за плечами довольно техническое образование (безопасность в IT), что-то она кодила, про веб знает немного. Можно охарактеризовать так: html/css, немного питона (по моей инициативе), примерное представление о парадигмах программирования (ООП), что-то знает про сети (шлюз, роут, днс, дхцп, скорее всего, помнит даже, что такое бгп (sic!) и т.п.), но опыта нет ни в чем вообще. Есть аналитическое мышление, но нет уверенности, "нет наглости делать так, как кажется правильным и не бояться писать велики".

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

Но с моей точки зрения знать надо много: у меня есть ощущение, что тестировщик - это почти разработчик. Как можно тестить интерфейс без понимания того, как устроена верстка (html/css/svg, особенно фичи с селекторами)? Как можно тестировать сложные сценарии без знания основ взаимодействия фронтенда и бэкенда (кукисы, аякс, основы js, чтобы не пугаться, если что)? Кроме того, хорошо было бы знать что-нибудь про бекенд. Кроме того, в реальном месте вообще может оказаться какая-нибудь связка ангуляра, кармы тест раннера, жасмина или чего-то в этом роде, надо бы быть в теме.

Что я сделал: решил начать с питона, потому как JS учить как первый язык и умереть в прототипах, очень интересном приведении типов, 100 способах объявить приватный член и стрелять по ногам, с миллионами фреймворков/парадигм/стандартов/модулей/классов... Это очень сложный язык, я считаю. Начинать с популярной джавы - это вообще провал, потому как я сам с ним знаком на уровне универа всего лишь, во-вторых, я считаю, что это не лучший язык для разработки и обучения, кроме того, мы все-таки в области фронтенда. На питоне мы уже написали тестовый класс и юнит-тестик для него, чтобы примерно понимать суть тестирования. Потом я сказал, что если сделать наоборот, то это будет TDD. А если перед TDD подумать и описать, что надо, то это будет BDD. Понимаю, что нюансов много, но стараюсь сделать так, чтобы возникли вопросы у человека, и он пошел гуглить. По пути я объясняю некоторые фичи вроде того, зачем нужен self (для непитонистов - this - указатель на текущий объект), что такое типизация, ООП, даю ссылки на хабру, в доки, показываю, как дебажить, разбирать ошибки, в общем, стараюсь объяснить как можно больше всего из программирования вообще, могу параллельно залечивать на темы "а ты знаешь, вот в си есть указатели, и они там работают вот так...", потому как язык - это все фигня. С вероятностью значительной ей придется учить либо js, либо, прости господи, джаву. И все это будет очень просто, я считаю, если она будет знать базовые концепции.

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

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

Я думаю, мой подход понятен, я учу читать доки и стараюсь из обрывков инфы в ее голове создать что-то, причем моя задача - это "знать суть + моментальная практика, а нюансы нужны только тогда, когда знаешь, что они существуют". Смотрим доки, если что не известно, то тут же надо гуглить, если нужна фундаментальная инфа, то статьи/обрывки книг по основам и так далее.

Так вот. Прав ли я вообще? Моя задача объяснить основы веба, в т.ч. программирования, популярные инструменты для тестирования, популярные парадигмы, чтобы можно было пойти джуном тестером. Я чувствую, что я не учитель, ибо у меня есть какое-то видение автоматически, как должно быть, и я строю все уже из него. Есть ощущение, что говорю очень много инфы сразу, что вводит в ступор. Есть ощущение, что я не могу передать все, что знаю, ибо всего очень много и часто все затягивается на длинные монологи, когда я что-то показываю, делаю, но у человека разрывает мозг. Кто-нибудь считает, что я дико не прав, возможно? Может, есть фундаментальная литература с основами по тестированию веба вообще? Она начинала читать "тестирование дот ком" от кого-то, по моему мнению ее вообще читать не стоит, ибо все, что там есть, можно увидеть на вики, немного подумав. Может, есть какие-то прямо суперские книги, такие как Кормен в алгоритмах, например? Или мне стоит вообще изменить подход?

Сам нахожусь в некотором замешательстве, ибо начал чувствовать, что я, скорее, "укладываю инфу в своей голове", чем что-то объясняю ей... %)

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

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

Systems Sciences Institute при IBM выявили, что стоимость исправления ошибки, выявленной после релиза, была в 4-5 раз выше, чем стоимость выявленной и исправленной ошибки во время разработки. Следовательно, стоит тщательно тестировать веб-приложение до его выпуска.

Ниже приведен обзор 6 шагов, которые помогут в этом.

Шаг 1. Функциональное тестирование (Functional Testing)

Первым шагом тестирования веб-приложения является проверка функциональности системы.

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

Обычно функциональное тестирование включает в себя:

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

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

Шаг 2. Юзабилити тестирование (Usability Testing)

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

Юзабилити тестирование включает в себя следующие шаги:

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

Шаг 3. Тестирование интерфейса (Interface Testing)

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

Шаг 4. Тестирование совместимости (Compatibility Testing)

Ключевой шаг в тестировании веб-приложений - это обеспечение совместимости приложения со всеми веб-браузерами и устройствами.

Совместимость с веб-браузерами.

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

Кроме тестирования приложения на различных браузерах (и даже на Internet Explorer! :)), следует убедиться, что и другие версии одного и того же браузера обеспечивают корректную работу приложения.

Совместимость с мобильными устройствами.

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

Шаг 5. Тестирование производительности.

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

Чтобы определить предел работы приложения, оно подвергается высокому (стрессовому) уровню нагрузки до тех пор, пока не нарушится его функциональность (stress testing). Также это помогает проверить, как приложение восстанавливается после сбоев.

Шаг 6. Тестирование безопасности.

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

Тестирование безопасности включает в себя следующие шаги:

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

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

• Безопасная передача данных;
• Аутентификация;
• Управление сеансом;
• Авторизация;
• Криптография;
• Проверка данных;
• Отказ в обслуживании (Denial of Service);
• Специфические функциональные тесты;
• Обработка ошибок.

Заключение.

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

Тестирование веб-приложений

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

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

Виды тестирования веб-приложений

Вот несколько основных видов тестирования веб-приложений:

1. Функциональное тестирование. Это тестирование используется для проверки всех ссылок веб-страниц; Тестирования форм, файлов cookie и подключение к базе данных.

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

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

4. Тестирование совместимостb. Тестирование на совместимость очень важно, так как оно проверяет совместимость браузера, совместимость с операционной системой, параметры браузера и печати.

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

6. Тестирование безопасности. Проверяет безопасность веб-приложений. В целях безопасности внутренние страницы не должны открываться, если вы не вошли на веб-сайт. Другая статистика не должна отображаться, даже если пользователь вошел в систему. Файлы должны быть доступны только при входе в аккаунт, и к ним нельзя получить доступ без этого. CAPTCHA для автоматизации входа должна быть также протестирована. SSL должен быть протестирован на меры безопасности.

После завершения тестирования всех веб-приложений необходимо провести тестирование в реальном времени для веб-приложений и веб-сайтов. Затем загрузите сайт и выполните полное тестирование.

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

Возможны многочисленные способы использования приложения (Entry-Exit)

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

Даже в том же браузере приложения могут выполняться по-разному в зависимости от локальных нюансов, таких как разрешение экрана / аппаратная / программная конфигурация системы

Приложения могут потребовать тестирования на совместимость и удобство использования

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

А развить навыки успешного тестировщика Вам помогут наши - звоните и записывайтесь прямо сейчас!

, recall , информационный шум , логические ошибки , раскрытие информации , SQL Injection , "stress" , Нагрузочное тестирование , тестирование производительности , Объемное тестирование , Объемное стабильности , visual test , probing , sniffing , firebug , RDP , load generation , tester , quality manager , тестирование web-сервера , Моделирование Транзакций , Метод Метод "Анализ данных на стороне клиента"Анализ данных на стороне клиентаМетод "Анализ данных на стороне клиента" , Метод Анализ Сетевого Трафика , Проверка HTML-кода , профилировщик , граф вызовов , call graph , code coverage , подсветка синтаксиса , Вьювер , development tools , смещение элементов , иерархический список , breakpoint , билд , Internet Explorer Developer Tools , functional decomposition , data-driven , время выполнения , кэш , валидность , DHTML , css

Презентацию к данной лекции Вы можете скачать .

19.1. Тестирование Веб-приложений

19.1.1. Введение

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

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

Будут рассмотрены принципы следующих подходов к тестированию Веб-приложений [ , ]:

• функциональное тестирование ;
• тестирование пользовательского интерфейса ;
• тестирование удобства использования ;
• нагрузочное и стрессовое тестирование ;
• проверка ссылок и HTML-кода;
• тестирование безопасности .

Также будет приведен обзор средств автоматизации тестирования Веб-приложений.

С общими вопросами тестирования и верификации информационных систем предлагается ознакомиться в курсе Интернет Университета Информационных Технологий "Верификация программного обеспечения" .

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

19.1.2. Подходы к функциональному тестированию Веб-приложений

Функциональное тестирование ( functional testing ) – процесс верификации соответствия функционирования продукта его начальным спецификациям . Характерным примером может быть проверка того, что программа подсчета выплат по банковской ссуде выдает корректные выкладки на любые введенные сумму ссуды и срок ее возврата. Обычно подобные проверки проводятся вручную, иногда к этому подключаются конечные пользователи в качестве бета-тестеров. Однако программные системы становятся все сложнее, а комбинации различных входных параметров и поддерживаемых операционных систем нередко исчисляются десятками и сотнями.

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

1. Record & Play – основан на возможности средств автоматизации тестирования автоматически генерировать код.
2. Functional Decomposition – в основе лежит разбиение всех компонент фреймворка по функциональному признаку на бизнес-функции (реализуют/проверяют бизнес-функциональность приложения), user-defined функции (вспомогательные функции, которые еще имеют привязку к тестируемому приложению или к конкретному проекту), утилиты (функции общего назначения, не привязанные к конкретному приложению, технологии, проекту).
3. Data-driven – основан на том, что к некоторому тесту или группе тестов привязывается источник данных, и этот тест или набор тестов циклически выполняется для каждой записи из этого источника данных. Вполне может применяться в комбинации с другими подходами.
4. Keyword-driven – представляет собой фактически движок для обработки посылаемых ему команд, а сами инструкции выносятся во внешний источник данных.
5. Object-driven – основан на том, что основные ходовые части фреймворка реализованы в виде объектов, что позволяет собирать тесты по кирпичикам.
6. Model-based – основан на том, что тестируемое приложение (или его части) описывается в виде некоторой поведенческой модели.

Самым распространенным является подход, называемый Capture & Playback (другие названия – Record & Playback , Capture & Replay) . Суть этого подхода заключается в том, что сценарии тестирования создаются на основе работы пользователя с тестируемым приложением. Инструмент перехватывает и записывает действия пользователя, результат каждого действия также запоминается и служит эталоном для последующих проверок. При этом в большинстве инструментов, реализующих этот подход, воздействия (например, нажатие кнопки мыши) связываются не с координатами текущего положения мыши, а с объектами HTML-интерфейса (кнопки, поля ввода и т.д.), на которые происходит воздействие, и их атрибутами. При тестировании инструмент автоматически воспроизводит ранее записанные действия и сравнивает их результаты с эталонными, точность сравнения может настраиваться. Можно также добавлять дополнительные проверки – задавать условия на свойства объектов (цвет, расположение, размер и т.д.) или на функциональность приложения (содержимое сообщения и т.д.).

Основное достоинство этого подхода – простота освоения. Создавать тесты с помощью инструментов, реализующих данный подход, могут даже пользователи, не имеющие навыков программирования.

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

19.1.3. Тестирование пользовательского интерфейса

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

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

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

Функциональное тестирование пользовательского интерфейса состоит из пяти фаз :

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

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

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

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

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

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

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

19.1.3.1. Ручное тестирование

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

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

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

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

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

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

Подход Webmart QA к тестированию веб приложений

В рамках тестирования веб-приложений нашей командой осуществляются:

• Тестирование функциональности (проверка реализации функционального наполнения приложения на соответствие требованиям и общепринятым стандартам).
• Тестирование кроссбраузерности и кроссплатформенности (выявление дефектов и различий в поведении системы при взаимодействии пользователя с продуктом в разных операционных системах, браузерах и на разных устройствах).
• Тестирование веб-сервисов (проверка корректности вызываемых веб-приложением сервисов на предмет корректной обработки данных, изменения статусов объектов, возвращение информации из БД и проч.).
• Интеграционное тестирование, E2E (тестирование сквозных сценариев для комплекса взаимодействующих подсистем, включающий валидацию подключений и коннективностей, подготовку тестовых данных в определенных компонентах и проверку результатов проведения бизнес-процессов пошагово всей системы в целом).
• Юзабилити-тестирование (проверка удобства пользования, обнаружение изъянов в навигации и интерфейсе, а также избыточной или недостаточной информативности).
• Нагрузочное и стресс-тестирование (проверка стабильности и устойчивости к сбоям системы при нормальных рабочих условиях и пиковых нагрузках в течение длительного времени).

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

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

Только подходящие комбинации

Наша команда никогда не предлагает все: мы реализуем лишь те подходы, которые действительно целесообразны и применимы в каждом конкретном случае:

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

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