Автоматизация тестирования
Это вообще святая святах всего QA: именно под регрессионное тестирование разрабатывается куча продуктов, которое стоит миллионы евро.
Оно выполняется на GUI уровне
.Боюсь, что это вы бредите гелой горячкой:
Регрессионное тестирование — это проверка ранее протестированной программы, позволяющая убедиться, что внесенные изменения не повлекли за собой появления дефектов в той части программы, которая не менялась.
Регрессионное тестирование - это методика. Никакого отношения к GUI не имеет. Совсем.
Каким боком вы сюда записали юнит тесты?
Очень просто - есть тест и он зелененький. Ты делаешь изменение в коде и какой-то из уже существующих тестов становится красненьким -> внесенные изменения повлекли за собой появление дефектов в той части программы, которая не менялась.
Зы. Вы только что не сдали ISTQB Foundation Level.
Мне наплевать на ISTQB Foundation Level. Особенно, если на этом уровне надо непонимать базовые вещи.
Вы к тому же понятия не имеете, чем отличается работа программиста при написании юнит тестов от работы инженера автоматизации в отделе QA при написании регрессионных GUI тестов.
Исчо б. А если программист сделает ну, например, селениум тест и он будет быстрый, проверять "функционал" и после каждого деплоймента выполнятся, т.е. получится (в вашей терминологии) регрессионный гуи тест, его расстреляют?
Да, так какое отношение "регрессионный тест" имеет к "гуи тестам"? Я-то необразованное быдло, понятно, но другим же тоже интересно. Может снизойдёте, на вопрос ответите?
Слив засчитан. Идите работать наклейщиком почтовых марок и разносчиком писем и пакетов, раз у вас такие ассоциации.
Не могу. Пакеты тяжелее мышки...
В нормальных процессах все работает не так. Разработка сначала делается на бумаге, и только потом пишется код. При этом есть архитертор, который в теме. Так что 20 изменений делаются на бумаге и даже не в MVP.
Осталось сущий пустяк - чтобы всегда всё было нормально. И даже когда сам один работаешь в незнакомой для себя теме.
Крокодильчики у вас в голове.
Это у вас фиксация на том, что у меня фиксация только на GUI.
Я лишь сказал, что GUI тестирование это самое дорогое тестирование. И поэтому именно там нужно внедрять автоматизацию регрессионного тестирования.
А вы начинаете прибадываться к этому. И нести еще большую дичь, обзывая юнит тесты регрессионными. Хотя они к QA по сути не имеют отношения. Это инструмент разработчика
Дурачок, прости господи. Влез со своими воплями "регрессионные только на гуи уровне!" в обсуждение юнит-тестов, теперь сливается "GUI тестирование это самое дорогое тестирование. И поэтому именно там нужно внедрять автоматизацию регрессионного тестирования." Фу.
обзывая юнит тесты регрессионными. Хотя они к QA по сути не имеют отношения. Это инструмент разработчика
Спасибо, понял. На этом общение с вами заканчиваю, смысла нет.
Есть идеи как можно автоматизировать тесты без программирования и без Selenium , например возможно ли это делать в Jira Xray ? Или ещё какие либо идеи по автоматизации регрессионных тестов
Влез со своими воплями "регрессионные только на гуи уровне!" в обсуждение юнит-тестов,
лолшто? В исходном постинге идет речь о веб гуи тестах, а не о юнит тестах.
Щас глянул в недра одного самописного фреймворка а-ля ORM. Логирование на каждую операцию. Буквально вызвал функцию, залогировал - что вызвал, откуда и с какими параметрами. Создал объект - залогировал, что и как создал. Потом валидируешь этот объект - залогировал, что и как валидировал. Каждый лог это несколько строк данных. Примерно посчитал - на одну запись в БД штук 20 записей в лог. В одной большой таблице сотни миллионов записей. Логи там наверное на многие терабайты ушли за года эксплуатации.
Вопрос. А есть ли смысл в таких логах? Кто потом эти терабайты читает и разбирает? Софт был написан лет 15-17 назад, и такое ощущение, что по каким-то модным в то время практикам. По навороченности и сложности - какой-то космический корабль. Огромное число своих типов исключений, распределённые транзакции, свои самописные фреймворки для маппинга объектов, создания контролов на тогдашнем куцем HTML'е с поддержкой памяти состояния и прочего. Всё разнесено на разные части - сервер приложений, сервер сервисов, сервер для мобильного приложения, контракты контроллеры, воркфлоус, на любой класс заведён свой интерфейс, логирование через строчку, сбор всех возможных исключений, все возможные паттерны напиханы без меры. Даже простейшая операция - куча обращений между всеми этими частями с активным использованием COM+ и прочих межпроцессных взаимодействий. Но начнёшь вчитываться - какое-то огромное количество воды, многословность зашкаливает, а местами откровенно лишний код с проверками по несколько раз одного и того же. Такое ощущение, что архитектуру писал супергений, захотевший абстрагироваться вообще ото всех фреймворков на свете и всё сделать сам, а код - какие-то обезьяны. ))
А есть ли смысл
-----
Хи-хи...
Декомпельни любой мелкомягкий продукт и посмотри что там.
Если с декомпиляцией никак, то можешь поверить на слово - местами до 50% актуально-исполняемого кода занимаются именно измерением производительности и логированием.
Видимо по-другому уже никак не сбить рост производительности железа до приемлемого уровня.
Часто это не "коварство" программистов, подкупленных масонами. А таки требования заказчиков. Как только речь заходит о сервисе, разработанном для нескольких крупных клиентов, развоачиваются эпические срачи на тему "а почему мы платим 32,754% от текущих расходов, когда мы делаем только 25,72346% запросов к сервису? А давайте считать не по CPU Time а по количеству запросов?"
А логирование... Это ты для банков и страховок ничего не делал. Кое-где и операции чтения в лог уходят. И не забываем анонимизировать данные в логе. Но чтобы можно было со 100% точностью определить о каком клиенте речь. Но анонимно! Экономисты и юристы - такие лапочки...
до 50% актуально-исполняемого кода занимаются именно измерением производительности и логированием.
Если бы до 50%... Щас вытащил одну методину (method) в блокнотик, и стал удалять всё, что не делает собственно работу. Осталось из где-то 30 строчек лишь три: создать объект, присвоить значение, сохранить.
Ещё такая штука. Вот в этом многослойном приложении даже простая операция проходит через все эти контроллеры, потоки работ и прочее. Штук 20 вызовов функций. Это только в своём фреймворке и приложении, без учёта разных сторонних и уже написанных API. Каждая функция от 1 до 10 строк. Вроде всё по фен-шую, как дяди Бобы завещали, чтобы можно было легко отюниттестировать и всё такое. А потом, где-нибудь на низах, всё равно лапша на 100+ строк кода. И не какая-то банальная инициализация кучи свойство объекта, а именно много логики в одной функции. Зачастую идёт повтор того, что было сделано в предыдущей кучке вызовов. Такое ощущение, что кто писал первым, ещё как-то разбирался в этой "Звезде Смерти", а последующие челы делали уже лишь бы как-то работало, не в силах понять до конца, как вся эта каша из десятка слоёв функционирует. Не скажешь же начальству, что первые 3 месяца только знакомишься с исходниками, потом полгода пытаешься что-то делать, и лишь минимум через год-полтора перестаёшь вносить в репу новые баги. Куда там фикс старых и выкатка новых фич. Поэтому побыстрее херакс-херакс, и в отчётик начальству о свёрнутых горах.
Частое явление, да?
У нас сейчас есть актуальный кейс - проблема с БД. Создаем тикет у оракла и они (оракл) требуют Verbose лог с проблемой. Генерим лог, отправляем в оракл на анализ.
Собственно говоря, не просто так придуманы 1) уровни логгирования (error, warning, info, debug и еще куча кастомных уровней) и 2) не просто так придуманы циклические логи, сроки давности логов и ограничения по размеру логов.
Все это работает на то, чтобы получать нужную для исследования проблемы информацию. И да, если кто-то вместо уровня debug использует info, то он сам себе злобный буратино :)
А таки требования заказчиков.
-----
Гы... ну и какой заказчик, скажем, у компилятора Т4-шаблонов?
А между тем при переходе с версии на версию там не отличия от документации пофиксили, а впилили трекинг и логгинг...
Бля, Я вообще не говорю об том, чтобы дать инструмент для смены генерируемого кода... а надо, ой как надо...