Общие сведения

ВступлениеПодготовка к запускуАрхитектура платформы TestoПорядок запускаПолитика запуска тестов

Обучающие материалы по Testo для Hyper-V

Часть 1. Самый первый тестЧасть 2. Устанавливаем Ubuntu ServerЧасть 3. Доступ в Интернет из виртуальной машиныЧасть 4. Гостевые дополненияЧасть 5. ПараметрыЧасть 6. КешированиеЧасть 7. Связываем две машины по сетиЧасть 8. ФлешкиЧасть 9. МакросыЧасть 10. Конструкция ifЧасть 11. No snapshotsЧасть 12. Управление мышкойЧасть 13. Импортирование жёстких дисковЧасть 14. JS-селекторыЧасть 15. Циклы

Обучающие материалы по Testo для QEMU

Часть 1. Самый первый тестЧасть 2. Устанавливаем Ubuntu ServerЧасть 3. Гостевые дополненияЧасть 4. ПараметрыЧасть 5. КешированиеЧасть 6. Доступ в Интернет из виртуальной машиныЧасть 7. Связываем две машины по сетиЧасть 8. ФлешкиЧасть 9. МакросыЧасть 10. Конструкция ifЧасть 11. No snapshotsЧасть 12. Управление мышкойЧасть 13. Импортирование жёстких дисковЧасть 14. JS-селекторыЧасть 15. ЦиклыЧасть 16. Макросы с объявлениями

Спецификация языка

Общая структура скриптовых файловБазовые конструкции языкаOбъявление виртуальной машиныОбъявление виртуального флеш-накопителяОбъявление виртуальной сетиПараметрыОбъявление тестовМакросыДействия с виртуальными машинамиДействия с мышкойПоиск изображений на экранеДействия с виртуальными флеш-накопителямиУсловияЦиклыСписок идентификаторов клавиш

Запросы на языке Javascript

Общая концепция построения JS-селекторовВстроенные глобальные функции JavascriptИсключенияКласс TextTensorКласс ImgTensorКласс Point

Политика запуска тестов

Организация тестов

Тесты в платформе Testo имеют иерархическую структуру и представляют собой тестирование "от простого к сложному". Более сложный тест полагается на результат выполнения простого теста и запускается только в том случае, если простой тест прошел успешно.

В приведенном примере тесты T1, T2 и T3 являются самыми простыми и будут запущены в любом случае. Тест T4 запустится только если успешно отработает тест T1 (тесты T5, T6, T7 и Т10 обладают схожей логикой). Тест T8 требует успешного выполнения тестов T5 и T6, а тест T9 - успешного выполнения всех остальных тестов.

С помощью аргумента командной строки test_spec <wildcard match> можно ограничить множество тестов для запуска. В случае указания этого аргумента будут запущены все тесты, подходящие под шаблон поиска, указанный в <wildcard match>. Если же требуется исключить определенные тесты из плана запуска, то их можно указать с помощью аргумента exclude <wildcard match>.

Ограничения в организации тестов

Ограничения в обращении к виртуальным машинам

В каждом тесте (если только он не пустой) фигурирует одна или несколько виртуальных машин (ВМ). Тест-потомок по отношению к родителю может использовать либо те же виртуальные машины, которые фигурировали в предках (пример в приведенной схеме - тесты T1, T4, T7), либо новые виртуальные машины, не использованные ранее (пример - тесты T2, T5).

Как только к виртуальной машине в тесте было сделано хотя бы одно обращение, она начинает принадлежать тому тесту, где было выполнено обращение. После этого виртуальная машина будет принадлежать и всем потомкам этого теста, даже если к ней больше не будет происходить никаких обращений. Например, в тесте T5 появляется обращение к виртуальной машине ВМ3, и с этого момента она принадлежит тесту T5. При этом у T5 есть потомки T8 и T9, и они унаследуют принадлежность ВМ3, даже если в них реально не будет ни одного обращения к этой виртуальной машине.

На сегодняшний момент не допускается ситуация, когда у теста одна ВМ принадлежит более чем одному предку.

В приведенном примере в тесте T6 было выполнено обращение к ВМ1 и это является ошибочной ситуацией: для теста T9 два предка будут обладать одной виртуальной машиной ВМ1.

Ограничения в обращении к виртуальным флеш-накопителям

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

Снепшоты и кеширование тестов

Выполнение тестов может занимать значительное время, и поэтому в платформе Testo существует механизм кеширования тестов, что позволяет запускать только те тесты, которые требуют перезапуска по определенным причинам. Более подробное описание тех факторов, которые принимаются во внимание при кешировании тестов, смотри здесь

В целом, для простоты восприятия, можно рассматривать процесс запуска тестов как процесс инкрементальной компиляции: заново будут скомпилированы или ещё не скомпилированные файлы, или файлы, в которых произошли какие-то изменения.

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

Алгоритм работы проще всего рассмотреть на примере. Рассмотрим схему, представленную на рис.1. Допустим, что нам необходимо запустить все тесты, и при этом эти тесты запускаются в первый раз. В этом случае будет выполнен "полный прогон" всех тестов, от начала и до конца, согласно иерархии. Если не возникает никаких ошибок, то в конце всех тестов с помощью гипервизора для всех виртуальных машин и флешек создаются снепшоты, и все тесты помечаются как "кешированные". Если запустить все тесты еще раз, то программа отработает моментально, т.к. все тесты являются закешированными (с момента последнего запуска ничего значимого не произошло).

Например, если по какой-то из причин тест T4 становится незакешированным, то кеш сбрасывается и для всех его потомков: T7 и T9. При повторном запуске в этом случае Testo восстановит снепшоты виртуальных машин ВМ1, ВМ2, ВМ3 и ВМ4 и вернет их в то состояние, в котором они были на момент окончания тестов T1 и T8, и будут заново проведены все незакешированные тесты: T4, T7, T8 и T9.

Помимо встроенных в Testo механизмов определения закешированности тестов, пользователь может вручную сбросить кеш у определенных тестов, используя аргумент командной строки invalidate <wildcard match>. При этом, сбрасывая кеш теста, пользователь автоматически сбрасывает кеш всех его потомков.

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

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

Тесты без снепшотов гипервизора

При большом количестве тестов количество снешпотов может стать очень значительным, что ведет к интенсивному использованию дискового пространства. Поэтому для экономии места на диске в Testo предусмотрена возможность создавать тесты, которые не требуют создания снепшотов гипервизора. Для этого перед тестом необходимо указать аругмент [no_snapshots: true]. В этом случае по окончанию теста для участвующих в нём виртуальных машин не будут созданы снепшоты гипервизора, что приводит к экономии места на диске.

Отсутствие снепшотов не означает отсутствие кеширования - в Testo это различные механизмы, которые могут работать независимо. Поэтому тест с атрибутом no_snapshots: true всё равно закешируется при успешном прогоне и при повторном запуске реального выполнения не произойдет, а тест будет помечен как закешированный (конечно, только в том случае, если кеш действительно не изменился с момента последнего запуска)

Тесты без снепшотов позволяют экономить место на диске, но при этом они не могут быть использованы как "точка отсчета" при инкрементальном прогоне тестов. Например, если в схеме на рис. 1. тест T4 помечен как тест без снепшотов, и при этом тест T7 становится незакешированным, то вместо того, чтобы восстановить состояние виртуальной машины ВМ1 из теста T4, Testo будет вынуждена откатить ВМ1 к состоянию из теста T1 (если он в свою очередь не помечен как no_snapshots: true),а затем заново прогнать тест T4, даже несмотря на то, что он был закеширован. Это нужно для того, чтобы привести все виртуальные машины в нужное состояние перед запуском потерявшего кеш теста.

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

Пример работы с атрибутом no_snapshots вы можете посмотреть здесь