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

А зачем менять ip клиента? Request lib в руки и копать.

До ваших переходов по факультетам никому нет дела. У нас есть парень, который в принципе - археолог, однако адекватно тестирует и не парит себе самосознание.

Я знаю как минимум одного филолога из тайги который в NativeDriver репы коммитит...

Другое дело, что многие начальства почему-то убеждены что в IT можно только технарям.

Не знаю)
возможно, но сомнительно.

"Я могу печатать до 9000 знаков в минуту, правда фигня какая-то получается" (с)

Ну а мы ему в ответ: "Это свойство системы. Именно такой она и разрабатывалась."

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

Конечно :) Писать код намного проще :)

Смотря какой

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

Нет ничего что всегда оправдано.

Писать полноценную машину это долго, но запчасти для таких роботов можно писать относительно просто, а профита с них много. Сколько у вас времени займет написание скрипта, который будет случайным образом наполнять корзину интернет-магазина и проверять что все ок? Сколько времени займет перевод скрипта на контролируемый ввод? Сколько времени займет построение графа состояний корзины (для дизайна же делается, чего уж там)? Сколько времени займет генератор сценариев из этого графа для вашего скрипта с контролируемым вводом?
Скрипт на тестирование автоподсказок в bing'е у Harry Robinson'а составил всего 40 (кажется) строк кода. А профита с него было много.

Есть частично готовые решения (не очень хорошо заточенные именно под workflow, но зато отлично работающие в плане покрытия графа состояний): http://crawljax.com/plugins/
Можно начать писать с простого набора автоматизированных оракулов (искать и читать на тему Oracle Based Test Automation).
В общем поле для творчества весьма богатое, да и много времени много там далеко не все кушает, особенно если слона не целиком кушать.

В принципе, автоматизированно каждый шаг можно проверить и по отдельности. Однако, много раз встречал ситуацию, когда отдельно все работает, а вместе почему-то нет.
Если продолжать филосовствовать дальше, то можно сказать, что это своего рода системный тест на базе случаев использования (use cases), в то время как отдельные тесты - это аналог модульных тестов.
Такого рода сценарии мы называем end-2-end тестами и проводим их при каждой выдаче приложения в тест. Получается, что это автоматизированный Acceptance testing.

Если покрыть все функции довольно плотно, то шансов на то что вместе оно не работает будет мало.
Да, согласен, риски еще останутся, но статичный сценарий для автоматических тестов их никуда не уберет. Мы просто прочертим себе дорожку по минному полю, где мины будут находиться легко и просто.
Я ничего не имею против простых сценариев. Т.к. они простые - они быстро выполняются и их проще поддерживать/дописывать/мониторить покрытие. В ряде случаев достаточно простые сценарии это очень дешевый способ отскочить. Но с усложнением сценария все эти бонусы начинают теряться.
Т.е. в вашем сценарии сразу можно выкинуть логин и всю навигацию - лучше проверять их отдельно, а остальные тесты делать без них.
Потом сделать пачки тестов для манипуляций с корзиной (небольшие, легковесные, легко рандомизируемые).
Потом сделать пачки тестов для оплаты разных корзин (нам же не обязателен UI чтобы получить точно такую же корзину?).
Это будет дешево и сердито. И придется постараться чтобы оправдать чем-то кроме паранойи наличие теста в котором будет производиться склейка всего вышеприведенного. Если вы боитесь что там в куки валится мусор - лучше проверять их. Это быстрее, дешевле и проще интерпретировать. Если боитесь что в разных ситуациях в базу пишутся разные вещи - улучшайте проверки в существующих тестах, сценарий тут не сильно поможет.
Собственно это я и имею ввиду утверждая, что автоматические тесты лучше дизайнить отдельно. Оправдание паранойи развесистыми сценарными тестами это очень дорогостоящее удовольствие. Иногда необходимое, но зачастую служащее как оправдание того, что кому-то лень заниматься Failure Model.

ЗЫ: А про Acceptance Testing есть старенькая и очень хорошая презентация от Болтона, кстати. В случае с автоматизацией ко всем бедам можно просто пририсовать, что приемочный тест будучи автоматизированным тупеет на глазах. Тем самым используя, например, всякие BDD фреймы (да и просто большие наборы приемочных тестов) стоит очень хорошо понимать с чем связались.

почему именно на перле?)
мало ли кто с чем и как работает то)

Потому что читать я его могу. Писать на нем желания не возникает от слова "вообще".

И вполне нормально, что если у вас куча работы, и условно вы занимаетесь только черноящичным тестированием, а вам захотелось /приспичило полезть в серый ящик - вам начальство даст по голове и будет право. Если вы предварительно с ним это не обсудили.
А уж если вы сидите ковыряетесь в коде пытаясь понять баг Х, когда у вас там еще куча не протестированного функционала = это вообще фейл.

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

Вы не поймете если вы занимаетесь только автоматизированным тестированием.

Я занимаюсь очень разным тестированием. В том числе не очень автоматизированным тестированием в местах где GUI не светит.

Оппа... И чем же он не продуктивен? Как вы собираетесь писать скрипт на проверку некоевого сценария состоящего допустим из 7-8 шагов (а иногда и 10-15)?

Давайте начнем с простых вопросов.
Вам точно нужно проверять именно этот сценарий? Если да, то почему. Ответ "мне так начальник сказал" это плохой ответ.
Что происходит в ходе теста?
Что бы вы хотели узнать в ходе теста?
Точно ваш сценарий это самый простой и удобный способ получить ответы на предыдущие два вопроса?

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

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

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

Более того, далее стоит задача покрывать сценарии, описанные в спеке, т.е. там сделал действие, проверил, сделал, проверил итд в одном тесте.

А откуда такая задача? Это в принципе очень непродуктивный подход к дизайну автоматических тестов.

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

нас не пускают на пушечный выстрел ни в базу данных, ни к серверу.

А зачем? Поднять почтовый сервер можно на рабочей машинке.

ЗЫ: А вообще читаю я вас и складывается картина организационно-политического "ада и израиляЪ".

но когда умеешь читать, хочется попробовать писать и т.д.

Писать на перле? Боженька упаси!

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

надеюсь понятно обьяснила.

Вот это, кстати, я категорически не понимаю.

А что такое xml-запрос? *trollface.jpg*

Суть поста в том, что хотелось бы иметь какой-то инструмент (если таковой имеется), чтобы лучше локализовывать баги.

Основной инструмент тестировщика это его мозг. Все остальные инструменты применяются когда мозга уже явно недостаточно (я не про наркотики!)

Да, если у вас есть желание, возможность и время для вникания в продукт до уровня разработчика - это круто.
Но если я вникну до уровня разработчика - может я и фиксить сама буду?
что будет в итоге?
я стану разработчиком.
вы этого хотите?
вам это нужно - окей, вперед.

Вы не поверите, но читать код и писать код это две большие разницы.

ЗЫ: У меня нет должностной инструкции. У меня теперь нет обязанностей? Или есть? Можно я буду считать что мои обязанности это кушать пончики и смотреть телек? "Если в ваши обязанности не входит..." - аж ругаться хочется от такого рудимента.

Ну а вообще, дефекты вида "Не отрабатывает ajax-запрос на записях с NULL в таблице REFERENCES" нравятся разработчикам на порядок больше, чем описание "крутится круглый значок и ничего не появляется". Хотя конечно всегда приходится искать баланс между своим временем и трудозатратами разработчиков.

Баги вида "НИЧЕГО НЕ РАБОТАЕТ!" (общий случай бага "крутится круглый значок и ничего не появляется") это в худшем случае совершенно бесполезная паника (читать как "вредительство"), а в лучшем просто флажок вида "копать тут". ответ на вопрос кому копать во многом зависит от задач, которые ставятся. Если нужно посмотреть (поверхностно) как можно больше в сжатые сроки - тогда копать разработчику (тут, правда, предполагается что его время не казенное). Если нужно искать проблемы, причем проблемы серьезные - копать тестировщику.

ох ели бы)
наши разработчики самые занято-разрабатываемые в мире
нам реально в 100 раз проще и быстрее насоздавать себе обычных ящиков.)

А один раз научиться это делать самим не вариант?

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

Так вот и получается, что бага все-таки локализована была неправильно

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

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

Это быстро, особенно если надо только для себя. К тому же весьма небесполезное знание.

ЗЫ: Топикстартеру пофиг, флудим дальше.

Ок, давайте автору линки, или вы думаете, он так сходу и поймет, где ему взять нагрузочные инструменты, а также как с ними работать? :)
Это все - время...

Нененнененене! Врагу не пожелаю заниматься функциональщиной через нагрузочные инструменты!

не ерунда , увы)
на практике проверено и не единожды.)

Я к тому что:
1. В половине случаев это тестирование чужого сервера/клиента вашими письмами (как правило HTML формат и все такое).
2. В другой половине случаев это проверка интернетов.
Выполнять надо соответственно. Регистрация совсем не обязательна, достаточно письма отправлять.

Для тестирования того что ваша софтина работает корректно сама по себе достаточно локального почтового сервера (можно и без него, но тут объяснять дольше).

вы сможете гарантировать что пользователи отправившие запрос на регистрацию в яхо, яндекс, рамблер и пр получат письма? -нет
что там корректно распознается текст?- нет
что там корректно сработает переход по ссылке ?-нет
что приложенные изображения корректны, и открываются? - нет
что письмо пришло через Х секунд а не Х часов? -нет

Это, простите меня, ерунда полная.
POP3 как был POP3 так им и останется. И локальный это сервер или сервер Яндекса - ничего не изменится.
А все остальные ваши страхи проверять кроме как с продакшен ноды смысла нет - потому что интернет роутинг такой интернет роутинг. Кстати, пытаясь ответить на большую часть этих вопросов проверять вы будете в именно его. Но это сомнительное развлечение на долгосрочную перспективу, т.к. Сеть меняется не уведомляя вас и ведет себя плохо тоже без спросу.

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

Это была ваша проблема или проблема чужого сервера?

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

При этом работающее приложение вам в принципе не нужно для этого, т.к. фактически вы проверяете thirdparty клиенты (имеет смысл, наверное) и сервера + как до них идет ваша почта.

Когда он поймет, что надо изучить для проведения этого тестирования :) А может, есть более приоритетные задачи? На текущий момент? Глупо ведь отдавать неработающую по функциям систему, но зато "она выдержит 1000 юзеров сразу!". Приоритеты, расставляйте приоритеты!

Обычно такое кино выливается в функциональное тестирование на нагрузочном стенде нагрузочными же инструментами.