В большинстве случаев тестирование интернет-приложений – это более сложный процесс, чем тестирование обычного программного обеспечения. Сложность обусловлена:

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

Проблемы тестировании веб-приложений

Распределенные компоненты системы приумножает трудности тестирования:

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

Мы решаем проблемы функционального тестирования веб-приложений, разрабатывая такие наборы тестов, который:

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

Готовы начать!

Построение качественного процесса тестирования

Начинать процесс тестирования на этапе формирования требований либо самого интернет-приложения, либо добавляемого функционала;
Оценка рентабельности применения автоматизации тестирования. И его дальнейшая организация в случае его применения;
Ведение отчетности. Описываются различные документы для контроля и хранения результатов процесса тестирования: ТЗ на тестирование, ежедневные отчеты, отчеты полного тестирования приложения с рекомендациями по выпуску;
Разделение задач. Предлагается поручать такие задачи как тест-дизайн, автоматизация тестирования, выполнение тестов различным сотрудникам отдела;
Делегирование полномочий. Если работающий над конкретной задачей сотрудник лучше понимает ситуацию, чем руководитель данного проекта, то ему необходимо передать часть руководящих функций. Потому что ему будет проще найти выход из спорной ситуации и решить возможные проблемы;
Использование ротации. Суть состоит в перемещении тестировщиков между отделами IT департамента для лучшего понимания процесса разработки и развития новых профессиональных навыков у сотрудников.

Инструменты и сценарии тестирования веб-приложений

Boundary Value Testing – использование граничных значений. Техника тест дизайна, призванная помогать тестировщику выбирать наиболее эффективные значения из диапазонов значений. Она применима на всех уровнях тестирования: unit, integration, system, and system-integration test levels. Эта техника довольна проста и включает в себя 3 шага: определение диапазона значений; определение границ диапазонов; создание тест кейсов (3-4 на каждую границу);

Equivalence Class Testing – разбиение на классы эквивалентности. Эта техника используется для написания тестов для входных и выходных данных, которые обрабатываются приложением одинаково или обработка которых приводит к одному и тому же результату. Она резонно уменьшает количество создаваемых тестов. Использовать ее можно на всех уровнях тестирования: unit, integration, system, and system-integration test levels;

Decision Table Testing – таблицы требований. Техника для фиксирования требований и описания дизайна приложения. Decision Tables описывают логику приложения основываясь на условиях/свойствах состояния системы. Этими таблицами очень удобно описывать бизнес-логику приложения, если на тестируемое приложение нет адекватной документации. Представление требований в простой и компактной форме служит отличной основой для тест кейсов;

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

State-Transition Testing – описание состояний. Эта техника, как и decision tables testing, отличный инструмент для фиксирования требований и описания дизайна приложения. Но в отличие от decision tables testing, данная техника описывает, как эти состояния приложения могут меняться. Диаграммы определяют все события, которые возникают во время работы приложения, и как приложение реагирует на эти события. Существует два вида визуального представления этих событий:

State-Transition Diagrams (диаграммы). В этом представлении каждое состояние системы обозначается кругом, стрелками показываются возможные переходы в другие состояния, под стрелкой сначала записывают описание события, исходящего из вне системы, а потом действие системы в ответ на это событие;
State-Transition Tables (таблицы). При использовании данного подхода создается таблица состоящая из четырех столбцов: текущее состояние (Current State); событие (Event); действие (Action); следующее состояние (Next State). В этой таблице определяются все возможные State-Transition варианты (и не только валидные).

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

В первую очередь;
Более тщательно.

Готовы начать!

Pairwise Testing – попарное тестирование. Эта техника применяется в случае наличия большого количества комбинаций, которые необходимо протестировать, причем исключение каких-либо комбинаций выглядит рискованно. И если количество комбинаций настолько велико, то, скорее всего не хватит ресурсов, чтобы спроектировать и пройти тест кейсы. При использовании Pairwise Testing проверяются комбинации пар значений переменных, а не все комбинации значений для всех переменных. Эта техника существенно уменьшает количество комбинаций для тестирования. Существуют два способа ее реализации:

Orthogonal Arrays – подход заключается в разработке двумерного массива комбинаций значений входных данных со следующими свойствами:

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

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

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

Постановка задачи с использованием scrum методологий

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