Треугольник и квадранты. Тестирования. Основные понятия

Слайд 2

ТРЕУГОЛЬНИК ИЛИ ПИРАМИДА ТЕСТИРОВАНИЯ - ГРУППИРОВКА ТЕСТОВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПО РАЗНЫМ УРОВНЯМ ДЕТАЛИЗАЦИИ,

ТРЕУГОЛЬНИК ИЛИ ПИРАМИДА ТЕСТИРОВАНИЯ - ГРУППИРОВКА ТЕСТОВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПО РАЗНЫМ УРОВНЯМ
КОТОРАЯ ДАЕТ ПРЕДСТАВЛЕНИЕ СКОЛЬКО ТЕСТОВ ДОЛЖНО БЫТЬ В КАЖДОЙ ИЗ ЭТИХ ГРУПП.

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

Слайд 3

ПРИНЦИП ПИРАМИДЫ ТЕСТИРОВАНИЯ

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

ПРИНЦИП ПИРАМИДЫ ТЕСТИРОВАНИЯ Пирамида тестирования, в том числе, помогает наглядно объяснить причины,
количество Unit тестов должно быть больше чем интеграционных. Чем ниже находятся на пирамиде тесты, тем:
проще и быстрее они разрабатываются
ниже затраты на поддержку тестов
быстрее скорость запуска атомарного теста
выше уровень изоляции компонент между собой
меньше нужно денег на содержание инфраструктуры для запуска этих тестов
ниже уровень необходимой квалификации того, кто эти тесты может разрабатывать

Слайд 4

ПЕРЕВЕРНУТАЯ ПИРАМИДА ТЕСТИРОВАНИЯ ИЛИ "РОЖОК МОРОЖЕННОГО"

   Основные тезисы: 
1. Тесты пользовательского интерфейса должны

ПЕРЕВЕРНУТАЯ ПИРАМИДА ТЕСТИРОВАНИЯ ИЛИ "РОЖОК МОРОЖЕННОГО" Основные тезисы: 1. Тесты пользовательского интерфейса
автоматизироваться в большей мере. 2. Длинные тестовые прогоны, так как тестирование основано на взаимодействии с визуальными элементами пользовательского интерфейса и не обязательно имеет хуки в исходном коде. 3. Сложно поддерживать, так как тесты пользовательского интерфейса сложно писать и они очень сильно зависят даже от малейших изменений; 4. Больше подходит для сценариев позитивного пути. Тестирование отрицательных путей в сквозных тестах очень затратно и долго выполняется по сравнению с тестами более низкого уровня; 5. Ожидание написания модульных тестов до тех пор, пока функции не будут завершены, может привести к тому, что каждому придется несколько раз выполнить большую работу для решения проблемы.
 В практике такой подход встречается, но является примером "плохого поведения", того как делать не надо. 
Перевернутая пирамида считается не рекомендованной.