Перейти к содержимому

Публикации Evgenii163

29 публикаций создано Evgenii163 (учитываются публикации только с 29 марта 2023)



#172305 Выбор фреймворка и подхода к автоматизации тестирования

Отправлено автор: Evgenii163 27 мая 2019 - 07:24 в Автоматизированное тестирование

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

 

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

 

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

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

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

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

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

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

 



#172310 Выбор фреймворка и подхода к автоматизации тестирования

Отправлено автор: Evgenii163 27 мая 2019 - 08:47 в Автоматизированное тестирование

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

 

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




#172311 Выбор фреймворка и подхода к автоматизации тестирования

Отправлено автор: Evgenii163 27 мая 2019 - 08:48 в Автоматизированное тестирование

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

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




#172322 Выбор фреймворка и подхода к автоматизации тестирования

Отправлено автор: Evgenii163 27 мая 2019 - 13:01 в Автоматизированное тестирование

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

 

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




#172323 Выбор фреймворка и подхода к автоматизации тестирования

Отправлено автор: Evgenii163 27 мая 2019 - 13:09 в Автоматизированное тестирование

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

 

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




#172326 Выбор фреймворка и подхода к автоматизации тестирования

Отправлено автор: Evgenii163 27 мая 2019 - 13:16 в Автоматизированное тестирование

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

 

 

 

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




#172328 Выбор фреймворка и подхода к автоматизации тестирования

Отправлено автор: Evgenii163 27 мая 2019 - 13:27 в Автоматизированное тестирование

 

 

 

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

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

 

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

 

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

 

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




#172728 Как избежать повторяющихся проверок и шагов в тестировании

Отправлено автор: Evgenii163 26 июня 2019 - 08:28 в Тест-дизайн и ручное тестирование

Всем привет. При составлении тест-кейсов столкнулся с проблемами. Покажу на реальном примере. 

 

Есть список проверок:

  1. создание тестового задания 

  2. pагрузка изображения в тестовое задание

  3. cоздание тестовой спецификации

  4. прохождение теста по тестовой спецификации

 

Существуют зависимости между проверками:

 

  1. Чтобы создать тестовую спецификацию вначале мне нужно создать тестовое задание

  2. В момент создания тестового задания, мне нужно загрузить в него изображение

  3. Чтобы пройти тест,  вначале мне нужна тестовая спецификация

 

Из-за бесконечной нехватки времени, я хочу разделить функционал на приоритеты. (smoke, high, medium, low)  чтобы знать, что проверять в самую первую очередь, что проверять во вторую и так далее. И в дальнейшем иметь статистику по этим проверкам. 

 

Приоритет проверки “создание тестового задания” - smoke

Приоритет проверки “Создание тестовой спецификации” - -high

Приоритет проверки “Загрузка изображения в тестовое задание” - medium

Приоритет проверки  “Прохождение теста по тестовой спецификации” - low

 

Вопрос:

 Как избежать повторяющихся проверок и шагов в тестировании.

Пример:

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

И таких вот примеров у меня на проекте очень много.

 

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

Поделитесь пожалуйста своими идеям, может кто-то решал такую проблему?




#172740 Как избежать повторяющихся проверок и шагов в тестировании

Отправлено автор: Evgenii163 26 июня 2019 - 12:11 в Тест-дизайн и ручное тестирование

Нужен DataManager который контролирует создание и модификацию тестовых данных. Соответственно если нужные данные уже есть, просто отдает их, если нет - создает.

 

Можете  пожалуйста дать ссылку, о каком  DataManager  идет речь. Поиск в гугл не дал внятных результатов.




#172929 Как писать тест-кейсы для автотестов или как сделать так, чтобы они пи

Отправлено автор: Evgenii163 15 июля 2019 - 14:41 в Автоматизированное тестирование

Как писать тест-кейсы для автотестов или как сделать так, чтобы они писались автоматически (Извините за кривое название темы, что-то не найду как отредактировать)

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

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

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

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

 

Вопрос:

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




#172932 Как писать тест-кейсы для автотестов или как сделать так, чтобы они пи

Отправлено автор: Evgenii163 15 июля 2019 - 16:23 в Автоматизированное тестирование

 

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

 

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




#173371 Как не хардкодить путь к chrome.driver

Отправлено автор: Evgenii163 20 августа 2019 - 08:57 в Selenium - Functional Testing

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




#173935 Как работать с состоянием или сбрасывать его в web странице в UI автот

Отправлено автор: Evgenii163 03 октября 2019 - 13:52 в Автоматизированное тестирование

Есть web- приложение c большым количеством логики, которое происходит в пользовательском интерфейсе. Например при нажатии кнопки, не дергается никакое API бэкэнда, а срабатывает эвент, результат которого кладется в redux store приложения. Соответственно возникает проблема с подготовкой тестовых данных для прохождения автотеста.

Мой стек для автотестирования Cypress.io + javascript

Есть сценарий - “Загрузка медиаконтента в тестовую спецификацию”

Есть логика работы тестовой спецификации, условно три раздела:

  1. Заполнение инфы о тестовой спецификации
  2. Заполение параметров тестовой спецификации
  3. Загрузка медиаконтента в тестовую спецификацию

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

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

Очевидно что такой автотест написан плохо, и его нужно делить. Потому что он проходиться долго и весьма хрупкий.

Соответственно возникает вопрос:

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

Может есть вообще какие - то инструменты для управления тестовыми данными через UI, где есть какая-то возможность скажем сделать часть полей web-страницы заполненными сразу при навигации в тесте, а часть нет.
В том фреймворке, rоторый я использую “https://www.cypress.io/” есть возможность работать с redux store, но только если сам cypress интегрирован в локальную сборку в качестве dependency. Но на данный момент у меня нет возможность писать автотесты на локальную сборку внутри проекта. По этому тесты пишутся уже на расскатанный проект для тестирования




#174611 Прошу помощи в споре с коллегами про принципы разработки автотестов

Отправлено автор: Evgenii163 26 ноября 2019 - 14:00 в Автоматизированное тестирование

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

 

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

 

Я работаю в небольшой фирме и я единственный человек, который занимается автоматизацией тестирования.  Мой стек - это 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 по этому и ты должен делать также.

 

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

 

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

 

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




#174615 Прошу помощи в споре с коллегами про принципы разработки автотестов

Отправлено автор: Evgenii163 26 ноября 2019 - 14:35 в Автоматизированное тестирование

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

 

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




#174616 Прошу помощи в споре с коллегами про принципы разработки автотестов

Отправлено автор: Evgenii163 26 ноября 2019 - 14:35 в Автоматизированное тестирование

 

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

 

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




#174617 Прошу помощи в споре с коллегами про принципы разработки автотестов

Отправлено автор: Evgenii163 26 ноября 2019 - 14:42 в Автоматизированное тестирование

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

 

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

 

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




#174619 Прошу помощи в споре с коллегами про принципы разработки автотестов

Отправлено автор: Evgenii163 26 ноября 2019 - 14:46 в Автоматизированное тестирование

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

 

 

 

 

 

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




#174620 Прошу помощи в споре с коллегами про принципы разработки автотестов

Отправлено автор: Evgenii163 26 ноября 2019 - 14:57 в Автоматизированное тестирование

 

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

 

 

 

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




#174628 Прошу помощи в споре с коллегами про принципы разработки автотестов

Отправлено автор: Evgenii163 27 ноября 2019 - 07:32 в Автоматизированное тестирование

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

 

 

 

 

 

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




#174629 Прошу помощи в споре с коллегами про принципы разработки автотестов

Отправлено автор: Evgenii163 27 ноября 2019 - 07:33 в Автоматизированное тестирование

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

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




#174630 Прошу помощи в споре с коллегами про принципы разработки автотестов

Отправлено автор: Evgenii163 27 ноября 2019 - 07:35 в Автоматизированное тестирование

 

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

 

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




#174633 Прошу помощи в споре с коллегами про принципы разработки автотестов

Отправлено автор: Evgenii163 27 ноября 2019 - 08:31 в Автоматизированное тестирование

 

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

 

 

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




#174636 Прошу помощи в споре с коллегами про принципы разработки автотестов

Отправлено автор: Evgenii163 27 ноября 2019 - 09:45 в Автоматизированное тестирование

 

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

 

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




#174673 Как грамотно построить архитектуру автотестов?

Отправлено автор: Evgenii163 29 ноября 2019 - 14:52 в Автоматизированное тестирование

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

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

 

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