Революция веб-технологий привела к появлению "вечнозеленых" браузеров. Они обновляются автоматически, как только выходит обновление, зачастую не требуя никакого вмешательства пользователя.
Благодаря этому новшеству веб-приложения наконец смогли забыть про необходимость поддержки древних браузеров. Программное обеспечение всегда росло и развивалось, но после появления таких браузеров оно понеслось вперед с сумасшедшей скоростью. Добавьте к этому расцвет agile-разработки, и вы получите рекордные скорости развития программных и технологических инноваций.
Добрый день! Возможно кто-то сталкивался с подобной проблемой. Написал кейс в selenium ide, тест работал и проблем с элементами не было. Тест я начал переносить в testNg и тут столкнулся с проблемой, что webDriver не находит элемент по css селектору.
Ошибка:
org.openqa.selenium.TimeoutException: Timed out after 20 seconds waiting for presence of element located by: By.cssSelector: a[class="gi-icon-caret-left2"]:contains(Мои роли)
Падает везде, где есть кириллица. Для меня такая проверка удобна тем, что я сразу проверяю наименование элемента, хотелось бы по-возможности избежать разбиения этого шага на 2- ожидание элемента по другому селектору и ассерту имени элемента.
Возможно есть смысл вообще отказаться от переноса? Но тогда проект сервера непрерывной интеграции(Team City) будет у меня похож на смесь бульдога с носорогом, так как у нас на UI пока не все данные можно создать необходимые для тестирования и я использовал TestNg для создания данных рестами.
Во время тестирования ресурса объём ОЗУ потребляемой JMeter'ом постоянно растёт, даже при условии что число потоков остаётся неизменным.
Доходит до определённого значения, примерно 1,8 Гб, затем начитает грузить ЦПУ до предела. После загрузки ЦПУ начинают отваливаться потоки, вплоть до полной остановки процесса тестирования.
Вопрос: На какие инструменты тратиться ОЗУ во время тестирования?
JMeter 3.0
Используются: HTTP Request, __CSVRead(), Summary Report, jp@gc - Active Threads Over Time, jp@gc - Response Times Over Time, jp@gc - Transactions per Second, jp@gc - Composite Graph.
Заметил что при появлении нового тестировщика на проекте, частенько находятся какие-то баги (как правило минорные) которые из цикла в цикл упускались старой командой.
На сколько я понимаю, это такой себе фактор человеческой психики, заключающийся в том что люди просто устают от постоянных регрессий на одном и том же проекте и не находят многих багов, которые выжили после многократных "обработок пестицидами"
На днях, попробывал на своем проекте привлечение свежего тестировщика на парочку дней. Похоже что какой-то результат дало. Таки нашел десяток минорчиков. Прада и вопросов задавал массу. В результате получили:
+ нашли некоторые баги которые выжили после "обработок пестицидами",
- потратили определенное время и силы для того чтоб тестировщик влился в проект и потестил
Какие вы знаете методы для борьбы с "жуками" пережившими "чистку пестицидами"?
И как вы относитесь к ротации тестировщиков между проектами на короткий срок (или односторонним вовлечением в проект свежих глаз)?