Неделя 2. Теория тестирования. Часть 2⁠⁠

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

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

А теперь конспект:

Классификация тестирования:

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

• Компонентное, модульное, unit-тестирование - тестирование отдельных компонентов (например, корзины в интернет магазине)

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

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

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

• Системное тестирование - тестирование выполняется на полной интегрированной системе с целью проверки соответствия системы исходным требованиям.

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

  • UAT (User Acceptance Testing, Пользовательское приемочное тестирование) - проводится пользователями конечного продукта.

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

  • Тестирование на соответствие контракту - проводится проверка на соответствие спецификации либо же другому документу нормативного акта (например ГОСТу).

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

  • Бета - проводится на внешней стороне без участия разработчиков

По позитивности:

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

• Негативное - тестирование, в рамках которого применяются сценарии, которые соответствуют внештатному поведению системы.

Всегда нужно сначала проводить позитивные тесты, а затем уже негативные.

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

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

• CLI (интерфейс командной строки)

• GUI

По степени важности:

• Smoke - направлено на проверку готовности разработанного продукта на проведение расширенного тестирования и определения общего состояния продукта. В данном виде тестирования проверяется работоспособность основного функционала системы.

• Тест критического пути (Critical Path Testing) - направлено на проверку значимых элементов и функций приложения на предмет правильности работы при их стандартном использовании.

• Расширенный тест (Extended Testing) - проверка нестандартного использования программного продукта (например, вводить специальные символы в поле логина, нелогично кликать по кнопкам и т.п.).

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

• Тестирование новой функциональности (New Feature Test) - проверка качества новой функциональности, поставленной на тестирование. Проходит полный этап тестирования (smoke, тест критического пути и расширенный тест).

• Регрессионное тестирование (Regression Testing) - раннее тестирование проверенной функциональности с целью удостовериться что изменения в коде не повлияло на работу старой функциональности. Проводится в каждом новом билде.
  Может включать в себя проверку исправления багов, проверку связанных функциональностей.
  Обычно проводится несколько раз и часто автоматизируется.
  Выбор тестов для регрессии:
  Безопасность и критичные функции
  Часто меняющиеся области
  Тесты функций с высокой вероятностью ошибки

• Re-test - проверка результата работы над дефектом.

  
  Классификация тестирования:

• По степени автоматизации - ручное и автоматизированное. Основными объектами для автоматизации являются регрессионное тестирование, а также smoke.

• По доступу к коду:

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

  • Тестирование серого ящика - частичный доступ к коду (например, к бд).

  • Тестирование белого ящика - с полным доступом к коду.

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

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

  • Тестирование на отказ - исследование программной системы на предмет восстановления после ошибок и сбоев.

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

    • Нагрузочное - проверяется работоспособность при нормальных нагрузках (ожидаемых).

    • Стресс - проверяется работоспособность при экстремальных нагрузках.

    • Тестирование стабильности - проверяется работоспособность при длительной работе с ожидаемой нагрузкой.

    • Объемное - проверяется работоспособность  при увеличенных объемах обрабатываемых данных.

  • Тестирование удобства использования

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

  • Тестирование установки - проверяется успешность установки приложения, его настройки, обновления и удаления.

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

    • Кроссплатформенное

    • Кроссбраузерное

  • Тестирование локализации (l10n) - тестирование адаптации системы к языку клиента. (язык, единицы измерения, формат даты и времени и т.п.)

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

  • Тестирование GUI - проверка соответствие UI требованиям, макету, проверка профессионализма исполнения.

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

• Тестирование по исполнению сценария

  • Ad-hoc тестирование - тестирование без использования спецификаций, планов и заготовленных тест-кейсов.

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

  • Сценарное тестирование - тестирование по тестовым сценариям.

• По запуску кода

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

  • Динамическое тестирование - предполагает запуск программного кода. Таким образом анализируется поведение программы во время ее работы.

Модели разработки ПО

Водопадная (waterfall)

Плюсы:

• Полное документирование

• Четкое планирование

• Прозрачность

Минусы:

• Утверждение полного объема работ на первом этапе

• В случае изменения требования - начало работы заново

• Увеличение затрат при изменении требований

  V-модель

Плюсы:

• Строгие этапы

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

• Промежуточное тестирование

Минусы:

• Нет гибкости

• Написание кода только в середине процесса

• Нет динамического внесения изменений

  Итерационная модель (PDCA (PLAN DO CHECK ACT))

Плюсы:

• Раннее создание работающего ПО

• Гибкость

• Процесс тестирования и анализ рисков

Минусы:

• Каждая фаза самостоятельна

• Не все требования известны к проектированию

Тестовая документация:

• Чек-лист - список проверок (высокоуровневые проверки), в котором показано, что мы будем тестировать и, как следствие, результат и статус данных проверок.

• Тест-кейс - пошаговый сценарий (низкоуровневые проверки), в котором расписано как будет проходить тестирование, результат проверок

• Тест набор (test suite) - набор тест-кейсов, в котором результат выполнения каждого тест-кейса является некоторым предусловием для выполнения следующего.

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

Тест дизайн - этап процесса тестирования, на котором проектируются и создаются тестовые случаи (тест-кейсы) в соответствии с определенными ранее критериями качества и целями тестирования.

Более простыми словами - это придумывание тестов, т.е. их разработка.

Цели тест-дизайна:

• Помочь обнаружить наиболее серьезные ошибки

• Минимизация количества тестов

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

• Эквивалентное разбиение

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

• Правила:

  • Определение классов эквивалентности

  • Проведение хотя бы одного теста для одного класса

• Анализ граничных значений

  • Правила:

    • Определение классов эквивалентности

    • Определение границ этих диапазонов

    • Проведение двух (или трех) тестов для границ (на самой границе, на значение выше границы и на значение ниже границы (для двух тестов - на самой границе и на значение выше/ниже границы)

Баг-репорт:

Баг (дефект) - несоответствие фактического результата выполнения программы ожидаемому результату

Атрибуты баг-репорта:

• Название бага

• Описание

  • Шаги воспроизведения (STR)

  • Фактический результат (Actual result)

  • Ожидаемый результат (Expected result) - желательно указывать откуда информацию о том, что данный результат является ожидаемым.

• Проект

• Компонент

• Версия билда

• Серьезность (severity)

  • Blocker

  • Critical

  • Major

  • Minor

  • Trivial

• Приоритет (priority)

  • High

  • Medium

  • Low

• Статус

• Автор

• Назначение (assign to)

• Окружение (environment) (Test, Dev, Stage, Pre-prod, Prod и т.п.)

• Прикрепленные файлы

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