Size: a a a

QA — Автоматизация

2019 November 06

АК

Александр Кот in QA — Автоматизация
Alexei Barantsev
офигеть... сегодня в баг-трекере мозиллы у меня переоткрыли баг, который я зарепортил 7 лет назад, его якобы не могли воспроизвести, и 2 года назад закрыли с вердиктом "не воспроизводится". а теперь он вдруг воспроизвёлся :)
offtop: старые баги всегда возвращаются
источник

AK

Alexey Kasatkin in QA — Автоматизация
Evgenii B
успеваете готовить данные или нет, есть ли коллизии тестовых данных или нет, изолированный контур или нет, в тестах датапровайдеры настроены получать тестовые данные как гипотезу или нет (хардкод значения) да полно вещей так-то.
Успеваем, есть коллизии, изолированный, если датапровайдер - это про ТестНГ, то не юзаю, про гипотезу вообще не понял, неуч, каюсь =) Честно признаться, понимания мне это всё равно не добавляет =)
источник

EB

Evgenii B in QA — Автоматизация
мне лень объяснять, поэтому вместо читания того что я тут пишу наверное проще почитать вот это:
https://github.com/2gis/2fingers
источник

EB

Evgenii B in QA — Автоматизация
если кратко: вместо подготовки данных в тесте

user = 'vasya',

в датапровайдере можно получать данные по запросу типа
User().isRegistered(True).hasFollowers(True).withReviews(True).getRandom()

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

Такой подход подразумевает, что в тестовом контуре есть достаточно данных для всех тест-кейсов в БД:, то есть слепок базы данных может быть прод-лайк или урезанный дамп с прода, а те сущности которых нет -- могут периодически по шедулеру миграциями накатываться на тестовую базу с разного рода "мутациями" полей и их значений, чтобы допустить, что в какой-то момент тест будет брать объект удовлетворяющей тестовой гипотезе, но содержащий какие-то рандомные данные якобы не влияющие на тест, Иногда выясняется, что либо гипотеза тестовых данных не верна. либо "неважные" данные оказываются важны,


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

Плюсы:
перед каждым тестом не нужно создавать исходные данные, вполне возможно они уже есть в базе (мы используем прод-лайк базу или урезанный дамп базы с полными консистентными связями таблиц) нужно просто их получить селектом (в примере 2fingers для это используется builder pattern и ORM)

Минусы:
база данных может быть не богата на данные для теста, конкретный инстанс бд может становиться пустым со временем -- если запускать на нем 100 раз подряд тесты на удаление объектов, например

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

-- гонять тестовые наборы с +- одинаковым удалением / созданием / изменением на один тестовый запуск
источник

O

Oleg in QA — Автоматизация
ух, что бы было, если бы тебе было не лень объяснять
источник

O

Oleg in QA — Автоматизация
Про воркэраунд - у нас например тестовые данные удаляются и генерятся с запасом перед прогоном. То есть не надо мониторить что где то заканяиваются данные, но у нас и ci так себе. Плюс есть функциональность  подгенеривать данные, если вдруг не хватило
источник

AK

Alexey Kasatkin in QA — Автоматизация
Evgenii B
если кратко: вместо подготовки данных в тесте

user = 'vasya',

в датапровайдере можно получать данные по запросу типа
User().isRegistered(True).hasFollowers(True).withReviews(True).getRandom()

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

Такой подход подразумевает, что в тестовом контуре есть достаточно данных для всех тест-кейсов в БД:, то есть слепок базы данных может быть прод-лайк или урезанный дамп с прода, а те сущности которых нет -- могут периодически по шедулеру миграциями накатываться на тестовую базу с разного рода "мутациями" полей и их значений, чтобы допустить, что в какой-то момент тест будет брать объект удовлетворяющей тестовой гипотезе, но содержащий какие-то рандомные данные якобы не влияющие на тест, Иногда выясняется, что либо гипотеза тестовых данных не верна. либо "неважные" данные оказываются важны,


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

Плюсы:
перед каждым тестом не нужно создавать исходные данные, вполне возможно они уже есть в базе (мы используем прод-лайк базу или урезанный дамп базы с полными консистентными связями таблиц) нужно просто их получить селектом (в примере 2fingers для это используется builder pattern и ORM)

Минусы:
база данных может быть не богата на данные для теста, конкретный инстанс бд может становиться пустым со временем -- если запускать на нем 100 раз подряд тесты на удаление объектов, например

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

-- гонять тестовые наборы с +- одинаковым удалением / созданием / изменением на один тестовый запуск
Понял, спасибо
источник

RI

Rut Inje in QA — Автоматизация
Поделитесь пожалуйста опытом. Хотим начать новый прект c# с подключением на devops server . Какова должна быть общая структура построения кода. Использовать ли в коде pageobject?или есть другие рекомендации
источник

M

Merg in QA — Автоматизация
Rut Inje
Поделитесь пожалуйста опытом. Хотим начать новый прект c# с подключением на devops server . Какова должна быть общая структура построения кода. Использовать ли в коде pageobject?или есть другие рекомендации
Да, используй. Других рекомендаций не имею.
источник

A

AnimArt in QA — Автоматизация
Здравствуйте всем. ЕСть вопрос по SoupUI. Суть в том, чтобы послать на сервер хеш номера телефона в sha3-256, используя либу bouncycastle. Пытаюсь сделать это с помощью GroovyScripta.
import java.security.MessageDigest
import java.math.BigInteger
import org.bouncycastle.jcajce.provider.digest.SHA3
 
 def attachment = testRunner.testCase.testSteps['CreateUser2'].getPropertyValue("phone");
 String sha3256 = org.bouncycastle.jcajce.provider.digest.SHA3(attachment);
 assert sha3256
 return sha3256

 log.info(sha3256)
Но библиотека импортироваться не хочет... Может кто сталкивался и знает как решить такое?
источник

M

Maksim in QA — Автоматизация
Есть вопрос с использованием trends в отчетах Allure gitlab-ci
как сделать сохранение сборок ?
источник

A

Anton in QA — Автоматизация
Maksim
Есть вопрос с использованием trends в отчетах Allure gitlab-ci
как сделать сохранение сборок ?
нет вопросов =)
источник

B

Bola in QA — Автоматизация
Такого вопроса нет
источник

M

Max in QA — Автоматизация
Подскажите пожалуйста, есть ли способ получить имя SelenideElementa передаваемого в метод ? (использую Java+Selenide)

Для примера скрин:
https://monosnap.com/file/ImcMF4reMgKvbtcleFkrMzwQQMp6n2
источник

AB

Alexei Barantsev in QA — Автоматизация
название метода получить?
источник

AB

Alexei Barantsev in QA — Автоматизация
в том виде, в котором вы написали код — нет, нельзя
источник

B

Bola in QA — Автоматизация
Alexey Kasatkin
Поделитесь, пожалуйста, опытом подготовки тестовых данных. Поясню: я сейчас пишу сценарии таким образом, что в рамках каждого сценария очищаются нужные хранилища (SQL или NoSql бд например), далее наполняются необходимыми данными для этого сценария и уже сами действия, допустим запрос в API. Есть мысли попробовать сначала готовить все данные для всего прогона, а потом уже по-быстрому сценарии прогнать. Может уже есть какая-то вундервафля, которая это умеет?
Одно время баловался с созданием тестовых данных в тестовой среде. В итоге перешел на живые обезличенные данные. Условно, нужен счёт в нац валюте с положительным остатком - в базе селектом ищется такой клиент с таким счётом. В редких случаях, для особых кейсов, создаются свои записи, но только через стандартные процедуры в системе, не напрямую в бд.
источник

M

Max in QA — Автоматизация
Alexei Barantsev
название метода получить?
ага, что бы не создавать дополнительную переменную String nameLocator, пытаюсь найти способ как можно получить название передаваемоего SelenideElement в метод
источник

PG

Peter G. in QA — Автоматизация
Добрый день!
У нас имеется десктоп программа написанная на с++
Появилось желание покрыть ее автотестами.
Нашел гайды по написаню  UI тестов для WPF приложух с помощью White - прикольно, потыкал, запускается, кнопки нажимаются, поля заполняются - результаты рисует
Смотрю на гитхабе - фреймворк то мертвый (уже пару лет как не обновляли)

Собсна вопрос - скажите, какие тулы сейчас для ЮАй тестов в мете? Или можно и с вайтом поиграться дальше 🤷‍♀
источник

M

Merg in QA — Автоматизация
Peter G.
Добрый день!
У нас имеется десктоп программа написанная на с++
Появилось желание покрыть ее автотестами.
Нашел гайды по написаню  UI тестов для WPF приложух с помощью White - прикольно, потыкал, запускается, кнопки нажимаются, поля заполняются - результаты рисует
Смотрю на гитхабе - фреймворк то мертвый (уже пару лет как не обновляли)

Собсна вопрос - скажите, какие тулы сейчас для ЮАй тестов в мете? Или можно и с вайтом поиграться дальше 🤷‍♀
источник