Тестировать нельзя помиловать
Как и ожидалось, недавний пост про тест производительности 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 тест.
Смысл прост: берём обычный компьютер, ставим на него антивирус с настройками по умолчанию и пытаемся всяческими способами запустить актуальную малварь. Всё просто!
Продукт работает в полную мощность, обстановка максимально приближена к боевой! А пользователь в итоге получает правильный замер качества антивируса и релевантную информацию для разумного выбора. Потом замерить нагрузку на систему, размер апдейтов, довесить цену, на каждую категорию тестирования поставить «вес за набранные баллы» - и результат готов.
Всё просто? Увы - нет.
Даже не говоря о трудностях с правильным выбором тестового зловредства, - самое сложное здесь то, что тестирование «в максимально приближенных к боевым» условиях требует этих самых максимально приближенных условий, которые крайне сложно автоматизировать. Т.е. подобные тесты требуют ОЧЕНЬ много ручной механической работы.
И именно по этой причине такие тесты проводятся крайне редко и в весьма усечённом режиме. В предыдущем посте я уже перечислил несколько. Но даже и тут у каждого есть свои особенности и нюансы.
Короче, как правильно советовать правильно тестировать - мне понятно и очевидно. Но где найти безумцев, которые могли бы взять на себя [бесплатно] проведение подобных тестовых замеров - мне неизвестно. Так что, увы, смотреть правильные результаты правильных тестов - пока некуда..
Вот такой си-бемоль-минор в завершение этой муз-композиции :(
Короче - получилось. Поскольку хочется найти истину. И не только - очень бы хотелось каким-то образом стимулировать правильность антивирусного тестирования.
А как вообще надо тестировать антивирусы?
Ага, значит так, во-первых. Во избежание наездов. Чтобы сразу сбить коменты, что типа мы сейчас будем учить тестеров варить табуретовку по нашим рецептам, чтобы наши продукты вылезали в лидеры. На это есть ответ - мы и так редко когда НЕ попадаем в тройку лидеров в различных тестах. А во-вторых, то, что о чем сейчас пойдёт речь - это не мои выдумки, а индустриальные стандарты 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 тест.
Смысл прост: берём обычный компьютер, ставим на него антивирус с настройками по умолчанию и пытаемся всяческими способами запустить актуальную малварь. Всё просто!
Продукт работает в полную мощность, обстановка максимально приближена к боевой! А пользователь в итоге получает правильный замер качества антивируса и релевантную информацию для разумного выбора. Потом замерить нагрузку на систему, размер апдейтов, довесить цену, на каждую категорию тестирования поставить «вес за набранные баллы» - и результат готов.
Всё просто? Увы - нет.
Даже не говоря о трудностях с правильным выбором тестового зловредства, - самое сложное здесь то, что тестирование «в максимально приближенных к боевым» условиях требует этих самых максимально приближенных условий, которые крайне сложно автоматизировать. Т.е. подобные тесты требуют ОЧЕНЬ много ручной механической работы.
И именно по этой причине такие тесты проводятся крайне редко и в весьма усечённом режиме. В предыдущем посте я уже перечислил несколько. Но даже и тут у каждого есть свои особенности и нюансы.
Короче, как правильно советовать правильно тестировать - мне понятно и очевидно. Но где найти безумцев, которые могли бы взять на себя [бесплатно] проведение подобных тестовых замеров - мне неизвестно. Так что, увы, смотреть правильные результаты правильных тестов - пока некуда..
Вот такой си-бемоль-минор в завершение этой муз-композиции :(