тестирование веб приложений это
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Тестирование web-приложений
Ключевые особенности и этапы тестирования WEB-приложений, обзор используемых технологий и применяемых решений.
Журнал «Научный лидер» выпуск # 12 (14), май ‘21
Тестирование, приложения, 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-приложения в различных браузерах и на различных операционных системах.
Кроссбраузерное тестирование проводит проверку по таким пунктам:
В диагностике нуждаются в первую очередь популярные браузеры, такие как Google Chrome, однако в случае наличия требований поддержки очень старых браузеров, может потребоваться тестирование, например, в браузере Internet Explorer.
При тестировании веб-приложения отдельное внимание нужно уделить валидаторам верстки. Для этого не требуется особых знаний, так как оценка соответствия качества верстки современным стандартам может выполняться за счет автоматических средств.
Следующая особенность веб-приложения – это формы заполнения, и здесь нужно выделить такие элементы, как:
Виды и этапы тестирования web-приложений
Виды и этапы тестирования WEB-приложений определяются исходя из стратегии тестирования. Это делается для того, чтобы определить какие ресурсы нужно привлечь в настоящий момент, чтобы только созданная программа была эффективно запущена в работу и функционировала без сбоев.
Выделяются такие виды тестирования программ, как:
При функциональном тестировании определяют работает ли каждая функция WEB-приложения согласно спецификации требования. Сюда входит проверка работы ссылок, форм пользователя, проверка кода HTML и CSS, тестирование workflow и др.
При тестировании удобства пользования определяют характеристики взаимодействия пользователя с web-приложением, чтобы обнаружить недостатки и эффективно их устранить. При такой диагностике обращают внимание на простоту обучения, навигацию, общий вид и др.
При тестировании интерфейса пользователя оценку проходит графический интерфейс WEB-приложения. В ходе диагностики оценивают, внешний вид интерфейса, его удобство и простоту использования. Важно отметить, что на этом этапе оценивают совместимость веб-приложения с различными браузерами и версиями браузеров.
При тестировании производительности проводится проверка веб-приложения на способность выдерживать большие нагрузки. Здесь нужно отметить, что так называемое стресс-тестирование будет определять пределы производительности веб-приложения вплоть до полного отказа работы.
Нагрузочное тестирование проводится для того, чтобы определить, сколько пользователей могут одновременно обращаться к одной странице без потери качества их обслуживания.
Еще один важный этап тестирования веб-приложений – это диагностика безопасности, которая позволяет оценить степень защиты приложения от разного рода уязвимостей, атак и других рисков, как правило, приводящих к большим потерям.
Задача диагностики безопасности – это обнаружение угроз, которые разработчики должны устранить еще на этапе запуска веб-приложения в работу.
Виды и этапы тестирования веб-приложения должны быть отражены в документе, в котором будут перечислены все ошибки. На основе данного документа разработчики должны провести полное устранение ошибок и выполнить повторное тестирование, чтобы убедиться в том, что все риски и ошибки действительно устранены.
Если говорить о функциональном тестировании WEB-приложений, то возможна дополнительная инструментальная поддержка, которая будет включать следующие шаги:
Данный подход позволяет обнаружить и перечислить классические уязвимости, такие как генерация на странице скрипта (XSS), также уязвимости XSRF, PHP, SQL и др. Среди уязвимостей особенное внимание уделяют такой как несанкционированный доступ к учетной записи и переполнение буфера. Рекомендованные к использованию чит-листы – это XSS Filter, Evasion Cheat Sheet, MySQL SQL Injection Cheat Sheet.
Аналитики и разработчики должны еще до начала диагностики приложения составить план, в котором будут следующие пункты тестирования:
Обзор технологий для тестирования WEB-приложений
Программное обеспечение становится всем более сложным, при этом оно должно корректно работать, и без его тестирования обойтись невозможно. Важно понимать, что изолировать код, чтобы исправлять ошибки сейчас стало все сложнее.
Сегодня как эффективный вариант диагностики используют модульное тестирование, которое снижает риск возникновения ошибок, уменьшает их, и благодаря его использованию разработчики могут получить документацию для тестируемых кодов. Наравне с модульным тестированием используется регрессия и автоматизация UI. Примеры популярных библиотек для тестирования: QUnit, JSUnit, YUI Test, xUnit.
Модульный тест может проверить лишь одну функцию за один тест, при этом используя xUnit вы вначале задаете условия, затем руководствуетесь в процессе тестирования этими условиями, и в финале проверяете вывод диагностики.
Еще одна технология – это QUnit (инфраструктура JavaScript-кода). Ее можно считать облегченной версией тестирования, которая проста и удобна, с ее помощью можно тестировать любой код.
Как было указано выше, тестирование UI с помощью CUIT может выполняться в автоматизированном режиме, в нем возможно записывать новые тесты и редактировать текущие.
Приведённые выше технологии юнит-тестирования можно использовать вместе с Selenium или аналогичными технологиями, симулирующими реальное поведение пользователя в браузере, что позволяет покрыть большую часть встречающихся на практике случаев и выявить большинство потенциальных проблем.
Прогнозы на будущее (тенденции, новые методы и технологии применения)
Рассматривая современные тенденции, первое, на что следует обратить внимание это развитие веб-браузеров. В настоящее время на рынке преобладают браузеры, основанные на Chromium, и единственным конкурентом с альтернативным движком является браузер Firefox. Учитывая сложность современных веб-стандартов, маловероятно, что в ближайшее время будут появляться новые браузерные движки, поэтому можно предположить, что тестирование клиентской части будет сведено к двум упомянутым выше браузерам.
Можно предположить, что в будущем особую популярность обретут облачные SaaS решения для проведения тестирования, которые будут позволять удобным образом проверять наиболее популярные случаи – причём, возможно, даже без необходимости привлечения специалиста. Тем не менее, с большой долей уверенности можно сказать, что существующие инструменты будут актуальны ещё продолжительное время, и, вероятнее всего, продолжат совершенствоваться разработчиками.
Заключение
Подводя итог, для тестирования современных веб-сайтов и веб-приложений имеется существенное количество технологий и подходов, что, при должном их использовании позволяет выявить большую часть ошибок и потенциальных проблем, позволяя существенно повысить качество конечного продукта или услуги, что, в свою очередь, может существенно отразиться на состоянии бизнеса – увеличить лояльность клиентов, повысить метрики удержания и, в конечном счёте, благополучно сказаться как на прибыли компании, так и на удобстве пользователей. При этом следует принимать во внимание, что тестирование имеет собственные издержки – в частности, время специалистов, затрачиваемое на покрытие тестами необходимого функционала.
Основы тестирования и отладки Веб-приложений
19.1. Тестирование Веб-приложений
19.1.1. Введение
Вычислительные и коммуникационные системы используются все чаще и с каждым днем все глубже входят в нашу повседневную жизнь. Компании и отдельные пользователи все больше зависят в своей работе от web-приложений. Веб-приложения соединяют различные отделы внутри компаний, различные компании и простых пользователей. Веб-приложения очень динамичны, а их функциональные возможности непрерывно растут. Непрерывно возрастает потоковый трафик средств информации и запросов, формируемых переносными и встроенными устройствами. Вследствие этого возрастает сложность систем такого рода. Очевидно, что для понимания, анализа, разработки и управления такими системами нужны количественные методы и модели, которые помогают оценить различные сценарии функционирования, исследовать структуру и состояние больших систем. Наблюдаются тенденции к постоянному росту спроса на Веб-службы. Таким образом, проблемы, связанные с недостаточной производительностью будут возникать и в будущем, и, в конце концов, они станут превалирующими при планировании и вводе в эксплуатацию новых Веб-служб и увеличении пользователей Интернета. Веб-приложения становятся все более распространенными и все более сложными, играя, таким образом, основную роль в большинстве онлайновых проектов. Как и во всех системах, основанных на взаимодействии между клиентом и сервером, уязвимости Веб-приложений обычно возникают из-за некорректной обработки запросов клиента и/или недостаточной проверки входной информации со стороны разработчика.
В первой части данной лекции мы рассмотрим вопросы специфичные для тестирования и отладки Веб-приложений.
Будут рассмотрены принципы следующих подходов к тестированию Веб-приложений [1, 2]:
Также будет приведен обзор средств автоматизации тестирования Веб-приложений.
С общими вопросами тестирования и верификации информационных систем предлагается ознакомиться в курсе Интернет Университета Информационных Технологий «Верификация программного обеспечения» [3].
Во второй части лекции будут рассмотрены подходы и инструментальные средства отладки CSS, а также отладки и профилирования JavaScript.
19.1.2. Подходы к функциональному тестированию Веб-приложений
Функциональное тестирование ( functional testing ) – процесс верификации соответствия функционирования продукта его начальным спецификациям [4]. Характерным примером может быть проверка того, что программа подсчета выплат по банковской ссуде выдает корректные выкладки на любые введенные сумму ссуды и срок ее возврата. Обычно подобные проверки проводятся вручную, иногда к этому подключаются конечные пользователи в качестве бета-тестеров. Однако программные системы становятся все сложнее, а комбинации различных входных параметров и поддерживаемых операционных систем нередко исчисляются десятками и сотнями.
Перечислим некоторые из методов функционального тестирования веб-приложений [5, 6]:
Основное достоинство этого подхода – простота освоения. Создавать тесты с помощью инструментов, реализующих данный подход, могут даже пользователи, не имеющие навыков программирования.
19.1.3. Тестирование пользовательского интерфейса
Часть программной системы, обеспечивающая работу интерфейса с пользователем – один из наиболее нетривиальных объектов для верификации [7]. Нетривиальность заключается в двояком восприятия термина «пользовательский интерфейс».
С одной стороны пользовательский интерфейс – часть программной системы. Соответственно, на пользовательский интерфейс пишутся функциональные и низкоуровневые требования, по которым затем составляются тест-требования и тест-планы. При этом, как правило, требования определяют реакцию системы на каждый ввод пользователя (при помощи клавиатуры, мыши или иного устройства ввода) и вид информационных сообщений системы, выводимых на экран, печатающее устройство или иное устройство вывода. При верификации таких требований речь идет о проверке функциональной полноты пользовательского интерфейса – насколько реализованные функции соответствует требованиям, корректно ли выводится информация на экран.
С другой стороны пользовательский интерфейс – «лицо» системы, и от его продуманности зависит эффективность работы пользователя с системой. Факторы, влияющие на эффективность работы, в меньшей степени поддаются формализации в виде конкретных требований к отдельным элементам, однако должны быть учтены в виде общих рекомендаций и принципов построения пользовательского интерфейса программной системы. Проверка интерфейса на эффективность человеко-машинного взаимодействия получила название проверки удобства использования (usability verification, в русскоязычной литературе в качестве перевода термина usability часто используют слово «практичность»).
Функциональное тестирование пользовательского интерфейса состоит из пяти фаз [7]:
Все эти фазы точно такие же, как и в случае тестирования любого другого компонента программной системы. Отличия заключаются в трактовке некоторых терминов в применении к пользовательскому интерфейсу и в особенностях автоматизированного сбора информации на каждой фазе.
При сборе информации о выполнении тестовых примеров, как правило, применяются технологии анализа выводимых на экран форм и их элементов (в случае графического интерфейса) или выводимого на экран текста (в случае текстового), а не проверка значений тех или иных переменных, устанавливаемых программной системой.
Под полнотой покрытия пользовательского интерфейса понимается то, что в результате выполнения всех тестовых примеров каждый интерфейсный элемент был использован хотя бы один раз во всех доступных режимах.
Отчеты о проблемах в пользовательском интерфейсе могут включать в себя как описания несоответствий требований и реального поведения системы, так и описания проблем в требованиях к пользовательскому интерфейсу. Основной источник проблем в этих требованиях – их тестонепригодность, вызванная расплывчатостью формулировок и неконкретностью.
Тестирование пользовательского интерфейса может проводиться различными методами – как вручную при непосредственном участии оператора, так и при помощи различного инструментария, автоматизирующего выполнение тестовых примеров. Рассмотрим эти методы более подробно.
19.1.3.1. Ручное тестирование
В табл. 19.1 приведен пример сценария для ручного тестирования пользовательского интерфейса [7].
| № п/п | Действие | Реакция системы | Результат |
|---|---|---|---|
| 1 | Щелкните на значке «Система» и выберите пункт меню «Администрирование системы». | Появится окно ввода логина и пароля | Верно |
| 2 | Введите в появившееся окно ввода имя пользователя «admin» и пароль «admin». Затем нажмите кнопку «OK». | Появится окно «Администрирование системы». В верхнем правом углу должно быть выведено имя вошедшего пользователя admin. | Неверно Окно имеет название «Управление системой» |
Ручное тестирование пользовательского интерфейса удобно тем, что контроль корректности интерфейса проводится человеком, т.е. основным «потребителем» данной части программной системы. К тому же при чисто косметических изменениях в интерфейсах системы, не отраженных в требованиях (например, при перемещении кнопок управления на 10 пикселей влево) анализ успешности прохождения теста будет выполняться не по формальным признакам, а согласно человеческому восприятию.
19.1.3.2. Сценарии на формальных языках
Такие инструменты используют в качестве входной информации сценарии тестовых примеров, записанные на некотором формальном языке, операторы которого соответствуют действиям пользователя – вводу команд, перемещению курсора, активизации пунктов меню и других интерфейсных элементов.
И при передаче информации в тестируемый интерфейс и при получении информации для анализа могут использоваться два способа доступа к элементам интерфейса [7]:
При внесении изменений в пользовательский интерфейс при использовании первого метода в результате проведения регрессионного тестирования будет выявлено большое количество не прошедших тестов – достаточно изменения местоположения одного ключевого интерфейсного элемента, как все сценарии начнут работать неверно. Соответственно при таком методе автоматизации тестирования необходимо менять значительную часть сценариев в системе тестов при каждом изменении интерфейса системы. Такой метод автоматизации тестирования подходит для систем с устоявшимся и редко изменяемым интерфейсом.
Второй метод автоматизации тестирования более устойчив к изменению расположения интерфейсных элементов, но изменения тестовых примеров могут потребоваться и здесь в случае изменения логики работы интерфейсных элементов. Например, пусть в первой версии системы при нажатии на кнопку «Передать данные» передача данных начиналась сразу, и выводилось окно с индикатором прогресса. Сценарий тестового примера в этом случае включает в себя имитацию нажатия на кнопку и обращение к индикатору прогресса для получения значения прогресса в процентах.