Виды тестов

Виды тестов

Вместо того чтобы разделять тестирование на модульное, интеграционное и системное, мы делим все тесты на малые, средние и большие. Пожалуйста, не путайте с методом оценки из гибких методологий. Мы ориентируемся на охват, а не на размер теста. Малые тесты покрывают малые объемы кода, средние — объемы побольше и т.д. Любой инженер, независимо от своей роли, может заниматься любыми типами тестов. Их можно проводить в ручном или запускать в автоматическом режиме. Реальный опыт говорит, что чем меньше тест, тем скорее он будет автоматизирован.

На заметку

Вместо того чтобы разделять тестирование на модульное, интеграционное и системное, мы делим все тесты на малые, средние и большие, исходя из их охвата, а не размера.

Малые тесты чаще всего (хотя и не всегда) автоматизируются. Они исполняют код одной функции или модуля. Обычно они проверяют типичные функциональные проблемы, повреждение данных, неверные условия и ошибки, связанные со сдвигом значений на единицу. Малые тесты выполняются быстро, за несколько секунд и меньше. Как правило, их пишут разработчики, реже — разработчики в тестировании и почти никогда — инженеры по тестированию. Для выполнения малых тестов обычно нужна среда с подставными объектами и имитациями. Подставные объекты и имитации относятся к заглушкам (то есть заменителям реальных функций), они работают как заменители объектов в зависимостях — несуществующих, слишком ненадежных или затрудняющих эмуляцию ошибочных ситуаций. Мы расскажем об этом подробнее в следующих главах. Инженеры по тестированию редко пишут малые тесты, но могут выполнять их, диагностируя конкретные сбои. Малые тесты отвечают на вопрос «Делает ли этот код то, что он должен делать?»

Средние тесты обычно автоматизируются. Они покрывают две или больше функции. Тесты фокусируются на том, чтобы проверить взаимодействие между функциями, которые вызывают друг друга или контактируют напрямую. Такие функции мы называем ближайшими соседями. Разработчик в тестировании управляет разработкой средних тестов на ранней стадии цикла продукта. Их пишут, исправляют и сопровождают разработчики. Если тест не проходит, разработчик чинит его сам. На более поздней стадии разработки инженеры по тестированию могут выполнять средние тесты вручную (если его трудно или дорого автоматизировать) или автоматически. Средние тесты отвечают на вопрос «Взаимодействуют ли соседние функции друг с другом так, как должны?»

Большие тесты покрывают не меньше трех (а обычно больше) функций. Это реальные пользовательские сценарии, которые используют реальные источники данных, а их выполнение может занять несколько часов и даже больше. Они затрагивают и интеграцию в целом, но чаще всего большие тесты проверяют, насколько приложение соответствует потребностям пользователей. Все три роли вовлечены в создание больших тестов. Их можно проводить разными способами, от автоматизированного до исследовательского ручного тестирования. Большие тесты отвечают на вопрос «Работает ли продукт так, как нужно пользователю, и дает ли желаемый результат?» Сквозные сценарии, которые выполняются на завершенном продукте, относятся к большим тестам.

На заметку

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

Не так критично, как именно вы называете тесты, главное, чтобы все понимали эти термины одинаково.[10] Здесь важно то, что тестировщики Google говорят на одном языке, описывая, что именно тестируется и в каком объеме. Когда кто-то особо изобретательный говорит о четвертой разновидности тестов, которую они прозвали громадными тестами, любой инженер в компании сразу представит себе общесистемный тест, который выполняется очень долго и проверяет все функцио­нальные аспекты. Ничего больше пояснять не требуется.[11]

Мы определяем, в каком объеме проводить тестирование и что именно тестировать, по-разному для каждого конкретного продукта. Google предпочитает выпускать часто и стремится как можно раньше передать продукт пользователям, чтобы быстрее получить обратную связь и внести необходимые изменения. Google тратит много сил на то, чтобы создавать продукты, которыми люди действительно пользуются. Мы выкатываем новые фичи как можно раньше, чтобы они начали приносить пользу. Плюс мы избегаем лишних затрат на фичи, которые не нужны пользователям, потому что вовремя об этом узнаем. Для этого мы подключаем пользователи и внешних разработчиков в процесс как можно раньше. Так мы понимаем, соответствует ли наш продукт их ожиданиям.

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

На заметку

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

Замечу, что в Google выполняется очень много ручного тестирования, как сценарного, так и исследовательского, но даже оно проходит под зорким присмотром автоматизации. Технологии записи преобразуют ручные тесты в автоматизированные, которые снова прогоняются на последующих сборках, чтобы отловить регрессионные баги и дать тестировщикам возможность переключиться на новые проблемы. Мы автоматизируем отправку баг-репортов и распределение задач ручного тестирования.[12] Например, если автоматизированный тест не проходит, система определяет последнее изменение кода, которое считает наиболее вероятной причиной, отправляет сообщение его авторам и автоматически заводит баг. Максимально приблизить автоматизацию к человеческим возможностям — это техническое задание для следующего поколения инструментов тестирования, создаваемых в Google.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

Набор тестов

Из книги Разгони свой сайт автора Мациевский Николай

Набор тестов Итак, для проверки гипотезы и установления истинных коэффициентов нам потребуется 2 набора тестов:Тесты на сжатие: для набора пар значений «size — gzip»Тесты на запись: для набора пар значений «size — FS»Почему именно 2 — а как же издержки на инициализацию


Выполнение тестов

Из книги Системное программирование в среде Windows автора Харт Джонсон М

Выполнение тестов На Web-сайте книги в каталоге TimeTest находятся пакетные файлы, с помощью которых вы сможете запускать тесты как под управлением Windows 2000/NT, так и под управлением Windows 9x:• cpTIME.bat• cpTIME.bat• atouTIME.bat• grepTIME.bat• sortTIME.bat• threeST.batДля всех тестов, кроме тестов


11.4. ПОДХОДЫ К ПРОЕКТИРОВАНИЮ ТЕСТОВ

Из книги Технологии программирования автора Камаев В А

11.4. ПОДХОДЫ К ПРОЕКТИРОВАНИЮ ТЕСТОВ Рассмотрим два самых противоположных подхода к проектированию тестов.Сторонник первого подхода ориентируется только на стратегию тестирования, называемую стратегией "черного ящика", тестированием с управлением по данным или


11.5. ПРОЕКТИРОВАНИЕ ТЕСТОВ БОЛЬШИХ ПРОГРАММ

Из книги Удвоение продаж в интернет-магазине автора Парабеллум Андрей Алексеевич

11.5. ПРОЕКТИРОВАНИЕ ТЕСТОВ БОЛЬШИХ ПРОГРАММ Проектирование тестов больших программ пока в большей мере остается искусством и в меньшей мере является наукой. Чтобы построить разумную стратегию тестирования, надо разумно сочетать оба этих два крайних подхода и


11.7. СПОСОБЫ И ВИДЫ ТЕСТИРОВАНИЯ ПОДПРОГРАММ. ПРОЕКТИРОВАНИЕ ТЕСТОВ

Из книги Фундаментальные алгоритмы и структуры данных в Delphi автора Бакнелл Джулиан М.

11.7. СПОСОБЫ И ВИДЫ ТЕСТИРОВАНИЯ ПОДПРОГРАММ. ПРОЕКТИРОВАНИЕ ТЕСТОВ Существуют два способа тестирования: публичный и приватный.Публичное тестирование означает, что любой желающий может получить данный продукт (либо бесплатно, либо по цене дисков и доставки).Приватный


Товары для тестов

Из книги Как тестируют в Google автора Уиттакер Джеймс

Товары для тестов Можно сделать тестовую категорию товаров «Специальные предложения» и на них тестировать


Результаты выполнения тестов

Из книги Идеальный программист. Как стать профессионалом разработки ПО автора Мартин Роберт С.

Результаты выполнения тестов В разделе сопровождающих эту книгу материалов, который расположен на Web-сайте издательства, можно найти тестовую программу, которая применяет все рассмотренные нами тесты к стандартному генератору случайных чисел Delphi и минимальному


Выполнение тестов

Из книги автора

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


Определения размеров тестов

Из книги автора

Определения размеров тестов По мере роста Google и прихода новых сотрудников в компании началась путаница с названиями тестов: юнит-тесты, тесты на основе кода, тесты белого ящика, интеграционные тесты, системные тесты и сквозные тесты — все они выделяли разные уровни


Как мы используем размеры тестов в общей инфраструктуре

Из книги автора

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


Преимущества разных размеров тестов

Из книги автора

Преимущества разных размеров тестов Размер теста имеет значение. Он влияет на специфические преимущества теста. На рис. 2.5 показана общая сводка, а ниже мы приводим более подробный список достоинств и недостатков каждого типа тестов. Рис. 2.5. Ограничения разных размеров


Требования к выполнению тестов

Из книги автора

Требования к выполнению тестов У системы выполнения тестов в Google одинаковые требования ко всем тестам.— Каждый тест должен быть независим от других, чтобы тесты могли выполняться в любом порядке.— Тесты не должны иметь долгосрочных последствий. После их завершения


Разработка и качество тестов

Из книги автора

Разработка и качество тестов Команда разработчиков больше других групп по количеству людей и обладает гораздо большим знанием о компонентах и технических подробностях списков изменений. Мы хотим, чтобы разработчики обеспечивали полный набор модульных и


Панели мониторинга тестов

Из книги автора

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


Фреймворк выполнения тестов Autotest

Из книги автора

Фреймворк выполнения тестов Autotest Команды тестирования и разработки решили использовать Autotest как основной фреймворк для автоматизации тестов. Autotest удачно прошел проверку в сообществе Linux, использовался в нескольких внутренних проектах, и, кроме того, он


Обсуждение тестов и пассивно-агрессивная позиция

Из книги автора

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