сам искал такое.
Если найдете, сообщите пожалуйста.

Ничего вы не искали.
Вот например поищите на этом форуме по словам "проверка ссылок".
А вот то, что я рекомендую, чем пользовался 7 лет: linklint (но есть недостатки).
Ну и конечно есть linkchecker который мне же на этом форуме и посоветовали.

Xenu's Link Sleuth

это хорошее средство. но надо такое, которое можно было бы запускать из консоли на линуксе

чем обусловлено требование из консоли на линуксе? Почему нельзя воспользоваться виндовой виртуалкой?
Из консоли на линуксе хорошо запускается wget+grep

А что найдет wget + grep? Даже если рекурсивно wget запускать и потом анализировать коды ответа (хотя тут grep-а явно не хватит), то он битые ссылки внутри документа все-равно не найдет.

сам искал такое.
Если найдете, сообщите пожалуйста.

Ничего вы не искали.
Вот пример поиска: http://software-test...ch&fromsearch=1
А вот то, что я рекомендую, чем пользовался 7 лет: http://software-test...ch&fromsearch=1 (но есть недостатки).
Ну и конечно есть linkchecker который мне же на этом форуме и посоветовали.

Ок. Спасибо. Только поправьте первые две ссылки.
Linklint - не староват? как понимаю, вы им пользуетесь?
A xenu хорошь тем, что в virtualbox работает с куками IE, а у нас внутренние порталы с авторизацией.

Ссылки не поправляются ибо мудрые создатели IPBoard-а считают, что давать ссылку на результаты поиска никому не надо. Я уже отредактировал коммент.

linklint староват. Сейчас уже ничем не пользуюсь, но для наших целей на прошлой моей работе его хватало (API Javadoc тестировать). У нас его кто-то немного допиливал самостоятельно и много он не умеет (например https). Смотря для чего надо.

А linkchecker поумнее.

В своем комментарии я признал, что отчасти напрасно критиковал доукментацию на Selenium 2.
Полагаю все же, что уделить внимание именно ПОСТРОЕНИЮ ТЕСТОВ можно было бы, хотя бы и не в основной части.

Еще раз повторю, Селениум не вправе диктовать то, как автор тестов их будет организовывать. Способов очень много и я считаю, что это очень хорошо, что они не захламляют официальную документацию. Вот, кстати, вчера в твитленте обнаружил "Selenium is a BROWSER automation tool. For every-fucking-thing else please ask some-fucking-where else other than a Selenium user group." (отсюда: https://twitter.com/#!/FuckingSeTips)

Не порекомендуете какой-либо связный материал по построению тестов на WebDriver + Java?
...
Видимо, это в определенной степени востребовано,
но для новичков или начинающих, к коим я себя отношу, полезны были бы материалы начального уровня,
к-рые можно было бы изучить off-line, сравнить методики, выбрать более приемлемые и понятные, а не закладываться
на суждения и опыт "драйвера" данного сайта.

Скорее всего не посоветую ибо просто не знаю что можно посоветовать. Ищите в блогах на английском. Книгу по xUnit, которую Алексей предложил я (совершенно независимо) вчера скачал с корпоративной библиотеки и собираюсь читать сам). Какие-то сравнения фреймфорков организации тестов скорее всего можно найти в инете, никогда не искал. Нашел вот список, например http://java-source.n...e/testing-tools, но они тут все из разной оперы. Читайте, выбирайте тот, который подходит и используйте для организации своих тестов.
Что касается Junit, то JUnit4 мне не понравился и я бы посоветовал использовать JUnit3. Он проще сам и его при желании проще модифицировать. Или посмотрите в сторону TestNG, говорят он получше. По крайней мере его авторы не поленились написать документацию.

Когда-то сам копал в эту сторону и пришел к выводу, что оно того не стоит. Почти везде, где нужно серьёзное тестирование (и как следствие приличные зп) невозможно впринципе тестировать из дома.

Неправда ваша. У меня среди знакомых есть обратные примеры.

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

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

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

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

Ах да, наверняка для WebDriver для джавы есть специальные фреймворки. Я их, к сожалению, не знаю. Это одна из моих целей поездки в Киев на конференцию SQA Days - узнать, чем подобным люди пользуются. Я сам хотел написать какой-нибудь такой фреймворк, но на тот момент работа моя над селениумными тестами закончилась. Надеюсь в будущем реализовать эту идею.

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

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

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

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

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

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

Здравствуйте.
Решил использовать "по науке" 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 таким образом, чтобы человек захотел с вами связаться.
- вы предлагаете работу, но в вашем профиле "не указал" и "неизвестно".
- вам нужны "профи с именем", но вы приходите на форум, вместо того, чтобы идти на сайт (это не секрет, что те кто профессионально занимается какой-то подобной деятельностью имеют свой сайт).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

если вводишь верно имя, фамилию и дату рожд. НЕуникального пользователя (Петров Петр 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
Только метод не работает как там написано и надо в нем что-то поменять по мелочи. Исключить иннер-классы итд.

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

JUnit

Junit 3.x или 4.x?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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