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

Почему «Про Тестинг»?

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

Наша миссия

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

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

Вам нужна помощь?

Если вам нужна помощь, то вы пришли туда, где вам помогут. Наши специалисты окажут следующие услуги по тестированию и обеспечению качества:

1. Рецензия и подготовка документации для тестирования
2. Тестирование программного обеспечения
3. Консультации по вопросам тестирования и обеспечения качества программного обеспечения
4. Помощь в прохождении и проведении интервью (Виртуальное интервью)

Просто свяжитесь с нами по интересующим Вас вопросам на странице: Вопросы, пожелания и заявки

Наши планы

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

• запуск тестов и подготовка результатов в формате XML/HTML (пилотная версия уже доступна JTR — Java Test Runner)
• Фреймворк для автоматизации тестирования (пилотная версия уже доступна ATFwk)
• автоматическая генерация тест кейсов
• генерация данных, соответствующих вашим требованиям

и многое другое.

ProTesting.RU

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

Websitetools

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

FireBug

Load Impact

Web Developer Firefox Extension

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

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

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

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

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

Тестирование сайта — основные этапы, порядок работ

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

Зачем это нужно?

В интернете ходят легенды о простой, но невероятно прибыльной работе, заключающейся, как раз, в проверке сайтов, потому что люди ошибочно полагают, будто тестировать очень легко — достаточно просто проверить, туда ли ведут ссылки и работают ли формы. Не стоит и говорить, что этим должен заниматься специалист, который понимает суть, знает соответствующую методику и принципы, а работа его не так уж проста. Мало того, что он систематизирует несоответствия и работает с документацией. В ходе тестирования программных продуктов его интересуют такие вопросы, как, например, «Корректно ли поведёт себя программа, если на вот эту кнопку нажать 500 раз правой кнопкой мыши?». Так что отлов ошибок лучше доверить профессионалу.

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

Простое тестирование

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

Итак, в случае стандартного проекта всё тестирование сводится к сверке функционала и внешнего вида получившегося сайта с тем, что требовало ТЗ. Ссылки, формы, другие интерактивные элементы проверяются на работоспособность, а дальше — всё по заданию. Было заявлено, что ресурс должен корректно отображаться и на смартфонах и на ПК — адаптивность сайта проверяется, в ТЗ указана непременная совместимость сайта с Internet Explorer 9 — это тоже проверяется.

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

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

Этапы проверки

Подготовка. Специалист получает техническое задание, прототипы, прочую документацию; анализирует её, составляет план тестовых работ.

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

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

Тест юзабилити. Этот пункт выявляет удобство пользования ресурсом. Конечно, интерфейс продумывается ещё на стадии разработки ТЗ, но на практике реализованные решения не всегда бывают оптимальными. Юзабилити-тест проводится с участием пользователей. Такие работы практикуются и до, и после запуска проекта. Приёмы, подобные A/B-тестированию, призваны не только повысить удобство, но также помочь достичь целей создания проекта, например, увеличить конверсию продаж.

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

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

Результат

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

A/B тест — это просто / Хабр

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

Мне часто приходится сталкиваться с задачами организации A/B тестирования в различных интернет-проектах. В этой статье хочу поделиться необходимыми базовыми знаниями для проведения тестов и анализа результатов.

Зачем нужны А/B тесты?

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

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

Как проводим тесты?

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

Для снижения влияния внешних факторов, таких как рекламные кампании, день недели, погода или сезонность, замеры в сегментах важно делать параллельно, т.е. в один и тот же период времени.

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

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

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

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

Что улучшаем?

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

Конверсия

Экономические метрики

Поведенческие факторы

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

Анализ результатов

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

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

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

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

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

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

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

Как правило, для принятия положительного решения об эффективности изменений уровень значимости выбирают равным 90%, 95% или 99%. Пересечение распределений при этом равно соответственно 10%, 5% или 1%. При невысоком уровне значимости существует опасность сделать ошибочные выводы об эффекте, полученном в результате изменения.

Несмотря на важность этой характеристики, в отчетах по A/B тестам, к сожалению, часто забывают указать уровень значимости, при котором был получен результат.

Кстати, на практике примерно 8 из 10 A/B тестов не являются статистически значимыми.

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

Оценить значимость результатов

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

В качестве примера приведу сравнение средней длительности сессии в сегментах на одном из ресурсов, для которых я проводил эксперимент: studentttest.xls.

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

В случае, если вы измеряете только конверсию, то вы имеете дело с бинарной слуайной величиной, которая принимает только два значения: посетитель “сконвертировался” и “не сконвертировался”. Для оценки статистической значимости в этом случае можно воспользоваться он-лайн калькулятором.

Инструменты

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

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

А дальше?

Тестирование. Фундаментальная теория / Хабр

Ниже основы основ для повторения перед собеседованием для Trainee and Junior: определение тестирования, качество, верификация / валидация, цели, этапы, тест план, пункты тест плана, тест дизайн, техники тест дизайна, traceability matrix, test case, чек-лист, дефект, error/deffect/failure, баг репорт, severity vs priority, уровни тестирования, виды / типы, подходы к интеграционному тестированию, принципы тестирования, статическое и динамическое тестирование, исследовательское / ad-hoc тестирование, требования, жизненный цикл бага, стадии разработки ПО, decision table, qa/qc/test engineer, диаграмма связей.

Все замечания, корректировки и дополнения очень приветствуются.

Тестирование программного обеспечения — проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. В более широком смысле, тестирование — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Качество программного обеспечения (Software Quality) — это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [Quality management and quality assurance]

Верификация (verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа[IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].
Также можно встретить иную интерпритацию:
Процесс оценки соответствия продукта явным требованиям (спецификациям) и есть верификация (verification), в то же время оценка соответствия продукта ожиданиям и требованиям пользователей — есть валидация (validation). Также часто можно встретить следующее определение этих понятий:
Validation — ’is this the right specification?’.
Verification — ’is the system correct to specification?’.

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

Этапы тестирования:
1. Анализ продукта
2. Работа с требованиями
3. Разработка стратегии тестирования
и планирование процедур контроля качества
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Отвечает на вопросы:
Что надо тестировать?
Что будете тестировать?
Как будете тестировать?
Когда будете тестировать?
Критерии начала тестирования.
Критерии окончания тестирования.

Основные пункты тест плана
В стандарте IEEE 829 перечислены пункты, из которых должен (пусть — может) состоять тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) Staffing and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

Тест дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Роли, ответственные за тест дизайн:
• Тест аналитик — определяет «ЧТО тестировать?»
• Тест дизайнер — определяет «КАК тестировать?»

Техники тест дизайна

• Эквивалентное Разделение (Equivalence Partitioning — EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.

• Анализ Граничных Значений (Boundary Value Analysis — BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

• Причина / Следствие (Cause/Effect — CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» — это «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране — это «Следствие».

• Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тестировщик будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? », и так далее. Это и есть предугадывание ошибки.

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

• Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных. Сформулировать суть можно, например, вот так: формирование таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров.

Допустим, какое-то значений (налог) для человека рассчитывается на основании его пола, возраста и наличия детей — получаем три входных параметра, для каждого из которых для тестов выбираем каким-то образом значения. Например: пол — мужской или женский; возраст — до 25, от 25 до 60, более 60; наличие детей — да или нет. Для проверки правильности расчётов можно, конечно, перебрать все комбинации значений всех параметров:

А можно решить, что нам не нужны сочетания значений всех параметров со всеми, а мы хотим только убедиться, что мы проверим все уникальные пары значений параметров. Т.е., например, с точки зрения параметров пола и возраста мы хотим убедиться, что мы точно проверим мужчину до 25, мужчину между 25 и 60, мужчину после 60, а также женщину до 25, женщину между 25 и 60, ну и женщину после 60. И точно так же для всех остальных пар параметров. И таким образом, мы можем получить гораздо меньше наборов значений (в них есть все пары значений, правда некоторые дважды):

Такой подход примерно и составляет суть техники pairwise testing — мы не проверяем все сочетания всех значений, но проверяем все пары значений.

Traceability matrix — Матрица соответствия требований — это двумерная таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица соответствия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

Тестовый сценарий (Test Case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Пример:
Action Expected Result Test Result
(passed/failed/blocked)
Open page «login» Login page is opened Passed

Каждый тест кейс должен иметь 3 части:
PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)
Виды Тестовых Сценариев:
Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:
• Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
• Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.

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

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

Error — ошибка пользователя, то есть он пытается использовать программу иным способом.
Пример — вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.).
В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message), с красным крестиком которые.
Bug (defect) — ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные «радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.

Баг Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Шапка
Короткое описание (Summary) Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Проект (Project) Название тестируемого проекта
Компонент приложения (Component) Название части или функции тестируемого продукта
Номер версии (Version) Версия на которой была найдена ошибка
Серьезность (Severity) Наиболее распространена пятиуровневая система градации серьезности дефекта:
• S1 Блокирующий (Blocker)
• S2 Критический (Critical)
• S3 Значительный (Major)
• S4 Незначительный (Minor)
• S5 Тривиальный (Trivial)
Приоритет (Priority) Приоритет дефекта:
• P1 Высокий (High)
• P2 Средний (Medium)
• P3 Низкий (Low)
Статус (Status) Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)

Автор (Author) Создатель баг репорта
Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы
Окружение
ОС / Сервис Пак и т.д. / Браузера + версия /… Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования — имя и версия браузера и т.д.
…
Описание
Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению
Ожидаемый результат (Expected Result) Ожидаемый правильный результат
Дополнения
Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы

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

Градация Серьезности дефекта (Severity)

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

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

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

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

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

Градация Приоритета дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Уровни Тестирования

1. Модульное тестирование (Unit Testing)
Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

2. Интеграционное тестирование (Integration Testing)
Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

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

4. Операционное тестирование (Release Testing).
Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес модели системы. Следует учесть, что и бизнес модель может содержать ошибки. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях; недостаточная производительность системы в среде эксплуатации и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема. Поэтому так важно проведение не только верификации, но и валидации, с самых ранних этапов разработки ПО.

5. Приемочное тестирование (Acceptance Testing)
Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:
• определения удовлетворяет ли система приемочным критериям;
• вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

Виды / типы тестирования

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

• Функциональное тестирование (Functional testing)
• Тестирование пользовательского интерфейса (GUI Testing)
• Тестирование безопасности (Security and Access Control Testing)
• Тестирование взаимодействия (Interoperability Testing)

Нефункциональные виды тестирования

• Все виды тестирования производительности:
o нагрузочное тестирование (Performance and Load Testing)
o стрессовое тестирование (Stress Testing)
o тестирование стабильности или надежности (Stability / Reliability Testing)
o объемное тестирование (Volume Testing)
• Тестирование установки (Installation testing)
• Тестирование удобства пользования (Usability Testing)
• Тестирование на отказ и восстановление (Failover and Recovery Testing)
• Конфигурационное тестирование (Configuration Testing)

Связанные с изменениями виды тестирования

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

Тестирование пользовательского интерфейса (GUI Testing) — функциональная проверка интерфейса на соответствие требованиям — размер, шрифт, цвет, consistent behavior.

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

Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование

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

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

Объемное тестирование (Volume Testing). Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения

Тестирование стабильности или надежности (Stability / Reliability Testing). Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

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

Тестирование удобства пользования — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Сюда также входит:
User eXperience (UX) — ощущение, испытываемое пользователем во время использования цифрового продукта, в то время как User interface — это инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».

Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.

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

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

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

Повторное тестирование — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
В чем разница между regression testing и re-testing?
Re-testing — проверяется исправление багов
Regression testing — проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвало новых багов.

Тестирование сборки или Build Verification Test — тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. По своим целям является аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию. Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии.

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

Подходы к интеграционному тестированию:
• Снизу вверх (Bottom Up Integration)
Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
• Сверху вниз (Top Down Integration)
Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Таким образом мы проводим тестирование сверху вниз.
• Большой взрыв («Big Bang» Integration)
Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.

Принципы тестирования

Принцип 1 – Тестирование демонстрирует наличие дефектов (Testing shows presence of defects)
Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, это не доказывает его корректности.

Принцип 2 – Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible)
Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию.

Принцип 3 – Раннее тестирование (Early testing)
Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения или системы, и должны быть сфокусированы на определенных целях.

Принцип 4 – Скопление дефектов (Defects clustering)
Усилия тестирования должны быть сосредоточены пропорционально ожидаемой, а позже реальной плотности дефектов по модулям. Как правило, большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей.

Принцип 5 – Парадокс пестицида (Pesticide paradox)
Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот “парадокс пестицида”, тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения,
или системы, и найти как можно больше дефектов.

Принцип 6 – Тестирование зависит от контекста (Testing is concept depending)
Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем сайт электронной коммерции.
Принцип 7 – Заблуждение об отсутствии ошибок (Absence-of-errors fallacy)
Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям.

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

Исследовательское / ad-hoc тестирование
Простейшее определение исследовательского тестирования — это разработка и выполнения тестов в одно и то же время. Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом.

Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования.

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

Требования к требованиям:
• Корректность
• Недвусмысленность
• Полнота набора требований
• Непротиворечивость набора требований
• Проверяемость (тестопригодность)
• Трассируемость
• Понимаемость

Жизненный цикл бага

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

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

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

Жизненный цикл разработки ПО:
• Пре-альфа
• Альфа
• Бета
• Релиз-кандидат
• Релиз
• Пост-релиз

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

QA/QC/Test Engineer

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

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

Источники: www.protesting.ru, bugscatcher.net, qalight.com.ua, thinkingintests.wordpress.com, книга ISTQB, www.quizful.net, bugsclock.blogspot.com, www.zeelabs.com, devopswiki.net, hvorostovoz.blogspot.com.

Ресурсы рекомендованные в комментах Sofiya Novachenko: istqbexamcertification.com www.testingexcellence.com

Что такое веб-тестирование? Краткое руководство по тестированию веб-сайтов с помощью Testing Web Sites

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

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

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

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

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

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

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

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

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

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

Чтобы определить, что следует тестировать, ознакомьтесь с разделом «Планы и контрольные списки тестирования».

Тестирование совместимости браузера

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

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

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

Например, текущая тенденция состоит в том, чтобы кнопки и другие стили имели закругленные углы, поскольку это более эстетично. Как правило, этот стиль с закругленными углами применяется с использованием технологии CSS3. Старые веб-браузеры, такие как IE7 и IE8, не поддерживают CSS3, поэтому для этих старых браузеров необходимо сделать поправку.

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

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

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

Начните работу с 27 инструментами тестирования браузера.

Мобильное тестирование

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

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

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

Наконец, мобильное тестирование также охватывает тестирование специализированных или собственных приложений на мобильных устройствах, включая iPhone, iPad, Android, Blackberry и Windows Phone.

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

Нет ничего удивительного в том, что приложения Android, в частности, тестируются на 30-40 различных телефонах или более.

Начните работу с 49 инструментами мобильного тестирования.

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

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

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

Юзабилити-тестирование направлено на то, чтобы запомнить себя пользователем или посетителем и проработать сайт для выполнения тех же задач, что и настоящий посетитель.

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

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

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

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

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

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

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

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

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

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

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

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

Начните работу с 61 инструментом для тестирования удобства использования.

A / B, сплит- и многомерное тестирование

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

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

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

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

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

Начните работу с 22 инструментами A / B, разделенного и многовариантного тестирования.

Тестирование производительности

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

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

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

Начните работу с 21 инструментом для тестирования производительности.

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

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

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

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

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

Начните работу с 13 инструментами стресс-тестирования или нагрузочного тестирования.

Тестирование программного обеспечения

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

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

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

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

Начните работу с 41 инструментом для тестирования программного обеспечения.

Автоматизированное тестирование

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

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

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

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

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

Тестирование безопасности

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

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

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

Начните работу с 11 инструментами тестирования безопасности.

Тестирование доступности

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

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

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

Начните работу с 21 валидатором и инструментами тестирования доступности.

Контент-тестирование

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

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

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

Начните работу с 4 инструментами тестирования контента.

Мониторинг сайтов

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

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

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

Это можно сделать и дальше, чтобы гарантировать, что определенные аспекты веб-сайта продолжают работать правильно и в течение приемлемого периода времени.

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

Начните работу с 30 инструментами мониторинга сайта.

Заключение

Я надеюсь, что это поможет ответить на вопрос «что такое веб-тестирование» и упростит понимание типов тестирования, составляющих тестирование веб-сайтов, мобильных сайтов и приложений.

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

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

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

11 лучших бесплатных инструментов для тестирования скорости веб-сайтов в 2020 году

• Home

• Testing

  • • Back
    • Agile Testing
    • BugZilla
    • Cucumber
    • Database Testing
    • JTL Testing
      • Назад
      • JUnit
      • LoadRunner
      • Ручное тестирование
      • Мобильное тестирование
      • Mantis
      • Почтальон
      • QTP
      • Назад
      • Центр качества
      • 0003000300030003 SoapUI
      • Управление тестированием
      • TestLink

  • SAP

    • • Назад
      • ABA P
      • APO
      • Новичок
      • Basis
      • BODS
      • BI
      • BPC
      • CO
      • Назад
      • CRM
      • Crystal Reports
      • QM4O
      • Заработная плата
      • Назад
      • PI / PO
      • PP
      • SD
      • SAPUI5
      • Безопасность
      • Менеджер решений
      • Successfactors
      • SAP Tutorials
      4
    • Web
    • Apache
    • 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
    0000003 SQL0000003 SQL000
    • UML
    • VB.Net
    • VBScript
    • Веб-службы
    • WPF

• Обязательно учите!

  • • Назад
    • Бухгалтерский учет
    • Алгоритмы
    • Android
    • Блокчейн
    • Business Analyst
    • Создание веб-сайта
    • CCNA
    • Облачные вычисления
    • 00030003 COBOL
      9000 Compiler
      9000 Встроенные системы
      • 00030003 9000 Compiler 9000
      • Ethical Hacking
      • Учебные пособия по Excel
      • Программирование на Go
      • IoT
      • ITIL
      • Jenkins
      • MIS
      • Сети
      • Операционная система
      • 00030003
      • Назад
      Управление проектами Обзоры
      • Salesforce
      • SEO
      • Разработка программного обеспечения
      • VB A

    • Big Data

      • • Назад
        • AWS
        • BigData
        • Cassandra
        • Cognos
        • Хранилище данных
        00030003
        • HBOps
        0003
        • HBOps
        0003
        • MicroStrategy
        • MongoDB
        • NiFi
        • OBIEE
        • Pentaho
        • Назад
        • Power BI
        • Qlikview
        • Табличка
        • Pro000300030003
        • 000 Live
        000 Live000000 Live00030003
        • Live Agile Testing
        • Live HP ALM
    .

    20 лучших инструментов для веб-тестирования в 2020 году

    • Главная страница

    • Тестирование

      • • Назад
        • Гибкое тестирование
        • BugZilla
        • Cucumber
        • Тестирование базы данных
        • J2000 J2000
        • Тестирование ETL Назад
        • JUnit
        • LoadRunner
        • Ручное тестирование
        • Мобильное тестирование
        • Mantis
        • Почтальон
        • QTP
        • Назад
        • Центр качества (ALM)
        • SAP Testing
        • SAPU
        • Управление тестированием
        • TestLink

    • SAP

      • • Назад
        • ABAP
        • APO
        • Начинающий
        • Basis
        • BODS
        • BI
        • BPC
        • CO
        • Назад
        • CRM
        • Crystal Reports
        • FICO
        • 000 HRM
        • 000 HRM
        • Назад
        • PI / PO
        • PP
        • SD
        • SAPUI5
        • Безопасность
        • Менеджер решений
        • Successfactors
        • SAP Tutorials

    • 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
    0000003 SQL0000003 SQL000
    • UML
    • VB.Net
    • VBScript
    • Веб-службы
    • WPF

• Обязательно учите!

  • • Назад
    • Бухгалтерский учет
    • Алгоритмы
    • Android
    • Блокчейн
    • Business Analyst
    • Создание веб-сайта
    • CCNA
    • Облачные вычисления
    • 00030003 COBOL
      9000 Compiler
      9000 Встроенные системы
      • 00030003 9000 Compiler 9000
      • Ethical Hacking
      • Учебные пособия по Excel
      • Программирование на Go
      • IoT
      • ITIL
      • Jenkins
      • MIS
      • Сети
      • Операционная система
      • 00030003
      • Назад
      Управление проектами Обзоры
      • Salesforce
      • SEO
      • Разработка программного обеспечения
      • VB A

    • Big Data

      • • Назад
        • AWS
        • BigData
        • Cassandra
        • Cognos
    .

    Тест скорости веб-сайта | Проверить производительность в Интернете »Dotcom-Tools

    Тестирование скорости веб-сайта

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

    • Тестирование времени загрузки всех элементов страницы на основе браузера
    • Обнаружение медленных / недостающих элементов
    • Тестирование через Chrome, Firefox, IE и мобильные веб-браузеры
    • Полный отчет о водопаде, диаграммы и графики
    • Результаты почти из 2 десятков мест по всему миру
    • Абсолютно бесплатно — регистрация не требуется

    Тест скорости веб-сайта Dotcom-Monitor позволяет пользователям тестировать свой веб-сайт из 20 мест по всему миру, включая облачные тесты (Amazon-США-Восток) и из-за Великого китайского файрвола (Шанхай, Китай).После завершения теста пользователи могут выбирать «подробности», углубляться в подробные отчеты о производительности и анализировать водопадную диаграмму. Пользователи также могут выбрать, из какого браузера они хотят протестировать. Этот тест поддерживает Chrome, Firefox, IE и мобильные браузеры, включая iPhone, iPad и другие! Dotcom-Monitor постоянно разрабатывает инструменты повышения производительности, чтобы помочь пользователям, веб-мастерам и разработчикам улучшить свои сайты и удобство работы в Интернете.

    О компании Dotcom-Monitor

    Dotcom-Monitor — компания, занимающаяся веб-производительностью, базирующаяся в Миннеаполисе, штат Миннесота.Мы отслеживаем доступность веб-сайтов, серверов и приложений, скорость и функциональность из нашей всемирной сети.

    В ответ на возросший спрос на комплексное решение для тестирования производительности, Dotcom-Monitor недавно запустила революционную облачную Платформа для нагрузочного тестирования. LoadView предлагает 100% нагрузочное тестирование в реальном браузере, и все это из полностью управляемого и бесконечно масштабируемая облачная инфраструктура.Для демонстрации системы посетите LoadView-Testing.com Чтобы узнать больше о методах тестирования производительности, ознакомьтесь с нашей статьей об определении нагрузочного тестирования.

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

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

    .

    No related posts.