MO
Не помогла
Size: a a a
2020 August 14
IR
А я минут через 5-10 гляну у себч
IR
Ты сам заполнял .bash_profile? Или копипастил?
MO
сам заполнял, для моей версии ОС нужен ~/.zshrc
IR
сам заполнял, для моей версии ОС нужен ~/.zshrc
У меня такая же, я делал как выше писал
TD
#вопрос
Люди добрые, подскажите пожалуйста стратегии автоматизации e2e.
У нас есть много описанных ручных сценариев, были старые тесты на основе eggplant (работали по image recognition), но писать автотесты, повторяющие 1-в-1 ручные сценарии кажется не очень хорошей идеей.
1 длинный воркфлоу тест уже есть, покрывающий основной и самый главный сценарии приложения.
Думаю добавить тесты на каждый экран приложения (просто проверить наличие элементов и возможно, открытие внутренних попапов/меню).
Что дальше? Как приоритизировать сценарии?
Очень не хочется разводить e2e тестов длительностью более 2-3 часов... Но это трудно избежать, API у приложения нет совсем (это десктоп wpf)
Люди добрые, подскажите пожалуйста стратегии автоматизации e2e.
У нас есть много описанных ручных сценариев, были старые тесты на основе eggplant (работали по image recognition), но писать автотесты, повторяющие 1-в-1 ручные сценарии кажется не очень хорошей идеей.
1 длинный воркфлоу тест уже есть, покрывающий основной и самый главный сценарии приложения.
Думаю добавить тесты на каждый экран приложения (просто проверить наличие элементов и возможно, открытие внутренних попапов/меню).
Что дальше? Как приоритизировать сценарии?
Очень не хочется разводить e2e тестов длительностью более 2-3 часов... Но это трудно избежать, API у приложения нет совсем (это десктоп wpf)
АК
" но писать автотесты, повторяющие 1-в-1 ручные сценарии кажется не очень хорошей идеей."
Почему?
Почему?
AS
В идеале автотесты не должны быть такими же, как ручные тесты. Их надо проектировать по-разному. У них разные цели и разные возможности.
МЁ
Andrei Solntsev
В идеале автотесты не должны быть такими же, как ручные тесты. Их надо проектировать по-разному. У них разные цели и разные возможности.
почему?
AS
Ручными тестами надо покрывать то, что сложно поддаётся автоматизации и требует вмешательства мозга.
AS
Автотестами надо покрывать то, что быстро, много и легко поддаётся автоматизации.
AS
Т.е. те вещи, которые компьютеру легко проверить. Есть текст - нет текста. Есть айдишник - нет айдишника.
МЁ
покрывать автоматизацией нужно то что будет гоняться долго и часто
МЁ
а так же то, что руками не проверишь.
МЁ
чтобы затраты на написание теста окупились экономией живого времени.
МЁ
а так же убрали эффект снижения внимательности
МЁ
если вы уже заморочились написание тестового фреймворка и описание каждого экрана например, то затраты на написание каждого последующего теста становятся крайне невелики: кликнул кнопочку - проверил переход или открытие. кликнул следующую кнопочку
2020 August 15
АК
Andrei Solntsev
Т.е. те вещи, которые компьютеру легко проверить. Есть текст - нет текста. Есть айдишник - нет айдишника.
Смысл автотестов чтобы автоматизировать все возможно , и не возвращаться к этому больше.
Коллега сверху все хорошо расписал.
Коллега сверху все хорошо расписал.
AS
Ну да, не вижу противоречий.
2020 August 17
AD
#вопрос
Люди добрые, подскажите пожалуйста стратегии автоматизации e2e.
У нас есть много описанных ручных сценариев, были старые тесты на основе eggplant (работали по image recognition), но писать автотесты, повторяющие 1-в-1 ручные сценарии кажется не очень хорошей идеей.
1 длинный воркфлоу тест уже есть, покрывающий основной и самый главный сценарии приложения.
Думаю добавить тесты на каждый экран приложения (просто проверить наличие элементов и возможно, открытие внутренних попапов/меню).
Что дальше? Как приоритизировать сценарии?
Очень не хочется разводить e2e тестов длительностью более 2-3 часов... Но это трудно избежать, API у приложения нет совсем (это десктоп wpf)
Люди добрые, подскажите пожалуйста стратегии автоматизации e2e.
У нас есть много описанных ручных сценариев, были старые тесты на основе eggplant (работали по image recognition), но писать автотесты, повторяющие 1-в-1 ручные сценарии кажется не очень хорошей идеей.
1 длинный воркфлоу тест уже есть, покрывающий основной и самый главный сценарии приложения.
Думаю добавить тесты на каждый экран приложения (просто проверить наличие элементов и возможно, открытие внутренних попапов/меню).
Что дальше? Как приоритизировать сценарии?
Очень не хочется разводить e2e тестов длительностью более 2-3 часов... Но это трудно избежать, API у приложения нет совсем (это десктоп wpf)
Я бы посмотрел в сторону возможности параллелизации, часы для тестов это долго, мало ли что за это время может случиться с окружением