Добрый день, уважаемые тестировщики!)

Отправте или напишите, пожалуйста, пошаговую инструкцию по установке Selenium под Убунту и запуску первого теста на python(например, для популярного поисковика).

А чем вас не устраивает описание из официальной документации?
http://selenium2.ru/....html#webdriver
Есть команда, которую надо запустить для установки (на питоне) и есть маленький скрипт для этого же языка.
Убунта или неубунта - селениуму наплевать.

Ну ещё можно с ant'ом побаловаться и реализовать такую возможность:)

В анте используется "ихняя" реализация тест-раннера. Чтобы его поменять надо написать свой тест-раннер. Т.е. см. мой предыдущий ответ. В IDE, которое тоже реализовывает свой раннер, на самом деле перебираются все методы класса, но только все кроме выбранного не запускаются. Так 4й Junit устроен.

На самом деле в Junit-e есть возможность запускать тесты на основе селекции по аннотациям. Я не пробовал, но вроде бы для этого надо создавать отдельный тест-свит(могу наврать). Как я понял идею, например есть три теста, один с аннотацией @A, другой с @B, а третий с @A и @B. Создаем 2 тест-свита - первый для @А, второй для @B. Итого в первом наборе будут тесты 1 и 3, во втором 2 и 3.

Есть тесты написанные на JAVA с использованием Selenium 2.0

Задача: Настроить запуск тестов с использованием Hudson.
Кто-нибуть может помочь?

А в чем вопрос?
Могу сразу дать подсказку - тесты работать не будут, если агент запущен как windows service, т.к. сервис пускается из под пользователя, который не имеет доступа к экрану.

...
На ручное тестирование времени примерно надо в два раза меньше чем на реализацию этой фичи.

Леша, интересный подход. Надо бы посмотреть реально ли так. Хотя мне почему-то кажется, что реализация все-таки больше в % соотношении должна занимать (даже без учета багфиксов).

Автору топика.
На абстрактную фичу на тестирование затратится абстрактное время. Никакого более конкретного ответа дать нельзя. Могу дать совет, когда оцениваете время, прибавляйте время на написание багов, отчетов и верификацию быстро починенных дефектов. Это отнимает значительное время. Если не написана тестовая документация - то время на планирование тестирования тоже прибавляйте.
Если у вас есть готовый чеклист или набор тесткейзов, то оценить время будет проще.

А вообще прав Майкл Болтон. Он говорит, что суммарное время на тестирование оценить очень просто. Например, если сегодня 7 апреля, а релиз назначен на 21 апреля, то у вас есть ровно 2 недели на тестирование. Все.
И вы не должны приходить и говорить начальству, что я за 2 недели не успею, мне нужно 4 по моим подсчетам. А вы должны сказать, по моим подсчетам нужно 4 недели, за 2 недели мы протестируем это и это, а то и се только поверхностно. При этом есть такие-то риски. Устраивает? И пусть начальство дальше думает.

Может, пока готовится официальная выкладка презентаций/видео, докладчики поделятся своими слайдами здесь?

Я бы вот очень хотела бы получить презентацию двух Сергеев, распечатать себе "Тестировщик, не ной!"

Сделал слайдкаст своего секретного доклада на конференции SQA Days 11. Слайдшара ухитрилась испортить некоторые слайды, но не критично: http://www.slideshar...haL/ss-12710814

Звук взят из видео, за которое огромное спасибо Стасу Фомину. Видео моего выступления тут:

1) Уменьшить кол-во тестов, чтобы они проходили за час. Сделать разбивку на тестовые наборы. Остальные тесты, которые не успевают пройти за час запускать отдельно. Например ночью.
2) Использовать Хром. По моим ощущениям он самый быстрый.
3) Уменьшить количество перестартовок браузера, если таковые есть.
4) Уменьшить размер базы, гонять "часовые" тесты на эталонных данных. Тесты на расширенном наборе данных запускать ночью.
5) Избавиться от дублирующихся тестов, если таковые есть. Убрать большинство негативных проверок в другой тестовый набор.
6) Переиспользовать данные, созданные другими тестами, если они удовлетворяют условиям, но не полагаться на то, что они там уже есть.
7) Отказаться в большинстве тестов от селениума и тестировать не через UI.

Только я вот не пойму, почему на всех емейл сервисах, которые я нашел, нет подчинения этим стандартам. По-че-му? Может плохо искал? Могу предположить, что уменьшение количества символов в логине сделано для оптимизации размеров баз данных. А символы причем? Может следует изменить эти стандарты? Как же тогда производить тестирование или даже как кодировать? Выбрать самый требовательный к адресам сервис и по нему ориентироваться? И я так понимаю, что если какая-то форма не пропускает некоторые валидные емейлы из-за недопустимости адреса, то это не баг?

Интересно, сколько раз надо написать одно и тоже...
RFC - стандарт. Если вы пишете почтовый сервер - будьте добры, соблюдать все это.
Если ваша веб-програмулька не понимает всех возможных вариантов почтовых адресов - то это ХОРОШО!
В этом случае ваша программа не протеворечит этому стандарту. Но в ней будет меньше кода, и меньше ошибок, от исправления которых не станет лучше ни одному живому существу на планете.

Да и это нафиг никому не нужно, поддерживать все эти возможные адреса. И если найдется идиот с ненормальным адресом в 64 символа (или сколько их там) на домене второго уровня - то пусть он идет лесом мимо вашей программы со своим адресом.

Если вы не тестируете почтовый сервер (ну и возможно клиент тоже) - то использование всяких экзотических емэйлов - (а) трата времени и (б) создание ненужных записей в трэкере. Если бы я был программистом и ко мне бы пришли и сказали "first.(")middle.last(")@[IPv6:::12.34.56.78]" - не работает, согласно RFC, давай чинить. Я бы послал куда подальше.

Есть одно исключение, на которое мне как-то указали, зачем это надо делать - чтобы понять, что программа корректно себя ведет на идиотских(но валидных) адресах. А то ведь может дать зарегистрироваться, но потом не дать залогиниться и тд.

PS: кстати [IPv6:::12.34.56.78] - нихрена невалидный Ipv6 адрес - очередной булшит

Вопрос актуальный в контексте собеседования тестировщика.
Я придерживаюсь такой позиции, что не важно как называть эти вещи, главное, чтобы человек умел их применять.
Но иногда сталкиваюсь с ситуацией, когда нужно просто знать точное определение.
Какой, например, должен быть ответ на вопрос "Перечислите методы тестирования, которые вы знаете?"
На сколько я понимаю, методы - это более широкое понятие. Типа метод "белого" и "черного ящика". Техники - это подходы в рамках какого-то метода. Типа Equivalence partitioning и Boundary-value analysis. Технологии - просто слово из рефератов и резюме.
Поправьте, если я ошибаюсь.

Похожего вопроса касались вот тут: http://software-test...9272#entry49272

TestNG или JUnit юзаете?

JUnit

Junit 3.x или 4.x?

Для 4го Junit я гасил браузер через ShutDown hook, инициализировал драйвер перед самым первым тестом, если он еще не инициализирован.
Ну естественно в tearDown остается разлогинивание, а в setUp - логин (как-то так, у меня на самом деле логин выполнялся в базовом классе при инициализации тестового класса).

В третьем Junit должно быть проще реализовать акции которые делаются один раз перед всеми тестами и после окончания. Но я не делал.

Это тестовое задание такое, вопросы задавать некому)
Меня интересует как она вапще должна выглядеть...вот например данный сайт софтве-тестинг.ру
Должна стоять ячейка где в середине сам сайт, от него идут связывающие линии с разделами такими как портал , работа, тренинги, confet&qa ? или как...что собой она подразумевает карта функциональности то? )

Думаю, что пример того, что вам нужно, есть тут на слайде №21
http://www.slideshar...bject-webdriver
Сам таким подходом пользовался тоже. Подход рабочий и не сложный.

...
Опытный тестировщик находит больше багов и это нормально, но если он находит намного больше багов, как быть тогда?
Какова, по вашему мнению, нормальная разница между работой опытного и неопытного тестировщика?

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

Если человек перспективный - то учить. Узнать почему не нашел, может это только на взгляд опытного тестировщика все понятно написано. Попросить погонять тесты и посидеть рядом, пусть тестирует и рассказывает как он размышляет.

Если не секрет, с чем связано стремление использовать именно findElements?

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

Наверное, дело все-таки в том, что findElements удовлетворяется если ничего не найдено, а findElement ждет в течение времени заданного в ImplicitWait пока не появится элемент и затем только падает.

Добрый день!
На сегодняшний день подсчеты приблизительно такие: человеку с опытом от года можно устроиться на работу в тестирование на зп от 35-40тр, если с умением автоматизировать, то начальная планка будет на 5-10тр больше.
Квартиру не в центре и не самую лучшую, но нормальную можно снять за 18-20тр (с учетом ком. платежей). +2тр на дорогу.
Итого остается порядка 15+тр на жизнь.
Что будет через год не известно.

Если у вас есть склонность к программированию, то изучайте джаву и селениум. Знание скриптового языка типа ruby|python|groovy тоже будет плюсом. Если будет опыт работы с SQL, то тоже востребованно. А вообще - почитайте вакансии на spb.hh.ru - какие там требования к технологиям чаще встречаются.
Если с программированием не очень, то такие вещи как HTML, XML знать надо. Неплохо знать разные операционки - винда/линукс и какие-то навыки написания скриптов (batch|shell).
В целом, учитесь дизайнить тесты, взаимодействовать с программистами и оформлять дефекты.

Здравствуйте, уважаемые форумчане!

Хочу узнать, что входит в понятие "знание Linux/*nix". Например, знание bash-a, уметь написать простой скрипт, знание базовых комманд, умение работать без графической оболочки (только с консолью), умение собрать программу и так далее.
Если можно, поделитесь мыслями с указанием "уровня" знания (знание простейших комманд - beginner level, написать скрипт - intermediate, пересобрать ядро - advanced).

Так же интересно какие таски в этой ОС чаще всего приходилось делать, расскажите о вашем опыте.

В конце хочу составить для себя эдакий список-чеклист того, что надо выучить.

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

Начну с конца - тестировщикам "приходится" работать на разных операционках с разными настройками - ведь все зависит от того, как надо тестировать приложение. У нас, например, нет жестких требований по окружению, но корпоративный стандарт - убунта (хотя у меня openSuse).

Теперь о том, что делать - работать приходилось чаще всего. Собственно для этого и нужна операционка.
Поэтому, для начального уровня вам надо научиться устанавливать систему (с обычными "дружелюбными" дистрибутивами это не сложнее чем установка виндов). Научиться работать в системе (с консолью или без - решать только вам). Считайте это начальным уровнем.
Если вы захотите работать быстрее и удобнее (а если линукс это ваша единственная операционка - то это желание придет достаточно быстро), то вы волей-неволей начнете писать скрипты, использовать консоль, научитесь компилировать программы, которых нет в пакетах (обычно они компилируются достаточно легко и все это выглядит страшно только на первый взгляд). Считайте это уже более продвинутым уровнем.
Еще более продвинутым уровнем можно считать, когда вы научитесь настраивать свою машину таким образом, что сможете зайти на нее с любого другого компа по ssh и сделать в консоли все то, что могли бы сделать сидя за ней.

А ядро вам не придется пересобирать (если вы конечно не выберете какой-нибудь gentoo). Людям которым нужно "ехать" это ни к чему, ну а тем кому "шашешчки"...

Могу книгу порекоммендовать - http://www.books.ru/...ruzhenie-82361/
До середины - маст рид.

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

Сомневаюсь :) Люди занимающиеся подбором персонала обычно, в лучшем случае, знают что линукс существует и как-то используется в компании.

2) Научиться работать в консоли можно и в убунте. Просто забудьте, что есть графические конфигураторы, файловые менеджеры и центр установки приложений. Открывайте терминал и пытайтесь делать всё там. Убунта обладает тем преимуществом, что на начальном этапе помогает сберечь нервы и не способствует возникновению антипатии к ОСи.

Вот с этим могу поспорить. Убунта - УГ и вообще бажное УГ. И нервы попортить она как раз может больше чем другие дистры. Я предпочитаю openSuse.

3) Имхо, знание базовых команд не сильно отличается от умения написать скрипт для bash. Скрипт тоже может быть на "базовом" уровне. А вот поднабрать арсенал полезных утилит и опций можно только на практике: почитайте man даже по самым простым командам и убедитесь, что без опыта всё это множество опций освоить нереально.

Абсолютно точно, полностью поддерживаю этот комментарий. Хотите научиться - перебирайтесь на линукс и работайте в нем, если это не критично для тестируемого приложения (ну или пускайте его в виртуалке, если виндовое). Есть рецепт перелезания на линукс, которым я сам и воспольовался - сначала на виндах перейти на кросплатформенные продукты (мс офис - libre office, почтовик - thunderbird итд.) Единственно - нет замены Far-у (есть mc, но это отстой).

если вводишь верно имя, фамилию и дату рожд. НЕуникального пользователя (Петров Петр 03.03.1993) программа выдает ERROR

По мне так это ошибка в программе - должно логинить

спасибо большое за ответы! Вчера программистов уже спрашивала, но они не очень охотно хотят помогать... Пойду-ка надавлю на них пожалуй =)))
потом отпишусь о результатах.

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

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

Судя по описанию у вас и вправду используется JUnit 3.x
Там есть класс TestSuite:
http://www.junit.org.../TestSuite.html
Там есть пример как его наполнять. Также можно создавать разные наборы и включать одни наборы в другие. Беда этого подхода (так же как и того, который тут писали) - это статическое перечисление классов с тестами. Т.е. если вы напишите новый класс, то его надо будет добавить в какой-нибудь набор явным образом.

Чтобы этого избежать могу предложить 2 варианта.
1) Напишите ant скрипт. Стандартная таска junit умеет находить все тесты по маске начиная от единого корневого каталога.
2) Напишите свой класс, реализующий динамический поиск тестовых классов, например DynamicTestSuite, который отнаследуйте от стандартного TestSuite. Вызывайте его прямо из IDE.
Для поиска всех классов надо написать некоторые методы самостоятельно ибо такой богатый язык как джава не предоставляет такой возможности. Я у себя применил именно такой подход и воспользовался кодом, приведённом тут: http://stackoverflow...rationtest-in-m
Только метод не работает как там написано и надо в нем что-то поменять по мелочи. Исключить иннер-классы итд.

Здравствуйте.
Решил использовать "по науке" pageobject и столкнулся с проблемой. Есть у меня отдельно класс какой-либо страницы и класс проверок. Отдельно конечно же существует класс с тест-кейсами и вот тут-то у меня загвоздка, наверное, от плохого знания Явы. Так вот проблема в следующем.
MainWindow mainwndw = new MainWindow(driveк)
mainwndw.buttonclick(mainwndw.submit);

В константах у класса страниц хранятся xpath к элементам на этих страницах, а как же тогда к ним обращаться из тест-кейсов и проверок, неужели только через mainwndw.submit? Нельзя ли это сделать красивей как-то? Спасибо.

Не очень понятно в чем вопрос. Напишите, что вы хотите сделать. Что такое MainWindow?
Почитайте про PageFactory - на мой взгляд использование PageObject без PageFactory - это полумера.
PS: и еще, хоть к делу не относится, почитайте про java code style и название локальных переменных. mainwndw это не по джавовски.

Я использую camstudio,программой довольна,правда есть некоторые нюансы :)

Тоже пользуюсь camstudio. Программа как она должна быть - поставил, нажал кнопку - записывается, нажал другую - складывается на диск.
Умеет записывать регион экрана.
Не пробовал писать со звуком. Не пробовал писать ролики длиннее 10 минут.

Денег никому не надо, я так помнимаю? =))

Никак не претендую на данную работу, только учусь делать все это. Но хотелось бы заметить вот что:
- вам что-то надо, но вы боитесь написать свой e-mail таким образом, чтобы человек захотел с вами связаться.
- вы предлагаете работу, но в вашем профиле "не указал" и "неизвестно".
- вам нужны "профи с именем", но вы приходите на форум, вместо того, чтобы идти на сайт (это не секрет, что те кто профессионально занимается какой-то подобной деятельностью имеют свой сайт).

А тоже самое, но для вебдрайвера?

Я бы для вебдрайвера сделал через EventFiringWebDriver используя методы beforeOnclick и afterOnClick, которые вызываются последовательно, а данные о странице можно получить прямо там, т.к. одним из параметров методов является объект WebDriver-а.
Это позволит не делать специальных тестов вообще и при этом регистрировать время ожидания каждой загрузки страницы. Что, в свою очередь, даст возможность собирать статистику как для разных страниц, так и для одной и той же страницы в зависимости от её наполнения и условий проводимого эксперимента.

Попытайтесь неявное ожидание использовать:
Long timeout = 10;
driver.manage().timeouts().implicitlyWait(timeout, TimeUnit.SECONDS);

Только надо учитывать, что такой таймаут установится для ожидания _всех_ элементов, разыскиваемых драйвером при помощи findBy. Если это подходит - то наверное нет ничего сложного для написания такого метода.

У меня есть 2 таймаута короткий и длинный. Длинный я использую только в определенных местах. А короткий - установлен по умолчанию. Т.е. после длинного ожиания я сбрасываю значение обратно в короткое ожидание, чтобы тесты быстрее падали в случае ошибки. В случае, если элемент есть сразу, то разницы нет никакой, driver делает опрос каждые 500мсек, пока не найдет или пока не вывалится по таймауту.

Что не так с параллельностью в Руби?

Все понял, но осталось нек-рая неудовлетворенность документацией на Selenuim,
к-рая умалчивает о проверках и "игнорирует" JUnit.
Правда, там еще есть полезный раздел 7, но и он неполон.
Хотя, и это объяснимо: документация описывает ср-ва WebDriver, а построение тестов - шире и
предполагает применение JUnit или подобного инструмента в случае использования Java,
или дополнительного кода (или пакетов) для python, ruby и пр.
Впрочем, всегда можно обойтись и базовыми ср-вами языка.

Судя по вашему комментарию, все-таки не все поняли. Ожидать от документации селениума описания того как работает junit не стоит. Это все-равно, что ожидать увидеть в документации к дрели, которая делает дырки, описание того как правильно пользоваться лазерным уровнем для верного определения места где эти дырки быть должны.
Например. Недавно одни и те же тесты для сравнения я реализовал на связке selenium + ruby + одна из технологий (просто руби без дополнений, Test::Unit, Cucmber, FitNesse и RSpec). И еще rake пускалку приделал. Спрашивается какая технология должна какую описывать в своей документации?

И построение селениум тестов на java вовсе не предполагает использование junit. Только автор тестов знает что он будет использовать, авторы селениума не знают и не хотят гадать или заставлять. Selenium WD - это, по большому счету, только лишь автоматическая генерилка пользовательских событий (клик мышки, нажатие на кнопку клавиатуры, переход на страничку) в браузере. И все.

Вы можете использовать селениум вовсе не для тестирования, а для отсылки спама или для написания автоматических коментов в этот форум.