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

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

...

Спасибо за столь детальный анализ. На мой взгляд не хватает обобщенного вывода в конце, по которому можно было бы принять решение.
И конечно, данный анализ чрезмерно сложен для такой задачи. В качестве пояснения скажу, что весь код модифицируем так как этого хочется (в том числе и код приложения); а данные (например имена пользователей) заточены на специальное тестовое наполнение базы. В отличие от абстрактного ПО, рассчитанного на массового пользователя у этих тестов и фреймворка ограниченное и однозначное использование во вполне однозначных начальных условиях.

Что касается ваших примеров:
1. Изменились параметры корректного пользователя
Есть (или будут) такие тесты, которые это проверяют. Поэтому весьма штатная ситуация, предусмотренная реализацией типа User. Для всех трех вариантов тестов это не проблема. Наверное следует отметить, что в данном случае объект User - это не объект пользователя, зарегистрированного в системе, а некий тестовый субъект решивший зарегистрироваться или залогиниться в систему.

2. Изменилась форма логина: нужно ввести дополнительный код (инвайт)
Тут два подхода. Наиболее логичным, на мой взгляд, является изменение типа User, у которого помимо атрибутов "имя" и "пароль" будет еще и "инвайт", т.к. этот "инвайт" также является объектом для написания нескольких тестов.
Второй подход - это создание отдельного типа Invite, который в паре с пользователем будет передаваться в метод login. Можно написать два метода login(User u) и login(User u, Invite in), сохраняя неизменными те тесты, где нам неинтересно значение поля Invite. Очевидно, что первый укороченный вариант метода login будет только создавать внутри правильный Invite и вызывать второй метод, как это обычно и делается. Здесь третий вариант проигрывает, т.к. не имеет отдельного метода и возникнет необходимость менять все тесты на эту функциональность.

3. Изменилась проверка того, что пользователь успешно залогинился
Здесь вообще следует отметить, что на практике (при тестировании других объектов) зачастую возникает необходимость делать одинаковые проверки в разных тестах и логично при этом все такие проверки (asserts) выносятся в приватный метод внутри тестового класса. Поэтому, что в первом, что в 3м варианте все-равно будет метод checkIsLoggedIn, в который и надо будет внести изменения. Во втором варианте тестов этот метод принадлежит не тесту, а типу User.

По результатам общения и размышлений пришел к выводу, что надо реализовывать вариант №2.
Объясню почему.
1) Он дает возможность более просто писать тесты, оперирующие с разными наборами данных, но с примерно одинаковым алгоритмом действий.
2) Оперирует объектами бизнес логики приложения отдаляясь от конкретной реализации страниц. Страницы же отвечают за предоставление информации об элементах и их содержимом.
3) При реализации этого подхода, вариант №1 остается доступным.
4) Более просто проследить сценарии, описанные в спецификациях.
5) Позволяет более "чисто" писать именно сценарные тесты с несколькими проверками по ходу дела и оперирующими несколькими объектами (а не только пользователем, как в примере).
6) Даёт простую возможность переиспользовать методы объектов как предварительные акции и без всяких изменений. Надо только убрать методы "checkXXX".
7) Очень важно то, что он даёт возможность следить за тем, чтобы в методах был бы вызван хоть раз хоть один check, в отличие от стандартного unit теста, который будет пройден, даже если в нём нет ни одной проверки.
8) Позволяет использовать проверки неоднократно (не в рамках одного теста, а "шарить" их между разными тестовыми классами).
9) Позволяет проверить результат всех проверок (asserts) в тесте, в отличие от junit, где падение происходит на первой же проверке. Очень удобно при отладке тестов.
10) Позволяет делать негативные проверки без перехвата AssertError (или что там используется) в каждом тесте, где есть такая необходимость.

Что касается возможности вешать дополнительные asserts, то она ровно такая же как и в первом варианте.
Что касается сложности отладки или поиска неисправности во втором варианте - зависит от того как выдаётся информация при ошибке.
Что касается того, что все перевести на вариант №2 не получится, ну и ладно. Вариант №1 меня тоже устраивает, а вариант №3 при появлении будет переводиться в вариант №1 или №2. Вообще оптимальным при написании нового теста кажется такая последовательность: пишется тест в варианте №3 (можно опустить) и потом переделывается в №1, при появлении большего количества тестов на данную функциональность всё рефакторится к виду №2.

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

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

Всем привет.
Требуется определить, что приложение максимально использует пропускную способность канала. Может кто знает какие - нибудь утилиты для этого?
Заранее благодарен за ответы.

А по простому не получится? Если взять определённый набор данных и послать его через канал с известной пропускной способностью, то зная время начала передачи данных и время конца передачи, можно вычислить и реальную скорость передачи, которую можно сравнить с пропускной способностью.

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

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

№2 еще бы допилить, чтобы ассерты были только в одном тесте, ну и в идеале - один ассерт = один тест.

Зачем? Зачем я буду следовать синтетическому ограничению, которое в основном советуют люди, которые пишут книги, а не тесты?
Возможно (хотя я не верю) в "настоящих" юнит тестах такое ограничение имеет смысл. Но у меня же UI тесты имитирующие действия пользователя.

В моих тестах будет столько проверок, сколько требуется. Я буду проверять прекондишены перед запуском основного действия, например для уменьшении времени при неуспешном выполнении подготовительного действия. Более того, далее стоит задача покрывать сценарии, описанные в спеке, т.е. там сделал действие, проверил, сделал, проверил итд в одном тесте.
Или вот например:

.doLogout()
      .checkLoggedIn(false)
      .checkLoggedOut(true);

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

Честно говоря я большой непоклонник слепого следования сомнительным "бест практисам".

Если вам нужно писать тесты на workflow, пишите машину, которая будет уметь генерировать workflow, а не проходить один и тот же сценарий из раза в раз.

Интересная идея, надо обдумать. Хотя она не отменяет прохождение по специфицированным (читай acceptance) сценариям. А тестирование сценариев, конечно же, не отменяет функционального тестирования.

Походу можно новую тему открывать :) про уровни автоматизации тестирования :)

Только что обсуждали эти уровни с коллегами. Сошлись для начала на 3х (это для GUI тестирования только)
1) PreCommitTests - маленький набор, поддерживаемый в "зеленом" состоянии программистами и ими же используемый перед комитом.
2) ReqTests - набор тестов написанных по спеке, покрывающий как отдельные функциональные требования, так и описанные сценарии. Второе в будущем может трансформироваться в отдельный Acceptance Tests
3) OtherTests - тесты с разными наборами данных, негативные тесты (неописанные в спеке) и прочие тесты (например необходимые для воспроизведения дефекта и его верификации).

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

Только что обсуждали эти уровни с коллегами. Сошлись для начала на 3х (это для GUI тестирования только)
1) PreCommitTests - маленький набор, поддерживаемый в "зеленом" состоянии программистами и ими же используемый перед комитом.

Жутко интересно, как вы ограничили размер набора. Выбрали самое важное что укладывается в n минут? GUI тесты имеют свойство идти долго. Если не секрет, сколько идет этот зеленый набор?

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

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

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

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

Вы написали 6 строчек кода, тогда как можно написать 1 при инициализации драйвера (для implicit wait). И далее забыть об этих ожиданиях в своем тестовом коде, т.к ожидание будет включено при каждом поиске элемента.
Плюс к этому зачем писать свой метод, если уже есть готовый?

Всем привет!

Моя презентация с конференции SQA Days 10:
http://www.slideshar...haL/ss-10392275

К сожалению звук в зале был в высшей степени отвратительный и взять его для слайдкаста было бы позором. Так что, не смотрите видео на сайте конференции, поберегите уши. Теперь есть альтернатива!

Если честно, я не совсем понял как работают те методы, поэтому и написал свой

Там же написано как работает неочевидное (implicit) ожидание. Драйвер раз в 500мсек опрашивает модель и если элемент появился - возвращет его, если нет, то падает с exception по истечении времени ожидания. Поэтому, если у вас, например, 3 места - элемент А появляется через 5 сек, элемент Б через 2 сек, а элемент С есть сразу - то ставьте 5 и оно будет одинаково хорошо работать во всех трех случаях. При этом установка значения 5 надо сделать всего один раз и больше не трогать.

Единственно, если элемент Б или С не появлется вовсе, то драйвер будет ждать максимальное время.

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

Посмотрите доклад Стаса Фомина:
http://lib.custis.ru...ia-missing-link

Я не призываю к выбору именно этого инструмента, главное поймать идею с которой лично я согласен. И еще у него на слайдах упомянуто очень много подобных инструментов.

Какие-то лишние артефакты попали в текст после ссылки...

...К сожалению, сделанная во время конференции запись оказалась недостаточно качественной...

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

Да и кроме главного направления тестирования в каких еще направлениях смотреть - HTML, sql, Java? Я просматривал чужие резюме и заметил, что много чего мелькает, но что подучить, не сильно отвлекаясь от основной темы ТЕСТИРОВАНИЕ?

Одним из возможных преимуществ для работодателя может быть знание предметной области.

Добрый день, использовал ли кто-то из вас вот такой вот продукт: WindowTester Pro. Собственно, что бы не дублировать иноформацию приведу сразу первоисточник: https://code.google....p/windowtester/

Собственно у меня возникла проблема с автотестами для приложения на SWING, самая еще петрушка в том, что аутентификация проходит через одно наше приложение + Oracle Internet Directory. Занимался ли кто-то подобными извращением? :) Больше инетересуют подводные камни при тестировании свингового софта.

А почему вы не пользуетесь http://jemmy.java.net/ ?
Что может быть лучше, чем инструмент которым Swing и тестируют, написанный человеком, который это делает?

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

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

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

Возник вопрос, можно ли обмениваться информацией JS <-> Selenium?
Необходимо вызвать сохранение DOM в файл из JS по определенному событию в JS.

Можно также по таймеру из Selenium изменить какие-нибудь элементы DOM (значения форм, содержимое слоев)?

Если речь идет о WebDriver, то у меня не получилось сделать что-то подобное, поэтому скорее всего нет.
Единственно как я менял DOM, это используя bookmarklet-ы, но к сожалению WebDriver после этого зависал.
Продолжать изыскания я не стал ибо это было из разряда "интерсно, что если..", и не нужно для решения рабочих задач.

Возник вопрос, можно ли обмениваться информацией JS <-> Selenium?
Необходимо вызвать сохранение DOM в файл из JS по определенному событию в JS.

Можно также по таймеру из Selenium изменить какие-нибудь элементы DOM (значения форм, содержимое слоев)?

Залез в API нашел такой метод executeScript
http://goo.gl/gPxfX

Возможно то, что нужно для изменения элементов DOM. Попробуйте - отпишитесь, если работает.

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

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

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

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

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

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

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

А какие конкретно у вас затруднения с баг-трекером?
На последней конференции я кое-что рассказывал по этой теме.
http://www.slideshar...haL/ss-10392275

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