Веб тестирование: Тестирование сайтов и веб-приложений: полное руководство

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

В этой статье мы рассмотрим тестирование сайта (веб-приложения) с помощью наборов тестов. Она довольно длинная, поэтому усаживайтесь по удобнее.

1. Тестирование функциональности;
2. Тестирование удобства использования;
3. Тестирование интерфейса;
4. Тестирование совместимости;
5. Тестирование производительности и скорости загрузки сайта;
6. Тестирование безопасности.

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

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

Формы используются для получения информации от пользователей и взаимодействия с ними.

Что нужно проверить в формах:

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

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

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

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

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

Если вы оптимизируете сайт для поисковых систем, то валидация HTML/CSS особенно важна. Первым делом проверьте сайт на наличие синтаксических ошибок в HTML-коде. Проверьте, доступен ли сайт для различных поисковых систем.

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

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

При тестировании функциональности сайтов нужно проверить:

1. Внутренние ссылки;
2. Внешние ссылки;
3. Ссылки на электронную почту;
4. Битые ссылки.

1. Валидация полей;
2. Сообщения об ошибке при неверном вводе;
3. Обязательные и необязательные к заполнению поля.

Следует проверить целостность базы данных.

Тестирование юзабилити — это анализ взаимодействия пользователя и сайта, поиск ошибок и их устранение.

При этом проверяется:

• Легкость обучения;
• Навигация;
• Субъективная удовлетворенность пользователей;
• Общий вид.

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

Проверка юзабилити:

• Сайт должен быть простым в использовании;
• Инструкции должны быть очень четкими;
• Проверьте, достигают ли предоставленные инструкции поставленной цели;
• Главное меню должно быть доступно на каждой странице;
• Главное меню должно быть построено в логической последовательности.

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

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

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

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

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

Основные интерфейсы:

• Интерфейсы веб-сервера и приложения.
• Интерфейсы сервера базы данных и сервера приложения.

Если база данных или веб-сервер для какого-либо запроса, исходящего от сервера приложения, возвращает сообщение об ошибке, сервер приложения должен фиксировать его и отображать пользователю.

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

Нужно проверить:

• Совместимость с браузерами;
• Совместимость с операционными системами;
• Просмотр на мобильных устройствах;
• Параметры печати.

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

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

Проверьте работу веб-приложения в браузерах Internet Explorer, Firefox, Netscape Navigator, AOL, Safari, Opera разных версий.

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

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

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

Тестирование производительности сайта или веб-приложения должно включать в себя:

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

Проверьте производительность приложения на различной скорости интернета.

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

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

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

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

Сплит тестирование сайта при использовании различных вариантов интернет-соединения: через модем, ISDN и т.д.

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

1. Непрерывная нагрузка;
2. Производительность памяти, процессора, обработки файлов и т. д.

Ниже приведены некоторые наборы для тестирования веб-безопасности:

• Проверка с помощью вставки внутреннего URL в адресную строку браузера без авторизации. Внутренние страницы при этом не должны открываться.
• После авторизации с помощью логина и пароля, а также просмотра внутренних страниц попробуйте изменять URL. Например, вы проверяете какую-то статистику сайта под идентификатором ID= 123. Попробуйте изменить ID URL на другой ID сайта, который не имеет отношения к авторизованному пользователю. В любом случае доступ этого пользователя к просмотру других показателей должен быть запрещен.
• Попробуйте ввести неверные данные в поля формы для авторизации. Выясните, как система реагирует на ввод недопустимых данных.
• Каталоги или файлы не должны быть доступны напрямую, если для них не предусмотрена возможность скачивания.
• Проверьте работу капчи для защиты от автоматического входа с помощью программного кода.
• Проверьте, используется ли в целях безопасности SSL. Если да, то должно отображаться сообщение при переходе пользователя с незащищенных HTTP-страниц к защищенным и наоборот.
• Все операции, сообщения об ошибках, нарушения безопасности должны записываться в файл журнала на веб-сервере.

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

• Сетевое сканирование;
• Сканирование уязвимостей;
• Возможность потенциального взлома паролей;
• Обзор журнала;
• Средства для проверки целостности;
• Обнаружение вирусов.

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

Есть множество типов серверов и браузеров различных версий. Между ними есть небольшие, но значимые различия.

Дополнительные факторы, которые следует учесть при тестировании сайта:

• Какова ожидаемая нагрузка на сервер (например, количество запросов за единицу времени)?
• Какая производительность требуется при различных видах нагрузки (время ответа веб-сервера, время отклика базы данных на запрос)?
• Какие инструменты потребуются для тестирования производительности?
• Кто является целевой аудиторией? Какие браузеры будут использовать пользователи? Какова скорость подключения? Предназначен ли сайт для использования внутри организации или будет доступен в интернете для широкого круга пользователей?
• Какую производительность ожидает получить клиент (насколько быстро должны загружаться страницы, как должны себя вести анимации, апплеты, нагрузка и запуск)?
• Будут ли разрешены простои сервера и техническое обслуживание, а также обновление контента? Если да, в каком количестве?
• Какие средства безопасности требуются (файерволы, шифрование, пароли и т.д.), и какую работу они будут выполнять? Как их можно проверять?
• Насколько надежным должно быть интернет-соединение? Как оно будет влиять на резервное копирование системы?
• Как будет выполняться управление обновлением контента сайта?
• Требования для технического обслуживания, отслеживания и контроля содержимого веб-страниц, графических элементов, ссылок и т.д.
• Какая спецификация HTML будет соблюдаться? Насколько точно?
• Как будут проверяться и обновляться внутренние и внешние ссылки? Насколько часто?
• Как будет происходить управление и проверка CGI апплетов, сценариев JavaScript, компонентов ActiveX и т.д.?
• Максимальный размер веб-страницы не должен превышать 3-5 экранов, кроме случаев, когда контент сосредоточен на одной теме. Если размер веб-страницы больше, предоставьте внутренние ссылки для навигации по ней.
• Разметка веб-страницы и элементы дизайна должны быть последовательными и логично связанными.
• Отображение веб-страниц должно быть независимо от типа браузера.
• На каждой странице следует указать ссылку для связи.

Данная публикация представляет собой перевод статьи «Web Testing Complete Guide (Web Application Testing Tips and Scenarios)» , подготовленной дружной командой проекта Интернет-технологии.ру

телеграм канал. Подпишись, будет полезно!

Как протестировать сайт. Чеклист для новичков — Блог HTML Academy

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

Когда тестирование полезно

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

Предупреждение: статья не претендует на академическую полноту, но точно поможет что-нибудь не упустить.

Всё посмотреть и прокликать

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

Что проверять:

• Элементы страницы расположены как на макете на всех устройствах.
• Сайт одинаково выглядит и работает во всех нужных браузерах.
• Кнопки нажимаются и после этого что-то происходит, слайдеры крутятся, гамбургеры раскрываются.
• Все JavaScript-скрипты работают корректно.
• Отображается правильный контент.
• Отдаются нужные заголовки.
• Загружаются правильные шрифты.
• Фавиконка установлена.
• Текст отображается не кракозябрами (в 2020 такое редко, но бывает).
• Курсор интерактивный на интерактивных элементах и обычный на обычных.
• С локализацией всё в порядке (русская, английская версия).
• Страница не разъезжается, если включить блокировщик рекламы.

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

Фрагмент реального сайта о том, что тестирование полезно

Инструменты:

• Реальные браузеры и устройства.
• Эмуляторы (BrowserStack, LambdaTest, Browsera, BrowserShots).

Ошибки JavaScript

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

Валидность кода

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

Веб-формы

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

Что проверять:

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

Неправильные ссылки

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

Уберите ссылку на главную с главной

Локализация

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

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

Производительность сайта

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

Что проверять

• Как быстро браузер отобразит страницу?
• Сколько времени занимает доставка ответа от сервера к пользователю?
• Все ли ресурсы загружаются?

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

• Использовать сжатие контента. Например, выбирать подходящие форматы графики и шрифтов.
• Включить серверное и клиентское кэширование
• Избавиться от неиспользуемых данных, которые подгружаются подзапросом. Например в приложении 10 библиотек JS, а используется только одна.
• Правильно настроить файлы Cookie
• Хранить статические данные на отдельном CDN-сервере.

Критерии качества

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

Делать сразу хорошие сайты

Всё, что нужно фронтендеру — на курсах HTML Academy. Научитесь всему, чтобы у тестировщиков закончилась работа.

Выбрать курс

Несколько удобных инструментов для тестирования сайта / Хабр

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

Websitetools

Первый в списке — websitetools.com, точнее его бесплатные инструменты. Все тесты можно проводить с 35 серверов, размещенных в разных концах Земли.

Website test позволяет проверить статус сервера, размер главной страницы, время загрузки в общем и по отдельности DNS, соединения, редиректа (если есть), загрузки первого и последнего байт.

Web Page Test проверяет доступность страницы, ее размер, показывает время загрузки различных параметров (описанных выше) для каждого из 35 объектов страницы (если зарегистрироваться на сайте, то количество объектов не ограничено, тоесть загружаются абсолютно все объекты страницы)

Последовательность загрузки объектов

Статус и время загрузки объектов

HTTP Headers test обращается к введенному адресу и отображает возвращаемые заголовки в виде:
HTTP/1.1 200 OK

Server: nginx

Date: Sun, 14 Jun 2009 12:30:54 GMT

Content-Type: text/html

Transfer-Encoding: chunked

Connection: keep-alive

Keep-Alive: timeout=25

Кроме этих есть еще несколько полезных инструментов:

— Просмотр MX записей для ящика электронной почты

— Просмотр NS записей по адресу сайта, или ip

— Сопоставление доменных имен ip адресу

— Проверка DNS в популярных черных списках DNS

— Тестирование доступности HTTP, HTTPS, FTP, SMTP, POP3, IMAP, SSH, Telnet, DNS по домену, или ip

— Проверка валидности ящика электронной почты

— Сканирование портов

— PING, Traceroute, WHOIS, MTR

XenoCode Browser Sandbox

Сервис предоставляет набор из Internet Explorer 6, 7, 8, Firefox 3, Safari 3, Chrome и Opera 9, которые не надо устанавливать, а достаточно запустить прямо с их сайта. Это дает возможность посмотреть как выглядит сайт в различных браузерах, и в отличии от не менее известного BrowserShots, который делает только снимки страницы, позволяет полноценно пользоваться сайтом в окнах разных браузеров.

FireBug

Расширение для Firefox, которое позволяет в режиме реального времени исследовать множество элементов веб-страницы: JavaScript, DHTML, CSS, а также XMLHttpRequest. С помощью этого замечательного инструмента в считанные секунды можно найти любой HTML-объект страницы, изменить и просмотреть свойство CSS, увидеть CSS-контейнеры в удобном виде, исследовать DOM, получить список ошибок на странице, а также запускать JavaScript из консоли.
Во время написания этой статьи я нашел русскоязычный сайт, на котором всегда можно получить последнюю версию расширения, а также полную документацию к нему — firebug.ru

Load Impact

Замечательный стресс-тест сервис, который позволяет симулировать большую нагрузку на Ваш сайт и предоставляет подробные и удобные отчеты проделанного теста. В бесплатной версии можно симулировать не более 50 пользователей, однако в платной ($99 в день, или $499 в месяц) это число достигает 5000.

Web Developer Firefox Extension

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

W3C сервисы проверки

Несколько официальных сервисов для тестирования сайта от Консорциума Всемирной паутины.
W3C Markup Validation показывает ошибки синтаксиса HTML веб-страницы, их описание и в некоторых случаях предлагает пути их решения.

W3C CSS Validation то же самое, что и предыдущее, но проверяет синтаксис CSS

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

http://validator.w3.org/checklink — проверка на битые ссылки.

W3C Feed Validation Service — проверка синтаксиса Atom или RSS Feed

О тестировании web-приложений / Хабр

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

• управляющего проектом это позвоночник и вегетативная нервная система
• программисты это скелет и моторика
• аналитики это органы чувств
• тестеры это совесть

Quality Assurance часто считается синонимом тестирования, но на самом деле это методика предотвращения ошибок, а не их поиска и исправления. Качество в этом смысле — характеристика сделанного продукта.

Формально говоря, тестер должен проверять даже техническое задание, план проекта и анализ на логичность и понятность, а не только код и интерфейс программы. Тестирование как независимая дисциплина в общем потоке разработки ПО появилась в начале девяностых, когда стали более важны аудитория (клиенты), качество и время разработки.
Важность тестирования ПО особенно важна в критических системах. К примеру аппарат по лучевой терапии Therac (1985) облучил смертельной дозой радиации 6 человек из-за отсутсвия проверки состояния агрегата в коде и валидации. Или марсоход в 1999 году принёс убыток в 125 млн долларов из-за непродуманности единой системы измерения между коммандами разработчиков. И даже в Эстонии при электронных выборах были проблемы из-за плохого нагрузочного тестирования.
Основные принципы тестирования воплощены в небольшом документе ISTQB и в книге «Foundations of software testing».
Вся «прелесть» специальности тестера в том что как правило для этого не нужны большие познания в программировании и люди далёкие от web-строительства могут себя попробовать в этой роли.

Организационный процесс

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

Итерация тестирования состоит из следующих пунктов

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

   Посему у тестера хотя-бы внутренний, но анализ состоит из…

   • Условий (conditions)
   • Истории взаимодействий (cases)
   • Воплощение в виде документа (basis) со ссылками на спецификацию, архитектуру и прочие документы (коли они есть)

2. Проверки. В случае недоступностей и непонятностей — когда и с кем связаться что-бы задание не забылось.
   • Приоритезация тест-case’ов (обычно 1 case = 1 требование = 1 web-страница). Какие сценарии самые критичные? Какие в разработке и наиболее рискованные?
   • Группировка тестов в комплекты (suite) по общим модулям
   • Проверка и сравнение с требованиями (собственно поиск ошибок)
   • Написание рапорта (как багов, так и общей картины — процент покрытия)
   • Перепроверка изменнённой части (confirmation, retesting) или влияние на неизменённые части (regression testing)

3. Завершение. Архивация тестов, сохранение полученных уроков.

Уровни тестов

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

• Модульные (unit-testing). Полуавтоматическое тестирование, в том плане что тесты приходится писать программисту в очень тесном контакте с кодом классов которые unit-тест должен проверить. Не обязательно следовать TDD, можно написать хотя-бы для самых критичных частей (финансовые операции и тп.)
• Интеграционные (integration testing) проверяют связи между разными модулями. Можно делать как до общей интеграции системы (модуль за модулем), так и после (пишем, пишем, сложим — протестим до финального acceptance-теста). Тут опять тесная работа с кодом и программистами.
• Системные — пройтись по всей системе и найти несоответсвие общим стандартам и спецификации в целом. Как правило под конец, когда система в основном готова.
• Acceptance-тест проходит как правило уже с клиентом при передаче проекта и показывает готовность работы с клиентами. Именно на этой стадии появляются альфа версии (всё лежит ещё вероятно у разработчика на машине, привлекаются сторонние тестеры) и бета версии (всё уже лежит у клиента, привлекаются потенциальные клиенты)

Типы тестов

Теперь собственно по сути тестирования..

• Функциональные отвечают на вопрос «что» должно делать приложение
• Нефункциональные требования/тесты отвечают на вопрос «как». Нефункциональные включают в себя свойства удобства интерфейса, надёжности, безопасности данных, масштабируемости, кроссплатформенности и даже экономической целесообразности (см. ISO/IEC 9126)
• Внешние (black box) / Внутренние (структурные, white box). Структурное тестирование проверяет внутреннюю структуру приложения как оно реализовано, но нуждается в понимании кода. Подход «чёрного ящика» исходит из того что ПО ещё не реализовано либо мы не знаем его точной работы, зато есть спецификация как должно всё работать. Структурные (white box) подходы тестируют приложение снизу вверх, концентрируясь на максимальном покрытии кода (а не комбинаций входа-выхода в интерфейсе). Обычно white box подходы используются в дополнение к чёрному ящику (как должно работать).
• Регрессионное тестирование — а не поломалось ли что-то из-за этого изменения? Как правило именно это надо связывать с unit-тестированием для большей автоматизации
• Тест-поддержка (maintenance testing) — система уже работает и мы просто её обновляем (deploy & migration). Миграции в последнее время тоже как правило автоматизируются.
• Динамическое / статическое тестирование. Динамическое подразуемевает интерактив, работу с готовой системой или кодом. Это не всегда обязательно и возможно. Теоретически можно тестировать документацию или проверять логичность анализа, находить ошибки из логов и тп.

Тестеры как и «писатели тех-задания» для самоконтроля всегда должны помнить аббревиатуру SMART, что-бы их правильно поняли более практичные люди.

• Specific — точное описание требования, без копи-пастов переписки с клиентом, чатом, дампом данных и односложными предложениями
• Measureable — измеряемое значение чисел, времени, вероятности, пользователей, местоположения.
• Attainable — технически-достижимые требования. Не всё ещё возможно технически, вперёд прогресса не угонишься
• Realizeable — человечески-достижимые людские требования по времени, качеству, знанию, цене
• Traceable — соответсвие изначальной идее и цели, логичность соответсвия нескольких требований.

Black box техники

Ad-hoc (monkey) — случайное тестирование без определённой стратегии
Исследовательское тестирование (exploratory testing) — изучение продукта если документация во многом отсутствует
Группировка ошибок по эквивалентным классам (equivalence partitioning). Самый популярная методика. Каждый вход проверяется на требования (по длине символов, возможных значениях). В тестах для минизации их количества классы разных входов комбинируются что-бы сделать максимальное покрытие ошибок.
Ещё одна техника существует преимущественно для целочисленных значений. Ошибки как правило возникают в пограничных значениях, поэтому методика так и называется (boundary value analysis). Выбираются два или три значения возле границы. Например если максимальная длина заголовка 250 символов, то как будет выдаваться ошибка при 249, 250 и 251 значении?
Более приближенная к динамическим системам есть методика проверки перехода состояний (state transition testing). Состояние зависит от входа и от предыдущего состояния. Состояния и переходы описываются графами (finite state machine).
Таблица решений (decision table testing) сама собой приходит в голову когда бизнес-правила в приложении очень сложные и нуждаются в больших математических вычислениях. С помощью таблиц можно минимизировать число уникальных комбинаций
Тестирование сценариев (use-case based) проходит согласно созданных в анализе сценариях, с учётом разных ролей, альтернативных потоков.
Интуитивно-опытное тестирование (experience-based) как уже понятно приходит у человека со временем и позволяет находить систематические ошибки дизайна, программистов, потока данных с учётом изменения кода.

White box (структурные) техники

Цель структурных техник — максимально покрыть тестами код (code coverage), а поскольку white box используется как дополнение к сценарным техникам, то логично, что есть и максимальное покрытие сценариев или, точнее, их разветвлений (statement & decision coverage).
Математически процент покрытия = 100% * число покрытых единиц / число всех единиц. Это не значит, что будет всё протестировано, только выбранные единицы тестирования (coverage item). Единицы тестирования для каждой роли по разному выглядят — для разработчиков это таблицы БД, функции в коде, запрос к внешнему компоненту, тогда как для тестера и аналитика это действия в сценарии, классы эквивалентности.
Поднимаясь выше над единицами тестирования можно увидеть предложения и соответственно покрывать их (statement coverage). Хорошее тестирование с методиками чёрного ящика могут покрыть до 60-75% предложений. В плане кода это конкретная строка
Покрытие разветвлений (decision coverage) уже более высокий уровень, включает все типы иерархии (if-else, switch, вызовы методов и тп.). Методами чёрного ящика можно покрыть 40-60%. Циклическая сложность (cyclomatic complexity) — проверка алгоритма известная всем информатикам на квадратичную, экспоненциальную и логарифмическую сложность.
Следующая степень покрытия включает возможные пути по которым можно пройти по разветвлениям. Теоретически этих путей бесконечно много если учитывать ещё и все циклы.

Инструменты

Наиболее знакомые инструменты программистом это конечно системы отслеживания ошибок (bug/issue tracking) — Mantis, Bugzilla и Trac. Некоторые IDE могут интегрироваться с ними так, что commit-действии в репозиторий версионной системы (SVN/CVS/Git/Mercurial) можно обновить баг без работы в браузере.

Есть и более общие, индустриальные продукты включающие в себя и составление требований, группировку сценариев — HP (Mercury) Quality Center и IBM Rational Quality Manager

Автоматизированное тестирование интерфейсов сейчас наиболее популярно с помощью Selenium, SilkTest, HP QuickTest Pro, QF-Test, Rational Robot, TestComplete, Watir, TestPartner. Есть и более экзотические тесты типа soapUI.

Нагрузочное тестирование чуть более сложное, потому что нужны дополнительные машины (скажем одна машина симулирует 300 пользователей-соединений) — на одной машине запускать 3000 соединений как правило невозможно. Инструменты:

Оригинал статьи

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

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

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

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

Три основных вопроса, которые можно решить с помощью тестирования веб-приложений

1. Отвечает ли функциональность приложения заявленным требованиям?

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

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

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

2. Будет ли приложение правильно работать на всех устройствах, популярных у конечных пользователей?

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

Проверка совместимости продукта со всеми последними версиями браузеров Chrome, Firefox, MS Edge, Safari и ОС Windows 7, 8 и 10 является примером данного вида тестирования.

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

3. Выдержит ли приложение большое количество пользователей?

Тестирование производительности – комплекс проверок, направленный на определение лимитов производительности приложения.

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

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

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

Другие риски, которые устраняет тестирование веб-приложений

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

1. Могут ли незарегистрированные пользователи получить доступ к приложению?

Тестирование безопасности и тестирование на проникновение позволяет определить, как и при каких обстоятельствах приложение может быть взломано.

Анализ и оценка уровня защищенности приложения – зона ответственности инженеров по тестированию безопасности.

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

2. Учитывает ли ваше приложение культурные и лингвистические особенности целевых регионов?

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

Как грамотно тестировать программный продукт, который используется по всему миру? Читайте в статье.

Аспекты, качество которых проверяют специалисты по тестированию локализации:

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

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

3. Соответствует ли программный продукт всем необходимым нормам и стандартам?

Цель тестирования соответствия – установить, соответствует ли приложение юридическим нормам и стандартам, которым подчиняется ваш бизнес.

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

Выбираем виды тестирования: 5 вопросов, которые помогут сделать правильный выбор

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

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

1. Какова цель вашего проекта по разработке программного продукта?
2. С какими сложностями вы уже столкнулись?
3. Какие три главных риска реализации проекта?
4. Какую стратегию предлагают специалисты по обеспечению качества с учетом целей и сложностей вашего проекта?
5. Как специалисты по тестированию предлагают минимизировать риски?

Если цель проекта – выйти на рынок в кратчайшие сроки, то вам стоит провести тестирование функциональности продукта и убедиться в том, что при разработке были учтены все требования.

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

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

Подводя итог

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

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

Свяжитесь с нами сейчас и получите бесплатную консультацию специалистов по обеспечению качества веб-приложений.

Поделиться статьей:

Топ 10 инструментов автоматизации тестирования 2018 / Хабр

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

Не так давно свет увидел World Quality Report 2017–2018 (Мировой стандарт проверки качества), выпущенный благодаря совместному труду сразу нескольких крупных компаний (Capgemini, Sogeti и Micro Focus), в котором было отмечено ряд интересных трендов в разработке и тестировании программного обеспечения. Авторы этого отчета считают, что основные направления в развитии разработки ПО заключаются в постоянном совершенствовании автоматизации тестирования и повсеместном применении гибких и DevOps-методологий (методология, которая объединяет в себе работу программистов и системных администраторов). Так, в данном отчете указано, что компаниям необходимо внедрять интеллектуальную автоматизацию и смарт-аналитику, для того чтобы ускорить процессы принятия ключевых решений и валидации продукта. Благодаря таким нововведениям компании смогут более эффективно справляться с тестированием интеллектуальных устройств нового поколения и высокоинтегрированных продуктов, изменения в которые вносятся постоянно. В отчете также говорится о необходимости создания интеллектуальных платформ для тестирования, характеризующихся высоким уровнем адаптивности. Благодаря таким платформам можно будет обеспечить эффективную поддержку полного жизненного цикла приложения.

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

Selenium

Считается, что Selenium является самым популярным фреймворком с открытым исходным кодом, предназначенным для автоматизации тестирования веб-приложений. Разработанный где-то в далеких двухтысячных и развивающийся в течение последующего десятилетия, Selenium представляют собой фреймворк для автоматизации процесса тестирования веб-приложений. За это время он успел завоевать сердца многих тестировщиков, особенно тех, у кого в распоряжении имеются продвинутые навыки программирования и опыт написания скриптов. Selenium можно рассматривать в качестве родоначальника некоторых современных инструментов автоматизации тестирования с открытым исходным кодом, например: Katalon Studio, Watir, Protractor и Robot Framework.

Фреймворк Selenium поддерживается несколькими ОС (Windows, Mac, Linux), а также многими браузерами (Chrome, Firefox, IE, и браузерами Headless). Скрипты для данного фрейма можно написать на большинстве популярных сегодня ЯП: Java, Groovy, Python, C#, PHP, Ruby и Perl.

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

Веб-сайт: http://www.seleniumhq.org/

Лицензия: бесплатная

Katalon Studio

Katalon Studio — это эффективный инструмент для автоматизации процесса тестирования веб-приложений, мобильных приложений и веб-сервисов. Katalon Studio является потомком таких фреймворков, как Selenium и Appium. Он перенял у последних множество преимуществ, связанных с интегрированной автоматизацией тестирования ПО.

Для начала работы с данным инструментом вы можете как обладать начальными знаниями в тестировании ПО, так и быть настоящим гуру своего дела. Люди, далекие от программирования, могут с легкостью запустить свой проект по автоматизации тестирования (например, запустив функцию Object Spy для записи тестовых скриптов), а для программистов и опытных тестировщиков Katalon Studio окажется полезным с точки зрения экономии времени при написании новых библиотек и поддержке существующих скриптов.

Katalon Studio может быть интегрирован в CI/CD, он прекрасно работает в связке с популярными инструментами во время тестирования ПО: qTest, JIRA, Jenkins и Git. Для него предусмотрена приятная функция — Katalon Analytics, благодаря которой пользователи получают полное представление о процессе тестирования. Для этого предусмотрены специальные отчеты, которые выводятся на экран пользователей в виде метрики, диаграмм и графиков.

Веб-сайт: https://www.katalon.com/

Лицензия: бесплатная

UFT

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

UFT использует Visual Basic Scripting Edition, который может пригодиться для записи информации о выполненном тестировании, а также для управления объектами. UFT интегрирован с Mercury Business Process Testing и Mercury Quality Center. Инструмент поддерживает CI с помощью интеграции с инструментами CI, такими как Jenkins.

Веб-сайт: https://software.microfocus.com/fr-ca/software/uft

Лицензия: платная

Watir

Watir — это инструмент с открытым исходным кодом для автоматизации тестирования веб-приложений, использующий библиотеки Ruby. Для Watir предусмотрена возможность кросс-браузерного тестирования в большинстве существующих браузеров: Firefox, Opera, headless-браузеров и IE. Он также поддерживает управляемое данными тестирование и интегрирован с инструментами BBD, такими как: RSpec, Cucumber и Test / Unit.

Веб-сайт: http://watir.com/

Лицензия: бесплатная

IBM Rational Functional Tester

IBM RFT — это платформа для управляемого данными тестирования функциональности и регрессии ПО. Она поддерживает возможность тестирования широкого спектра приложений, написанных на различных языках программирования, таких как: .Net, Java, SAP, Flex и Ajax. RFT использует Visual Basic .Net и Java в качестве языков сценариев. RFT имеет уникальную функцию – Storyboard testing. Благодаря ей все связанные с автоматическим тестированием действия пользователей записываются и визуализируются в виде последовательных изображений – скриншотов приложений на различных этапах их тестирования.

Еще одной интересной особенностью платформы RFT является возможность ее интеграции с системами управления жизненным циклом приложений IBM Jazz (например, IBM Rational Team Concert и Rational Quality Manager).

Веб-сайт: https://www.ibm.com/

Лицензия: платная

TestComplete

TestComplete, созданный SmartBear, является эффективным инструментом для тестирования десктопных, мобильных и веб-приложений. TestComplete поддерживает различные языки сценариев, такие как: JavaScript, VBScript, Python и C ++ Script. Также как и в случае с рассмотренным ранее Katalon Studio, с помощью TestComplete тестировщики могут выполнять тестирование с использованием ключевых слов и управляемое данными тестирование. В инструменте также предусмотрена удобная функция записи и воспроизведения процесса тестирования.

TestComplete обладает схожей с UTF функцией распознавания объектов GUI, благодаря которой происходит автоматическое обнаружение и обновление объектов пользовательского интерфейса, что помогает избежать лишних хлопот по поддержанию тестовых скриптов при изменении AUT. Данный инструмент также интегрируется с Jenkins в течение CI-процесса.

Веб-сайт: https://smartbear.com/

Лицензия: платная

TestPlant eggPlant

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

Веб-сайт: https://www.testplant.com/

Лицензия: платная

Tricentis Tosca

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

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

Веб-сайт: https://www.tricentis.com/

Лицензия: платная

Ranorex

Ranorex – это платный универсальный инструмент для автоматизации тестирования веб-, мобильных и десктопных приложений. Инструмент характеризуется расширенными возможностями для распознавания GUI, применением многоразовых тестовых сценариев и возможностью записи/воспроизведения этапов тестирования ПО. Еще одной полезной чертой данного инструмента является возможность создания тестовых сценариев без необходимости писать код. Для тех тестировщиков, кто находится на самом начале пути, такая особенность окажется прекрасным подспорьем: тестировщикам не нужно будет обладать углубленными знаниями в программировании, для того чтобы проводить автоматическое тестирование своих проектов.
Инструмент поддерживает интеграцию Selenium для тестирования веб-приложений. Тестировщики могут группировать определенные результаты тестирований для разных платформ и в различных браузерах с использованием сетки Selenium. Для Ranorex также предусмотрены скидки для бизнес-клиентов.

Веб-сайт: https://www.ranorex.com/

Лицензия: платная

Robot framework

Robot Framework — это фреймворк для автоматического тестирования с открытым исходным кодом, в котором реализуется подход тестирования на основе ключевых слов для приемочного тестирования и разработки через приемочное тестирование (ATDD). Robot Framework предоставляет возможность решения различных задач автоматизации тестирования. Однако его возможности могут быть расширены благодаря внедрению дополнительных библиотек с помощью Python и Java. Например, Selenium WebDriver — популярная внешняя библиотека, используемая в Robot Framework.

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

Веб-сайт: http://www.robotframework.org/

Лицензия: бесплатная

Топ 5 лучших инструментов автоматизации тестирования в 2018 году


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

Похожие статьи:

— #1 сервис по продвижению на реддит.

Нагрузочное тестирование Web-систем. Как к нему подготовиться / Хабр

Если вы все знаете о нагрузочном тестировании и как правильно к нему подготовиться, то вам статья будет не интересна. Статья рассчитана на тех, кто хочет понять как строить “правильные” профили для тестирования и на что необходимо обращать внимание при подготовке сценария. Речь будет идти о Web-системах с Web-интерфейсом.

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

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

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

Количество соединений и последовательность выполнения

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

Internet Explorer:

Google Chrome:

Например я видел как для одного и того же ресурса https создавалось разное количество параллельных соединений. Так Google Chrome создавал 6 соединений и все запросы обрабатывал в рамках этого количества, а вот Internet Explorer мог создавать до 20 — 30 параллельных соединений.

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

То есть фактически неправильно говорить, что один поток в утилите для тестирования производительности будет всегда соответствовать работе одного реального пользователя.

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

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

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

Сторонние ресурсы

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

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

Группировка

Необходимо группировать запросы по выполняемым действиям. Так можно создавать отдельные группы на открытие главной страницы, на вход в систему, на переход по ссылке и т. д. Это все нужно в основном только для того, что установить необходимые задержки между группами действий. Мы рассматриваем одного виртуального пользователя как пользователя, который реально работает с системой. Естественно при наличии 100, 200, 1000 и более реальных пользователей, каждый из них будет проводить на определенной странице разное количество времени. Следовательно трафик должен идти от виртуальных пользователей неравномерно. Поэтому между группами действий необходимы устанавливать задержки. И чем более реальными они будут, тем более реальные результаты тестирования вы будете получать.

Заключение

Мы можем проигнорировать количество параллельно выполняемых соединений, сторонние ресурсы, группировки и задержки. Но в результате мы можем получить результаты тестов где видно, что система работает с 200 виртуальными пользователями (потоками), а на практике получите только 10 реальных. Или получить прямо обратные результаты, когда по графикам мы видим только 200 пользователей могут работать с системой, но с учетом разного времени использования страниц, количество используемых соединений и исключения сторонних ресурсов, мы можем получить и 500 реально работающих.

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

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

Update: продолжаем подготовку в статье
Update2: завершаем подготовку в статье

8 Step Guide to Website Testing

• Home

• Testing

  • • Back
    • Agile Testing
    • BugZilla
    • Cucumber
    • Database Testing
    • 9000 J2000
    • 9000 J7 Testing
    • JUnit
    • LoadRunner
    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад
    • Центр качества (ALM)
    • 000
    • Центр качества (ALM)

    000 Управление тестированием

    • TestLink

• SAP

  • • Назад
    • ABAP

    9 0003 APO

    • Начинающий
    • Basis
    • BODS
    • BI
    • BPC
    • CO
    • Назад
    • CRM
    • Crystal Reports
    • FICO

    Hroll

    Hroll

    • Назад
    • PI / PO
    • PP
    • SD
    • SAPUI5
    • Безопасность
    • Менеджер решений
    • Successfactors
    • SAP Tutorials
• Web
• Web
• AngularJS
• ASP.Net
• C
• C #
• C ++
• CodeIgniter
• СУБД
• JavaScript

• Назад
• Java
• JSP
• Kotlin
• Linux
• Linux
• Kotlin
• Linux

js

• Perl

• Назад
• PHP
• PL / SQL
• PostgreSQL
• Python
• ReactJS
• Ruby & Rails
• Scala
• SQL

000

• SQL

000

0003 SQL

000

0003 SQL

000

• UML
• VB.Net
• VBScript
• Веб-службы
• WPF