"Младших тестировщиков производительности" не бывает. Зато бывают люди, которые начинают заниматься тестированием производительности.
(с) Скотт Барбер (aka The Perf Guy)
В тестировании компьютерных программ есть "общедоступная" область функционального тестирования, куда доступ открыт всем желающим, и есть целый ряд областей с достаточно высоким "порогом входа", и тестирование производительности находится в их числе.
Для этого вида тестирования требуется хорошее владение оружием, его голыми руками не возьмёшь. Во-первых, нужно само оружие -- тестирование производительности обязательно требует умения пользоваться специальными инструментами. Во-вторых, нужно тщательно изучить соперника -- необходимо хорошее понимание протоколов взаимодействия тестируемой программы с внешним миром и её внутренней физической и логической архитектуры. Ну и конечно же нужно владеть приёмами -- знать какую нагрузку и как подать на тестируемое приложение, и на что смотреть, чтобы выявить проблемы с производительностью.
На тренинге мы будем учиться обращаться с этим оружием:
познакомимся с инструментами, предназначенными для генерации нагрузки и для мониторинга различных характеристик производительности,
освоим способы использования этих инструментов для генерации нагрузки различного вида,
изучим типовые архитектурные шаблоны построения приложений и связанные с этим источники потенциальных проблем с производительностью,
рассмотрим способы выявления проблем с производительностью на основе анализа результатов мониторинга.
Для практических демонстраций и для выполнения домашних заданий будет использоваться инструмент JMeter.
Онлайн-тренинг с практической работой, 10 занятий, начало 19 декабря.
Мы в очередной раз провели опрос про популярность языков программирования среди тестировщиков-автоматизаторов. И вновь, как и в прошлый раз, ожидаемо с большим отрывом победил язык Java. Но теперь Python и C# подобрались к лидеру уже ближе, проиграв не в три раза, а всего лишь в два :)
Но нельзя не признать, что инструменты разработки, создаваемые компанией Microsoft, эволюционируют семимильными шагами. Поэтому мы решили, что пришло время запустить тренинг "Программирование на C# для тестировщиков", аналогичный тренингу по языку Java.
Этот курс предназначен для обучения тестировщиков программированию на языке С# (для тех, кого интересует программирование на Java у нас есть другой курс).
Да, именно тестировщиков. Обучение программированию не сводится только к изучению языка программирования. Построение правильной архитектуры, использование фреймворков и библиотек, владение инструментами разработки и отладки -- это тоже часть “умения программировать”. Поэтому в этом курсе детально рассматриваются именно те возможности языка и вспомогательных библиотек, которые наиболее востребованы при разработке автотестов, в том числе при тестировании веб- и windows-приложений через пользовательский интерфейс.
Весь изучаемый материал будет демонстрироваться на одном сквозном примере -- мы будем разрабатывать на языке C# автоматизированные тесты для веб-приложения, используя Selenium WebDriver. Начав с простого теста, записанного “рекордером”, мы будем постепенно усложнять архитектуру тестового набора, добавлять и усиливать проверки в тестах, дополнять тесты генераторами тестовых данных. Основной акцент будет сделан не на алгоритмы, а на изучение различных полезных библиотек и фреймворков, а также шаблонов проектирования, позволяющих организоваэ ь код автоматизированных тестов таким образом, чтобы его было легко модифицировать и расширять.
Ни для кого не секрет, что наши цены являются одними из самых низких среди цен на тренинги вообще и на тренинги по тестированию в частности, мы редко повышаем цены. Весной мы запланировали, что осенью проведем индексацию цен на уровне инфляции.
Но в связи с последними событиями, с нестабильностью ситуации, мы поняли, что сейчас совсем не подходящее время для повышения цен.
Очень многие наши постоянные клиенты именно сейчас хотя получать новые знания и навыки, чтобы оставаться конкурентоспособными. Лучшее вложение в непростые времена – это вложение в себя, эти вложения точно не пропадут и окупятся. Кризис -- это время, когда активные люди делают мощный скачок вперед, в то время как другие сидят и боятся.
И мы решили: держим цены для физических лиц на прежнем уровне.
Для юридических лиц мы подняли цену на 15%, но компенсировали поднятие цены ликвидацией всех комиссий за оформление документов, теперь мы это будем делать за свой счет. А при регистрации сразу трех участников на один тренинг цена для юридических лиц остается старой. Таким образом мы стараемся держать цены и для юридических лиц на старом уровне.
Мы не знаем, что будет дальше и как долго мы сможем сдерживать цены на обучение, но пока цены остаются старые.
Пришел в новую компанию, влился в текущий проект и все поначалу было светло и безоблачно...
Столкнулся с такой ситуацией. ТЗ и функциональные требования есть, однако на деле нет ни одного документа отображающего реальное состояние реализованного функционала.
И когда пришел документ по приемочному тестированию, тут настал эпичный момент:
Клиент хочет проверить функционал который не реализован, разработчики тоже не в курсе должен этот функционал быть или нет.
Пришел к такому умозаключению(возможно не к лучшему), написать документ полностью описывающий разработанный функционал.
И желание и время есть на этот документ, но все же хотел узнать мнение "старичков".
Доброго времени суток, коллеги! Хотел бы спросить у опытных тестировщиков про самодостаточность автотестов, как правильно делать, или в каждом приложении свои правила.
Допустим в приложении существует регистрация пользователя, авторизация, набор действия с пользователем.
Нужно ли для каждого набора действия регистрировать нового пользователя, или достаточно создать нового пользователя один раз при прогоне и использовать его в дальнейшем для всех наборов действий? Возможна ли зависимость тестов от одного ранее выполненного теста.
Подскажите, пожалуйста, возможна ли фильтрация "AND" для JBehave?
Стоит задача проиндексировать каждую story различными мета-метками и передавать через build-Agents несколько параметров, которые будут запускать story, если в ней есть все мета-метки переданные в параметрах?
Плюс к тому хочется одновременно использовать и "OR" механизм. По определенной метке идет разбитие тестов между build-Agents.
Выполняю хранимую процедуру (ХП) следущим образом:
var result;
var cmd = ADO.CreateADOCommand();
cmd.ConnectionString = "Provider=SQLOLEDB.1;Server=******;Database=17;User Id=***;Password=***";
cmd.CommandType = cmdText;
cmd.CommandText = "exec dbo.checkEQ '"+DocRef+"'";
result = cmd.Execute();
Результат выполнения ХП присваиваю в result. ХП выполняется долго из-за этого тест падает по ошибке в строке 6, текст ошибки: "Время ожидания запроса истекло
". Подскажите как избежать этой ошибки (дождаться результатов выполнения хранимки)? Заранее спасибо.
Игровое подразделение Mail.Ru Group занимается созданием популярных компьютерных игр, оперированием игровых проектов, созданных зарубежными разработчиками, а также продюсирует создание игровых проектов внешними студиями разработки.
Мы ищем профессионального QA-специалиста, который возглавит и будет управлять контролем качества игровых проектов, создаваемых для нашей компании внешними разработчиками.
Обязанности:
контроль качества разработки;
участие в создании регламентов и процедур разработки;
участие в принятии решений об одобрении различных фич;
снятие производственных рисков;
приемочное тестирование;
организация работы аутсорс-команды.
Требования:
опыт работы в области тестирования или контроля качества программного обеспечения;
техническое или математическое высшее образование;
опыт программирования на С++ или Java от полугода;
умение устанавливать причину дефекта и пояснять ее;
опыт работы в проектных командах от 20 человек;
хорошие коммуникативные навыки и умение понятно формулировать задачи.
Условия работы:
комфортно работаем: просторные опенспейсы, звукопоглощающие панели, несколько десятков переговорных, дополнительные мониторы, мощное железо и макбуки, если нужно;
вкусно кормят: в офисе есть ресторан с завтраками и обедами, а на каждом этаже есть 2 кухни, где всегда есть фрукты и ягоды, чай, кофе, кола и, конечно, печеньки;
приятно отдыхаем: большая лаунж-зона, массажные кресла, бар со свежевыжатыми соками, качели, уголки с пледами и подушками, где можно отдохнуть, игровые приставки, кинотеатр;
занимаемся спортом: бесплатный фитнес-зал в офисе (со всеми тренажерами и, конечно, душевыми), теннисные столы и даже футбольное поле;
легко добираемся: мы находимся в пяти минутах ходьбы от м. «Аэропорт». Для тех, кто предпочитает добираться на работу на машине, у нас есть 5-этажная подземная парковка. И да, на ней есть места;
профессионально развиваемся: в нашем офисе регулярно проходят семинары, тренинги, мероприятия для разработчиков – Moscow.pm, Moscow Django Meetup, CocoaHeadsMoscow, UX-среда и др. Конечно, мы отправляем сотрудников и на внешние профессиональные мероприятия.
Новым сотрудникам из других городов/стран с удовольствием поможем с переездом в Москву.
Почта для резюме/вопросов: naumenko@corp.mail.ru (Алексей Науменко)
Есть форма с кнопками Сохранить и Отменить. Был баг, что при нажатии кнопки Отмена все равно данные сохранялись. Надо написать скрипт для проверки который заполнял все поля, жал на Отменить и затем проверял что запись не создана. Например запись можно проверить по:
@FindBy (xpath="/html/body/div[2]/div/div[2]/section/div/div/div/div/div/div/div[2]/div[2]/div[1]/div/button")
public WebElement Record;
Как грамотно и правильно написать условие на проверку if, чтобы если элемент Record есть на странице что скрипт валился и давал ошибку?
public boolean verifyDeleteRecordIsDisplayed()
{
if (!Record.isDisplayed())
{
}
return true;
}
Сейчас баг исправили и записи не создаются. Т.е. Record не будет найден. Можно как-то написать грамотно в if: если элемент не найден - то ок, если он есть - то скрипт не выполняется дальше и выдает ошибку? Спасибо.