Как протестировать программу на ошибки

Вы разработали мобильное приложение и выложили в сторы. Но почему-то в отзывах пользователи гневаются, а вы недополучаете прибыль. Как так? Где допущена ошибка? Ведь вы все продумали и записали в техзадании.
Дело в том, что пользователи могут взаимодействовать с мобильным приложением не так, как мы ожидали. Или так как мы ожидали, но результаты нас не устраивают — мы хотим лучше и больше.
Первый шаг к решению проблемы — тестирование.

[Тестирование должно сопровождать каждый этап разработки. То есть, на выходе продукт должен быть оттестирован сверху до низу. Однако не стоит думать, что после релиза о тестировании можно забыть. О, нет! Поведение живых пользователей сложно имитировать, часто они взаимодействуют с приложением непредсказуемо. Поэтому узнать о некоторых проблемах приложения можно только «в бою».]

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

Проверка компьютера на ошибки | Как проверить компьютер на ошибки

Добавим, что любое тестирование включает в себя:
1. Планирование теста (тут мы исходим из целей).
2. Проектирование теста (здесь мы выбираем или разрабатываем инструменты, скрипты, сценарии и прочее для проведения теста).
3. Выполнение теста (собственно приводим задуманное в действие, используя все необходимые ресурсы, которые заранее подготовили).
4. Анализ результатов (а что делать дальше, чтобы исправить ошибки?
Логичным завершением тестирования должно быть исправление ошибок в мобильном приложении или доработка приложения.

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

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

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

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

Как проверить ПК на стабильность | Быстро и просто

Все эти данные помогут составить правильные (жизненные) кейсы.

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

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

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

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

Нагрузочное тестирование

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

В чем суть?
Нагрузочное тестирование проходит в автоматическом режиме путем имитации действий нужного количества пользователей.

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

Конфигурационное тестирование

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

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

Как проводится?
Приложение тестируют в соответствии с техническим заданием:

• на различных гаджетах: планшеты, смартфоны, декстоп и др.
• в разных конфигурациях: типы процессора, разрешение экрана, оперативная память
• на разных версиях операционных систем iOS, Android
• в разных типах сети: GSM, Wi-Fi

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

Для чего нужно?
Собирая данные пользователей, вы обязаны обеспечить их безопасность. Но приложение не становится безопасным от рождения, таким его делают специально. Тестирование же помогает понять, все ли мы сделали, чтобы защитить данные (и не только пользовательские) от угроз. То есть по сути, проверяется устойчивость приложения к различным угрозам безопасности: DoS-атакам, вирусам, воровству данных.

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

Как проводится?
Варианты сценариев тестирования:

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

Юзабилити-тестирование приложения

Для чего нужно?
Юзабилити — это свойство интерфейса, которое либо помогает взаимодействию пользователей с приложением, либо затрудняет его. С одним интерфейсом мы ладим легко и непринужденно — от взаимодействия с другим испытываем раздражение и не достигаем нужной цели (либо достигаем с трудом).
Тестирование помогает выяснить, как пользователи взаимодействуют с приложением. Понять заранее поведение и эмоции пользователя трудно. Даже если у вас есть здравый смысл и логика (два столпа юзабилити). Все потому что вы видите приложение иным взглядом: вам все понятно, вы давно «в теме». А вот пользователи видят его впервые.

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

1. Экспертный анализ — используются накопленные знания о пользовательском опыте. Некоторые очевидные ошибки можно исправить с помощью этого метода.
2. Тестирование с помощью веб-аналитики — сервисы веб-аналитики дадут понимание, что где-то, на определенных экранах есть проблема. Также можно понять, какой путь выбирают пользователи. Но этот вид анализа не даст понимания, что именно мешает пользователям совершать все больше конверсий. Хотя отчасти ответ на этот вопрос могут дать записи вебвизора Яндекс Метрики (только для сайтов).
3. Тестирование с участием живых пользователей с помощью специальных сервисов. Найти эти сервисы можно в интернете. За плату «нанятые» пользователи будут следовать вашим заданиям, а вы получите записи их действий на экране. А это поможет понять, насколько удобен интерфейс «в действии».
4. Живое тестирование. С приглашением пользователей вашей целевой аудитории (иногда возможно пригласить клиентов конкретной компании, для кого и создавалось приложение). Подробнее о таком тестировании мы уже писали статью.

Подытожим: как провести тестирование с пользой для дела?

1. Ставим цель: что нас беспокоит, что не устраивает в работе приложения. Основываемся на техническом задании, затем на отзывах пользователей, на собственных ощущениях, что «что-то не так, как нам хотелось».
2. Выбираем вид тестирования под цель.
3. Находим исполнителя. Часто это может быть компания-разработчик. Он же поможет определить нужный вид тестирования.
4. Анализируем результаты и исправляем ошибки. В этом также поможет компания-разработчик.

Источник: punicapp.com

Лекция 8: Методы проверки и тестирования программ и систем

В фундаментальную концепцию проектирования ПС входят базовые положения, стратегии, методы, которые применяются на процессах ЖЦ и обеспечивают тестирование (верификацию) на множестве тестовых наборов данных. К методам проектирования ПС относятся структурные, объектно-ориентированные и др. Их основу составляют теоретические, инструментальные и прикладные средства, которые влияют на процесс тестирования.

Теоретические средства определяют процесс программирования и тестирования программного продукта. К ним относятся методы верификации и доказательства правильности спецификации программ (см. «Формальные спецификации, доказательство и верификация программ» ), метрики измерения (Холстеда, цикломатичная сложность Маккейба и др.) в качестве отдельных характеристик как формализованных элементов теории определения правильности и гарантии свойств конечного ПО . Например, концепция » чистая комната » базируется на формализмах доказательства и изучения свойств процессов кодирования и тестирования программ. Что касается тестирования как процесса, то это проверка правильности работы программы по заданным описаниям тестов и покрытия данными соответствующих критериев программы [7.1-7.5].

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

При проверке правильности программ и систем рассматриваются процессы верификации, валидации и тестирования ПС, которые регламентированы в стандарте ISO/IEC 12207 [7.7] жизненного цикла ПО . В некоторой зарубежной литературе процессы верификации и тестирования отождествляются. С теоретической точки зрения верификация была рассмотрена в «Формальные спецификации, доказательство и верификация программ» , здесь же будут определены задачи и действия, соответствующих процессов ЖЦ.

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

7.1. Процессы ЖЦ верификация и валидация программ

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

Для этих процессов определены цели, задачи и действия по проверке правильности создаваемого продукта (рабочие, промежуточные продукты) на этапах ЖЦ. Рассмотрим их трактовку в стандартном представлении.

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

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

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

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

Процесс валидации. Цель процесса — убедиться, что специфические требования для программного продукта выполнены, и осуществляется это с помощью:

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

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

На других процессах ЖЦ выполняются дополнительные действия:

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

Таким образом, основные задачи процессов верификации и валидации состоят в том, чтобы проверить и подтвердить, что конечный программный продукт отвечает назначению и удовлетворяет требованиям заказчика. Эти процессы взаимосвязаны и определяются, как правило, одним общим термином » верификация и валидация » или » Verification and Validation » (VV основаны на планировании их как процессов, так и проверки для наиболее критичных элементов проекта: компонент , интерфейсов (программных, технических и информационных), взаимодействий объектов (протоколов и сообщений), передач данных между компонентами и их защиты, а также оставленных тестов и тестовых процедур .

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

7.2. Тестирование программ

Тестирование можно рассматривать, как процесс семантической отладки (проверки) программы, заключающийся в исполнении последовательности различных наборов контрольных тестов, для которых заранее известен результат. Т.е. тестирование предполагает выполнение программы и получение конкретных результатов выполнения тестов [7.1-7.5, 7.11, 7.12].

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

Исторически первым видом тестирования была отладка .

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

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

7.2.1. Статические методы тестирования

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

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

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

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

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

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

7.2.2. Динамические методы тестирования

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

Динамическое тестирование ориентировано на проверку корректности ПС на множестве тестов, прогоняемых по ПС, в целях проверки и сбора данных на этапах ЖЦ и проведения измерения отдельных показателей (число отказов, сбоев) тестирования для оценки характеристик качества, указанных в требованиях, посредством выполнения системы на ЭВМ. Тестирование основывается на систематических, статистических, (вероятностных) и имитационных методах.

Дадим краткую их характеристику.

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

Цель динамического тестирования программ по принципу «черного ящика» — выявление одним тестом максимального числа ошибок с использованием небольшого подмножества возможных входных данных.

Методы «черного ящика» обеспечивают:

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

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

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

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

Метод «белого ящика» позволяет исследовать внутреннюю структуру программы, причем обнаружение всех ошибок в программе является критерием исчерпывающего тестирования маршрутов потоков (графа) передач управления, среди которых рассматриваются:

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

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

Тестирование по принципу «белого ящика» ориентировано на проверку прохождения всех путей программ посредством применения путевого и имитационного тестирования.

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

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

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

Источник: intuit.ru

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

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

Тестирование
приложения
WEB-приложения
виды и этапы тестирования
Симаненко Юлия Александровна

Журнал «Научный лидер» выпуск # 12 (14), май ‘21

Дата публицакии 22.05.2021

Цитировать

Симаненко Ю. А. Тестирование Web-Приложений // . 2021. №12 (14). URL: https://scilead.ru/article/231-testirovanie-web-prilozhenij

Тестирование, приложения, WEB-приложения, виды и этапы тестирования

Введение

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

Задачи тестирования WEB-приложений:

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

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

Особенности архитектуры WEB-приложения

Согласно статистике на 2016 год, которую проводил Международный союз электросвязи, в интернет-пространстве уже имеется свыше одного миллиарда приложений, и порядка 3,5 миллиарда людей со всей планеты пользуются разного рода интернет-приложениями.

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

Типичная архитектура веб-приложения выглядит следующим образом:

Веб-страницы состоят из HTML, CSS и Javascript-кода, а также могут включать в себя дополнительные элементы, такие как изображения или видео. Веб-страницы отображаются непосредственно на стороне пользователя.

Сервер принимает HTTP-запросы от пользователей и выдает им соответствующие HTTP-ответы, которые могут содержать веб-страницы для отображения, либо данные (обычно в формате JSON), используемые Javascript-логикой для динамического обновления веб-страницы. Веб-сервер может быть реализован с использованием различных языков программирования, таких как Java, Perl, Ruby, Python, PHP и других.

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

Под термином «база данных» понимается информационная модель, которая имеет различный набор качеств, которые можно систематизировать. База данных функционирует за счет систем управления базами данных (сокращенно СУБД). Одними из наиболее известных СУБД являются MySQL, PostgreSQL и др.

Особенности тестирования WEB-приложений

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

Кроссбраузерность — это тестирование правильности работы WEB-приложения в различных браузерах и на различных операционных системах.

Кроссбраузерное тестирование проводит проверку по таким пунктам:

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

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

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

Следующая особенность веб-приложения – это формы заполнения, и здесь нужно выделить такие элементы, как:

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

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

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

Выделяются такие виды тестирования программ, как:

• Тестирование функционала;
• Оценка удобства использования веб-приложения;
• Оценка интерфейса;
• Оценка производительности;
• Оценка безопасности.

При функциональном тестировании определяют работает ли каждая функция WEB-приложения согласно спецификации требования. Сюда входит проверка работы ссылок, форм пользователя, проверка кода HTML и CSS, тестирование workflow и др.

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

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

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

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

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

Задача диагностики безопасности – это обнаружение угроз, которые разработчики должны устранить еще на этапе запуска веб-приложения в работу.

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

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

• Разработка модели WEB-приложения;
• Разработка тестового сценария;
• Анализ результатов.