За прошедшие несколько лет инструмент автоматизации тестов для веб-приложений Selenium приобрел фантастическую популярность.
Владение этим инструментом стало одним из обязательных умений для тестировщика-автоматизатора, достаточно посмотреть динамику вакансий, чтобы убедиться в этом.
Если вы хотите считаться профессионалом в области автоматизации тестирования, строчка "я знаю Selenium" обязательно должна присутствовать в вашем резюме.
Простые тесты можно создавать при помощи рекордеров Selenium IDE или Selenium Builder. Но при увеличении объёма и сложности тестов этот подход теряет свою эффективность и привлекательность. Профессионалы пишут тесты на языках программирования.
Если до этого Вы не занимались автоматизацией и не знакомы с Selenium, то лучше начать с курса Selenium 2.0: стартовый уровень.
C# входит в число четырёх языков программирования, которые официально поддерживаются Selenium, наряду с Java, Ruby и Python (и у нас есть тренинги на языке Java и Python, аналогичные данному).
Этот курс предназначен для тех, кто хочет освоить программный интерфейс Selenium 2.0 и научиться разрабатывать автотесты для веб-приложений на языке программирования C#.
После прохождения тренинга учащийся будет уметь разрабатывать автоматизированные тесты для веб-приложений на языке программирования C# с использованием инструмента Selenium 2.0, в частности:
владеть базовым набором команд Selenium 2.0, эмулирующих действия пользователя (ввод текста, клики мышью),
владеть расширенным набором команд Selenium 2.0, эмулирующих действия пользователя (клавиатурные сочетания, перетаскивание элементов мышью и другие),
владеть техниками поиска (идентификации) элементов в окне браузера,
уметь обеспечивать стабильность и скорость выполнения тестов за счёт правильного использования ожиданий,
уметь выполнять проверки фактических данных, полученных из браузера, на соответствие ожидаемым значениям,
владеть основными шаблонами проектирования тестов, в том числе шаблоном PageObject,
уметь выстраивать архитектуру тестов таким образом, чтобы тесты можно было легко модифицировать и добавлять новые (при небольшом количестве тестов),
уметь организовывать инфраструктуру для запуска тестов на сервере непрерывной интеграции.
Всем известна народная мудрость: «Встречают по одёжке, а провожают по функционалу». Что бы ни умел ваш продукт, им не будут пользоваться, если он недостаточно удобен и интуитивно не понятен. Возможно, его безумно полезный и жизненно необходимый функционал просто не найдут!
Но что делать? Как оценить удобство? Как его измерить? Как избежать субъективности в оценках? Как сделать продукт, который будет нравиться вашим пользователям, а не тестировщикам? Как донести до руководства необходимость внесения изменений?
Ответить на все эти вопросы далеко не так просто, как кажется. Наука человеко-машинного взаимодействия активно развивается, и если вы хотите выпускать действительно качественные продукты, которые будут радовать ваших пользователей, вы должны глубоко в ней разобраться!
О том, как правильно тестировать удобство использования, вы узнаете в этом онлайн-курсе.
Как-то раз, молодой тестировщик пришёл к более опытному и успешному с вопросом:
- Я так стараюсь, я так много тестирую, но всё равно я не успеваю протестировать всё!
Что же мне делать? Неужели, пропускать баги – это нормально?
- Нет, - отрешенно ответил коллега.
- Но что же тогда мне делать? Тестировать больше? Тестировать по ночам?
- Тоже нет, - уже менее спокойно продолжал свои ответы опытный тестировщик.
- Но как иначе? Как же мне тогда успевать тестировать всё?
- Ничем не могу помочь! - молвил гуру, и углубился в чтение сайта.
"Тест-анализ" - прочитал молодой человек на мониторе и подумал: "Вот эгоист, а? Нет бы нормально ответить!!!".
Чтобы делать свою работу лучше, а не больше, требуются качественные изменения, а не количественные. Но что делать, если способы для этих самых качественных изменений пока не известны? Если вы не знаете, какие техники помогут в вашем случае сократить количество тестов? Если вы не знакомы с инструментарием, который помогает экономить время на генерации тестовых наборов, на поддержке документации? В этом случае приходится увеличивать усилия, перерабатывая или расширяя команду, но получая на выходе крохотный прирост в результате.
Мы предлагаем уйти от этой порочной практики. Как сказал Стив Джобс, «работать надо не 12 часов, а головой». Поэтому, на курсе «Школа Тест-Аналитика» мы собрали и заботливо для вас упаковали только те знания, которые позволяют получить качественный прирост в результате. Что из этого получилось – посмотрите в Программе курса.
«Курс, практически, перевернул мое сознание в сфере тестирования. До него я ничего не слышала про тест-анализ, была только куча разной информации, плавающей где-то на поверхности… В общем, ощущение, что у меня был сломан мозг, а мне его вправили!»
Один из отзывов на Школу Тест-Аналитика
Хотите записаться? Не торопитесь! Для начала, оцените, готовы ли вы к участию в курсе:
Курс рассчитан не на новичков, так что записывайтесь, только если у вас есть не менее 1-2 года активного стажа в тестировании
Помимо ознакомления с теорией, вас ждёт объёмная практическая часть – не стоит регистрироваться, если вы не сможете выделить на обучение как минимум 5-6 часов в неделю
"Младших тестировщиков производительности" не бывает. Зато бывают люди, которые начинают заниматься тестированием производительности.
(с) Скотт Барбер (aka The Perf Guy)
В тестировании компьютерных программ есть "общедоступная" область функционального тестирования, куда доступ открыт всем желающим, и есть целый ряд областей с достаточно высоким "порогом входа", и тестирование производительности находится в их числе.
Для этого вида тестирования требуется хорошее владение оружием, его голыми руками не возьмёшь. Во-первых, нужно само оружие -- тестирование производительности обязательно требует умения пользоваться специальными инструментами. Во-вторых, нужно тщательно изучить соперника -- необходимо хорошее понимание протоколов взаимодействия тестируемой программы с внешним миром и её внутренней физической и логической архитектуры. Ну и конечно же нужно владеть приёмами -- знать какую нагрузку и как подать на тестируемое приложение, и на что смотреть, чтобы выявить проблемы с производительностью.
На тренинге мы будем учиться обращаться с этим оружием:
познакомимся с инструментами, предназначенными для генерации нагрузки и для мониторинга различных характеристик производительности,
освоим способы использования этих инструментов для генерации нагрузки различного вида,
изучим типовые архитектурные шаблоны построения приложений и связанные с этим источники потенциальных проблем с производительностью,
рассмотрим способы выявления проблем с производительностью на основе анализа результатов мониторинга.
Для практических демонстраций и для выполнения домашних заданий будет использоваться инструмент JMeter.
Проблема while controller в сценарии вызывается один раз, в последующем прохождении сценария он не вызывается. Может кто сталкивался, в чем причина может быть. Как вариант переменная, указанная в condition определяется не так.
Вопрос можно ли написать свой свой запрос с циклом jsr & bsf с преферансом и поэтессами?
Структура цикла : в while controller отправляется запрос, регулярной достается код ответа, когда ответ будет с кодом 302 цикл закончится.