https://github.com/b...ebdrivermanager

Спасибо тебе добрый человек

Всем привет. На проекте планируется большой рефакторинг тест-кейсов. Попутно с этим, на проект постепенно внедряется полноценная автоматизация. Как бы мне сделать так, чтобы минимизировать трудозатраты на тест-кейсы. Я рассатриваю два варианта
1. Вовсе отказаться от тест-кейсов

2. Чтобы отдельно вручную не писать тест-кейсы.  сделать так, чтобы тест-кесы писались либо как-то автоматически, либо в процессе написания автотестов, как например  в  "behavior driven testing". 

 
Но возникает ряд проблем:
1. Вовсе отказаться от тест-кейсов как я думаю - невозможно, потому что как минимум их с нас требует заказчик, причем по своему шаблону в гугл-таблицах
2. Скорее всего отказ от документации (тест-кейсов) не лучшая идея, потому что документация в общем-то нужна (наверное)

3. Не все сценарии на проекте возможно автоматизировать, значит если нет автотестов, то нет и тест-кейсов

Вопрос:

У кого есть опыт решения данных проблем? Поделитесь своими мыслями и опытом. Как вы автоматизировали тест-кейсы. Может кто-то вообще их не использует?

 

1. Непонятно. Вы собрались делать 100% автоматизацию? Так обычно не делают, хотя зависит от специфики продукта.

 

Я как раз это и имел ввиду. Что я физически не смогу автоматизировать 100% Проекта. Значит придется закрывать оставшуюся непокрытую автотестами часть - стандартными тест-кейсами. Ах их вот вообще не хочется ни писать ни поддерживать)

Как это всё более-менее грамотно объединить/построить, чтобы через N лет не выбросить автотесты совсем или потом не хвататься за голову при внесении незначительных изменений в один тест?

В моей конторе разработчики не особо хотят что-либо делать ради удобства разработки и поддержки АТ. Получается что мои тестируемые проекты тоже в некоторой степени для меня черный ящик. По этому я выкручиваюсь следующим образом:

Изучив главные аспекты автоматизации, советую максимально избегать управления тестовыми данными через UI. Используй API например для авторизации или создания пререквезитов для теста. Уж к API у тебя всегда должен быть доступ и ты должен уметь написать запрос к серверу в твоем фреймворке для автоетстов. В моем случае такой подход упрощает мне поддержку и разработку тестов.

тут видимо отсутствует компонентный тест поля, поэтому и вайнят, что может сломаться. Был бы компонентный тест, селектор был бы железный и в Вашем тесте можно его было бы сетить как угодно

 

 

 

 

 

Да, тестов нет.  Верно. Но я думал что покрытие моего теста способно заменить отсутсвтие компонентного теста

 

тут видимо отсутствует компонентный тест поля, поэтому и вайнят, что может сломаться. Был бы компонентный тест, селектор был бы железный и в Вашем тесте можно его было бы сетить как угодно

 

 

 

А как вы определяете тестовое покрытие ? Точнее как вы поняли что компонентный тест отсутствует. Скажите хоть что почитать/посмотреть

 И чтоб теперь никто из разработки не смел коммитить код без вашего одобрения и согласования.

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

 

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

 

Согласен. Но так и не понял, равноценно ли диспатчить action компонентному тесту, и как это определить?

 

Так может вам просто мстят?)))))))))))))))

 

 

Ну не) Все вроде смеялись. Но я спрошу на всякий случай)

 

А вам платят за вашу работу в тестировании или за то, что вы всем доказали, что вы правы?))

 

Да тут уже просто личный интерес возник разобраться и реально все разложить по полочкам, чтобы они вообще ничего не смогли аргументировать. Типо так наверное где угодно придеться делать. Но тут я реально чувствую какой-то пробел в знаниях автоматизации. Вот собственно и обратился за помощью на этот форум

Все правы, но вы правее))

 

1.  "То это не E2E тестирование" - да, допустим. И что из этого? Вам нужен работающий функционал или E2E обязательно?

 

Вот тут кстати есть вопрос, который мне никак не дает покоя. А полностью проверяет ли тест работоспособность той или иной фичи, если управлять им не как пользователь. Вот в том же примере выше. Допустим есть тест который выбирает тот же sql_id из drop-down листа. Можем ли мы его полностью покрыть действием со стор. Или нужно обязательно взаимодействовать с этой фичей как пользователь? Есть идеи? 

смотрите тестовую пирамиду: сайпресс должен использоваться на уровне Е2Е тестов, он не должен тестировать отдельные компоненты

 

 

 

 

 

Кстати сайпресом можно тестировать компоненты https://github.com/b...react-unit-test. Тут опять же я просто думал что если диспатчить action то этим действием можно заменить компонентный тест, поправьте если я не прав. В остальном придельно понял. Спасибо

 

Ваши коллеги - это тестировщики?

 

В основном  разрабы. Тестировщики как раз на моей стороне)

Все правы, но вы правее))

 

По всем пунктам с вами согласен. Более того. Я и делаю раздельные тесты для каждого сценария. Но я просто уже устал бодаться и постоянно доказывать свою точку зрения и типо того. В частности спасибо за идею про Е2Е и про "на что заточен тест" 

Приветствую коллеги.

Чтобы было максимально понятно, опишу максимально подробно.

Я работаю в небольшой фирме и я единственный человек, который занимается автоматизацией тестирования.  Мой стек - это cypress.io + javascript

Я знаком с некоторыми принципами автоматизации тестирования и знаю несколько способов управления тестовыми данными

1. Создание тестовых данных напрямую в БД

2. Создание тестовых данных через UI

3. Создание тестовых данных через API

4. Создание тестовых данных, используя состояние приложения (appStore)

В основном, я использую способы 3 и 4. Потому что я знаю. Что управлять тестовыми данными через UI очень дорого и тесты получаются хрупкими и т.д. 

Собственно из-за этого у меня возникает постоянный спор с коллегами, которые с автоматизацией тестирования почти не знакомы. Они утверждают следующее: (Примерно процитирую)

Цитата: “Если ты пишешь автотесты, используя такие способы как “3” и “4” . То это не E2E тестирование. Потому что в такое случае приложение не ведет себя как пользователь. И соответственно такой тест, может не найти те баги, которые найдет тест, которые пишется с помощью способа “2”.

Приведу пример пары моих реальных тестов для наглядности. Думаю вы сразу все поймете.

Пример с использованием appStore

На двух видео представлен один и тот же тест

https://ibb.co/hXtgT2J -  На этом видео, я через appStore приложения сразу ставлю  поле с sql запросом в нужное мне состояние с нужным мне sql_id, тем самым избегая хрупкости селектора и тому подобное.

Но здесь мои коллеги мне говорят (Примерно процитирую):

Цитата: При скролировании может быть какая-то ошибка, по этому неправильно сетить данные сразу в appStore, вместо того чтобы делать так, как делает пользователь

https://yapx.ru/u/FzcCI -На этом видео я использую только возможности UI и скролю вниз до тех пор, пока нужный id sql запроса не будет найден в списке. И здесь есть самое слабое место.

Очень хрупкий селектор для выбора скрола, потому что наши разработчики уверены в том, что код приложения для тестирования менять неправильно или вроде того. По этому у меня нет id на этом элементе и мне приходится скакать по парентам и чилдренам чтобы добраться до нужного мне селектора. И любое изменение дерева, сразу ломает мне весь тест.

Пример с использованием API

Представьте простой кейс. “Редактирование пользователя”

Шаги:

1. Создать пользователя

2. Отредактировать пользователя (Например изменить userName)

  На примере работы моего тестируемого приложения. На скриншоте - https://ibb.co/jfkc6D8показано, что при нажатии на кнопку “Сохранить” на предыдущем шаге, отправляется запрос, который сохраняет пользователя и возвращает user_Id.

 По этому вместо того, чтобы создавать пользователя в автотесте через UI и затем через UI его редактировать, я сразу отправляю API запрос, в котором, в пререквизитах к автотесту,  создается пользователь для редактирования. И Затем уже в UI интерфейсе я его редактирую

Но здесь мои коллеги мне говорят (Примерно процитирую):

Цитата: Ты делаешь не как пользователь. Реальный пользователь приложения не может создать пользователя через API. Он создает и редактирует его через UI по этому и ты должен делать также.

Здесь очевидна проблема хрупкости теста, в котором на шаге создания пользователя для его редактирования, тест может отвалиться по любой причине. И до редактирования тест даже не дойдет.

Спасибо что дочитали до конца

Друзья. Подскажите пожалуйста. Как мне переубедить моих коллег. Какие аргументы мне им предъявлять. Чем оперировать? В чем я не прав?

Отложите автоматизацию на пару месяцев и приведите в порядок ваши тесты. 30 - 50 шагов на тест это нечто за гранью. Если вы сейчас это автоматизируете, то через полгода проклянете свою работу из-за постоянной поддержки кода.

Как мне кажется, это все равно не решит проблему. Нужно как-то менять саму архитектуру автотестов. А с этим как раз проблемы.

2. UI тесты заменяются API- тестами, но не все, основные сценарии все равно надо проходить через UI

 

 На этот счет у меня есть идея. Приведу пример. Если я правильно вас понял, то например в моем web приложении, в UI есть кнопка, при нажатии на которую  дергается какая-то API ручка. Если я напишу тест на этот API я покрою проверку работы кнопки?  Ну и соответсвтенно если при нажатии на другую кнопку API ручка не дергается, то следовательно на эту кнопку нужно писать полноценный UI тест?

если тестируете "нажатие кнопки" то создайте компонентный юнит тест для именно этой кнопки

 

А как мне написать тест на "нажатие кнопки" если например, чтобы нажать эту кнопку, нужно до нее дойти, и перед этим сделать еще кучу действий. У меня есть конкретный пример на проекте. Мне нужно загрузить задание в спецификацию. Но чтобы дойти до загрузки этого задания, мне нужно полюбому пройти еще 3 страницы со своей логикой работы. Сразу перейти на страницу загрузки задания - невозможно, потому что стоит валидатор на необходисость заполнить нужные поля на всех предыдущих страницах...

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

Короче я в абсолютном тупике. Потому что не представляю по какой логике нужно разделять тесты и как понять для какого теста нужно писать UI тесты а для какого API. Также не понятно как не дублировать код (кроме выноса повторяющихся действий в отдельные методы).

Доброго времени суток. Надеюсь что сможете подсказать и навести на путь истинный вы выборе подхода к автоматизации.

Проект - web приложение - очень масштабное,  есть тонны бизнес схем и логики и к сожалению, полностью отсутствует автоматизация тестирования. Самая главная проблема - много сценариев на 30 -50 шагов. То есть нужно сделать все предыдущие шаги, чтобы дойти до конечного  и считать что сценарий пройден,

У меня есть небольшой опыт написания автотестов (год), используя javascript + cypress, другие фреймворки пока не пробовал. И так как это было на добровольных началах, получилось много огромных, зависимых друг от друга тестов. Сейчас же к этому хотелось бы подойти более осмысленно и ответственно, но возникают вопросы:

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

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

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

А ведь логично было бы иметь один-два теста в бот-стиле, которые бы проверяли корректность работы UI, а тест логики был бы уже совсем другой песней.

Подскажите какие-нибудь подходы для решения данной проблемы, может быть у кого-то был опыт решения подобных ситуаций.

 

 

 

Как вы определяете какой тест нужно писать для какого функционала?)

по тестовой пирамиде. тесты надо создавать на наиболее низком уровне

 

надо например ясно понимать что такое "создание спецификации". что это не "нажатие кнопки на фронте", что спецификация создаётся на бэкенде, скорее всего одним методом в который передаются все эти параметры создания

 

и тоже что такое "кнопка", что это просто компонент на странице, который можно и нужно тестировать независимо от бэкенда, РЕСТ сервисов и даже независимо от самой страницы

 

Очень доходчиво, спасибо! 

для этого создайте юнит тест на бэк-енде который проверяет сохранение спецификации

 

 

 

Как вы определяете какой тест нужно писать для какого функционала?)

В джаве пишется класс-менеджер тестовых данных. 

А какие-нибуль библиотеки используются или самописный класс?

Всем привет.

Подскажите пожалуйста. Есть ли какие-нибудь подходы, патерны и т.д. для создания/упревления тестовыми данными для UI автотестов.

Приведу пример для понимания сути вопроса.

Есть некая система с большим количеством микросервисов. У этой системы есть например пользователь, а у этого пользователя есть права на доступ в другие части системы. Например мне нужно проверить эти доступы. 

В данный момент я, посредством API запроса, создаю пререквезиты к тесту (в нашем случае пользователя с нужными правами), в самом файле теста, в блоке "before". А в теле теста использую этого  пользователя.

Через API получается быстрее и надежней создать пререквезит, чем через UI по понятным причинам. Но возникают трудности когда пререквезит состоит не из одного API запроса, а из цепочки API запросов зависящих друг от друга. 

У меня совершенно нет опыта создания пререквезитов другими способами. В интернете находил идеи создания тестовой базы данных с уже созданными в ней нужными данными для автотестов посредством docker. Где перед прогоном всем АТ БД разварачивается на тестовый стенд.

Если не трудно. Опишите пожалуйста хотябы вкратце процесс создания пререквезитов для АТ на вашем проекте, чтобы я хотябы знал в какую сторону копать. Заранее спасибо!

PS. Пишу АТ на javascript.

Спасибо за уделенное время и идеи!