Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 Переходим к пирамиде тестирования - частному случаю системы тестировния. Почему мы про нее говорим я скажу чуть позже.

2 <h2>Что такое пирамида тестирования</h2>

3 Пирамида тестирования выглядит следующим образом:

4 Как видите, пирамида состоит из трех уровней:

5 <ul><li>Юнит-тесты - нижний и самый широкий уровень пирамиды</li>

6 <li>Интеграционные тесты - средний уровень</li>

7 <li>Системные тесты - самый высокий и узкий уровень пирамиды</li>

8 </ul>Пирамида тестирования диктует, как выстраивать тесты на проекте. В большинстве случаев должно быть много юнит-тестов, меньше интеграционных тестов и еще меньше системных тестов.

9 Такая структура помогает эффективно организовать тестирование и обнаруживать дефекты на ранних этапах разработки.

10 Обсудим, почему пирамида тестирования устроена именно так. Дело в том, что тесты занимают много ресурсов. Чем выше уровень тестирования, тем дороже его реализация и поддержка, тем медленнее обратная связь.

11 Под поддержкой тестов мы понимаем изменение тестов при изменении требований. Любые тесты нуждаются в поддержке, но у каждого уровня есть свои особенности.

12 Юнит-тесты самые простые в поддержке:

13 <ul><li>Они быстрые. Чтобы выполнить юнит-тесты, программист просто запускает их на своем компьютере. Ему не нужно тратить время на сборку дистрибутива и развертывание на тестовом стенде</li>

14 <li>Их редко нужно переписывать. Они проверяют короткие фрагменты кода, которые редко меняются от изменений в других частях системы</li>

15 </ul>В этом-то и состоит одно из главных преимуществ пирамиды тестирования - она подталкивает к более активному использованию юнит-тестов, которые удобны в поддержке.

16 Намного сложнее поддержка системных тестов:

17 <ul><li>Они изменяются вместе с функциональностью. Часто они завязаны на конкретные элементы страницы, поэтому изменение требований может вести к полной переработке тестов</li>

18 <li>Они медленные. Системные тесты часто требуют больше времени на подготовку и выполнение</li>

19 <li>В них сложнее разобраться. Представим такую ситуацию - утром программист вносит изменения и отправляет код. На следующий день тестировщик берет код и проверяет его до вечера. В итоге программист получит обратную связь только через два дня. Это растягивает рабочий процесс, потому что за время ожидания программист уже забыл контекст задачи</li>

20 </ul>Из-за всех причин выше, важно, чтобы команда придерживалась принципов пирамиды тестирования. Другими словами, тесты более высокого уровня должны проверять только то, что невозможно проверить на предыдущих уровнях. С таким подходом пирамида будет устроена правильно: на вершине - системные тесты, затем интеграционные, а на нижнем уровне - множество юнит-тестов.

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

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

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

24 <ul><li>Перевернутая пирамида - мало юнит-тестов, среднее количество интеграционных тестов, много системных тестов</li>

25 <li>Песочные часы - много юнит-тестов, мало интеграционных тестов, много системных тестов</li>

26 <li>Стек - равное количество тестов всех трех уровней</li>

27 </ul>Эти схемы могут подходить для каких-то специфичных проектов, но чаще они указывают на неэффективный подход к тестированию.