На прошлой неделе компания Microsoft провела конференцию ALM Summit, один из четырех треков которой был посвящен тестированию программного обеспечения. Судя по отзывам в твиттере, одним из наиболее интересных выступлений в этом треке был рассказ Алексея Баранцева "Управление требованиями, тестами, дефектами: чему нас учит наука кибернетика". Записи этого и других выступлений вы можете найти на сайте конференции.
За прошедшие несколько лет инструмент автоматизации тестов для веб-приложений Selenium приобрел фантастическую популярность.
Владение этим инструментом стало одним из обязательных умений для тестировщика-автоматизатора, достаточно посмотреть динамику вакансий, чтобы убедиться в этом.
Если вы хотите считаться профессионалом в области автоматизации тестирования, строчка "я знаю Selenium" обязательно должна присутствовать в вашем резюме.
Простые тесты можно создавать при помощи рекордеров Selenium IDE или Selenium Builder. Но при увеличении объёма и сложности тестов этот подход теряет свою эффективность и привлекательность. Профессионалы пишут тесты на языках программирования.
Если до этого Вы не занимались автоматизацией и не знакомы с Selenium, то лучше начать с курса Selenium 2.0: стартовый уровень.
Python входит в число четырёх языков программирования, которые официально поддерживаются Selenium (наряду с Java, Ruby и C#).
Также существует аналогичный тренинг на языке Java.
Этот курс предназначен для тех, кто хочет освоить программный интерфейс Selenium 2.0 и научиться разрабатывать автотесты для веб-приложений на языке программирования Python.
После прохождения тренинга учащийся будет уметь разрабатывать автоматизированные тесты для веб-приложений на языке программирования Python с использованием инструмента Selenium 2.0, в частности:
владеть базовым набором команд Selenium 2.0, эмулирующих действия пользователя (ввод текста, клики мышью),
владеть расширенным набором команд Selenium 2.0, эмулирующих действия пользователя (клавиатурные сочетания, перетаскивание элементов мышью и другие),
владеть техниками поиска (идентификации) элементов в окне браузера,
уметь обеспечивать стабильность и скорость выполнения тестов за счёт правильного использования ожиданий,
уметь выполнять проверки фактических данных, полученных из браузера, на соответствие ожидаемым значениям,
владеть основными шаблонами проектирования тестов, в том числе шаблоном PageObject,
уметь выстраивать архитектуру тестов таким образом, чтобы тесты можно было легко модифицировать и добавлять новые (при небольшом количестве тестов),
уметь организовывать инфраструктуру для запуска тестов на сервере непрерывной интеграции.
Статья подготовлена Александром Хозей и Андреем Дзыней в рамках подготовки к тренингу Тестирование мобильных приложений 2.0, который начнется 28 февраля.
Тестирование работы с разными типами и качеством связи является одним из столпов тестирования мобильных приложений. Смартфон - личная вещь и находится с владельцем практически всегда: будь то поездка в городском транспорте или, например, на экскурсии в пещеры. Мобильные приложения не должны подводить, особенно в трудную минуту.
Пример из жизни. Вы установили приложение одной из авиакомпаний, с помощью которого можно осуществлять электронную регистрацию и посадку на борт. Регистрация была совершена дома, а телефон установлен в режим ожидания. По прибытию в аэропорт, где необходимо показать билет - Вы разблокировали экран. В момент подключения к открытой точке доступа аэропорта (в таких точках доступа необходимо авторизоваться в браузере) приложение принялось за обновление закешированной страницы и скрыло ее за экраном активности (в худшем случае, закрылось после сбоя). Работник аэропорта не может считать штрих-код с экрана, вы безуспешно пытаетесь отыскать сохраненную страницу, очередь сзади начинает роптать. В конечно итоге вам приходится разрешать проблему в индивидуальном порядке с представителями авиалиний. Неприятная ситуация.
Очевидно, что над сетевой частью и кешированием недостаточно тщательно поработали. Давайте подумаем какие проверки необходимы, чтобы избежать подобных ситуациях в собственных продуктах.
Статья подготовлена Александром Хозей и Андреем Дзыней в рамках подготовки к тренингу Тестирование мобильных приложений 2.0, который начнется 28 февраля.
Тестирование работы с разными типами и качеством связи является одним из столпов тестирования мобильных приложений. Смартфон - личная вещь и находится с владельцем практически всегда: будь то поездка в городском транспорте или, например, на экскурсии в пещеры. Мобильные приложения не должны подводить, особенно в трудную минуту.
Пример из жизни. Вы установили приложение одной из авиакомпаний, с помощью которого можно осуществлять электронную регистрацию и посадку на борт. Регистрация была совершена дома, а телефон установлен в режим ожидания. По прибытию в аэропорт, где необходимо показать билет - Вы разблокировали экран. В момент подключения к открытой точке доступа аэропорта (в таких точках доступа необходимо авторизоваться в браузере) приложение принялось за обновление закешированной страницы и скрыло ее за экраном активности (в худшем случае, закрылось после сбоя). Работник аэропорта не может считать штрих-код с экрана, вы безуспешно пытаетесь отыскать сохраненную страницу, очередь сзади начинает роптать. В конечно итоге вам приходится разрешать проблему в индивидуальном порядке с представителями авиалиний. Неприятная ситуация.
Очевидно, что над сетевой частью и кешированием недостаточно тщательно поработали. Давайте подумаем какие проверки необходимы, чтобы избежать подобных ситуациях в собственных продуктах.
В феврале в Твери запускается серия мастер-классов от специалистов компании EPAM Systems - EPAM IT Magazine.
Первый выпуск "UNICODE: Трудности перевода" от эксперта в области .Net программирования Андрея Понякова. Приглашаем всех в Интернет-Центр ТвГУ (Садовый переулок, 35, 1 этаж). Дата: 18 февраля, 15:40 Вход бесплатный
Два раза в месяц новый выпуск = новый мастер-класс! Планируются выступления как разработчиков так и тестировщиков.
Стоит задача нагрузить сайт из логов сервера. Сайт довольно производительный и держит до 2000 запросов в секунду. По крайней мере такая производительность была получена с помощью инструмента wcat. Хотим перепроверить на jmeter. Но выяснилось, что даже с использованием Acess Log Sampler не удается сгенерировать достаточную нагрузку на сервер. Проблема - в скорости чтения из файла, который считывается построчно. В итоге перед отправкой очередного запроса получается существенная задержка и сгенерировать нужное количество запросов не получается. Запуск сразу нескольких инстансов jmeter проблемы не решает, т.к. с определенного момента скорость чтения с диска становится препятствием на пути наращивания нагрузки.
Выход видится только один - считывать каким-то образом файл с запросами полностью в память и потом к нему обращаться. Можно ли это как-то сделать средствами Jmeter? Может быть, есть какие-то плагины для считывания запросов из файла помимо Acess Log Sampler?
Есть необходимость за-mock-чить Oracle БД таким образом, чтобы модуль системы, подключался к mock БД и при возникновении события обращения к БД от модуля я точно знал, что конкретно модуль хочет от неё получить и/или записать.
Собственно сама проблема заключается в том чтобы сделать фэйковый коннектор БД которым я смогу управлять (задать стандартные ответы БД и отслеживать обращения)
Может кто подсказать подходящий инструмент на python чтобы реализовать этот функционал если это возможно с приемлемыми трудозатратами.