Это копия, сохраненная 18 декабря 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
What is Selenium?
Selenium automates browsers. That's it!
http://www.seleniumhq.org/
Для начала предлагаю тебе пройти курс по Python на codecademy, чтобы ты узнал что же такое Python и какой у него синтаксис.
Все предложения выслушиваю в этом треде и, надеюсь, я не один такой, который заинтересован в данном вопросе.
http://selenium-python.readthedocs.org/index.html - официальная документация по Selenium с использованием Python. Перевод некоторых глав есть на хабре http://habrahabr.ru/post/248559/
https://www.youtube.com/watch?v=KCPI5JJNQTI - введение в PageObject (этот вопрос я только начал изучать)
Автоматизация действий пользователя, которые описаны в тест-кейсах. Например: при вводе в строку поиска гугла "2ch", первая ссылка должна содержать "2ch.hk". Если это так, то тест прошел успешно.
https://www.youtube.com/watch?v=--vqRAkcWoM
Пишу юнит и E2E тесты на php + codeception + phantomjs (через ghostdriver который использует селениумовский протокол).
phantomjs так как его гораздо проще запустить локально чем настраивать селениум. Если нужно много браузеров, то возможно проще задействовать сервис вроде saucelabs чем самому поднимать грид из виртуальных машин.
ОП, расскажи о том как ты используешь селениум, сколько браузеров, машин, какие бывают баги и тд.
>ОП, расскажи о том как ты используешь селениум, сколько браузеров, машин, какие бывают баги и тд.
ОП только осваивает понемногу питон в связке с Селениумом. Пишу примитивные автотесты, которые проверяют работоспособность ссылок, правильный тайтл страницы и некоторые ошибки, которые должна отображать система. Поэтому и создал этот тред, чтобы опытный анон-автоматизатор помогал ньюфагам типа меня, но, наверное, нету здесь таких.
Потому что низкий порог вхождения.
>но вроде в виде COM-библиотек идет
К счастью нет, не только. Привязки для селениум-сервера, реализующего протокол вебдрайвера, существуют практически для чего-угодно. Это больше вопрос удобства написания или основного языка проекта.
>What is Selenium?
Селениум жуткий монстр, система локаторов, тянущаяся со времен тестового жабоскриптового фреймворчика, слепленного на коленке, издевательство над здравым смыслом. Боролись с "ограничениями жаваскриптовой песочницы", а главные ограничения, связанные с событийной моделью и моделью локаторов, так и оставили.
При вводе текста в текстовое поле не срабатывает валидация или автокомплит? Форма не сабмитится при клике на кнопку? Чекбокс не выбирается, потому что над чекбоксом элемент, который и обрабатывает событие MouseDown или MouseUp, еще записывая по пути что-то в hidden? Добро пожаловать в Селениум!
На странице налеплено элементов, к которым кроме как километровым xpath-ом не добраться? Завтра ты уже не будешь помнить, что этот //div[@class="tvoya-mamka"]/div/div/table/tbody/tr[153]/td[@class="is-a-whore"]/following-sibling::td/div/div[5]/ul/li[8]/span означает, да это и не важно, так как верстку снова переделали и тебе нужно все переписывать. Добро пожаловать в Селениум!
Для этого всего люди придумали дополнительные инструменты и фреймворки. А еще есть такая штука, как Page Object Pattern.
Все это подпирание костылями мертворожденной технологии, не способное исправить ее основной недостаток.
Пользователь не вводит текст в локатор, он кликает над областью, которую он идентифицирует как поле для ввода и нажимает на клавиатуре нужную комбинацию клавиш. И только тогда все эти события передаются через операционку в окно браузера и там обрабатываются. Пользователь не кликает по xpath //div[@class="knopka"]/div/div/div/span/span, он наводит указатель в определенную область окна и нажимает кнопку мыши или давит по тачпаду. Разница тут колоссальная, локаторы противоестественны тому, как используется браузер в реальной работе. Элементы не всегда являются тем, чем кажутся.
Написал, например, кто-то ввод текста в текстовый инпут и полагает, что все сделал правильно. А вот и нет, оказывается введенное пользователем значение записывается в input hidden хрен знает каким событием, хрен знает где висящим. Текст "введен" в локатор, а ничего не сработало.
Это уже не говоря об всяких обертках, фреймворках, паттернах и прочих экзерсисов в ООП, которые часто лепятся над Селениумом.
>если всё это широко используется
Так вменяемой альтернативы нет.
>и успешно
Успешность трудноопределима для чего-либо сложнее простенького теста на открытие страницы, прокликивания ссылок, других элементарных действий с простым интерфейсом.
>к чему ты ведешь
К тому, что надеюсь на появление более вменяемого инструмента, ориентированного на реальные процессы разработки, тестирования и пользовательского опыта использования веб-приложений. А не локаторной каши под названием Селениум.
Я согласен с тобой, отчасти, но я даже представить не могу, как может выглядеть альтернатива в силу малого багажа знаний по этому вопросу. Может у тебя есть какие-то идеи по этому поводу?
Могу более-менее определенно сказать две вещи.
Первая, относительно простая в реализации, события должны генерироваться на уровне ОС и передаваться в браузер как есть. Это повторяет естественный ход вещей. Пользователь совершает какие-то действия, а далее компоненты ОС и браузера определяют какие в конечном счете события и для каких элементов возникнут. Сейчас с Селениумом все наоборот, разработчик сам должен определять, а чаще всего гадать, для какого элемента какое событие настанет в том или ином случае, это противоестественно.
Второе, более сложное, элементы с которыми взаимодействует тест не должны определяться через верстку. Связи между версткой, отображением и тем, как элементы на странице работают, нет. Нет прямой связи между версткой и функциональностью страницы. Элементы должны определяться тем же образом, как их распознает пользователь, и по своему функциональному назначению.
Это случайно не Sikuli? По-моему, его как раз-таки можно использовать для генерации событий. Обрабатывать результат, емнип, можно Селениумом. Дискасс.
Ну так и дрочи autoit, зачем тебе селениум?
>Sikuli
Как-то идея определять элементы по скриншотам кажется не надежной. Разные браузеры под разные ОС отрендерят разные по виду страницы. И хотя про Sikuli, что она не сравнивает пиксели 1:1, а допускает некоторые расхождения, не понятно, на сколько адекватно все это будет. И что, например, делать не со статическими данными, а например, текущей датой, которая каждый раз будет разная, или, скажем, номером какого-нибудь заказа, который скорее всего будет определяться по номеру записи в базу.
>дрочи autoit, зачем тебе селениум?
Тем, что только для винды. Но особых проблем нет имитировать пользовательские события ОС, как уже писал, это самое простое. Не понятно от чего этого не делают более массово, в том же Селениуме, например.
Так ты определись, ты хочешь DOM тестировать или то, как он отрисован. Разные уровни - разные инструменты.
>Так ты определись, ты хочешь DOM тестировать или то, как он отрисован. Разные уровни - разные инструменты.
Я хочу тестировать функциональность веб-приложения в браузере. В том и специфика.
Взаимодействие пользователя со страницей совершается внутри контекста браузера, то что можно назвать "уровнем DOM-а", но происходит оно как и с любым другим приложением через взаимодействие пользователя с машиной при посредничестве ОС. Инструменты автоматизирующие ОС не дадут тебе полной картины того, что происходит в браузере, а "изнутри" браузера невозможно полностью имитировать взаимодействие пользователя с системой.
Но проблемы как таковой нет, есть же инструменты делающие все это в своей области. От чего их до сих пор не совместили в одно удобное решение не понятно.
Почему, вполне понятно - тестирование на уровне OS - штука сложная, нестабильная и очень объёмная. То, что ты хочешь, не делается без тонны нативного кода, который ещё и зависит от ОС, её версии, локализации и версии браузера, а выхлоп всего этого сомнительный.
>штука сложная, нестабильная и очень объёмная
Это штука простая и намного более стабильная, чем тот же Селениум, сгенерить событие клика по координатам x,y просто, на это есть горы документации.
>То, что ты хочешь, не делается без тонны нативного кода
Можно подумать, что тот же Селениум из пары строчек состоит. Но опять же все эти задачи тривиальные, инструменты, которые все это делают уже существуют.
А если хочется уневерсализма, есть
http://docs.oracle.com/javase/7/docs/api/java/awt/Robot.html
например.
>а выхлоп всего этого сомнительный
Как уже писал это минимум даст инверсию направления генерации событий с противоестественного на человеческий. Разработчику не нужно будет изнутри браузера гадать какие события родятся при определенных действиях пользователя. Это сделает сам браузер в ответ на событие ОС.
>сгенерить событие клика по координатам x,y просто
Ага, только тебе нужно кликать не по x, y, а по кнопке, для которой поди ещё их определи.
>а по кнопке, для которой поди ещё их определи
Ты не поверишь, но для Файрфокса, например, есть
https://developer.mozilla.org/en-US/docs/Web/API/window/mozInnerScreenY
https://developer.mozilla.org/ru/docs/Web/API/Window/mozInnerScreenX
Что делает пересчет координат банальным.
Да и зафиксировать разницу в экранных координатах и координатах браузера дело нехитрое. Если не замешан скейлинг, например, для экранов с высоким DPI. Но если мы говорим о тестовом окружении, которое мы часто можем сами контролировать, то это не проблема.
Ну напиши свою кликалку-по-заданным-координатам и дёргай её из тестов, использующих селениум.
Ну спасибо, что разрешил.
Но мы все-таки о проблемах автоматизированного тестирования говорим. Можно сделать значительно больше, чем просто "кликалку", хотя даже от нее польза будет существенная. Могу только повторить, надеюсь, что удобный и полноценный инструмент автоматизации браузера тем или иным образом появится на замену простому Селениуму.
Как-то с учётом состояния дел, сильно на это лучше не надеяться. Там, вон, оп про питон говорит, а ведь тот же autopy не может поддержать ретину уже 3 года как самому пилить пришлось, в процессе уплевался
Были ли случаи, когда вы находили ошибки в повседневной жизни? Если да, то приведите несколько примеров.
Да. Приходишь на вокзал, а там вместо расписания поездов - прогноз погоды в бегущей строке. Фактический не совпал с ожидаемым, например.
Это тестовый вопрос одной небезызвестной конторы. Как бы вы ответили на этот вопрос?
Укажите, какие из представленных вариантов на ваш взгляд не являются багами, и объясните почему:
1)У модели танка отсутствует текстура орудия.
2)Наличие различий в формате текста в системном сообщении о покупке танка и в нотификации о старте боя.
3)Отсутствие точки в конце первого предложения описания танка.
4)Символика Вермахта, нанесенная на советский танк ИС-3.
5)Для выхода из окна обслуживания танка пользователь должен подтвердить выход в диалоговом окне «Подтверждение выхода из окна обслуживания».
6)На карте «Малиновка» солнце садится на востоке.
Варгеймингблядь не палитсяю
1. Как посчитать количество синих машин в городе?
2. Приложение должно принимать неограниченное количество пользователей. Как Вы это протестируете?
У меня есть своё мнение на этот счет, но интересно, как бы ответил на эти вопросы Анон.
Проиграл с символики вермахта.
1. Баг
2. Какие различия? Если различие вида Цена Танка - Стоимость Танка, то похуй, если не указно, что тексты ОБЯЗАНЫ совпадать. Если, например, указаны разные ТТХ или орфографические ошибки - это баг.
3. Если она там должна быть и предложение не единственное - баг.
4. Как посмотреть, если в спеке указано, что на танках СССР должна быть только символика СССР - баг, если кастомайз пользователь крутит как угодно - не баг.
5. Точно не баг, возможно flaw интерфейса и это стоит выделить в импрувмент, хотя по мне этот пунт норм.
6. Похуй, ебанутые суки, солнце у них на востоке, кусты свои уберите, пидарасы. Ладно, опять же - вопрос, как описано в спек к карте, если не описано ничего конкретного - вероятнее всего не баг, т.к. реализм это не про картофан и тестировщик не должен тащить всякую хуйню вроде солнца садящегося не там и забивать багтрекер неисторическими кустами, которые нужно сдвинуть на 2мм правее.
Вообще в /wrk есть тред, который для подобной шляпы и предназначался.
Native events разве не оно? Грят клик происходит на уровне операционной системы
Успеваете ли сидеть на посторонних сайтах (вк, youtube и др.)?
Или вы ВСЕ ВРЕМЯ заняты непосредственно работой?
Просто интересно как выглядит типичный рабочий день тестера.
От твоего поста возникло ощущение, что у тестеров своя атмосфера. Запилите кулсторей что ли про свою работу.
В зависимости от нагрузки по задачам. Если окружение находится в пизде и что-то не работает, то есть, блокирует твою работу или доступ к той области, которую ты должен тестировать, то сидишь и еблуешь (смотришь видосики на youtube, разводишь тянок в вк, капчуешь). Если задач дохуя, у ПМа начинает чердак протекать и он просто тебе вешает всякую хуйню, потому что завтра релиз, то времени ни на что другое просто нету.
Бывает по-разному, но, в основном, времени хватает и на видосики и на вк. Главное, чтобы работа была сделана.
Говорят, что к одному продукту может быть тысячи тест кейсов.
Этож надо нон-стопом писать их. Или это миф?
Могут быть, конечно же. Но, в таком случае, за отдельным модулем (или несколькими) закреплён свой автоматизатор.
а в чем прикол этой работы? по мне бы лучше диваны спускать с 12-го этажа, да цемент класть на стройке
А мне нет.
Да, нужно писать нон-стопом, в этом и фишка. Главное не проебаться и начать как можно раньше эту активность.
Даже не знаю что тебе ответить... Хотя, знаю - иди на хуй!
Лел, какраз вчера отвечал на эти дурацкие вопросы.
Сама задача:
Description
Task verifies several candidate abilities including:
● ability to study independently by learning POSIX file systems standard
● perform data analysis by selecting important information
● design test cases and prepare documentation
● implement code based on design
Test Task
Design a set of test cases for owner/permission/content modification testing of NFS4 file system.
Implement designed test cases as testing application (test suite). E.g. all tests are stored in “tests” folder
and there is “main” file which run all tests and produces an output.
The results of the task are:
1. Test documentation. Use the following format:
○ Name of test case
○ Description
○ Steps
○ Expected result of each step
2. Source code of test suite
3. Logs of the latest successful tests execution
Test case example:
Test name: Change file attributes to disable run, enable it , disable again. Description: test verifies that
after several disable ,enable actions permissions set to last value.
Тесты надо писать на чистом питоне.
Возможно я аутист и не правильно понял данные условия:
4. Use one of the following scripting language:
a. Python (preferable)
b. Ruby
c. Perl (in OOP style)
5. Test Suite has to prepare and clean environment
Помоги же мне разобраться, друже!
Ебать долбоеб. Юнеттесты нинужны. Можно ебануть несколько интеграционных, да. Но хуячить по тесту на каждый чих - эталон долбоебизма. Требования постоянно меняются, причем довольно таки координально. Для проверки есть макаки-тестеры. Еще большим долбоебизмом является TDD - хуяришь говнотест, а по нему уже сама собой будет разрабатываться архетиктура, ага. Лишь бы голову не напрягать лишний раз.
Автотесты - та еще хуита. Посидел я однажды на автотестах. Говноедство то еще. Особенно это касается вебразработки, когда даже ебаный селениум не в силу справиться с поведением браузера.
На автоматизатора можно пойти с нуля, или нужно сначала отработать пару лет макакой? Просто собираюсь податься в тестировщики, закончил пару курсов, теоретическую базу набил, SQL, Ubuntu cmd, сети немного. Да, еще даже не джун, но хотел бы услышать советов мудрых от опытных макак.
нет, можно сразу, я сразу начал автоматизатором работать и продолжаю
Да, я из qa ушел, петушинная работа, кто больше двух лет там - сочувствую бездарностям.
Хуй знает, кому как. Может ты просто тупорылый, может и не тупорылый, но просто QA тебе не подошёл. Если ты говоришь про мануальное тестирование - это да, там ничего хорошего нет. Работа по 10 часов, а зарплата ниже раза в 3, чем у среднего дева - просто пиздец петушиная работа, никакого развития, а только одна ебала, среди мануальщиков текучка просто пиздец, проходная работа.
Но автоматизация - вполне себе отдельная сфера и самодостаточная. Хороший фулл-стек автоматизатор очень ценный специалист, который сможет делать нагрузочное/перформанс тестирование, сконфигугрировать и поставить CI и собственно будет делать автоматизацию UI/API/сервисов, на это уйдёт дохуя времени и хороший автоматизатор ценится, им не так просто стать, он должен совмещать частично 3 профессии: быдлокодер, билд-инженер, перформанс аналитик. Я знаю некоторых qa-автоматизаторов - очень умные ребята и хорошие программисты, некоторые на порядок лучше знают программирование и сетевые технологии, чем мои знакомые некоторые быдлокодеры, пару разрабов синьёров, которых я знаю даже рядом не стоят по знаниям с этими автотестерами, но просто работы для них нет, кроме как в больших компаниях, поэтому они привязаны к эпаму/люксофту/варгеймингу/итре. Зарплаты у хороших автотестеров сравнимы с девелоперскими. Но многие съёбывают в разработку чистую, поэтому если взять усреднённого разраба, то он будет умнее, чем усредненный автотестер и у разраба будет раза в 1.5-2 выше ЗП. Хуй знает кароч, надо каждый отдельный случай отдельно рассматривать, нельзя всех под одну гребенку, всё сугубо индивидуально: у меня есть знакомыая тёлка - мануальная макака(андроид и ios тестит) у неё ЗП 1500$, есть знакомый быдокодер, который строить из себяд дохуя умного, но у него ЗП 1300$.
Алсо, сажи треду. ОП - хуй. Скрыл.
а что не так с тредом юноша?
> Алсо, сажи треду. ОП - хуй. Скрыл.
Проиграл с дебила. Не ты ли тот быдлокодер, который получает $1300?
С каких пор в програмаче перестали удалять треды для тестировщиков?
>1. Как посчитать количество синих машин в городе?
Это что-то из серии "почему люки круглые"? Если предположить, что все машины находятся в пределах видимости и различимы между собой, если делать съёмку с высоты, которая может охватить всю площадь города (например, при съёмке со спутника), то можно сделать фотографию города, а потом накатать программу, которая могла бы распознавать синие машины на фотографии и, соответственно, вести их счёт.
>2. Приложение должно принимать неограниченное количество пользователей. Как Вы это протестируете?
Ограничения всегда есть, по крайней мере на уровне ОС. Такое просто невозможно, чтобы приложение оперировало чем-то бесконечным. JVM оперирует памятью как бесконечным ресурсом, но мы то знаем, что этот ресурс ограничен на самом деле. Так что я бы просто узнал, какие есть лимиты в данной ОС на машине с конкретной конфигурацией и как с этими лимитами коррелирует приложение (например, процедура "приёма" пользователя требует выделения в памяти структуры данных на 1 КБ), и тест бы проходил в том случае, если приложение практически полностью достигало исчерпания всех возможных ресурсов, что выделены ей ОС.
Занимаюсь автоматизацией тестов для ядра Linux и частично юзерспейса вокруг этого ядра в одном дистрибутиве. Какой дистрибутив не скажу, дианон тхавля, хотя дистрибутив принципиально не важен, один хуй ядро везде одно и то же, практически, и дохуя тестовых сюит в опенсорсе, которые все юзают и допиливают под себя и какие-то изменения коммитят в апстрим по мере необходимости.
>в том что я о данной ФС и позиксе в первый раз то слышу
Ну и нахуя ты хочешь устраиваться на вакансию, где блядь эти знания от тебя требуются? Может, стоит сначала заняться самообразованием немного?
Бля, с языка всё это у меня снял. Занимался 2 года в прошлом функциональным автотестированием - было более-менее норм, потом стал менеджерить тестировщиков и проекты, бля как же у меня начало бомбить, что они кучу времени убивали на починку своих сломанных тестов. Это просто пиздец. Если задуматься об экономической эффективности функционального автотестирования, то она крайне низка. Виной тому, по моему мнению, как раз то, что ты назвал - хуевый инструмент - ВЕБДРАЙВЕР и конкретно вся эта мозгоебля с локацией, событиями и асинхронностью. Он конечно намного лучше чем ничего и в простых случаях нормально показывает себя, но ДОЛГО, ЛОМУЧЕ, ДОРОГО убивают всю его пользу и намного лучше работает связка 2 девелопера + 1 тест-макака.
Я постоянно ломаю голову как эту хуйню улучшить и сделать более лучший инструмент, но пока ничего не придумал. И мне еще интересно, почему какой-нибудь гугол рисёч не запилил ёба-тулзу
>Если задуматься об экономической эффективности функционального автотестирования, то она крайне низка.
>Он конечно намного лучше чем ничего и в простых случаях нормально показывает себя, но ДОЛГО, ЛОМУЧЕ, ДОРОГО убивают всю его пользу и намного лучше работает связка 2 девелопера + 1 тест-макака.
Бро, те вещи, о которых ты пишешь, в последнее время все чаще и чаще погружают меня в отчаяние и толкают к размышлениям о ничтожности и пустоте бытия. Занятие автотестированием наполнено болью и страданиями.
Разрабы на всех уровнях, вплоть до руководящих, от чего-то думают, что автотесты это такая волшебная палочка-выручалочка, которой можно заткнуть все проблемы проекта. Код-лапша вперемешку с легаси, для которой даже юнит-тестов написать практически невозможно. Конечно, дешевле и проще вместо наведения порядка "покрыть" все вокруг функциональными тестами. И это бы прекрасно работало в волшебном мире сферических эльфов и единорогов, где тесты выполняются за секунды, не падают от малейшего чиха в верстке или затупившего асинхронного запроса. Где проект уже разрабатывается пригодным и удобным для тестирования.
Подход с персональными макаками в каждую команду, конечно, работает, но ведь это надо штат раздувать. А всем хочется за просто так хоп-хоп налепили автотестов, получили блэкджек и шлюх.
И автотесты же действительно могли бы быть полезными, они могут выполняться хоть 24/7 круглый год, есть не просят, в отпуск-декрет не ходят. Но только если они действительно интегрированная часть проекта, а не где-то сбоку-припека затычка для говнокода.
Ну я как руководитель проекта только за чтобы всё было так как ты говоришь. Только зп ручника 20к, а зп достойного автоматизатора 50, ручника можно задрочить так чтобы он давал сравнимый профит, по этому это проще и дешевле. Но я лично за автоматизацию, только вот никто не умеет ее делать хорошо, а те кто умеют стоят дорого. По этому нужен какой-то более лучший инструмент, который позволит менее квалифицированным специалистам делать качественную автоматизацию.
Да нет, все правильно, это был просто бугурт от всего этого. Но есть и нюанс, как мне видится:
>>618832
>Только вручную, только хардкор
Автотесты реально могут позволить снять наиболее рутинную часть работы с ручника, что позволит тратить время на более нетривиальные вещи, а значит ценность его труда увеличивается.
Есть, что интересует задавай вопросы.
Есть мнение, что проблема как всегда не в инструменте, а в кривых ручонках. В чем проблема с локаторами такая прям невъебенная, что ничем не лечится? Надо корректно их указывать и не ломать при изменении верстки обратную совместимость без необходимости. Первое лечится ревью, второе душеспасительными разговорами с разработкой.
Согласен,
1. у многих автоматизаторов ручонки пиздец кривые. У них просто нет необходимого скилла программирования. Честно говоря, обычно они вобще нихуя не умеют программировать. И не особо учатся, а если учатся то по всяким "ООП-для-тестировщиков-и-обезъян. Онлайн курс от Ивана Баранцева". Я не знаю что сложного заботать программирование на минимальном уровне, но средний автоматизатор сравним по уровню с джуниором-разрабом. Видимо, это из-за узкоспециализированного программирования, за пределы которого они вылезать не желают.
2. проблема с локаторами она есть как не крути. Самый пик прогресса на текущий момент - это пейдж обджект и вынос локаторов в отдельный слой абстракции и создании собственной библиотеки контролов, которыми оперируют тесты. Если это в проекте реализуется - это ок, с этим можно жить и минимизировать боль. Но не в каждом проекте есть время на написания всей этой машинерии и часто нужно "покрыть по быстренькому". Во вторых, обычно автоматизация пишется после хоть какой-то стабилизации кода, т.е когда уже все нахуячено. И обычно никто не слушает вопли QA "сделайти нам чтобы было легко тестировать!111", так же как все кладут хуй на TDD, вот ровно по той же механике. В итоге нигде нет никаких айдишников, начинается ебля с Xpath, никакой семантики нет, локация становится кучей говна. Может мне так не везло все время, но все проекты, которые я видел - такие.
3. Автоматизация - дорогая вещь. Хорошо, когда ты Badoo или Mail.ru и у тебя есть деньги содержать 100 человек в отделе качества, но вот у меня, например, денег на это нет, а спокойно релизить и ласкать глаз зелеными полосками на CI я хочу. И таких как я - овердохуя. Нам нужна дешевая и качественная автоматизация.
Вот почему я считаю, что вебдрайвер - это хорошо, но мало.
2. Либо я разбаловался, либо ты отстал, но PageObject это не пик прогресса, это санитарный минимум. Стоимость внедрения нулевая, есть готовые фреймворки а-ля яндексовый htmlelements (вот тут есть что допиливать, но это отдельный разговор). Вообще, дело идет к тому, что API веб-драйвера будет стандартным интерфейсом независимо от внутрянки, будь то Marionette, phantomjs, appium и так далее, так что придется с этим жить.
Есть еще готовые продукты а-ля QTP, вдохновленные идеей "А давайте посадим кучу макак, авось они нам напишут Войну и мир", но это треш и содомия, принципиально немасштабируемая.
Третий стул - готовые фреймворки на базе webdriver типа thucydides, от которых у меня люто пригорает, но в условиях дефицита всего и низкого уровня автотестеров может помочь.
3. У меня есть опыт успешного запиливания такого счастья в одно жало, но это действительно недешево и требует определенной упоротости в хорошем смысле + большого количества собранных граблей. Посадить отбросы кодерского сообщества и ожидать позитивного результата не приходится.
Алсо, по технологиям уровень бардака в тестировании фронтенда на порядок меньше бардака в вебе и в разработке фронтенда в частности, так что качественного скачка тут не ожидается.
2. про htmlelements не знал, спасибо. Ну хорошо, что кто-то таки написал это и сократил количество работы
3. у меня тоже есть такой опыт, только вот то ли я такой был упоротый, что думал как себе работу сократить, то ли еще что, но я глянул в проект через 2 года и увидел тот же самый свой код на котором накостылили еще 10 этажей, закрыл и больше не открывал никогда.
>Автоматизация - дорогая вещь
Дешевой она не станет без качественно нового инструмента тестирования. Никакими программерскими экзерсисами с сегодняшними технологиями, имеется в виду вебдрайвер, такого не добьешься.
Но если Гугл, который уже тут упоминали начнет что-то делать, то сделает, очевидно, для хромого браузера в первую очередь. У МС есть набор технологий, на основе которых можно было бы делать интересные вещи по автоматизации, но это все под шиндовс и мелкомягкие браузеры в первую очередь опять же. У файрфокса есть набор API, тоже расширяющих возможности по автоматизации, но они нестандартные и нигде их больше нет.
Пока никто этот зоопарк собрать в единый качественно новый инструмент не осилил. А может это и невозможно вовсе.
Сами же производители, похоже, не горят желанием облегчать жизнь конкурентам и подстраивать свои продукты под других.
>>620856
>у многих автоматизаторов ручонки пиздец кривые
>>621023
>так что придется с этим жить.
С тем, что есть сейчас, нельзя эффективно автоматизировать что угодно. Часто цена поддержки автотестов превышает все разумные границы. Проект изначально должен делаться удобным для автотестирования. Это работа и квалификация не только автотестеров, но и всех разработчиков от фронтэнда до бекэнда.
Тогда цену создания и поддержки автотестов можно контролировать.
Так что проблема не только в автотестерах, скорее во всей системе.
Сажа приклеилась.
В целом, мне больше нравится идея внедрить вебдрайвер как стандарт во все браузеры, это правильный путь. Но пока этого нет и хз когда w3c этот стандарт примет. Последний раз когда я этим интересовался, вроде был драфт.
Я на своих проектах стараюсь заставлять всех фронтовиков придерживаться бест практис чтобы хуйни не писали сразу, но не всегда это можно сделать. Проекты разные, длинные, короткие, дешевые и хуевые, а качество нужно делать всегда. Лучше бы автоматически нежели вручную
Проблема с этим в том, что вебдрайвер это протокол. В своем определении он слишком общий.
Например.
http://www.w3.org/TR/webdriver/#element-click
>The Element Click command scrolls into view the element and then attempts to click the centre of its visible area. In case the element is not displayed, an element not visible error is returned.
Это слишком абстрактно, не понятно что конкретно будет делаться в браузере, чтобы выполнились требования этой спецификации. Как будет имитироваться клик, как именно и какие события будут выброшены. Эта спецификация в принципе не может гарантировать, что реализация протокола будет работать так как подразумевается и единообразно для всех браузеров на всех системах.
Нет, я не говорю, что этого нельзя достичь, но из спецификации это ниоткуда не следует.
Кстати, сейчас пересмотрел и не нашел в спецификации определения понятия "Клик".
Если я его где-то пропустил, ткните туда, пожалуйста, носом.
Что такое "клик", из каких действий он состоит, какие события в результате будут выброшены.
Какой период времени между нажатием на воображаемую кнопку мыши и освобождением ее? Ничего этого не видно, а главное в спецификации протокола такое особо и не пропишешь.
Значит каждый волен велосипедить как в голову взбредет. Но это же полный трындец. Чего-то не взлетит оно, мне кажется.
>С тем, что есть сейчас, нельзя эффективно автоматизировать что угодно. Часто цена поддержки автотестов превышает все разумные границы.
Если мы говорим про автотесты через UI - таки да. Надо исходить из реалий, что хорошие покрытие через верстку - для богатых буратин. Не надо пытаться на маленьком проекте сделать pixel-perfect заебись на фронте. Так, самый минимум, остальное через апи, модульные тесты и т.п. Другое дело, что частенько архитектура - монолитный ком, и попробуй там концы найди.
А это важно? Конкретная реализация может быть платформо-зависимой: c ходу приходит в голову, что на таче определение клика явно отличается от десктопа. Реализации будут использовать апи конкретного браузера/ОС, так что фактический алгоритм будет различаться, и это норм.
xpath, конечно тебе могут начать кукарекать за время выполнения и т.д., но xpath
Алсо, выкатывайтеьс нахуй из этого говна и идите кодерами как я сделал
Менеджероболи
«Девелопер сражается с косяками требований, технологии и легаси-кода. Автоматизатор сражается с косяками требований, технологии, легаси-кода, тест-кейсов, серверного окружения, клиентского окружения и инструмента автоматизации. Пожалейте автоматизатора. Ему и так в жизни не повезло»
Меняй работу, переезжай поближе, читай в транспорте. Лол, шучу, просто ной на сосаче. Этого хватит, инфа 146%.
А зачем? Я вот не работаю, и круглосуточно играю в игры, смотрю кинцо, сижу на двачах и программирую.
Приходишь ты на проект с двадцатилетней историей, хуяк - юниттестов нет, комментов нет, в VCS, мигрировавшей три раза комментов к коммитам нет, что и зачем работает - неясно. Рефакторинг? Не - хер тебе, понять как и главное зачем что-то было написано и что должно делать - хер тебе.
Берёшь и хуячишь. Специфических граблей хватает, но проблем особых не должно возникнуть, если конечно ты реальный фронтендер, а не table/tr/td макака. Тесты на js уебищны, факт. Кстати, советую при первой возможности выкинуть кукумбер нахер, вся эта история с "описания фич на естественном языке" - маркетинговый буллшит и ничего кроме лишнего геморроя не принесёт.
А что тогда посоветуешь? Освоить базовый руби или питон и вкатится в Селениум?
Да. Руби няшен, на нем тесты выглядят очень круто. Писон потопорнее, но вроде как более популярен. Ну и личный профит более ощутим, "автотестер на js" - это какая-то совсем уж НЕХ.
Устроился в свою первую конторку и охуел, мне нужно по обезьяни тестить функционал приложения на разных платформах, но проблема в том, что все рабочие станции на которых я работаю развернуты до меня и засраты.
И я больше всего времени трачу не на собственно работу, а на то что сижу и конфигурирую все это говно, Ставлю Лотусы, Эксченжи, 1С, настраиваю FTP-серверы, etc., чтобы оттестить работу приложения.
Внимание вопрос, как автоматизировать разворачивание рабочего окружения, так чтобы можно было быстро откатиться к первоначальному состоянию системы после того как, что-то изменил? Я так понимаю смотреть нужно в сторону Vagrant? Короче где почитать реальный кейс, того как это устроено в нормальных конторах?
Я может сейчас скажу ересь, но как насчёт держать весь скоп конфигов под контролем версий? Список для установки у меня это простейший ебилд, конфигурация по возможности вынесена в local, то есть при обновлении пакета не нужно морочить голову мерджем, если нельзя так, то я обязательно пишу небольшой текстфайл с пояснениями того что нужно изменить чтобы стало хорошо.
>И я больше всего времени трачу не на собственно работу, а на то что сижу и конфигурирую все это говно, Ставлю Лотусы, Эксченжи, 1С, настраиваю FTP-серверы, etc., чтобы оттестить работу приложения.
Вот сеймшит, целый день сижу и пытаюсь всего лишь УСТАНОВИТЬ проект.
Зарепортил на вас. Чмошникам кю эй тут не место. Это раздел для людей, а не для петушни.
Где это ты таких дешевых ручников видел? Меньше чем за 35к даже в моём миллионике никто не работает.
>Зарепортил на вас
Научись для начала предлоги использовать правильно, даун. Где ж ты такой работаешь, чмо?
Выкатывайся из этого говна и иди в свой бизнес.
бэмп
Таким образом тестироваться может не только веб даже.
Знаю такие. Вопрос: а почему ими не пользуются?
С одной стороны, они работаю именно так, как юзер. С другой - их может программировать куда большая макака, чем те обсуждаемые выше штуки.
Нет, ручное дешевле и вообще эффективнее. Но это же айти, "разработка ПО просто так работает"
А я и не против, говорят делать вебдрайвер, сижу, аутирую
Разве что для солидных господъ - крупных сервисов с хорошими командами. Технологии пока не доросли до уровня, когда можно взять рандомную макаку и она быстро запилит нормальные тесты.
Вообще нет времени на посторонние занятия, из вещей не относящихся к работе могу выделить только перекуры, обед и выпить кофе, последнее обычно совмещается с работой. Работаем обычно с 10 (+- 30 мин) и до 19-30. Обед занимает примерно 30 минут. Часто отчеты или еще какую мелочь доделываю дома. На выхах то же не редко заползаю на окружение с целью попробовать различные идеи. Общее ощущение - время летит настолько быстро что об выходные буквально уебываюсь как головой об стену, практически всегда внезапно и, вероятно да, я слегка ебанутый на тему работы но у нас большинство таких.
Чё там самое навороченное чтобы виндовые оконные приложения автотестировать и чтоб на питоне запустилось?
Делай на виртуалке. Либо ставь юникс, либо делай бэкапы vhd.
Autohotkey. Даже питон не нужен.
Те кто пишет про то, что юнит тесты не нужны - сразу нахуй.
Те, кто считает, что автоматизация тестирования - это автотестики на селениуме по тесткейсикам ручников. Идите нахуй тоже.
Те, кто думает, что все автоматизаторы криворукие и не осилили программирование - молите бога, что бы мы не стали коллегами и я не ревьювил ваш код(хотя шанс очень маленький, что я с такими унтерменьшами буду работать).
Все вышеперечисленные - нахуй из треда, с остальными господами мы теплово лампово пообщаемся, про пирамиду автоматизированного тестирования, xunit паттерны, тестирование микросервисов, мокинг и стабинг, а так же про доставку.
1. Где работаешь?
2. Язык :)
3. Про второй пункт это потешно: в последнее время в дс2 dev in test обычно под собой подразумевает автоматизатора. Модно стало.
В оракле вот нормальные ребята сидят. Знают что такое разработка в тестировании. Правда называется не модно)
Пока все.
О себе: ex senior qa, говнокожу в java сейчас (понимаю что много не знаю)
Пиздюлей за непонимание
Cucumber это Bdd а не ddt. Вообще имхо ddt это термин для программиста в основном. Потому что грубо говоря ручное тестирование это ddt.
А так жди копания в велосипедах, если не повезет.
Ну в продакшене селениум обрастает фреймворком (кэп). Иногда этот фреймворк пишут тестироащики без помощи пряморуких людей с опытом в проектировании
>1. Где работаешь?
Я у мамки СТАРТАПЕР! Только не как студентики за еду, а на уважаемых людей, которые уже три успели продать за кучу бабоса. А до этого работал в продуктовой компании известной каждому задроту в пост-совке.
>2. Язык :)
Java, python, go. Дома пишу на джаве. На работе на змеюке и Го.
>3. Про второй пункт это потешно: в последнее время в дс2 dev in test...
Ну это да. В моём понимании, основное различие в направленности автоматизации. Я пишу свои тесты для девелоперов и ускорения доставки продукта. А обычные автоматизаторы пишут для qa, автоматизируя макакин труд.
И поэтому я боярин с мнением которого считаются и я сам решают, что и как мне автоматизировать и какими способами, а большая часть автоматизаторов - это, по мнению qa, рабы которым неоправданно много платят, и нужны они только, чтобы упростить их жизнь, а девелоперам либо похуй, либо автоматизаторы для них - это дауны недоучки.
Печально, на самом деле. Сколько раз, пытался объяснить, что говно жрать не обязательно и что сделать всё можно в разы быстрее, круче и надежнее. Но нет. Из-за людей с мануальшиной головнога мозга или ебнутых манагеров, для которых автоматизация тестирования - это "повторять поведение пользователей в UI по тесткейсикам", все было медленным, не эффективным и через жопу.
Сука, пытал бы каленым железом всех этих фреймворко-писателей. 2016 год, все уже написанно за нас, 1000 удобных маленьких библиотечек - бери да используй! Нет блять! Напишем свой легаси, нахуй не нужный, кусок говна величиною с сам код проекта и погрязнем в анальном рабстве.
Это богоугодно, осталось нахуй кукумбер выкинуть. Сириусли, кто в эти BDSM ещё верит?
Кстати, а если просто как долбоеб кликать по баннеру с одного IP (ботом), забанят ли хозяина сайта в adsense/директе? Думаю, это предусмотренно, и для старых сайтов не прокатит. Что должно случится, чтоб мой сайт забанили найух в партнерках?
Ебать ты кукарекало знатный, единственное, что понятно. "Кокок я афтамтезирую, йа даставку ускоряю" - а конкретно че, пишешь юнит или мутную "интеграционную" хуету, сосешь бабки.
>Ебать ты кукарекало знатный, единственное, что понятно. "Кокок я афтамтезирую, йа даставку ускоряю" - а конкретно че, пишешь юнит или мутную "интеграционную" хуету, сосешь бабки.
Пишу интеграционные межсервисные тесты. Пишу контрактные тесты на моках. Пишу очень редко UI тесты. Консультирую девелоперов по юнит тестам. Пишу на UI тесты тоже на моках. Короче, мы разделяем и властвуем. Ну и пару енд то енд сценариев, как пику на пирамиду автоматизации.
Огурец в идеале для всех кто работает над продуктом. Если петушков за яица держат и заставляют пользоваться то это удобно. Все видят требования и тесты более менее простые получаются. Так что дело привычки.
>Огурец в идеале для всех кто работает над продуктом. Если петушков за яица держат и заставляют пользоваться то это удобно. Все видят требования и тесты более менее простые получаются. Так что дело привычки.
В идеальном мире - да! Но, на практике доменная область идёт по пизде, репорты никто не читает. Очень часто, то что там напридумывали сложно автоматизировать. И в итоге, это очередная не нужная штука, которую надо поддерживать команде автоматизации, а всем остальным похуй.
Ну если она нужна только команде автоматизации то да. Вообще она нужна клиентам.
1) Бытие тестировщиком. У вас нет ощущения, что к вам относятся, как к второсортном говну? Какая зп? Какие перспективы?
2) Как у вас в фирме построен процесс тестирования? Стандартный вотерфол - требования, кодинг, тестирование?
3)Написание тест кейсов - на сколько они подробными должны быть? Полностью описывать вес затрагиваемый функционал или же все, кроме проверяемой фишки, вскользь?
Спаибо
1)нет, мой отдел легко может исполнить госпожу
2)аджайл tdd
3)для авто тестов важно юнит тестирование, оно не формалезуемо, а вот е2е по юзер стори мутим
>исполнить госпожу
Чтоу?
>юнит тестирование
А этим, разве, не программисты занимаются? У вас на java пишут? А автоматизируете чем - JUnit ?
Обычный Junit, остальным говном сложно проверить, очень много сложных срабатываний.
Юнит тесты и сам код пишут разные люди, иначе будет одна призма, е2е селениум и HP UFT , это только тестеры.
а ты как думал, если кодер напишет свой юнит тест, то покрытие будет согласно его пониманию, а есил второй чкловек подключится он всегда напишет по своему. в юзер стори всего пару строк, а понимание от человека к человеку разнится.
>в юзер стори всего пару строк
Мне кажется, речь уже идет не о модуле, а о системе, нет?
Если программист не делает модульного или интеграционного тестирования, как он вообще понимает, что его произведение хотя бы на минимальном уровне работает?
Покрытие юнит-тестов минимальное, там не разгуляешься
Плюсую парня.
Хороший программист понимает что в его коде происходит и пишет на это юниты. Сам.
Его задача протестировать свой код и отдать в тестирование на более высокий уровень.
Про интеграционное и системное тестирование еще вопрос. (Я например запускаю свой код и прохожу тесты, благо опыт есть 4 летний:) ) Мне кажется что каждый адекватный кодер так делать должен. Ибо нахуя отдавать нерабочий код в тестирование если потом все равно фиксить.
1) У меня в конторе на тестерах огромная ответственность, потому что заказчики могут выкатить миллионные штрафы за баг. Поэтому тестеры могут продавливать какие-то решения, а девелоперам придётся их реализовывать. ЗП у миддл QA с навыками автоматизации - 85к после налогов, полностью белая. ДС2, если что.
2) Зависит от проекта, на текущем - типа скрам. Кейсы и разработка пилятся параллельно.
3) Ручные кейсы делают акцент на проверяемой функциональности, автотесты - как придётся. Специфика проекта такова, что автотесты никак не могут покрыть gui-related части, только функционал.
>Хороший программист
>пишет на это юниты. Сам.
>Его задача протестировать свой код
это если работодатель готов платить за двойное время, на написание кода и написание тестов, иначе все хуячат в продакшен и тестирует заказчик сам
а зачем ты делишь время кодера таким образом? тесты это просто часть процесса кодинга
это часть здорового процесса, который присутствует не везде я хуй знает даже где, кроме бодишопов, в которых тестеры и нужны
пилил 2 года в конторе прогу для автоматизации тестов веба и андроида, иос и вф в будущем
в итоге получилась софтина, где пользователь может писать тесты в виде человеко-понятном виде
entertext awdaw id login №1
entertext zxczxc name password №1
clickbutton text Login №1
checktext Login incrorrect
внутри всё это разбиралось на действия и транслировалось в требуемый бекенд - дроид или веб
для веба - селениум, вокруг которого я навертел хуеву тучу кода чтобы правильно найти объект, кликнуть куда надо, отловить косяки и выебоны типа "кнопка логин вводит текст в hidden и прожимает кнопку размером 1х1 пиксель для входа"
для дроида - полностью самописная библиотека, которая через высоко и низкоуровневые вызовы делать с андроид приложением вообще всё что угодно. Вводить текст, прокручивать экран, внутренний эвристик сам решает на сколько надо
промотать экран чтобы домотаться до вьюхи чтобы с ней сделать действие, отдельный эвристик отлавливает косяки дизайна типа scrollview в scrollview. Позволяет перечислить меню и прожать его
спрашивайте ваши ответы
да, всё это на джаве, а гуи на java fx
>сап зк
>пилил 2 года в конторе прогу для автоматизации тестов веба и андроида, иос и вф в будущем
>в итоге получилась софтина, где пользователь может писать тесты в виде человеко-понятном виде
>entertext awdaw id login №1
>entertext zxczxc name password №1
>clickbutton text Login №1
>checktext Login incrorrect
>внутри всё это разбиралось на действия и транслировалось в требуемый бекенд - дроид или веб
>для веба - селениум, вокруг которого я навертел хуеву тучу кода чтобы правильно найти объект, кликнуть куда надо, отловить косяки и выебоны типа "кнопка логин вводит текст в hidden и прожимает кнопку размером 1х1 пиксель для входа"
>для дроида - полностью самописная библиотека, которая через высоко и низкоуровневые вызовы делать с андроид приложением вообще всё что угодно. Вводить текст, прокручивать экран, внутренний эвристик сам решает на сколько надо
>промотать экран чтобы домотаться до вьюхи чтобы с ней сделать действие, отдельный эвристик отлавливает косяки дизайна типа scrollview в scrollview. Позволяет перечислить меню и прожать его
>спрашивайте ваши ответы
Исходники остались?
конечно
да, что ещё забыл
сделал систему "интеграционных тестов" - можно погонять часть сценария на вебе, потом на дроиде и так в любом порядке
у нас фирма делает приложения которые имеют и веб и андроид интерфейс
для этого отдельный трендж заводи
Ну и да, знаком только с селениумом.
Офигеть. Я веб-макака с 12-летним стажем. Думал посмотреть в сторону селениума для своего проекта, но ты мне сейчас все представления разрушил.
Парень, поясни если не трудно:
1. Если, как ты говоришь, там всё стыкуется на уровне dom, то как тогда тестируют, к примеру драг-н-дроп?
2. Или как тестирую просто перемещение элементов, (на шахматной доске, к примеру, щас же есть канвасы всякие, там много можно намудрить)? Или, к примеру, дергания без перемещения?
3. Можно ли там тестировать нестандартные вещи типа длинного клика (держать зажатым и потом отпустить)?
И еще вопрос к анонам:
Какие есть тест-решения, которые бы позволяли локализовать (пускай с постфильтрацией даже) область интерфейса на основе нанесенного текста? Понятно, что для этого придется отрендерить ее и прогнать через OCR, но вроде же для десктопа такая тактика где использовалась уже? (программы-переводчики вроде не помню уже).
Накосячил с разметкой, простите.
Еще вопрос, неужели в селениуме не отправляются просто события устройства ввода фокусное окно, т.е. браузер? Может там режим какой-то специальный есть? Я помню для даже Windows 3.11 была программа, которая записывала события клавиатуры и мыши (но в рамках всей ОС), потом воспроизводишь, оно открывает нужные файлы, рисует картинки, сохраняет. Она конечно не тест и вообще игрушка, но подход-то близок. Должно же быть что-то внутрибраузерное для теста веб-страниц?
Я-то блин уже думал даже что книгу селениуму надо будет подобрать, тут на тебе.
>мануальная макака(андроид и ios тестит) у неё ЗП 1500$
Сказочки. Никто не будет платить такие деньги за такую работу.
А может заказчик за него вообще 3к платит. Чего тут невозможного-то.
Python + Selenium + WebSockets, и всякое говно через API
Сейчас думаю попробовать Appium (для себя).
А я умный, верстаю XML-формочки и пишу для них модели на PL/SQL, получая 400$.
Скоро выпилюсь нахуй.
Посоветуй шо-нить по джаваскрипт для дебилов, хочу понимать, что происходит на странице в контексте дом в разные моменты типа пейджлоад. Периодически работаю в вебдрайвером джва года, сложные действия там реализованы как-то, но если там нужно иногда заморачиваться с простым кликом, какие уж тут драг дроп.
По поводу событий ОС, по-моему, это зависит от реализации вебдрайвера. В драйвере хрома они вроде бы есть, например - на клике вычисляются координаты и якобы вызывается клик ОС.
>Я так понимаю смотреть нужно в сторону Vagrant?
This. Отличная штука, если ее правильно приготовить.
Ввожу в курс дела:
1. Есть планшет торгового представителя (агента), на нем установлен Monolit Agent, в который забиваются заказы от контрагентов.
2. Есть ПК, на котором установлен Trade Assistant, в котором строятся торговые отчеты для этих самых агентов. Порядок действий такой: строится отчет в Trade Assistant -> отчет представляет собой список товаров с указанием цены, МРЦ, названия товара, количества -> агент берет распечатку отчета и начинает вручную заколачивать заявки в планшет.
Необходимо:
автоматизировать выгрузку фактур из Trade Assistant в Monolit Agent, чтобы агенты вручную не колотили заявки, а только правили их через ПК, если возникнут какие-то проблемы.
Есть у кого какие идеи как это устроить?
Собеседование через 3 часа.
Может ли быть этот самый Selenium полезен программистишке? Ну там автоматически генерировать юнит-тесты например?
Юнит тесты и селениум-тесты совершенно разные вещи. Первые создают исскуственные ситуации, напрямую через исходный код. Вторые же имитируют действия пользователя, крутясь как будто в чёрном ящике, используя бразуер. Нет, совершенно не нужен, кроме некоторых статей про архитектуру авто-тестов.
Я все равно не понимаю зачем тебе селени ум, который предоставляет лишь возможность управлять браузером локально или на серваке
Пацаны из codeborn с тобой не согласны. Всем любимый java фреймворк для webdriver, который selenide - писался, чтобы девелоперы для своих фич сами накидывали тестики.
А разобрать приложение, посмотреть как оно работает и писать либо в базу прилаги, либо, если она общается с кем-то, реализовать протокол?
А чому не casperjs+phantomjs? Есть всякие вкусные штуки, хотя либа assert'ов хромает маленько...
Мимо веб-пидор с проектом на casperjs
Можно вебдрайвером сделать. Но по мне, так овер инжениринг. я бы маленький плагинчик под google chrome написал бы. Их писать как два пальца обосцать.
>Может ли быть этот самый Selenium полезен программистишке?
Не может, за исключением ситуаций, когда программистишка разрабатывает сам Selenium или смежные инструменты или автоматизирует тестирование чужого продукта. На селениуме делаются функциональные тесты, а их, согласно умным книжкам, не должно делать разработчику системы, в отличие от юнитов.
В приличном обществе за такой вопрос бьют в ебало. Если у твоих автотестов появилась архитектура - значит, ты хуй, который занимается хуйней в место написания тестов. Я таких даже за инженеров не считаю. Ну а если, ты просто хочешь научится писать ХОРОШИЕ тесты, то вот можешь почитать: http://xunitpatterns.com/
по дружбе начальник подкинул
наняли на новые проекты кучу тестеров, надо было как-то организовать их работу
>Если у твоих автотестов появилась архитектура - значит, ты хуй, который занимается хуйней в место написания тестов
Это, тысячу раз это. Одно "светило" подкинуло идею написания автотестов разрабами. Ну и понеслось AbstractDataProviderGenericInterfaceFactoryProducer, мы хотим подставить пару переменных и тесты сами на все случаи жизни напишутся, патамушта везде архитектурка, паттерны-хуяттерны. Нужно ли говорить, что ни во что, кроме потока боли и страданий, это не вылилось. На страничке изменился чекбокс, идем перепердоливать 10 слоев абстракции.
Ты говоришь про unit-тесты или всё же про автоматизацию тестирования? Без доёбов - поясни мне, пожалуйста, как нормально организовать структуру автотестов на длительном проекте? Что-то мне подсказывает, что без нормальной архитектуры и в бодишопе дороговато будет содержать "просто хорошие тесты"
>>797618
ну то охуенно разработанная архитектура и приводит к такой ебале.
С юнитами все просто. Один класс - один тест. Все, что не относится к тестируемому классу, мокается. Если во время создания моков возникли серьезные сложности и не удается изолировать класс, то в 95% это проблемы самого тестируемого проекта, а не тестов. Сильная связанность, являющаяся основной причиной проблем с изоляцией классов, аукнется и во время рефакторинга и во время разработки нового функционала.
С функциональными тестами, документация
https://github.com/SeleniumHQ/selenium/wiki/PageObjects
и всякие гуру
http://martinfowler.com/bliki/PageObject.html
рекомендуют использовать PageObject. Ничего особенного, просто отделяется функциональность, предоставляемая страницей, от деталей ее реализации(верстки). Такой подход позволяет типа переиспользовать компоненты.
По своему опыту скажу, не все так однозначно. Подход работает для функционала, активная разработка которого уже завершена и логика работы которого меняться уже не будет. Или для функционала, логику работы которого легко изолировать. Например, вход в систему. Как бы ни менялась верстка, суть, заключающаяся в вводе логина и пароля, вряд ли изменится.
С другой стороны, если составляющий единое логическое целое функционал разнесен на несколько страниц, и эти страницы активно меняются, то происходит засада.
Чекбокс переехал на пару страниц вперед, а селект вернулся на пару страниц назад, при этом от того, что в этом селекте выбрано, зависит дальнейшее поведение системы. В таком случае приходится перелопачивать всю кучу классов-оберток, чтобы передвинуть логику. Цена такого перелопачивания быстро перевешивает сложность поддержки кода, написанного тупо "в лоб" без всяких абстракций.
Ну а если над всем этим разрабы уже написали несколько слоев своих абстракций, то тут и начинается настоящая боль.
мимо
И про то, и про то.
Базовые принципы на которых строиться хороший тест:
1. Быстро пишется.
2. Легко читать и понять, что он проверяет.
3. Имеет одно тестовое утверждение.
4. Отсутствует связанность между тестами.
5. Не содержит логику.
6. Результат теста легко воспроизводим.
7. Не зависимо от порядка запуска тестов и количества запусков - результат всегда ожидаем.
Для того, чтобы добиться всего вот этого вот не нужно ничего придумывать, всё уже есть готовое. Сами фреймворки тестирования обеспечат тебя всем необходимым. Максимум, что тебе может понадобиться, так это вспомогательные методы, под твой тестируемый продукт. Это как с MVC и MVP - никто эту хуйню уже давно не реализует сам от проекта к проекту, а использует готовые фреймворки.
Вот вам, пацаны, годные презентации от капитана Хаоса в них мудрость автоматизированного тестирования: http://de.slideshare.net/orgeirIngvarsson/presentations
Ну и книжку про шаблона Xunit тестирования почитайте.
Годно написал. Но то, что ты описал, легко у меня фиксилось следующими нехитрыми правилами:
1. К скомпонованным в пейдж-обжекты элементам нельзя обращаться на прямую. Только через метод, описывающий законченное действие пользователя на странице. "логин", там, или "создать документ".
2. В такие методы передается объект бизнес модели, а не куча полей. К примеру login(user) - тру, login(username, password, isRemember, isAdmin, isPidor) - не тру.
3. Законченные действия пользователя со страницами - компануются в шаги, или флоу, которые описывают бизнес кейс, которые может затрагивать несколько страниц.
В каких случаях это не работает? Когда у вас в пизду перекошена пирамида автоматизации тестирования и вас всякое говно заставляют автоматизировать вебдрайвером.
Причины такой хуйни:
1. Девелоперы, которые не пишут нормальные тесты более низкого уровня, либо пишут хуйню на отъебись.
2. Ручные тестировщики, которые хотят, чтобы вы завтоматизировали весь тот бред, что они по навыдумывали из-за паранойи вызванной не способностью в инженерию и чтение кода.
3. Вы еблан, который умеет только в вебдрайвер и не может писать тесты протокольного и интеграционного уровня.
Лечится всё это пикрелейтед.
P.S.: Извините, анноны-коллеги, если кого обидел... Но у меня реально пригорает от того, что выбрав осознанно специализацию в автоматизированном тестировании, я постоянно сталкиваюсь с дремучим невежеством.
Ну. Официально его вроде как перестали поддерживать баблом. + Сейчас новые фавориты: скала и котлин. + Кроме gradle там нету ничего такого от чего бы все сказали: 'давай еще.'
Я бы попробовал убедить, что нам это не нужно.
Или вы инжей по нагрузочному за своих не считаете ?
чот мне подсказывает, что это такие же сообщества как и у программистов на разных языках. Ни больше ни меньше.
> К примеру login(user) - тру, login(username, password, isRemember, isAdmin, isPidor) - не тру.
> хранить пароль в модели пользователя
Это вообще законно?
Ну хуй знает. Понадобилось вставить микрослип для всех кнопок определенного типа после нажатия, чтобы аякс пропердеться успел, - переопределил клик, вызвал super.Click(), Sleep(), и через 10 минут уже перезапустил тесты.
А сами тесты выглядят как на пике, весь пердолинг с селекторами под капотом.
•Preparation of accurate and detailed test plans and test cases.
•Quickly learn and use in-house and external testing tools for test case design and execution.
•Clearly document and report software/hardware defects, issues and enhancements via defect tracking tools.
•Work effectively in a team setting – take direction, proactively seek out information and build productive working relationships.
•Serve as a QA engineer on an Agile/Scrum team to define user scenarios and implement tests to verify those scenarios are accounted for in the software'
Платят от 50-60 долларов в час.
Анон, почему ты еще не в сша?
Ну так давай я тебя научу английскому, а ты меня научишь быть макакой тестером.
обоснуй свою вонь
Пишу скрипты на HP Loadrunner для объемного банковского приложения на PEGA 7 с прибамбасами.
На проекте:
Разработчики: один я (напомню, что недавно вкатился в нагрузочное тестирование);
МП: блондинка 1 шт;
Аналитик: это у него не основная работа - видел в офисе 1 раз - неделю назад переписал все сценарии по бизнесу так, что мне пришлось половину скриптов переделывать.
2 недели пашу на выходных - проект спасает только то, что заказчик тупит со стендом для тестирования.
Собственно, стоит ли работать в конторе, в которой руководитель отдела \ технический директор считает, что такой вариант взлетит?
Сам раньше такой был. Рано или поздно тоже начнешь писать тесты.
Никто и не говорит, что юниттесты надо писать на каждый чих. Тривиальный код можно не тестировать.
Проиграл.
>На странице налеплено элементов, к которым кроме как километровым xpath-ом не добраться?
Дописать во вьюшку параметр вроде element-test="huita-01" и искать этот элемент [element-test="huita-01"] или //*[@element-test='huita-01'] религия не позволяет?
Учу английский. Как закончится текущий курс занятий один на один - попробую устроиться в компанию, где язык будет требоваться каждый день. Может и раньше.
Нет, ты не понял
мимо-начинающий-автоматизатор
Что именно непонятно? Класс-инициализатор PageObject, если ты пользуешься PageObject, должен его использовать.
если верить официальному сайту (это намек, анон, что прежде чем нести хуйню, можно попробовать почитать документацию), то можно с удивлением обнаружить, что селениум можно приделать к до-диезу, яве, руби-хуюби, питономешалке и прости господи, JS.
Ну это ж пользователь для тестов. И, естественно, тестовый пользователь должен быть на тестовом стенде, а не на проде. Так что законно. У моих тестовых аккаунтов везде пароль "test" =)
>Собственно, стоит ли работать в конторе, в которой руководитель отдела \ технический директор считает, что такой вариант взлетит?
Я бы не стал. Звучит так, словно ваша контора занимается лютым наебаловом.
История пока еще не успеха, но я стабильно лежу в его направлении:
пришел в аутсорсинговую контору после курсов, которые она же организовала (пригласили на испытательный срок после окончания курсов). Первый год-полтора тыкал руками, сменил проект, продолжил тыкать руками, но уже поздазаебло и начал ковырять селениум. Сейчас уже полноценная миддлота с задатками сеньора (по мнению руковводства), поруливаю джуниорами и миддлами у себя, как ручниками, так и автоматизаторами. Опыт работы - 4 года.
ну еб. Увидел "Автоматизация" - думал тут про ТОЭ и АСУТП чего будет. А тут какая-то хуйня никому не нужная. Оп, ты, внатуре, ОДИН ТАКОЙ.
Никому ненужная хуйня у тебя в штанах. А тут конкретные посоны сидят, которые тебя на бутылку насадят на раз-два.
Уровень программирования чуть выше нуля.
С чего начать? Селениум вроде везде требуют, но в то же время везде пишут что он ебанутый и сложный.
Селениум не то чтобы сложный. Он доебывает рандомно падающими тестами, но вцелом, штука относительно простая. По сути тебе лишь надо ЯП подтянуть до хоть какого-нибудь джуниорско-программистского уровня.
Опыт 0,5 года, джява.
Естественно можно, почему бы нет? Гугли QA Automation и вебдрайвер тебе в руки
я называю свой Иннокентий Вениаминович
гугли Page Object. В одном классе собираются элементы страницы и методы по работе с ними, в другом - все тесты только для этой страницы. Внутри страницы тесты можно группировать аннотациями или аттрибутами. Не скажу, как на джаве, но в C# и NUnit перед методом теста ставится аннотация типа:
[Category("Smoke")] или [Category("Regression")] или сразу комбинация нескольких категорий. NUnit умеет запускать отдельные категории тестов из .dll-ки.
Понятно, спасибо, а как тогда тестировать функциональности затрагивающие 2 и более страниц сразу? Ну, например покупка чего-то в магазине?
Да точно так же. Только в методе теста у тебя будут дергаться методы для разных страниц, дерганье которых приведет тебя к покупке. Условно говоря, на пальцах:
public void CheckBookingNumberCreated(){}
public void CheckBookingNumberCreated(){
CatalogPaeg.SelectProduct();
Cart.MakeBooking(BookingData);
ThankYouPage.CheckNumberGenerated();
}
быстрофикс
берём aws sdk и chromedriver последний: как хэндлить ситуацию, когда aws sdk октрыл неблокирующий сокет и не успел получить ответ, но мы уже отправили запрос на старт chromedriver и он охуел от такой наглости и не смог взять себе другой io?
Вся хуйня происходит из-за кода в сторонних гемов, т.е. нужен какой-то хак вроде выставить мьютекс или хз
ruby
Это копия, сохраненная 18 декабря 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.