[Из песочницы] Чистое и грязное тестовые окружения
Доброе время суток, хабр! В этом посте я бы хотел рассказать о тестовых окружениях, что такое чистое и грязное окружение, какие тесты в них выполняются и какие задачи достигаются. Если вы не равнодушны к этим вопросам, добро пожаловать под кат.Каждый разработчик ПО, когда-нибудь тестировал свое детище, иногда даже не подозревая об этом. Будь то приложение для windows, а может мобильное приложение для Android или iOS… Как правило, начинающие разработчики ограничиваются тестовыми запусками в том окружении, в котором происходит разработка. С профессиональным ростом разработчика растет и сложность его творений. Простыми тестовыми запусками уже не обойтись. Тогда в ход идет ручное тестирование функционала. С дальнейшим увеличением сложности и возраста продукта увеличивается и количество функций, которые нужно покрыть тестированием, в то же время необходимо помнить о старых функциях, работоспособность которых следует проверять. Последние обрабатывать в ручную становиться не эффективно и на сцену выходит автоматическое тестирование.Конечно, выполнять автоматическое тестирование только в среде разработки не эффективно, так как она ограничивается, одной платформой, одной операционной системой, одним набором установленного ПО и следами присутствия продукта оставшихся от прошлых тестовых запусков. Проблема проверки работоспособности функционала от платформы, операционной системы решается увеличением количества тестового окружения: например, увеличением виртуальных или физических машин с разными операционными системами, на которых будут запущены автоматические тесты. Чем больше операционных систем будет охвачено, тем качественней выйдет продукт. Все операционные системы должны быть в актуальном состоянии.
С физическими машинами все просто: достаточно включить автообновление. С виртуальными машинами, разворачиваемыми из образов, дело обстоит сложней. Для поддержания их в актуальном состоянии, требуется обновлять образ. Периодичность зависит от момента выхода сервис паков или критичных для продукта обновлений операционной системы. Кроме того, само по себе полезно обновлять образ. Наша небольшая группа автоматизации тестирования Acronis TrueImage приняла волевое решение: этот период приравнять к трем месяцам.
Как и в любом деле, не стоит впадать в крайности, все вариации версионности операционных систем учесть очень сложно и не эффективно. С большой вероятностью, у пользователя будет актуальная версия Операционной системы (ОС). На это и стоит ориентироваться.
Что такое чистое тестовое окружение
Проблемы следов присутствия прошлых версий продукта и взаимодействия со сторонними программами, решается добавлением в тестовый план окружений, максимально приближенных к реальному окружению пользователя (так называемое грязное окружение) и минималистичное окружение (так называемое чистое окружение). Оба вида имеют право на жизнь и свое назначение в процессе тестирования.
Чистое окружение — в идеале, это только что установленная операционная система с последующей установкой на ней продукта. Количество внешних факторов, влияющих на работоспособность продукта, минимально. Тестируемый «варится в собственном соку». Тут нет следов от прошлых запусков продукта, исключается какое-либо взаимодействие со сторонними программами, например, антивирусами или фаерволами. Таким образом, в случае нарушений в функционале, мы с уверенностью можем сказать, что проблема в продукте. Даже если проблема в ОС, разработчик должен обеспечить работоспособность в ней, так как ОС — это более низкий уровень. К огрехами ОС надо приспосабливаться или смирится. ОС правит балом. В итоге, чистое окружение облегчает локализацию багов, уменьшает время на настройку и разворачивание тестового окружения.
В качестве чистых тестовых окружений, в которых приходится варится TrueImage, выступает небольшая стайка физических машин с поголовьем в 5–10 особей. Они, как правило, в распоряжении инженеров ручного тестирования.
Кадр из фильма, где доблестные инженеры-тестировщики локализуют баги
В нашем арсенале еще присутствует орда из виртуальных машин, большинство из которых живут на blade-серверах. Виртуальные машины считаются условно чистым окружением, так как они опорочены нашими python-скриптами, которые копируются на подопытную виртуалку с целью проверки функционала продукта. Срок жизни виртуальных машин короток и равняется сроку жизни выполнения тестового сценария. После выполнения виртуалка, в случае отсутствия багов с почестями в виде «зеленого» лога, удаляется с сервера. Но если есть намек на дефект тестируемого приложения, виртуальная машина, предварительно сложив логи в укромное хранилище, замораживается для дальнейших выяснений обстоятельств.
И тут в дело вступает наша палочка-выручалочка, которая экономит кучу времени — программа анализа логов на предмет известных багов. Принцип её действия не сложен, так как логии пишутся компьютером, а не непредсказуемым человеком, то достаточно найти соответствующие фразы или совокупности фраз, характерные для бага. По аналогии с антивирусом ведется база характерных фраз и проявлений дефектов. К сожалению, свой антибагус с блекджеком и эвристическим анализом мы еще не написали, так, что при встрече неизвестного дефекта приходится собственноручно лезть в логи.
…и с чем это чистое окружение едят
У нас принято разделять тесты на несколько уровней в зависимости от покрытия функционала и времени выполнения. Первый уровень — это уровень BVT (P1) — тесты, покрывающие основной критичный функционал, без которого запускать продукт даже и не стоит: системный бекап, последующий рестор и т.п. Следующий уровень называется Common (P2-P3). Он включает проверки функционала, без которого пользоваться продуктом хоть как-то можно: бекап дисков разных файловых систем, рестор на диски, с размером отличным от забекапленого, планировщик. BVT и Common целесообразно выполнять, прежде всего, в чистых окружениях. Так как эти наборы тестов выполняются на этапе активной разработки продукта, важно их запускать регулярно и, в случае нахождения багов, можно будет легко их локализовать.А что такое грязное тестовое окружение…
С чистыми окружениями, где присутствует только ОС и продукт разобрались. Но мир ПО это не только чистая операционная система. И на свете, помимо тестируемого продукта, есть и другие программы, даже другие версии самого продукта. И как они влияют на функционал подопытного тоже хорошо бы проверить. Тут на сцену выходит так называемое грязное окружение.
Грязное не всегда плохо…
Грязное окружение — окружение, в разной степени приближенное к реальному окружению, в котором будет использоваться продукт: состав установленных драйверов дополнительное ПО, аппаратные компоненты. Также может оказывать влияние наличие следов от прошлых запусков предыдущих версий продукта, использование аккаунтов (например, в облачных сервисах) содержащих вторичные данные (бекапы в облаке).
Так как у разных окружений разная роль, соответственно и наборы тестов для них тоже разные.
А зачем нам грязнули? Теперь настало очередь рассказать, какие проверки выполняются в грязном окружении.Какую функцию продукта обязательно следует проверить? Операция рестора? Разве не ради неё все затевалось? Разве не после этой операции падает камень с плеч? Нет. Пользователь может в спокойствии жить-поживать, зная, что у него есть бекап под подушкой. Так что, бекапу обязательно надо уделить внимание. Но есть еще одна операция, без которой не будет ни бекапа, ни рестора. Это операция установки продукта.
В компании Acronis этой операции уделено большое внимание. Существует вид тестов, охватывающих весь цикл жизни продукта — LifeCycle. Эти тесты состоят из таких шагов, как: установка, удаление, переустановка, апдейт, апгрейд и т.п. Плюс к этому, в цепочках учитывается богатая история наших продуктов: 10 мажорных версий — апгрейдов (но в тестировании участвуют только последние 5 версий, в том числе новые версии продукта: TrueImage 2013, TrueImage 2014) каждая из которых имеет от 2 до 5 минорных версий — продуктовых апдейтов. И весь этот зоопарк требуется проверить. А установиться ли TrueImage 2014 update2, если на компьютере уже была установлена TrueImage 2013 update1 версия? А проапгрейдиться TrueImage 2013 RTM до TrueImage 2014 update1? На эти вопросы ответят вышеупомянутые тесты LifeCycle. Но и этого оказалось мало. Не достаточно просто поставить продукт. Хорошо бы убедиться, что он работает. Поэтому, между установками, апгрейдами, апдейтами и переустановками выполняется проверка базового функционала BVT.
Талисман TrueImage. Величать хомкой. В честь бывшего названия TrueImage Home
Другой тип тестов, выполняемых в грязном окружении, так называемые Longhaul или Stability тесты. Они выполняются для оценки стабильности продукта с течением времени. Суть их в выполнении базовых операций BVT, заключенных в автоматический цикл на продолжительный отрезок времени. У нас этот отрезок равен 7–14 дней, затем билд обновляется и цикл тестов повторяется. Таким образом, предыдущий цикл тестов влияет на последующий. Бекап и рестор большого количества информации порой занимают ни один день, особенно из облака, и особенно при медленном канале. Так же на такие тесты выявляют баги, связанные с долгой работой, например, утечка памяти, заполнение жесткого диска и др.
Мир, дружба, жвачка
Но и это еще не все. А как же влияние сторонних программ на продукт? Тут к сожалению, автоматическое тестирование не эффективно. Компьютер не может в полной мере оценить корректность взаимодействий продукта и сторонних программ.
Самые серьёзные проблемы возникают с программами, контролирующими доступ: антивирусами и фаерволами. Тут на помощь приходить ручное тестирование. Например, позволит ли стандартный фаерволл Windows отрестроить ранее подготовленный бекап, который находиться в облаке?
Тесты разные нужны, тесты разные важны Разделение тестов на разные уровни дает возможность выбирать компромиссные решения: время выполнения тестов обратно зависимо от покрытия. Например, BVT тесты выполняются за самый короткий отрезок времени и позволяют оперативно выявлять критические и блокирующие баги. Common уже в разы больше времени занимает, но и покрывает больший функционал. Подобные тесты, запускаемые регулярно и часто, позволяющие «держать руку на пульсе», как правило, запускаются в чистых окружениях.LifeCycle и тесты на влияние стороннего ПО имеет смысл запускать как минимум не раньше этапа бета-тестирования, когда продукт стабилен. Особое значение занимают stability тесты. Они выполняются на отдельных машинах 24 часа в сутки. В этом случае нам уже пригодиться грязное окружение.Наличие разных уровней тестов и разных тестовых окружений обеспечивает более широкие возможности по локализации багов. Чем ниже уровень теста, тем меньше времени он требует и тем чаще выполняется. Допустим баг был обнаружен при выполнении теста на взаимодействие со сторонним ПО (высокий уровень). Так же этот баг проявился при выполнении Common тестов, но в то же время не был замечен на самом низком уровне BVT, можно сделать вывод, что стороннее ПО не причем, так как баг обнаружился в чистом окружении Common тестов, но не в BVT тестах. Значит он в функционале, покрываемом Common тестах.
Чистое окружение помогает оперативно выявлять и локализовать баги с малыми затратами. Грязное окружение напротив, помогает найти самые изощренные дефекты продукта. Автоматизация оправдывает средства, затраченные на её внедрение, но полностью вас не избавит от ручного тестирования, в то же время некоторые вещи, такие как жизненный цикл продукта, невозможно протестировать без автоматизации.
