Тестировать нельзя помиловать

Как и ожидалось, недавний пост про тест производительности Passmark наделал некоторого шума. Причём главное – шум был не столько в блоге, сколько в антималварной индустрии. Ну, это именно то, чего обычно хочет настоящий Монморанси :)

Короче – получилось. Поскольку хочется найти истину. И не только – очень бы хотелось каким-то образом стимулировать правильность антивирусного тестирования.

А как вообще надо тестировать антивирусы?

Ага, значит так, во-первых. Во избежание наездов. Чтобы сразу сбить коменты, что типа мы сейчас будем учить тестеров варить табуретовку по нашим рецептам,  чтобы наши продукты вылезали в лидеры. На это есть ответ — мы и так редко когда НЕ попадаем в тройку лидеров в различных тестах. А во-вторых, то, что о чем сейчас пойдёт речь – это не мои выдумки, а индустриальные стандарты AMTSO (Anti-Malware Testing Standards Organization – есть такая организация), в которой есть представители практически всех ведущих АВ-вендоров и разные известные эксперты.

Увы, широкая публика и прогрессивная мировая общественность с AMTSO знакома мало, а большинство тестеров до сих пор предпочитают делать свою работу по старинке. Оно и понятно – это дешёво и привычнее, а юзеру, мол, главное — результат – кто занял первое-второе-третье место, а кто пошёл в отвал.

Вроде бы все довольны, НО! Это реально искажает картину. В итоге получается, что наверх проползает не самый лучший софт, положение в списке победителей тестов практически никак не соответствует реальному уровню обеспечиваемой защиты – короче, туфта и эээ… обман потребителя, короче.

Почему я так горячусь – да иногда бывает просто обидно, что время и ресурсы тратятся не для того, чтобы «делать дело» — а чтобы обеспечить показательные выступления в очередном говно-тестировании. Чтобы показывать результат не хуже тех, что тупо точит свои продукты не на реальное качество – а только чтобы протестироваться правильнее остальных.

Вот. Ну а теперь — перейдём к главному.

Итак, как НЕ надо тестировать.

Классический, старый-добрый on-demand тест.

Собственно, это – самый обычный стандартный и привычный тест и когда-то, давным-давно, в до-массово-Интернетовские времена, он действительно был самым правильным.

// мы, кстати, в 1994 году устроили международную премьеру AVP как раз на таком тесте Гамбургского Университета – участвовали в первый раз и сразу же всех порвали.

Методика тестирования такая: берётся диск и забивается малварой, чем больше – тем лучше, самой разной, до чего руки дотянулись. Потом на него натравливаются разные антивирусные сканеры и замеряется количество детекта. Дёшево и сердито. Но уже лет 10 как абсолютно нерелевантно!

Почему? А потому что антивирусные сигнатурные, эвристические и прочие «сканирующие» движки – это только часть комплекса технологий, которые используются в реальном мире для защиты! (причём значение этих движков в общем уровне защиты стремительно падает). Зачастую сканер вообще работает как последняя инстанция для чисто хирургической работы: например, у нас System Watcher выслеживает какого-нибудь трояна, понимает картину заражения и потом уже передаёт сканеру задачу по выпалыванию.

Другой недостаток – база малвари для сканирования.

Тут две крайности и обе порочные. Слишком мало малварных файлов – сами понимаете, нерелевантно. Слишком много сэмплов – та же трабла, но уже с другого конца: в мега-коллекции попадает слишком много мусора (битые файлы, файлы данных, не-очень-малварь,  например, скрипты, которые пользуются малварью и т.п.) И очистить коллекцию от подобного мусора – тяжелейшая и неблагодарная работа. К тому же низкооплачиваемая :)

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

Ещё раз.

Для того, чтобы показать в «тестах сканирования» близкий к 100% результат, не надо упираться и повышать качество технологий. Надо просто детектить всё то, что попадает в эти тесты. Примерно как в анекдоте про охотников и медведя:

— Но медведь же бежит быстрее нас! – говорит первый охотник.

— А мне и не надо бежать быстрее медведя, — отвечает  второй, — мне нужно просто бежать быстрее тебя.

Чтобы победить в этих тестах не нужно «бежать быстрее медведя». Нужно просто присосаться к источникам малвари, которые используют самые известные тестеры (а эти источники известны – VirusTotal, Jotti и малваро-обменники антивирусных компаний) – и тупо детектить всё, что детектят остальные. Т.е. если файл детектируется конкурентами – просто задетектить его по MD5 или типа того.

Всё! Я лично готов с нуля, силами пары разработчиков, сделать сканер, который будет через пару месяцев показывать почти 100% детект. // почему именно два разработчика нужно – на всякий случай, вдруг один заболеет.

Короче, on-demand-тесты – это тесты неправильные. Поскольку ничего реального не показывают, под них легко подстроиться и крайне тяжело победить честно.

Как можно тестировать, но куда НЕ спецам лучше НЕ смотреть.

Тут целый зоопарк всяких нишевых тестов, которые показывают качество антивирусов в какой-то очень специфической области.

В принципе, право на существование имеют, более того – крайне полезны для сравнения качества изготовления какой-либо конкретной фичи. Но надо БОЛЬШИМИ буквами писать об этой специфике и что тест НЕ учитывает всех способностей продукта. Что обычному пользователю тут делать нечего – это сугубо индустриальные тесты, несущие полезную нагрузку только для спецов и прочих гиков.

Например, тест на лечение конкретного случая (как продукт справляется с лечением системы, заражённой определённым образом), тест на ложные срабатывания (как продукт «фалсит» на чистое ПО), проактивный тест (как продукт ловит малварь без сигнатур, т.е. только проактивными технологиями), on-access тест (качество on-access сканера при real-time операциях с малварью), замеры производительности и гуёвости интерфейса, и т.п. – различные тесты специфического назначения.

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

Наконец, как НАДО тестировать, и куда НАДО бы смотреть…

Начну издалека. Для чего вообще нужны тесты?

Прежде всего, чтобы показать качество защиты. Да, при всех равных юзабилити и производительность тоже важны, но, в конечном счёте, нам же «ехать, а  не шашечки». Посему так.

А как проверить качество защиты?

Разумеется в обстановке максимально приближённой к боевой! Методология правильного теста должна базироваться на самых распространённых сценариях работы пользователей в реальной жизни. Всё остальное – компромисс и сослагательности из разряда «если бы да кабы».

Для этой задачи большего всего подходит динамический или real world тест.

Смысл прост: берём обычный компьютер, ставим на него антивирус с настройками по умолчанию и пытаемся всяческими способами запустить актуальную  малварь. Всё просто!

Продукт работает в полную мощность, обстановка максимально приближена к боевой! А пользователь в итоге получает правильный замер качества антивируса и релевантную информацию для разумного выбора. Потом замерить нагрузку на систему, размер апдейтов, довесить цену, на каждую категорию тестирования поставить «вес за набранные баллы» — и результат готов.

Всё просто? Увы – нет.

Даже не говоря о трудностях с правильным выбором тестового зловредства, — самое сложное здесь то, что тестирование «в максимально приближенных к боевым» условиях требует этих самых максимально приближенных условий, которые крайне сложно автоматизировать. Т.е. подобные тесты требуют ОЧЕНЬ много ручной механической работы.

И именно по этой причине такие тесты проводятся крайне редко и в весьма усечённом режиме. В предыдущем посте я уже перечислил несколько. Но даже и тут у каждого есть свои особенности и нюансы.

Короче, как правильно советовать правильно тестировать – мне понятно и очевидно. Но где найти безумцев, которые могли бы взять на себя [бесплатно] проведение подобных тестовых замеров – мне неизвестно. Так что, увы, смотреть правильные результаты правильных тестов – пока некуда..

Вот такой си-бемоль-минор в завершение этой муз-композиции :(