Тестирование пользовательского интерфейса.
Графический интерфейс пользователя (Graphical User Interface, GUI)- разновидность пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки, логотипы, списки и т.п.) представлены пользователю на дисплее и исполнены в виде графических изображений.
Общие проверки пользовательского интерфейса:
•Вид элементов при уменьшении окна браузера + появление полосы прокрутки (скрол-бар)
•Правильность написания текста (грамматика, форматирование)
• Правильность перемещения фокуса в окне (Tab / Tab+Shift)
•Выбранные элементы корректно выделяются
•Качество используемых изображений
•Неизменяемые поля выглядят одинаково и отличаются от редактируемых
•Проверка наличия нужных уведомлений (нотификейшенов)
•Унификация дизайна (цвет, шрифт, размер)
•При необходимости должны быть всплывающие подсказки (тултипы)
•Изменение вида элемента при наведении на него, если это предусмотрено в системе
•Если формы дублируются, то должны быть одинаковые названия.
Наиболее распространенные баги:
•курсор не переходит в пойнтер при наведении на активный элемент (Свойство pointer-events не срабатывает);
•орфографические и грамматические ошибки;
•неровное расположение полей ввода в формах, самих форм;
•неправильное отображение элементов при смене размера окна браузера и масштаба страницы;
•изменение размера текста при смене языка;
•неровное расположение форм •разные шрифты •выбранные элементы не отличаются от не выбранных.
Ad-hoc тестирование
Ad hoc (лат. «по месту»)
• Этот вид тестирования ПО является неформальным и неструктурированным и может выполняться любым заинтересованным лицом, без ссылок на какие-либо тестовые сценарии или тестовые документы;
•Лицо, проводящее Ad-hoc-тестирование, хорошо понимает рабочие процессы приложения, при этом пытается найти дефекты и взломать ПО. Специальные проверки предназначены для обнаружения дефектов, которые не были обнаружены в существующих тестовых случаях.
Это вид исследовательского тестирования. Когда мы просто клацаем по всем элементам и пытаемся найти дефекты. Оно требует изощренного мышления и знания системы. По хорошему Ad-hoc тестирования не должно быть, т.к. это подразмевает то, что мы каким-то образом остались без документации и что мы не смогли расписать тестовую модель.
Monkey-тестирование
•Разновидность стресс-тестирования для воспроизведения ситуаций, которые не описаны в имеющейся тестовой модели, а потому не покрыты тестами.
•Поддается автоматизации (инструменты типа MonkeyRunner)
•Затруднено воспроизведение замеченной ошибки, если не автоматизировано.
Это почти Ad-hoc тестирование, но без понимания системы, которую мы тестируем.
В данном тестировании происходит беспорядочное "тыкание" по интерфейсу пользователя, пытаясь выявить какие-нибудь баги. С одной стороны данное тестирование иногда полезно, т.к. все же может выявить какой-нибудь баг, тыкнув куда-нибудь в ненужное место и тем самым сымитировать поведение человека, но с другой стороны здесь будет сложность воспроизведения действия, которое привело к багу.
Monkey-тестирование невысокопродуктивное и не может покрыть все риски. Она хороша для больших систем, когда нам все, просто, не проверить, там где вариабельность работы очень высока, где не существует сценариев более предсказуемой работы с пользователем, где он может делать все, что угодно.
Smoke-тестирование
Оно же – Дымовое тестирование. Минимальный набор тестов на явные ошибки. В первую очередь направлено на проверку готовности разработанного продукта к проведению более расширенного тестирования, определения общего состояния качества продукта.
Например:
•Ошибки инсталляции: если программный продукт не устанавливается, его тестирование, скорее всего, окажется невозможным;
•Ошибки при соединении с базой данных, актуально для архитектуры клиент-сервер;
•Ошибка авторизации оператора. Старт и финиш пользовательской сессии;
•Рабочие элементы загружаются не полностью (не загружаются);
•Рабочие функции недоступны, некорректно ограничены.
Тесты Smoke-тестирования быстрые, легкие, однозначные. Ориентированы на частое и быстрое прохождение после сборки очередного релиза.
Smoke-тестирование отвечает на вопрос: можем ли мы, вообще, тестировать данное приложение. Если дымовое тестирование пройдено, то мы можем заниматься другими видами тестирования. Если не пройдено, то мы сразу сообщаем ответственному, что система не работает. И здесь не всегда виновен разработчик, т.к. может быть не соответствие системных требований в тестовой среде.
Санитарное тестирование (Sanity)
•В ряде теорий считается подмножеством регрессионного тестирования. В некоторых – как самостоятельный вид. В некоторых – часть приемочного тестирования. Нацелено на установление факта того, что определённые части тестируемого продукта всё так же работают как положено после минорных изменений или исправлений багов.
•Выполняется после smoke-тестов, но перед регрессом.
•Может выполняться без тест-кейсов, но знание тестируемой системы обязательно
•Периодически используется синоним «тестирование согласованности/исправности».
Оно проходится по основному пользовательскому функционалу системы и говорит, что, В ПРИНЦИПЕ, мы можем работать с данной системой. К примеру, заполняя поля для выдачи банковской карточки, мы можем выдать карточку, но не вдаваясь в детали.
Регрессионное тестирование
•Регрессио́нное тести́рование (англ. regression testing, от лат. regressio — движение назад) — собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода;
•Не путать с re-testing (ретестингом) – повторной проверкой функции после заявленного разработчиком исправления дефекта.
Включает в себя два аспекта:
• old bug-fix — проверка, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова;
•side-effect — проверка того, что не нарушилась работоспособность работающей ранее функциональности, если её код мог быть затронут при исправлении некоторых дефектов в другой функциональности.
Регрес не надо путать с ретестом. Регрес направлен на тестирование того функционала, который уже был протестирован и мы убеждаемся, что разработка нового функционала не повлек отказ старого функционала.
Ретест - это когда мы ранее проверяли неисправный функционал и мы перепроверяем данный функционал, что его исправили.
Нагрузочное тестирование
•Нагрузочное тестирование (англ. load testing) — подвид тестирования производительности, сбор показателей и определение производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству);
•Часто включает в себя элементы стресс-тестирования;
•Подразумевает высокий уровень автоматизации т.к. требует эмуляции множественных одновременных запросов пользователей;
•Характеризуется высокими требованиями к аналитической обработке результатов нагрузки.
Данное тестирование проверяет поведение приложения, как себя ведет система, при эмуляции воздействии множества пользователей; одновременное использование базы данных, когда один пользователь хочет удалить запись, а другой изменить ее.
Нагрузочным тестированием занимаются отдельные тестировщики, но его можно включать в тестовую модель, если подразумевается комплексное проведение тестирования.
Бета-тестирование
Бета способен найти только те баги, которые не нашел до него тестировщик…
•Бета-тести́рование (англ. beta testing) — интенсивное использование почти готовой версии продукта с целью выявления максимального числа ошибок в его работе для их последующего устранения перед выводом его в промышленную эксплуатацию.
•В отличие от альфа-тестирования, проводимого силами штатных разработчиков или тестировщиков, бета-тестирование предполагает привлечение добровольцев из числа обычных будущих пользователей продукта, которым доступна упомянутая предварительная версия продукта (так называемая бета-версия).
Оно происходит после того как приложение проверил тестировщик и используется на тех проектах, где полная проверка очень затратна, где все комбинации, просто, не проверить. Поэтому бета-тестирование проводится на рабочем проекте, множеством пользователей и, которые предоставляют обратную связь и это, можно так сказать, что это враг тестировщика, т.к. они смогли найти то, что не смог найти тестировщик.
И многое другое
•Тестирование документации. С этим в Agile-проектах сложно, т.к. документация разрабатывается и внедряется уже в момент разработки нового функционала при новом спринте и тестировщку остается мало времени на создание тестовой модели и самого тестирования.
•Тестирование инсталляции/деинсталляции
•Стресс-тестирование
•Юзабилити-тестирование
•Тестирование портативности
•Тестирование мобильных приложений
•Веб-тестирование
•SEO тестирование
•Тестирование локализации и интернационализации
