I have never used Dr. Web. I have no idea how it works. But this did not stop me from writing a number of autotests for it (and only laziness did not allow me to write a hundred more others):

1. Installation test web;
2. Test for restricting access to removable devices (flash drives);
3. Test for delimiting access to the directory between programs;
4. Test for delimiting access to the directory between system users (parental control).

Such and many other tests can be riveted like hot cakes, and not only in relation to Dr. Web, and not only in relation to antiviruses. In this article, I will show you how to do it.

Prepare

For tests, we need a virtual machine with Windows on board. I prepared it manually by performing the following manipulations on it:

1. Actually, installed Windows 10 Pro x64;
2. During installation created the main user "testo" with the password "1111";
3. Enabled autologin for this user;

To automate tests, I will use the Testo platform. What is it and how to use it you can read here. We now need to import the finished virtual machine into autotests. It's very easy to do this:

Here it is assumed that /path/to/win10.qcow2 is the path to the disk of the virtual machine that I prepared manually. This completes the preparation and the action begins.

Test #1 - Installing Dr. Web!

First, you need to resolve the issue of transferring the Dr. web to a virtual machine. You can do this (for example) using a flash drive:

All we have to do is put the Dr. Web to daddy ${DR_WEB_DIR} (we will set the exact value of this parameter when starting testo). And Testo itself will make sure that this installer is on a USB flash drive.

Now we can start actually writing the test. For now, let's start the test with simple things: turn on the virtual machine (it will be turned off after creation), wait for the desktop to appear, turn on the flash drive and open its contents through the explorer:

Screenshot at the end of the script

You can, of course, run the installer right from here, from the flash drive itself. But we'd better do everything honestly - we will copy the installer to the desktop and run the installer from there. How can we copy the file? How would a person do it?

Screenshot showing file being copied

Everything, copying successfully completed! Now you can close the window with the flash drive and pull it out:

Screenshot after closing explorer

Now that the installer is on the desktop, we need to double click on it to start the installation process. And the installation itself comes down to a simple clicking of buttons and checkmarks and is not of great interest:

Screenshot at the end of the installation

We complete our test with a reboot. And in the end, let's not forget to check that after the reboot, an icon with Dr. web:

Screenshot after reboot

Great job! We have automated the installation of Dr. Web! Let's take a break and see how it looks in dynamics:

Let's move on to feature testing.

Test number 2 - Restricting access to flash drives

The first feature on the list is restricting access to flash drives. To do this, we plan a fairly straightforward test:

1. Let's try to insert a USB flash drive and create an empty file there - it should work. Pull out the flash drive;
2. Enable blocking of removable devices in Dr. Web Security Center;
3. Insert the flash drive again and try to delete the created file. The action must be blocked.

Let's create a new flash drive for ourselves, insert it into Windows and try to create a folder. What could be easier?

Screenshot at the end of the script

Create a new text file through the explorer context menu:

Screenshot after renaming the file

Turn off the flash drive, do it safely:

Now we have made sure that it is possible to work with the flash drive, which means that we can start blocking it in the Dr. Web. To do this, you first need to open the security center:

Screenshot of the Security Center window

We can notice that to open any application in Windows, you need to perform virtually the same actions (click on the search bar, wait for a window with popular applications to appear, type in the name of the application of interest, wait until it appears in the list and finally press Enter). Therefore, this group of actions can be separated into a macro open_app, in which the name of the application to be opened will be passed as a parameter:

This macro is still useful to us.

The first thing we will do by opening the Dr. Web - enable the ability to make changes:

Now let's click a little on the menus and go to the "Configure device access rules" menu. In this menu, check the box "Block removable media".

Screenshot of the Devices and Personal Data window

Let's try to open the flash drive now:

Screenshot with error message

So, little by little, we wrote the first test with testing a quite tangible feature in Dr. Web. It's time to take a break and meditate, looking at the results of our labors:

Test # 3 - Differentiation of access to the directory between programs

The main idea of ​​this test case is to check the work of Dr. Web when restricting access to a specific folder. Specifically, it is necessary to protect the folder from any changes, but add an exception for some third-party program. Actually, the test itself looks like this:

1. Let's install a third-party program on the OS, for which a little later we will add an exception when accessing a protected folder. Today's third-party program of the day is a file manager FreeCommander;
2. We create a folder with a file, which we will protect with all our might;
3. Let's open the Dr. Web and enable the protection of this folder there;
4. Set up an exception for FreeCommander;
5. Let's try to delete a file from the protected folder in the usual way (via Windows Explorer). It shouldn't work;
6. Let's try to delete the file using FreeCommander. It should work.

Wow, a lot of work. The sooner we start, the sooner we finish.

Point one, installing FreeCommander is not much different from installing Dr.Web. The usual routine: inserted a USB flash drive, launched the installer, and so on. Let's skip this and go straight to the interesting.

If you are still wondering how to install FreeCommander

Let's start with a simple one: create a flash drive in which we place the FreeCommander distribution, and then insert the flash drive into the OS in the test and open it:

Next, a few non-clicks to start the installation:

The installation is not very interesting, just click "Next" everywhere, and at the end do not forget to turn off the checkboxes with the ReadMe view and the immediate launch of FreeCommander

We finish the test by closing all windows and pulling out the flash drive

Done!

To work with Dr. Web create a new test dr_web_restrict_program, which will rely on the result of the previous test win10_install_freecommander.

Let's start the test by creating a Protected folder on the desktop:

Screenshot after folder creation

Go to the Protected folder and create a file there my_file.txt, which will play the role of a protected file:

Oh, I should have done that as a macro too, but oh well...

Screenshot after file creation

Great, now you need to enable folder protection. We follow the familiar path and open Dr. Web, don't forget to enable change mode. Then go to the "Data Loss Prevention" menu.

Screenshot with Data Loss Prevention window

Let's work a little with the mouse and add our Protected folder to the list of protected ones:

Screenshot of the Add Protected Folder Wizard

Well, now we need to set up a folder access exception for FreeCommander. A little more mouse work:

Screenshot with added exception program

Now carefully close all windows and try to delete the "my_file.txt" file in the standard way:

Screenshot with a message from Dr.Web

But nothing happened, so Dr. Web really worked! Half of the test is over, but we still need to check that the exception for FreeCommander will work. To do this, open FreeCommander and go to the Protected folder:

Screenshot with FreeCommander window

Well, let's try to delete the my_file.txt file:

Screenshot after file deletion

The exception for FreeCommander works!

Great job! A large and complex test case - and everything is automated. A little relaxation:

Test #4 - Parental Control

We will build this last test case for today as follows:

1. Let's create a new user MySuperUser;
2. Log in with this user;
3. Let's create a file my_file.txt on behalf of the new user;
4. Let's open the Dr. Web and enable parental control for this file;
5. In parental control, we restrict the rights of the MySuperUser user to the file created by him;
6. Let's try to read and delete the file my_file.txt on behalf of MySuperUser and look at the result.

I will not provide a test script here. It is built on the same principle as the previous tests: we actively work with the mouse and keyboard. At the same time, it doesn’t matter to us what we automate - even Dr.Web, even the creation of a new user in Windows. But let's still see how the run of such a test will look like:

Conclusion

→ Sources of all tests you can see here

Moreover, you can run all these tests on your machine. To do this, you will need the Testo test script interpreter. You can download it here.

Dr. Web turned out to be a good training, but I would like to draw inspiration for further exploits from your wishes. Write in the comments your suggestions about what autotests you would like to see in the future. In the next article I will try to automate them, let's see what happens.

Source: habr.com