Виды тестирования интерфейсов

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

Рассмотрим наиболее популярные типы и виды тестирования.

По целям тестирования:

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

Нефункциональное Тестирование пользовательского интерфейса (User Interface Testing (UI)) — довольно большая доля успеха проекта. Оно позволяет выявить: ошибки в функциональности посредством интерфейса, необработанные исключения при взаимодействии с интерфейсом, потеря или искажение данных, передаваемых через элементы интерфейса, ошибки в интерфейсе (несоответствие проектной документации, отсутствие элементов интерфейса и т. д.).

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

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

Тестирование безопасности (Security and Access Control Testing) обеспечивает целостный подход к защите приложения от атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным. Может выполняться как автоматизировано так и в ручную, включая проверку как позитивных, так и негативных тестовых случаев. Основывается на трех основных принципах — это конфиденциальность, целостность и доступность (confidentiality, integrity, availability). Тестирование безопасности зачастую рассматривается как функциональное, так как для некоторых проектов их безопасность является критически важна.

По степени автоматизации:

Ручное (мануальное) — Проверка системы без использования дополнительных программных средств, кроме Exel, NotPad и т. д.

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

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

По позитивности сценария (по типу вводимых данных):

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

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

По знанию системы:

Белого ящика (White / Glass Box) — метод тестирования программного обеспечения, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику. Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Точно так же мы знаем, каким должен быть результат этой обработки и можем проверить как данные записываются в базу. Знание всех особенностей тестируемой программы и ее реализации — обязательны для этой техники. Тестирование белого ящика — углубление во внутренне устройство системы, за пределы ее внешних интерфейсов Серого ящика (Grey Box) — предполагает, комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично. Предполагается, например, доступ к внутренней структуре и алгоритмам работы ПО для написания максимально эффективных тест-кейсов, но само тестирование проводится с помощью техники черного ящика, то есть, с позиции пользователя.

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

По разработке тестовых сценариев:

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

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

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

По исполнителям тестирования:

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

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

По уровню тестирования, в процессе разработки:

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

Интеграционное — тестирование проводится для выявления дефектов в интерфейсах и во взаимодействии между интегрированными компонентами или системами.

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