Comments 6
Если честно, то статью писал явно человек, который не разобрался с Ranorex.
Если писать доступ к элементам руками, а не через UIMap (свой page object), то можно сесть в гигантскую лужу, ибо нужно описывать полную иерархию контролов. Например обратится к контекстному меню по имени и классу нельзя, нужно сначала описать верхнее окно. В ranorex нет такой проблемы, так как поиск идёт в более «умно».
Если честно, то xpath реализованный в ranorex настолько удобный и полный, что работа с ним ни чем не отличается от работы с selenium. Это даёт большой простор для написания своего page object и динамического поиска объектов, см вверх.
Вот тут я вообще не понимаю. Что мешает обернуть ranorex в mstest или даже в codedui? Ядро ranorex — это ranorex library. Ranorex library — это набор DLL, которые легко подключаются к тестовому проекту. Опять же говорю о том что тут работа с ranorex вообще ни чем не отличается от работы с Selenium.
И так, ranorex — это набор DLL. Контролы ищутся через xpath. Всё прекрасно работает внутри MSTest/NUnit/CodedUI. Тесты пишутся на С# в студии. Что ещё нужно для построение красивого и удобного тестового фреймворка?
Так как тесты легко оборачиваются в MSTest, то их можно запускать на любом CI сервере.
Красиво и информативно оформить выхлоп тестов можно всегда и везде, главное желание.
Выкидываем Ranorex Studio + пишем через нормальный тестовый юнит-тест провайдер = возможная интеграция куда угодно.
Хороший тестовый фреймворк можно построить и там и там. Но из коробки конечно ranorex лучше.
Странно видеть такое не профессиональное сравнение в блоге такой компании. У себя в отделе мы используем связку Ranorex+SpecFlow+CodedUI. Тесты легко пишутся, легко поддерживаются, видны в MTM, нативно запускаются через Team Build. В прошлом году я читал доклад как мы выбирали Ranorex qa.optsconf.ru/schedule
Поддержка динамически генерируемых контролов
Если писать доступ к элементам руками, а не через UIMap (свой page object), то можно сесть в гигантскую лужу, ибо нужно описывать полную иерархию контролов. Например обратится к контекстному меню по имени и классу нельзя, нужно сначала описать верхнее окно. В ranorex нет такой проблемы, так как поиск идёт в более «умно».
Настраиваемая система поиска контролов
Если честно, то xpath реализованный в ranorex настолько удобный и полный, что работа с ним ни чем не отличается от работы с selenium. Это даёт большой простор для написания своего page object и динамического поиска объектов, см вверх.
Простая поддержка Data Driven Testing
Вот тут я вообще не понимаю. Что мешает обернуть ranorex в mstest или даже в codedui? Ядро ranorex — это ranorex library. Ranorex library — это набор DLL, которые легко подключаются к тестовому проекту. Опять же говорю о том что тут работа с ranorex вообще ни чем не отличается от работы с Selenium.
Возможность разработки фреймворков для тестирования
И так, ranorex — это набор DLL. Контролы ищутся через xpath. Всё прекрасно работает внутри MSTest/NUnit/CodedUI. Тесты пишутся на С# в студии. Что ещё нужно для построение красивого и удобного тестового фреймворка?
Поддержка запуска тестов на CI-сервере
Так как тесты легко оборачиваются в MSTest, то их можно запускать на любом CI сервере.
Генерация информативных отчетов по результату прогона
Красиво и информативно оформить выхлоп тестов можно всегда и везде, главное желание.
Возможность интеграции тестов с тест-кейсами TMS
Выкидываем Ranorex Studio + пишем через нормальный тестовый юнит-тест провайдер = возможная интеграция куда угодно.
Простота изучения и использования тестировщиками
Хороший тестовый фреймворк можно построить и там и там. Но из коробки конечно ranorex лучше.
Странно видеть такое не профессиональное сравнение в блоге такой компании. У себя в отделе мы используем связку Ranorex+SpecFlow+CodedUI. Тесты легко пишутся, легко поддерживаются, видны в MTM, нативно запускаются через Team Build. В прошлом году я читал доклад как мы выбирали Ranorex qa.optsconf.ru/schedule
Вы совершенно правы, особенно что касается
«Хороший тестовый фреймворк можно построить и там и там. Но из коробки конечно ranorex лучше.»
Более того, даже автор статьи с вами согласен
«По выбранным нами критериям сравнения Ranorex был оценён выше, главным образом за счёт удобства.»
Выбор CodedUI был сделан только в аспекте конкеретных проектов
«Что же касается наших проектов.»
«В конечном счёте выбор стоял между инструментом, в котором тестировщики отдельно от продукта и разработчиков будут писать GUI-тесты, и временем, потраченным на разработку всего необходимого (фреймворка, документации) для быстрой и удобной разработки тестов с использованием CodedUI.»
Вы же предлагаете купить еще один продукт, выкинуть почти все из него. Зачем, если легче добавить удобство локаторов в готовую инфраструктуру (ведь именно этот подход, основы на инфраструктуре диктует Microsoft?)
«Выкидываем Ranorex Studio + пишем через нормальный тестовый юнит-тест провайдер = возможная интеграция куда угодно.»
К слову, легкость написания и поддержки тестов в selenium при помощи xpath для меня крайне сомнительна. И минусов там куча, начиная от скорости работы в IE, до поддержки постоянной смены интерфейса. Но это вероятно оффтоп.
«Если честно, то xpath реализованный в ranorex настолько удобный и полный, что работа с ним ни чем не отличается от работы с selenium.»
«Хороший тестовый фреймворк можно построить и там и там. Но из коробки конечно ranorex лучше.»
Более того, даже автор статьи с вами согласен
«По выбранным нами критериям сравнения Ranorex был оценён выше, главным образом за счёт удобства.»
Выбор CodedUI был сделан только в аспекте конкеретных проектов
«Что же касается наших проектов.»
«В конечном счёте выбор стоял между инструментом, в котором тестировщики отдельно от продукта и разработчиков будут писать GUI-тесты, и временем, потраченным на разработку всего необходимого (фреймворка, документации) для быстрой и удобной разработки тестов с использованием CodedUI.»
Вы же предлагаете купить еще один продукт, выкинуть почти все из него. Зачем, если легче добавить удобство локаторов в готовую инфраструктуру (ведь именно этот подход, основы на инфраструктуре диктует Microsoft?)
«Выкидываем Ranorex Studio + пишем через нормальный тестовый юнит-тест провайдер = возможная интеграция куда угодно.»
К слову, легкость написания и поддержки тестов в selenium при помощи xpath для меня крайне сомнительна. И минусов там куча, начиная от скорости работы в IE, до поддержки постоянной смены интерфейса. Но это вероятно оффтоп.
«Если честно, то xpath реализованный в ranorex настолько удобный и полный, что работа с ним ни чем не отличается от работы с selenium.»
Выбор CodedUI был сделан только в аспекте конкеретных проектов
В тестировании через UI это вообще главное. Особенно в десктопе. Контролы могут просто не определяться. Так что если были выбраны два инструмента, то они оба имеют достаточную поддержку технологий конкретных проектов и дальше идёт уже удобство и всё остальное.
Вы же предлагаете купить еще один продукт, выкинуть почти все из него. Зачем, если легче добавить удобство локаторов в готовую инфраструктуру (ведь именно этот подход, основы на инфраструктуре диктует Microsoft?)
У ranorex есть разные редакции. Для себя мы покупаем только Ranorex Runtime на CI. Разрабатываем мы тесты локально, а запускаем на виртуальных машинах. Так проще контролировать среду исполнения и не надо ждать завершения тестов.
К слову, легкость написания и поддержки тестов в selenium при помощи xpath для меня крайне сомнительна. И минусов там куча, начиная от скорости работы в IE, до поддержки постоянной смены интерфейса. Но это вероятно оффтоп.
Вы писали локаторы на чистом механизме CodedUI? Уверяю вас что xpath по сравнению с ним просто сказка в поддержке. А деструктивные эффекты от смены интерфейса помогают преодолеть page object + Cucumber/SpecFlow.
А деструктивные эффекты от смены интерфейса помогают преодолеть page object + Cucumber/SpecFlow.
или механизмы автогенерация локаторов при сборке продукта.
Sign up to leave a comment.
CodedUI или Ranorex? Автоматизация функционального тестирования .NET приложений