Я автоматизировал тестирование Dr. Web. А сможете ли вы?


    Я никогда не пользовался Dr. Web. Я понятия не имею, как он устроен. Но это не помешало мне написать для него ряд автотестов (и лишь лень не позволила мне написать ещё сотню других):


    1. Тест на установку Dr. Web;
    2. Тест на ограничение доступа к съемным устройствам (флешкам);
    3. Тест на разграничение доступа к каталогу между программами;
    4. Тест на разграничение доступа к каталогу между пользователями системы (родительский контроль).

    Такие и многие другие тесты можно клепать как горячие пирожки, и не только применительно к Dr. Web, и не только применительно к антивирусам. В этой статье я расскажу, как это сделать.


    Подготовка


    Для тестов нам понадобится виртуалка с Windows на борту. Я подготовил её вручную, выполнив на ней следующие манипуляции:


    1. Собственно, установил Windows 10 Pro x64;
    2. Во время установки создал основного пользователя "testo" в паролем "1111";
    3. Включил автологин для этого пользователя;

    Для автоматизации тестов я буду использовать платформу Testo. Что это такое и как этим пользоваться можно почитать здесь. Нам же сейчас требуется импортировать готовую виртуалку в автотесты. Сделать это очень просто:



    Здесь предполагается, что /path/to/win10.qcow2 — это путь к диску той виртуалки, которую я подготовил вручную. На этом подготовка заканчивается, и начинается экшен.


    Тест №1 — Устанавливаем Dr. Web!


    Для начала надо решить вопрос с переносом дистрибутива Dr. Web на виртуальную машину. Сделать это можно (например) с помощью флешки:



    Всё, что нам надо сделать — это положить установщик Dr. Web в папочку ${DR_WEB_DIR} (точное значение этого параметра мы будем задавать при запуске testo). А Testo само позаботится о том, чтобы этот инсталлятор оказался на флешке.


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



    Скриншот на момент окончания сценария


    Можно, конечно, запустить инсталлятор прямо отсюда, из самой флешки. Но мы лучше сделаем всё по-честному — мы скопируем инсталлятор на рабочий стол и запустим инсталлятор оттуда. Как же нам скопировать файл? А как бы это сделал человек?



    Скриншот, на котором ещё происходит копирование файла


    Всё, копирование успешно завершено! Теперь можно закрыть окно с флешкой и вытащить её:



    Скриншот после закрытия проводника


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



    Скриншот на момент окончания установки


    Завершаем наш тест перезагрузкой. И в конце не забудем проверить, что после перезагрузки на рабочем столе появилась иконка с Dr. Web:



    Скриншот после перезагрузки


    Отличная работа! Мы автоматизировали установку антивируса Dr. Web! Давайте немного передохнём и посмотрим, как это выглядит в динамике:



    Переходим к тестированию фич.


    Тест №2 — Ограничение доступа к флешкам


    Первая фича по списку — ограничение доступа к флешкам. Для этого спланируем довольно прямолинейный тест:


    1. Попробуем вставить флешку и создать там пустой файл — должно получиться. Вытащим флешку;
    2. Включим блокировку съемных устройств в Dr. Web Security Center;
    3. Ещё раз вставим флешку и попробуем удалить созданный файл. Действие должно быть заблокировано.

    Создадим себе новую флешку, вставим её в Windows и попробуем создать папку. Что может быть проще?



    Скриншот на момент окончания сценария


    Создаём новый текстовый файл через контекстное меню проводника:



    Скриншот после переименования файла


    Отключаем флешку, делаем это безопасно:



    Теперь мы убедились, что с флешкой работать можно, а значит можно приступать к её блокировке в центре безопасности Dr. Web. Для этого сначала надо открыть центр безопасности:



    Скриншот с окном Security Center


    Можем заметить, что для открытия любого приложения в Windows нужно выполнить фактически одинаковые действия (кликнуть на строку поиска, дождаться появления окна с популярными приложениями, вбить имя интересующего приложения, дождаться, когда оно появится в списке и, наконец, нажать Enter). Поэтому эту группу действий можно выделить в макрос open_app, в который в качестве параметра будет передаваться имя открываемого приложения:



    Этот макрос нам ещё пригодится.


    Первое, что мы сделаем, открыв центр безопасности Dr. Web — включим возможность вносить изменения:



    Теперь немного покликаем по менюшкам и зайдем в меню "Configure device access rules". В этом меню поставим галочку в пункте "Block removable media".



    Скриншот с окном Devices and Personal Data


    Попробуем открыть флешку теперь:



    Скриншот с сообщение об ошибке


    Вот так потихоньку-полегоньку мы и написали первый тест с тестированием вполне осязаемой фичи в Dr. Web. Настало время передохнуть и помедитировать, глядя на результаты наших трудов:




    Тест №3 — Разграничение доступа к каталогу между программами


    Основная идея этого тесткейса — проверить работу Dr. Web при ограничении доступа к определенной папке. Если конкретно, то необходимо защитить папку от каких-либо изменений, но добавить исключение для какой-нибудь сторонней программы. Собственно, сам тест выглядит следующим образом:


    1. Установим на ОС стороннюю программу, для которой чуть позже добавим исключение при доступе к защищаемой папке. Сегодня сторонняя программа дня — файловый менеджер FreeCommander;
    2. Создаем папку с файликом, которую будем защищать всеми силами;
    3. Откроем центр безопасности Dr. Web и включим там защиту этой папки;
    4. Настроим исключение для FreeCommander;
    5. Попробуем удалить файл из защищаемой папки обычным способом (через проводник Windows). Не должно получиться;
    6. Попробуем удалить файлик через FreeCommander. Должно получиться.

    Ух, много работы. Быстрее начнём — быстрее закончим.


    Пункт первый, установка FreeCommander не сильно отличается от установки Dr.Web. Обычная рутина: вставили флешку, запустили инсталлятор и так далее. Пропустим это и перейдём сразу к интересному.


    Если всё-таки интересно, как установить FreeCommander

    Начнём с простого: создадим флешку, в которую поместим дистрибутив FreeCommander, а затем в тесте вставим флешку в ОС и откроем её:



    Далее несколько не кликов чтобы запустить установку:



    Установка не очень интересная, просто кликаем везде "Далее", а в конце не забываем отключить галочки с просмотром ReadMe и немедленным запуском FreeCommander



    Заканчиваем тест, закрывая все окна и вытаскивая флешку



    Готово!


    Для работы с Dr. Web создадим новый тест dr_web_restrict_program, который будет полагаться на результат работы предыдущего теста win10_install_freecommander.


    Начнём тест с создания папки Protected на рабочем столе:



    Скриншот после создания папки


    Заходим в папку Protected и создаём там файл my_file.txt, который будет играть роль защищаемого файла:



    Ох, надо было бы тоже оформить это в виде макроса, ну да ладно ...


    Скриншот после создания файла


    Отлично, теперь надо включить защиту папки. Идём знакомой дорожкой и открываем Dr. Web, не забываем включить режим изменений. После чего переходим в меню "Data Loss Prevention".



    Скриншот с окном Data Loss Prevention


    Немного поработаем мышкой и добавим нашу папку Protected в список защищаемых:



    Скриншот с мастером добавления защищаемой папки


    Ну а теперь надо настроить исключение по доступу к папке для FreeCommander. Ещё немного работы мышкой:



    Скриншот с добавленной программой-исключением


    Теперь аккуратно закрываем все окна и пробуем удалить файл "my_file.txt" стандартным способом:



    Скриншот с сообщением от Dr.Web


    Но ничего не получилось — значит Dr. Web действительно отработал! Половина теста позади, но нам ещё надо проверить, что будет работать исключение для FreeCommander. Для этого открываем FreeCommander и переходим в папку Protected:



    Скриншот с окном FreeCommander


    Ну и попробуем удалить файл my_file.txt:



    Скриншот после удаления файла


    Исключение для FreeCommander работает!


    Отличная работа! Большой и сложный тесткейс — и всё автоматизировано. Немного расслабона:




    Тест №4 — Родительский контроль


    Этот последний на сегодня тесткейс мы построим следующим образом:


    1. Создадим нового пользователя MySuperUser;
    2. Залогинимся под этим пользователем;
    3. Создадим файл my_file.txt от имени нового пользователя;
    4. Откроем центр безопасности Dr. Web и включим родительский контроль для этого файла;
    5. В родительском контроле ограничим права пользователя MySuperUser на им же созданный файл;
    6. Попробуем прочитать и удалить файл my_file.txt от имени MySuperUser и посмотрим на результат.

    Я не буду приводить здесь сценарий теста. Он строится по тому же принципу, что и предыдущие тесты: активно работаем мышкой и клавиатурой. При этом нам не важно, что мы автоматизируем — хоть Dr.Web, хоть создание нового пользователя в Windows. Но давайте всё же посмотрим, как будем выглядеть прогон такого теста:



    Заключение


    → Исходники всех тестов Вы можете посмотреть здесь


    Более того, все эти тесты Вы можете прогнать на своей машине. Для этого Вам потребуется интерпретатор тестовых сценариев Testo. Скачать его можно здесь.


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

    Testo Lang
    Компания

    Комментарии 6

      0

      Лирическое отступление:


      А сможете ли вы?

      Конечно же да!


      Ох, помнится когда-то и я это делал у того же самомого доктора. Вроде совсем недавно было, но воды утекло уже неверотяно много. Уже и винду то года три не трогал вовсе. Настольгически так вспомнил сейчас все эти муки с jsonrpc-велосипедами вокруг lua и прочее роботостроение.


      А теперь по тексту. Скриншоты вроде из саблайма, а это наводит на ряд не очень хороших мыслей про разработку на этой штуке. А почему имено выбрали разработку своего DSL, а не стали писать какой-либо фреймфорк или библиотечку на нормальном языке для которого есть нормальные инструменты разработки и средства отладки? Со времен своего знакомства с робот-фреимворком крайне настороженно отношусь к таким штукам. Кажется, что тестирование десктоп приложений вообще штука не тривиальная, а необычные инструменты могут в один день усугубить поддержку автотестов поддержкой инструмента тестирования и войной бесконечности с костылями.


      PS: Код скриншотами на хабре — страшный грех во времена когда хабр умеет сам светить синтаксис.

        0
        Поделитесь опытом! Каким инструментом пользовались? С ним получись бы лучше/хуже?

        Почему мы решились на создание своего языка — описано в предыдущей статье. Если кратко, то одна из причин — мы хотели получить что-то похожее на make/cmake. То есть инструмент должен сам отслеживать, какие тесты актуальны, какие надо заново прогнать, в каком порядке и так далее. Это довольно сложно оформить в виде библиотечки. Наверное, поэтому системы сборки — это обычно конфиг файлы или специализированные языки. У нас конечно не система сборки, но принцип работы примерно такой же.

        Знаю, что код скриншотами — это грех, гореть мне в аду. Да только ведь хабр не знает этого языка. Вопрос знатокам — можно ли научить хабр новым фокусам? То есть добавить подсветку своего языка?
          0
          Код в конце статьи на гитхабе искупит все Ваши грехи. Заодно при первом использовании графического кода сошлитесь в конец статьи.
        0
        Идея для сценария: Обновление 1С.
        Скачать последний дистрибутив.
        Установить нужную конфигурацию (тонкий клиент например).
        Проверить подключение к серверу.
        Удалить старые версии, скаченный файлы.
        В случае фэйла удалить новую версию, и скаченные файлы.
        Как бонус — зайти в настройки 1С и проверить что ККМ не отпал и статус зеленый.
          0
          Я правильно понял, что работает по принципу кликера?? А если изменилось разрешение экрана? А если вдруг случайно иконка переместилась? Будет работать?
            0

            Детект объектов на экране работает с помощью нейросетей. Нейросети нечуствительны к разрешению экрана и им всё равно где именно объект на экране. Главное чтобы он на экране был

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое