Базовые знания тестировщика веб-приложений

кнопка [Search];

кнопка [Clear].

Не важно, какие элементы имеет ваша поисковая панель, в любом случае начинать тестирование нужно с простого нефильтрованного поиска. Такой поиск должен возвращать все заказы, которые есть в базе данных. Для этого все фильтры должны быть выставлены в значение “Любой”, “Все”, “All” и т.п. Поле для ввода поискового терма также должно быть оставлено пустым. После запуска такого поиска проверьте следующее:

все записи действительно вернулись из базы (Количество записей в базе соответствует количеству заказов в результатах поиска);

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

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

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

Поиск

Только убедившись, что действительно все записи возвращаются из базы, можно приступать к фильтрованному поиску. Тестирование фильтров нужно начинать с тестирования каждого фильтра по отдельности. Удобнее это делать, когда в базе имеется лишь небольшое количество записей. Например, наш интернет-магазин занимается продажей книг. Все книги разделены по видам литературы: “Художественная литература”, “Образовательная литература” и “Документальная проза”. В поисковую панель добавлен фильтр “Вид Литературы”. Помимо всех видов литературы этот фильтр также должен иметь вариант “Все виды”. Выставьте фильтр в одно из значений и проверьте, что все книги этого вида и доступные текущему пользователю представлены в поисковой выдаче. Убедитесь, что нет книг, не относящихся к выбранному виду. Только проверив все фильтры по отдельности, переходите к тестированию нескольких фильтров одновременно.

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

– Номер заказа;

– Название книги;

– Вид Литературы;

– Цена;

– Заказчик;

– Дата;

– Статус.

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

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

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

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

Пользователи ищут книгу по названию. Порой они не знают точного названия и хотят найти ее лишь по обрывку из памяти. В этом случае лучше отсортировать книги по их релевантности к поисковому терму. Релевантность – это соответствие текстовых полей поисковому терму. При сортировке по релевантности сверху списка будут результаты, наиболее точно совпадающие с поисковым запросом. Каждый поисковый движок имеет свой алгоритм подсчета релевантности. Он учитывает количество совпадений, частоту повторений, совпадение словоформы и наличие синонимов. Например, пользователь ввел в поисковое поле фразу “Уход за маленькими котятами”. Вот как могут быть отсортированны результаты поиска:

– уход за котятами;

– уход за маленькими щенками;

– котята маленькой кошечки;

– красивые котята.

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

Если на вашем сайте есть сортировка числовых данных, то нужно проверить, что числа сортируются по возрастанию или убыванию. Иногда сортировка чисел упорядочивает их по алфавиту, как будто это строковые значения, а не числа. Например, 2, 12, 20 и 100 будут отсортированы в 100, 12, 2, 20. Это, конечно же, баг.

Поисковый Движок (Search Engine)

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

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

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

Тестирование поискового движка можно разделить на 2 части:

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

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

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

Создание

Проверьте, что новые сущности ищутся по всем индексируемым полям

Удаление

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

Обновление

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

Копирование

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

Клонирование (Sharing)

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

Дополнительные кнопки

Кроме [Submit] на форме могут быть и другие кнопки (например, кнопка выбора файла). Файл загружается на сервер автоматически после его выбора. По окончанию загрузки данные в базе будут обновлены. Не забудьте проверить, что индекс также обновляется;

Перестановка (Drag and Drop)

Перетаскивание и перестановка элементов в дереве (drag&drop and reorder in tree) – этот кейс актуален, если Вы индексируете данные, которые хранятся в дереве. Проверьте, что при изменении порядка и взаимного расположения элементов в дереве они не выпадают из индекса.