checo

Полистайте вот эту книгу, например

http://svyatoslav.bi...e_testing_book/

Могу порекомендовать Gson. Можно парсить в классы, а можно вынимать отдельные элементы динамически.

Видно же, что рекурсия бесконечная. В любом цикле или рекурсии должно быть условие прерывания (обычно - самый максимальный таймаут, что готовы ждать), тут ничего такого нет.

Если элемент так и не появится, мы дождемся StackOverflowException, вот только с интервалом вызовов в минуту ждать его будем ооочень долго.

Если координаты постоянные и спрайты шариков всегда одинаковые (нет анимации, например), то брать скриншот и потом средствами джавы смотреть цвет пикселей по координатам.

Если есть анимация, и могут быть одинаковые цвета пикселей у шариков с разным цветом (например, белые блики), брать несколько пикселей с области отображения шарика, усреднять RGB значения и определять, к какому цвету ближе полученный оттенок.

В результате, у нас будет матрица 5х5 со значениями цветов.

Ну, а как собрать комбинацию - это отдельный алгоритм.

Любые некорректные сценарии работы покупателя в магазине или то, что дает негативный результат какой-то операции. По описанию предполагаю, что это интернет-магазин, тогда могут быть такие примеры:

• Ввод некорректных данных. Даже если валидация покрыта требованиями, это всё равно негативный кейс.
• Кейсы с разрывом связи. Например, что заказ не может быть закрыт при разрыве. Хотя, здесь более важен позитивный кейс - например, что состав корзины или недооформленный заказ будут по прежнему доступны при возобновлении соединения с сервером.
• Тоже ввод некорректных данных, но не со страницы, а через запросы (попытка взлома).
• Конкурентное резервирование оставшихся единиц товара разными покупателями. Кто-то из них получит отказ, и это негативный кейс. и т.д.

Ну так логично.

В проекте имеется класс SelectElement, пустой неимплементированный шаблон. Скорее всего, сами его и создали по неосторожности.

И берется именно он, а не из Селениума.

Иначе бы в коде теста была директива ```using OpenQA.Selenium.Support.UI```, где и лежит настоящий SelectElement.

И еще наводящий вопрос: если уже запускаете нагрузку, а не отладку в один тред, то нет ли такого, что все треды пытаются работать под одним логином?

 

Не очень поняла ваш наводящий вопрос ) : вы интересуетесь не запускала ли я нагрузку на все рабочие ветки одновременно, и не идет ли запрос к одному и тому же сайту, так? Нет, веток у меня много, но я их одновременно не запускаю, только конкретную.

 

Ну, это просто было предположение. Теоретически, ошибка 403 может возникать, если ресурс уже открыт пользователем, и потом его из другого потока под тем же пользователем пытаются получить.

Раз пишете про замену ${token}, то про поиск динамических параметров советовать не нужно - тема уже знакомая

Тогда, совет на все времена, простой, как кирпич - поискать разницу с реальным трафиком из браузера. Это долго, но когда проблема и без того долго не решается, делать нечего.

Просто сравнить все заголовки, контент - на каком этапе возникает расхождение или появляются уникальные для сессии параметры. Лучше взять какой-нибудь прокси, независимый от JMeter, и трафик самого JMeter'а тоже пустить через него. Например, в Fiddler можно посмотреть сырые нераспарсеные запросы и ответы, иногда по ним сразу видно разницу.

И еще наводящий вопрос: если уже запускаете нагрузку, а не отладку в один тред, то нет ли такого, что все треды пытаются работать под одним логином?

https://www.soapui.o...properties.html

параллельно я прохожу курс по пайтону на codeacademy

Кстати, для целей автоматизации курс на Codecademy ну очень слабенький. Например, тема модулей не освещается и еще много чего.

Вот есть очень хороший курс для начинающих. Минус в том, что код не надо писать, однако покрытие тем мне понравилось, и проверочные тесты с умом сделаны.

http://www.sololearn.../Course/Python/

1) Всегда всё зависит от запросов работодателя. Для начала, нужно ориентироваться на какую-то конкретную технологию. Посмотрите, какие вакансии вам ближе. Если нужно писать/поддерживать автотесты, например, на Java, или Python, будут предже всего искать человека со знанием этого языка. Можно просто для себя сделать небольшой демо-проект, чтобы и при случае показать, и самому быть уверенным, что сумеете написать тестовый фреймворк.

А так, бывает по-разному:

- иногда готовы учить: если видят, что человек что-то может сделать в одной технологии, дадут время на освоение новой

- иногда готовы выслушать ваши предложения, и можно самому выбрать используемые средства

- иногда сразу говорят "фи", если чего-то не знаешь, но это называется "не повезло", иди же нашли более подходящего кандидата

2) Именно знания ОС обычно не надо. Если проект виндовый, могут вообще ничего не спросить. Если где-то сервера на никсах, пригодится знание bash и основных команд. Важнее знание базовых технологий: HTML/CSS (если это веб), работа с сервисами, настройка сети, VCS, CI.

3) С тестированием мобильных не помешает быть знакомым, но необязательно с этого начинать. Разве что идете в организацию, у которой профиль связан с мобильными. Важнее освоить, с одной стороны, написание тестовых проектов (а они по структуре непохожи на девелоперские), с другой - основы процесса тестирования, виды тестирования, посмотреть, как вообще пишутся тест-кейсы (не авто, а обычные).

Вообще, по сравнению с фронтендом придется сменить вектор развития. Девелопер часто концентрируется на какой-то технологии, глубоко изучает ее, и затем продает себя как специалиста в этой области. Например, столько-то лет пишу на JS, досконально знаю такие-то фреймворки, умею быстро делать страницы с разными хитрыми элементами.

Автоматизация - ниша небольшая, а проекты приходят разные. В результате, нужно быть знакомым с большим количеством технологий, но очень глубоких знаний не требуется. Главное - уметь использовать простые и эффективные паттерны. Зато нужно быть готовым, что сегодня тестируешь фронтенд и пишешь на стандартном Selenium+Java, через месяц переведут на проект, где будет тестирование сервисов на C#, еще через полгода - будут мобилы и Appium плюс параллельно поддержка CI со скриптами на PowerShell+Perl+VisualBasic и далее в том же духе.

Мне на практике было удобнее не фичи выбирать, а фильтровать тесты по тэгам.

Тэг можно навесить как на отдельный тест, так и на фичу. В итоге, в параметре features указываешь корневую папку, где лежит вообще всё. А дополнительно в командной строке в cucumber.options укаываешь нужные тэги.

Важная особенность: ключей "--tags" может быть несколько, а в одном ключе можно указать несколько тэгов через запятую. Так вот, при перечислении в одном ключе выборки объединяются (OR), а для разных ключей применяется пересечение (AND). В доках этого не видел, выяснил экспериментально.

Из платных и красивых, например, Telerik Test Studio

Из бесплатных и хардкорных, например, White и более новый Winium.

Про BadBoy не подскажу, не юзал.

В JMeter'е надо поймать тот запрос, по которому приходят эти кнопки: либо саму страницу, либо какую-то подкрузку данных через AJAX. Соответственно, распарсить в постпроцессоре и извлечь нужный компонент в переменную.

Как это делать - вопрос чисто технический, зависит от бизнес-логики приложения. Может, регулярки хватит, а может, и скрипт писать.

Простите, а с каких пор строки в PHP конкатенируются через +? Вы хоть проверьте, что за локатор в итоге получается.