Наши UI друг с другом еще как конфликтуют — специфика приложения плюс большие фикстуры.
У нас намного больше клиентского кода, чем серверного. Соответственно и ошибки могут проявляться только при отображении данных, работе с данными в интерфейсе.
Приоритеты кейсов — опыт тестировщиков и мудрые указания аналитиков.
Имитация бизнес процесса проще решается через нашу тестирующую систему, а не unit тестами благодаря развитым DSL.
Отчет удобен в том плане, что генерируется автоматически.
А скажите, кто читает ваши отчеты? Тестировщики? Программисты? Менеджеры? Кто с ними реально работает.
Если бы я был программистом, то мне удобней был бы стек, лог приложения и строка в которой надо ставить breakpoint.
Если ручной тестер — отличный отчет.
Если менеджер — то нужен заголовок теста.
Параллелим — просто 3-6 дочерних сборок с разным набором тестов. В круге четвертом об этом есть.
А я со своей колокольни считаю, что менеджмент ваш прав. Мы писали UI тесты, решая определенный класс проблем. Если у вас их нет — зачем вам UI? А если есть — так его и предъявить менеджерам.
Воспримут всерьез когда вы этими тестами начнете решать проблемы неработающего интерфейса при работающей бизнес логике. Когда UI тесты писать будет проще, чем Unit. Когда UI будут писать все, а юнит только программисты. Например так.
Если бы мы решили перейти, то изменения затронули бы 1-2 класса.
Но мы не задумывались об этом именно потому, что основной потребитель времени — рендер в браузере и отклик приложения. Скорость поиска элемента на порядок меньше.
Наши тесты пишутся по постановкам и на самом деле меняются достаточно редко. Но — я думал о переходе на готовый фреймворк, Очень уж нравится балансировка тестов, в меньшей степени — синхронизация сценариев и отчеты. Вполне возможно, что это нам светит.
Xpath ищем по id через нашу обертку, проблем нет.
За JaCoCo спасибо, не слышал, Скоро посмотрим, что это.
PageObject рассматривали, он нам не подошел, так как логика нашей системы — не экраны, а объекты. Но многие подходы взяли оттуда, я слежу за ним.
Фреймворки даже не рассматривали, хотя и зря. Из-за наивного желания сделать самостоятельно и хорошо. В середине 2011 года я еще не знал, по каким критериям их выбирать, теперь знаю, но у нас уже есть свой. Со всеми его плюсами и минусами.
Таким образом — уже ближе к реальности.
Но все же требуется доработка напильником. Jmeter (по умолчанию) выполняет запросы к серверу последовательно, а браузер какие-то последовательно, какие-то параллельно, в зависимости от не знаю чего уж там.
И так далее.
У нас была проблема, что асинхронные запросы могут серьезно меняться от одной версии приложения к другой(от одной настройки к другой… ), поэтому каждый раз необходимо перезаписывать сценарий для jmeter.
У нас была система функционального тестирования. Мы пытались использовать ее для нагрузки. Фейл.
Мы пытались использовать jmeter. Интерфейс асинхронный, скрипты, яваскрипты и прочий аякс — а значит недостаточно просто запросить страницу, большая часть данных передается как раз после отработки скриптов, асинхронно. Фейл.
Теперь мы создали монстра: в рамках одного теста с помощью selenium прогоняется сценарий, который автоматически записывается в lmeter. Таким образом мы перехватываем все асинхронные запросы.
Затем он парсится, параметризуется для масштабирования, затем запускается jmeter — это нагрузка.
Отклики jmeter мы не считаем, это бесполезные цифры, мы считаем совершенное им количество бизнес операций — это нагрузка на сервер.
А в это время selenium тест выполняет сценарии и запоминает отклики.
Не соглашусь. Степень достоверности результатов выше как раз у Selenium, он по поведению ближе к реальному пользователю(браузер, много хостов), чем инструменты для нагрузочного тестирования(нет браузера, только запросы к серверу, причем большинство с одного хоста).
В случае активного использования аяксов на сайте специнструменты вообще сложно применять.
Специализированные инструменты выигрывают на 2-4 порядка по потребляемым ресурсам в расчете на одного сэмулированного пользователя, поэтому и приходится использовать их, делая модель нагрузки более грубой.
А какие именно подробности?
Ветвь для фичи можно протестировать, запустив специально созданную для этого сборку. Они уже есть, 4 штуки.
С ужасом и радостью осознаю, что и к Continuous Delivery мы идем. Медленно, но идем.
АТ пишет тесты.
Ручной тестер читает кейсы.
Разработчик чинит приложение.
Выглядит тоже не очень презентабельно,
У нас намного больше клиентского кода, чем серверного. Соответственно и ошибки могут проявляться только при отображении данных, работе с данными в интерфейсе.
Приоритеты кейсов — опыт тестировщиков и мудрые указания аналитиков.
Имитация бизнес процесса проще решается через нашу тестирующую систему, а не unit тестами благодаря развитым DSL.
Отчет удобен в том плане, что генерируется автоматически.
А скажите, кто читает ваши отчеты? Тестировщики? Программисты? Менеджеры? Кто с ними реально работает.
Если бы я был программистом, то мне удобней был бы стек, лог приложения и строка в которой надо ставить breakpoint.
Если ручной тестер — отличный отчет.
Если менеджер — то нужен заголовок теста.
Ну или какие у вас там есть роли?
А я со своей колокольни считаю, что менеджмент ваш прав. Мы писали UI тесты, решая определенный класс проблем. Если у вас их нет — зачем вам UI? А если есть — так его и предъявить менеджерам.
Воспримут всерьез когда вы этими тестами начнете решать проблемы неработающего интерфейса при работающей бизнес логике. Когда UI тесты писать будет проще, чем Unit. Когда UI будут писать все, а юнит только программисты. Например так.
Но мы не задумывались об этом именно потому, что основной потребитель времени — рендер в браузере и отклик приложения. Скорость поиска элемента на порядок меньше.
Впрочем, ничего не мешает поставить эксперимент.
Xpath ищем по id через нашу обертку, проблем нет.
За JaCoCo спасибо, не слышал, Скоро посмотрим, что это.
Фреймворки даже не рассматривали, хотя и зря. Из-за наивного желания сделать самостоятельно и хорошо. В середине 2011 года я еще не знал, по каким критериям их выбирать, теперь знаю, но у нас уже есть свой. Со всеми его плюсами и минусами.
Но все же требуется доработка напильником. Jmeter (по умолчанию) выполняет запросы к серверу последовательно, а браузер какие-то последовательно, какие-то параллельно, в зависимости от не знаю чего уж там.
И так далее.
У нас была проблема, что асинхронные запросы могут серьезно меняться от одной версии приложения к другой(от одной настройки к другой… ), поэтому каждый раз необходимо перезаписывать сценарий для jmeter.
Мы пытались использовать jmeter. Интерфейс асинхронный, скрипты, яваскрипты и прочий аякс — а значит недостаточно просто запросить страницу, большая часть данных передается как раз после отработки скриптов, асинхронно. Фейл.
Теперь мы создали монстра: в рамках одного теста с помощью selenium прогоняется сценарий, который автоматически записывается в lmeter. Таким образом мы перехватываем все асинхронные запросы.
Затем он парсится, параметризуется для масштабирования, затем запускается jmeter — это нагрузка.
Отклики jmeter мы не считаем, это бесполезные цифры, мы считаем совершенное им количество бизнес операций — это нагрузка на сервер.
А в это время selenium тест выполняет сценарии и запоминает отклики.
Как-то так.
В случае активного использования аяксов на сайте специнструменты вообще сложно применять.
Специализированные инструменты выигрывают на 2-4 порядка по потребляемым ресурсам в расчете на одного сэмулированного пользователя, поэтому и приходится использовать их, делая модель нагрузки более грубой.