Я никогда не пользовался Dr. Web. Я понятия не имею, как он устроен. Но это не помешало мне написать для него ряд автотестов (и лишь лень не позволила мне написать ещё сотню других):
- Тест на установку Dr. Web;
- Тест на ограничение доступа к съемным устройствам (флешкам);
- Тест на разграничение доступа к каталогу между программами;
- Тест на разграничение доступа к каталогу между пользователями системы (родительский контроль).
Такие и многие другие тесты можно клепать как горячие пирожки, и не только применительно к Dr. Web, и не только применительно к антивирусам. В этой статье я расскажу, как это сделать.
Подготовка
Для тестов нам понадобится виртуалка с Windows на борту. Я подготовил её вручную, выполнив на ней следующие манипуляции:
- Собственно, установил Windows 10 Pro x64;
- Во время установки создал основного пользователя "testo" в паролем "1111";
- Включил автологин для этого пользователя;
Для автоматизации тестов я буду использовать платформу Testo. Что это такое и как этим пользоваться можно почитать здесь. Нам же сейчас требуется импортировать готовую виртуалку в автотесты. Сделать это очень просто:
Здесь предполагается, что /path/to/win10.qcow2
— это путь к диску той виртуалки, которую я подготовил вручную. На этом подготовка заканчивается, и начинается экшен.
Тест №1 — Устанавливаем Dr. Web!
Для начала надо решить вопрос с переносом дистрибутива Dr. Web на виртуальную машину. Сделать это можно (например) с помощью флешки:
Всё, что нам надо сделать — это положить установщик Dr. Web в папочку ${DR_WEB_DIR}
(точное значение этого параметра мы будем задавать при запуске testo
). А Testo само позаботится о том, чтобы этот инсталлятор оказался на флешке.
Теперь можем приступить, собственно, к написанию теста. Пока что начнём тест с простых вещей: включим виртуалку (после создания она будет выключена), дождёмся появления рабочего стола, включим флешку и откроем её содержимое через проводник:
Можно, конечно, запустить инсталлятор прямо отсюда, из самой флешки. Но мы лучше сделаем всё по-честному — мы скопируем инсталлятор на рабочий стол и запустим инсталлятор оттуда. Как же нам скопировать файл? А как бы это сделал человек?
Всё, копирование успешно завершено! Теперь можно закрыть окно с флешкой и вытащить её:
Теперь, когда инсталлятор оказался на рабочем столе, нам нужно дважды кликнуть на него чтобы запустить процесс установки. А сама установка сводится к простому прокликиванию кнопок и галочек и не представляет большого интереса:
Завершаем наш тест перезагрузкой. И в конце не забудем проверить, что после перезагрузки на рабочем столе появилась иконка с Dr. Web:
Отличная работа! Мы автоматизировали установку антивируса Dr. Web! Давайте немного передохнём и посмотрим, как это выглядит в динамике:
Переходим к тестированию фич.
Тест №2 — Ограничение доступа к флешкам
Первая фича по списку — ограничение доступа к флешкам. Для этого спланируем довольно прямолинейный тест:
- Попробуем вставить флешку и создать там пустой файл — должно получиться. Вытащим флешку;
- Включим блокировку съемных устройств в Dr. Web Security Center;
- Ещё раз вставим флешку и попробуем удалить созданный файл. Действие должно быть заблокировано.
Создадим себе новую флешку, вставим её в Windows и попробуем создать папку. Что может быть проще?
Создаём новый текстовый файл через контекстное меню проводника:
Отключаем флешку, делаем это безопасно:
Теперь мы убедились, что с флешкой работать можно, а значит можно приступать к её блокировке в центре безопасности Dr. Web. Для этого сначала надо открыть центр безопасности:
Можем заметить, что для открытия любого приложения в Windows нужно выполнить фактически одинаковые действия (кликнуть на строку поиска, дождаться появления окна с популярными приложениями, вбить имя интересующего приложения, дождаться, когда оно появится в списке и, наконец, нажать Enter). Поэтому эту группу действий можно выделить в макрос open_app
, в который в качестве параметра будет передаваться имя открываемого приложения:
Этот макрос нам ещё пригодится.
Первое, что мы сделаем, открыв центр безопасности Dr. Web — включим возможность вносить изменения:
Теперь немного покликаем по менюшкам и зайдем в меню "Configure device access rules". В этом меню поставим галочку в пункте "Block removable media".
Попробуем открыть флешку теперь:
Вот так потихоньку-полегоньку мы и написали первый тест с тестированием вполне осязаемой фичи в Dr. Web. Настало время передохнуть и помедитировать, глядя на результаты наших трудов:
Тест №3 — Разграничение доступа к каталогу между программами
Основная идея этого тесткейса — проверить работу Dr. Web при ограничении доступа к определенной папке. Если конкретно, то необходимо защитить папку от каких-либо изменений, но добавить исключение для какой-нибудь сторонней программы. Собственно, сам тест выглядит следующим образом:
- Установим на ОС стороннюю программу, для которой чуть позже добавим исключение при доступе к защищаемой папке. Сегодня сторонняя программа дня — файловый менеджер FreeCommander;
- Создаем папку с файликом, которую будем защищать всеми силами;
- Откроем центр безопасности Dr. Web и включим там защиту этой папки;
- Настроим исключение для FreeCommander;
- Попробуем удалить файл из защищаемой папки обычным способом (через проводник Windows). Не должно получиться;
- Попробуем удалить файлик через FreeCommander. Должно получиться.
Ух, много работы. Быстрее начнём — быстрее закончим.
Пункт первый, установка FreeCommander не сильно отличается от установки Dr.Web. Обычная рутина: вставили флешку, запустили инсталлятор и так далее. Пропустим это и перейдём сразу к интересному.
Начнём с простого: создадим флешку, в которую поместим дистрибутив FreeCommander, а затем в тесте вставим флешку в ОС и откроем её:
Далее несколько не кликов чтобы запустить установку:
Установка не очень интересная, просто кликаем везде "Далее", а в конце не забываем отключить галочки с просмотром ReadMe и немедленным запуском FreeCommander
Заканчиваем тест, закрывая все окна и вытаскивая флешку
Готово!
Для работы с Dr. Web создадим новый тест dr_web_restrict_program
, который будет полагаться на результат работы предыдущего теста win10_install_freecommander
.
Начнём тест с создания папки Protected на рабочем столе:
Заходим в папку Protected и создаём там файл my_file.txt
, который будет играть роль защищаемого файла:
Ох, надо было бы тоже оформить это в виде макроса, ну да ладно ...
Отлично, теперь надо включить защиту папки. Идём знакомой дорожкой и открываем Dr. Web, не забываем включить режим изменений. После чего переходим в меню "Data Loss Prevention".
Немного поработаем мышкой и добавим нашу папку Protected в список защищаемых:
Ну а теперь надо настроить исключение по доступу к папке для FreeCommander. Ещё немного работы мышкой:
Теперь аккуратно закрываем все окна и пробуем удалить файл "my_file.txt" стандартным способом:
Но ничего не получилось — значит Dr. Web действительно отработал! Половина теста позади, но нам ещё надо проверить, что будет работать исключение для FreeCommander. Для этого открываем FreeCommander и переходим в папку Protected:
Ну и попробуем удалить файл my_file.txt:
Исключение для FreeCommander работает!
Отличная работа! Большой и сложный тесткейс — и всё автоматизировано. Немного расслабона:
Тест №4 — Родительский контроль
Этот последний на сегодня тесткейс мы построим следующим образом:
- Создадим нового пользователя MySuperUser;
- Залогинимся под этим пользователем;
- Создадим файл
my_file.txt
от имени нового пользователя; - Откроем центр безопасности Dr. Web и включим родительский контроль для этого файла;
- В родительском контроле ограничим права пользователя MySuperUser на им же созданный файл;
- Попробуем прочитать и удалить файл
my_file.txt
от имени MySuperUser и посмотрим на результат.
Я не буду приводить здесь сценарий теста. Он строится по тому же принципу, что и предыдущие тесты: активно работаем мышкой и клавиатурой. При этом нам не важно, что мы автоматизируем — хоть Dr.Web, хоть создание нового пользователя в Windows. Но давайте всё же посмотрим, как будем выглядеть прогон такого теста:
Заключение
> Исходники всех тестов Вы можете посмотреть здесь
Более того, все эти тесты Вы можете прогнать на своей машине. Для этого Вам потребуется интерпретатор тестовых сценариев Testo. Скачать его можно здесь.
Dr. Web оказался неплохой тренировкой, но вдохновение для дальнейших подвигов я хотел бы почерпнуть из Ваших пожеланий. Пишите в комментариях свои предложения о том, какие автотесты Вы бы хотели увидеть в будущем. В следующей статье я попробую их автоматизировать, посмотрим, что из этого получится.
shpaker
Лирическое отступление:
Конечно же да!
Ох, помнится когда-то и я это делал у того же самомого доктора. Вроде совсем недавно было, но воды утекло уже неверотяно много. Уже и винду то года три не трогал вовсе. Настольгически так вспомнил сейчас все эти муки с jsonrpc-велосипедами вокруг lua и прочее роботостроение.
А теперь по тексту. Скриншоты вроде из саблайма, а это наводит на ряд не очень хороших мыслей про разработку на этой штуке. А почему имено выбрали разработку своего DSL, а не стали писать какой-либо фреймфорк или библиотечку на нормальном языке для которого есть нормальные инструменты разработки и средства отладки? Со времен своего знакомства с робот-фреимворком крайне настороженно отношусь к таким штукам. Кажется, что тестирование десктоп приложений вообще штука не тривиальная, а необычные инструменты могут в один день усугубить поддержку автотестов поддержкой инструмента тестирования и войной
бесконечностис костылями.PS: Код скриншотами на хабре — страшный грех во времена когда хабр умеет сам светить синтаксис.
testo-lang Автор
Поделитесь опытом! Каким инструментом пользовались? С ним получись бы лучше/хуже?
Почему мы решились на создание своего языка — описано в предыдущей статье. Если кратко, то одна из причин — мы хотели получить что-то похожее на make/cmake. То есть инструмент должен сам отслеживать, какие тесты актуальны, какие надо заново прогнать, в каком порядке и так далее. Это довольно сложно оформить в виде библиотечки. Наверное, поэтому системы сборки — это обычно конфиг файлы или специализированные языки. У нас конечно не система сборки, но принцип работы примерно такой же.
Знаю, что код скриншотами — это грех, гореть мне в аду. Да только ведь хабр не знает этого языка. Вопрос знатокам — можно ли научить хабр новым фокусам? То есть добавить подсветку своего языка?
remzalp
Код в конце статьи на гитхабе искупит все Ваши грехи. Заодно при первом использовании графического кода сошлитесь в конец статьи.