Comments 13
Может где то и нужно оптическое распозравание текста, но не в том примере, который показан в статье. Сайт хабра можно потестить и без этого. Распознавать капчу пробовали?
Такой задачи не стояло. Задача именно в автоматизации рутинных действий с GUI приложения со сбором статистики.
Tesseract OCR очень плохо распознаёт искажённые тексты, коими чаще всего капча и является. Конечно можно сделать поверх изображения кучу фильтров, выровнять некоторые символы, но попадание будет очень низким. Для таких целей подойдёт что-то более специализированное.
У себя распознаём мульти-язычные pdf с в целом вменяемым качеством снимков страниц и то приходится делать несколько попыток что бы найти в тексте то что нужно на произвольном документе. Чуть что отличное от прямого текста — разметка (порядок) символов превращается в кашу с кучей пробелов. А так в целом хорошая библиотека.
У себя распознаём мульти-язычные pdf с в целом вменяемым качеством снимков страниц и то приходится делать несколько попыток что бы найти в тексте то что нужно на произвольном документе. Чуть что отличное от прямого текста — разметка (порядок) символов превращается в кашу с кучей пробелов. А так в целом хорошая библиотека.
Selenium и для десктопа есть, от 2gis.
Это и хорошо. Вот только в софте от 2gis используется UIAutomation Framework, который кстати говоря, не всегда применим, даже к Desktop приложениям.
В статье же я попытался описать совсем другой подход к автоматизации тестирования — не нужно никаких фреймворков, просто PrintScreen + OCR
В статье же я попытался описать совсем другой подход к автоматизации тестирования — не нужно никаких фреймворков, просто PrintScreen + OCR
Но ведь уже давно есть Sikuli, что с ним не так?
Да, Sikuli это классный фреймворк судя по описанию, но там используется другой механизм — матчинг паттернов без распознавания текста. Т. е. «если эта картинка выглядит как шаблон, то кликаем».
Описанный механизм OCR на мой взгляд дает больше свободы — можно брать информацию с экранной формы.
Кстати, template matching неплохо реализован и в AForge.
Описанный механизм OCR на мой взгляд дает больше свободы — можно брать информацию с экранной формы.
Кстати, template matching неплохо реализован и в AForge.
В подходе я вижу проблему в том, что элемент UI может поменять свое положение и не всегда понятно, как предсказать, где должен быть элемент, простой пример, вы ищете хаб «Программирование» и он всегда у вас на первом месте, и тут вдруг добавили хаб «Администрирование» и он стал на первом месте, а «Программирование» ушло на второе место и как это обработать, это ошибка интерфейса или придется переделать тест? Сам пользуюсь Coded UI Test для автоматизации тестирования GUI.
Определенно, элементы могут менять положение. В данном случае это лишь добавить шагов проверки «если не здесь, то здесь». В тест придется добавить проверку всех положений или обрабатывать данную ситуацию как-то особенно (используя тот же UIAutomation если это возможно).
Ошибка или не ошибка интерфейса — это вопрос скорее по usability и дизайну. На мой взгляд каждый раз произвольное положение каких-то контроллов — это плохая usability.
Ошибка или не ошибка интерфейса — это вопрос скорее по usability и дизайну. На мой взгляд каждый раз произвольное положение каких-то контроллов — это плохая usability.
Ну допустим вы добавили пост на Хабрахабр и хотите проверить, что он отобразился, но сразу после вашего поста другой тест, который запущен на другом агенте добавил еще один пост, то есть ваш пост стал вторым, вопрос, как вы определите положение вашего поста, ведь высота поста из второго теста может быть любой?
Вообще для тестирования GUI приложений куда более логично использовать Accessebility технологии, как уже вышеупомянутые MSAA или UI Automation. Т.е. процесс выглядит как «опросить систему и получить список диалогов -> зная ожидаемые контролы на диалоге, определить, какой диалог из этих нам нужен (без всякого распознавания, простой обход деревьев) -> из полученной информации получить информацию о конкретном контроле „Next“ -> послать эвент по нажатию этой кнопки». Да, с таким подходом на линуксе и маке немного посложнее, чем на винде, но все равно применимо. И меня уже долгое время мучает вопрос — почему все пытаются написать свой велосипед, использующий графическое распознавание, нежели использовать Accessebility?
Sign up to leave a comment.
Тестирование GUI приложений с помощью оптического распознавания текстов