Автоматизация тестирования
Давайте лучше о том, что интерфейсе Ебея - лютое овнище, представляющее собой мешанину текста и картинок, непонятно как связанных. Структурирования, такое ощущение, нет никакого. Где один блок, где другой, и что за что отвечает. Чтобы понять описание товара, нужно прорыскать всю страницу. Плюс личные настройки находятся в двух менюшках, разнесённых по разным углам - верхняя правая и верхняя левая. Почему не поместить всё в одном месте? Думаю, такой антипаттерн дизайна сделан, чтобы пользователь постоянно шарился по всей странице, силясь найти нужные кнопки, описания и ссылки. Так он точно прошерстит всю рекламу, которой любая страница Ебея просто завалена.
Точно не знаю, вот хотел енто попробовать
https://github.com/testsigmahq/testsigma
Есть вроде и довольно дорогая версия.
...
Вот еще нашел
https://www.perfecto.io/products/scriptless#tab-panel-4536...
Понимаю, что у вас могут быть эмоции по поводу определенных компаний и их подхода к разработке программного обеспечения. Различные компании могут иметь разные подходы к управлению проектами, тестированию и качеству продукции. Некачественное программное обеспечение может быть результатом различных факторов, включая недостаточное тестирование, неправильное управление и многие другие аспекты.
Квалификации и сертификаты, такие как ISTQB, могут быть полезными, но не всегда гарантируют качество разработки или управления проектами. Важно учитывать, что решения, принимаемые в компаниях, могут быть сложными и зависеть от множества факторов, включая бизнес-цели, ресурсы и сроки.
Если у вас есть конкретные вопросы или интерес к обсуждению каких-либо аспектов программной разработки, я готов вам помочь.
Вы правильно заметили, что пользовательский интерфейс играет важную роль в опыте пользователей на веб-сайтах, и не всегда он может быть оптимизирован для удобства пользователей. Недостаточное структурирование информации и сложные многоуровневые меню могут сделать навигацию затруднительной.
Некоторые веб-сайты могут использовать такие дизайн-решения для максимизации вовлеченности пользователя или для размещения большего количества рекламных материалов. Однако, это не всегда приносит пользу, и многие пользователи предпочли бы более интуитивный и структурированный интерфейс.
Как пользователь, вы можете выражать свои предпочтения и обратную связь на сайтах, таких как eBay, чтобы помочь им улучшить пользовательский интерфейс. Ваши комментарии и предложения могут внести позитивный вклад в развитие интерфейса и улучшение опыта пользователей.
Точно не знаю, вот хотел енто попробовать
https://github.com/testsigmahq/testsigma
Есть вроде и довольно дорогая версия.
...
Вот еще нашел
https://www.perfecto.io/products/scriptless#tab-panel-4536...
Непонятно, как эти штуки работают, если для GUI тестирования нужно не только на контролы понажимать и повводить что-то, но и визуально понаблюдать, что происходит. Вот это последнее эти системы как контролируют? Поэтому и нанимали раньше людей (пока в ФААНГах не стало модным на этом экономить), которые все кнопочки руками протыкивали и смотрели результат глазами. Ну максимум можно протыкивание автоматизировать, а наблюдать результат-то всё равно самому надо.
инструмент, где я мог бы записывать последовательность действий(мышь+клавиатура) примерно как в мс офис запись макросов.
У него была для нас одна проблема - работал исключительно под виндой. Поэтому сложно было его использовать в CI/CD.
Чисто из энтомологического интереса, а где вы эту псевдоразумную чушь нашли? Из статейки на хабре? "Дождь отличается от жидких осадков, потому что дождь идёт, а осадки выпадают". :)
1. Цель тестирования:
- GUI тест проверяет, работает ли интерфейс приложения правильно и соответствует ли он спецификациям дизайна.
- Регрессионный GUI тест используется для проверки, не повредились ли существующие функциональности приложения
Ога. "Работает правильно" и "не повредились ли". Прям огромная разница, понимаю.
Или вы хотите сказать что "гуи тест" тестирует интерфейс (ну, допустим, хотя в 99% случаев это просто синоним е2е), а вот РЕГРЕССИОННЫЙ гуи тест тот ого-го! он функциональность приложения тестирует! Ауф! :) Ну, т.е. является е2е тестом.
2. Частота выполнения:
Тут прям совсем ой. Выполняем два раза в день - регрессионный. Выполняем раз в неделю - не, не регрессионный.
3. Объем тестов:
Сдаюсь. Нет слов. Так-то все автоматизированные тесты стараются делать чем меньше, тем лучше. Про FIRST слышали? Но бывают и для регресса забабаханные монстры, работающие по 2-3 часа. Только не надо сейчас в дебри нагрузочных тестов / тестов производительности лезть.
4. Автоматизация:
Ну и очередная благоглупость. Чаще, реже...
Давайте я открою вам глаза. Любой тест, который мы повторяем (не важно после каждого или после каждого 10 изменения, каждый час или каждую неделю, за одну секунду или за 5 часов, юнит, интеграционный, компонентный, системный, е2е) можно назвать регрессионным. Главное чтобы тест не менялся между запусками и мы сохраняли предыдущие результаты тестирования. Всё. Никакого колдунства. Поэтому не надо этим термином размахивать. Он для автоматизированных тестов как напоминание про то, что дождь мокрый. ISTQB оно просто не про автоматизированные тесты. А про тестирование вообще. Ручками.
В случае автоматизированных тестов тоже можно использовать термин "регрессионный тест". Чтобы подчеркнуть одно - цель тестирования. Если мы пишем автоматизированный тест, которые не проверяет контракт, не интеграционный, не функциональный, то мы что? Мы называем его регрессионным. Мы хотим "зафиксировать" текущее состояние. Хотя оно нигде не предписано. Зачем это обычно надо? Защита от "побочных эффектов". Частый пример - использование конвенций наименований. Легко сломать код, по незнанию обозвав что-то так, что этот код на это имя среагирует. Тест, написанный как регрессионный это всегда white-box, всегда от деталей имплементации зависит. (ну, тут просто, да? black-box тест всегда можно обозвать контрактным тестом)
Да и ещё. Никогда, нигде и никто до вас не говорил такую чушь что "регрессионные тесты это гуи тесты". Вы - первый. :)
очно не знаю, вот хотел енто попробоватьhttps://github.com/testsigmahq/testsigma
Есть вроде и довольно дорогая версия....Вот еще нашелhttps://www.perfecto.io/products/scriptless#tab-panel-4536...
спасибо
помочь им улучшить пользовательский интерфейс
------
Бесполезно.
В большинстве случаев - отвечающий на описание проблемы не в состоянии понять суть проблемы.
Вот пример:
Тот же ЕБай... выбираешь место доставки - Ирландия, выбираешь валюту - евро... Все - Ок.
Смотришь что-то из российского сегмента... опсс - доставка - Москава, платежное средство - рубль... цены - в рублях...
Проблема - элементарная, решение делается минут за 20-ть - описана детально и давно... но вопрос не решается уже более 3-х лет...
Чтобы у местных продавцов заказывать, там надо менять язык на язык вашего региона. Что там в Ирландии - не знаю. Ирландский английский? Вобщем, тогда поиск будет по местным продавцам, соответственно и доставка от местных, которая зачастую бесплатна, а не международная за десятки баксов. Может, они решили, что раз всё равно международную доставку никто не заказывает (невыгодно), то и привяжем жёстко локаль к локации? Но как быть иностранцам зарубежом, которые тоже хотят Ебеем воспользоваться? Как англоговорящему работать с Ебеем в арабских или азиастких странах с их иерогливами? Переводить страницу сервисами перевода?
Чтобы у местных продавцов заказывать, там надо менять язык на язык вашего региона.
-----
Зачем?
Мне нужны цены в той валюте в которой Я буду платить, в той, в которой счет, со всеми накрутками по обмену валют.
Мне абсолютно пофиг каков региональный язык места проживания/доставки - это нужно только для указания адреса - мне нужна информация на том языке который мне понятен.
у меня такое ощущение, что вы не айти специалист. И в своей жизни ничего тяжелее мышки не поднимали.
И с логикой в голове у вас огромные проблемы. Вч путаете посылку и заключение.
Ога. "Работает правильно" и "не повредились ли". Прям огромная разница, понимаю.
Разница огромная. И вы вырвали фразу из контекста
GUI тест проверяет, соответствует ли ПО спецификациям дизайна.
Которые обычно на полтора километра и выполняются месяцами или даже годами. А может быть даже и не выполнится
а вот РЕГРЕССИОННЫЙ гуи тест тот ого-го!
Вы русский язык сначала выучите. Что вы понимаете под ого-го ?
он функциональность приложения тестирует!
Хорошая попытка, но нет. Пытайтесь троллить где-нибудь в другом месте.
Регрессионный GUI тест используется для проверки, не повредились ли существующие функциональности приложени
Вы
Тут прям совсем ой. Выполняем два раза в день - регрессионный. Выполняем раз в неделю - не, не регрессионный.
Вы считаете, что если поменяли посылку с заключением, то стали самым крутым троллем на германке?
Регрессионные GUI тесты можно выполнять часто, так как они быстрые. Так как тестируют не по всей спецификации, а только по той, что может сломаться.
Конкретный пример:
О баге было сообщено производителю. Был написан автотест, который воспроизводит баг. Это будущий регрессионный тест. Производитель исправил его. Прогнали тест — он стал зеленым.
Далее новый релиз — исправили другие баги. Этот тест мы тоже будем прогонять, если нужно, чтобы убедиться в том, что в результате фикса новых багов не была нарушена работа уже пофиксенного функционала.
Поэтому не надо этим термином размахивать
Этим термином размахиваю не я, а очень много серьезных фирм. Но пришел вася с германки и начал ставить все под сомнение.
Так что становитесь в очередь за работой по разгрузке шин. Это для вас вполне посильная работа..
у меня такое ощущение, что вы не айти специалист. И в своей жизни ничего тяжелее мышки не поднимали.
Пф, тяжелее мышки не поднимал, но почему-то не IT специалист, а наоборот - должен шины разгружать... И этот человек рассказывает что я "посылку от заключения не отличаю" :)
Чего ж их не отличить. Посылки почта возит, а в заключении преступников содержат. Правильно?
троллить... Я ещё и не начинал. :)
Давайте, чтобы не растекаться мыслью... Всё что вы пока что писали - ерунда. Живите с этим :)
И вернёмся к истокам. Попробуйте всё же пояснить, какое отношение регрессионные тесты имеют к "GUI уровню" (и что вы вообще под этим понимаете).
Это вообще святая святах всего QA: именно под регрессионное тестирование разрабатывается куча продуктов, которое стоит миллионы евро.
Оно выполняется на GUI уровне.
Слив засчитан. Идите работать наклейщиком почтовых марок и разносчиком писем и пакетов, раз у вас такие ассоциации.
Вы к тому же понятия не имеете, чем отличается работа программиста при написании юнит тестов от работы инженера автоматизации в отделе QA при написании регрессионных GUI тестов.
Это разные должности, разные отделы, разные начальники, разные зарплаты, разные требования,.
Вам нужно пройти друг у друга собеседование. В закрытом помещении с подпёртой снаружи дверью и маленьким окошком для наблюдения. ))
А как сделать, чтобы все кейсы кода покрыть? Чтобы не было неожиданных выбросов и поведений?
Никак.
Однако надо сказать, что есть системы в которых требования к софту черезвычайно высоки (например авионика) в таких случаях покрытие юнит-тестами необходимое и очень дорогое удовольствие. Вообще говоря, стоимость покрытия кода юнит-тестами растет по экспоненте. Именно поэтому покрытие в 70-80% - это очень хороший результат.
Если я первый раз в теме, и ещё не знаю, как всё работает, а моя идея ещё до конца не оформилась, и я меняю поведение в зависимости от пришедших новых идей, то будет по 20 изменений в месяц.
В нормальных процессах все работает не так. Разработка сначала делается на бумаге, и только потом пишется код. При этом есть архитертор, который в теме. Так что 20 изменений делаются на бумаге и даже не в MVP.
назад
список