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

Аудит и оптимизация QA-процессов
онлайн, начало 4 декабря
Практикум по тест-дизайну 2.0
онлайн, начало 4 декабря
Логи как инструмент тестировщика
онлайн, начало 30 ноября
Тестирование REST API
онлайн, начало 30 ноября

Публикации Evgenii163

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



#176376 Как создавать тестовые данные для UI тестов

Отправлено автор: Evgenii163 28 апреля 2020 - 11:23 в Автоматизированное тестирование

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

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




#176374 Как создавать тестовые данные для UI тестов

Отправлено автор: Evgenii163 28 апреля 2020 - 10:56 в Автоматизированное тестирование

 

 

 

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




#176372 Как создавать тестовые данные для UI тестов

Отправлено автор: Evgenii163 28 апреля 2020 - 10:48 в Автоматизированное тестирование

API тесты это слишком высокий уровень, от этого и проблемы

 

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

 

 

Как понять что какой-то уровень системы достаточно покрыт такого уровня тестами? Я так понимаю для этого как раз и существуют системы, которые измеряют test coverege?
И еще как понять на каком уровне находится функционал системы? Путем того как и где это функционал используется?




#176370 Как создавать тестовые данные для UI тестов

Отправлено автор: Evgenii163 28 апреля 2020 - 10:20 в Автоматизированное тестирование

Всем привет.

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

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

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

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

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

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

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

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




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

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

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

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

 

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




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

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

 

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

 

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




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

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

 

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

 

 

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




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

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

 

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

 

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




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

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

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

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




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

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

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

 

 

 

 

 

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




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

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

 

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

 

 

 

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




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

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

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

 

 

 

 

 

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




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

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

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

 

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

 

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




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

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

 

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

 

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




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

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

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

 

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




#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 по этому и ты должен делать также.

 

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

 

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

 

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




#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. Но на данный момент у меня нет возможность писать автотесты на локальную сборку внутри проекта. По этому тесты пишутся уже на расскатанный проект для тестирования




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

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

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




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

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

 

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

 

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




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

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

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

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

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

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

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

 

Вопрос:

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




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

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

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

 

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




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

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

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

 

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

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

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

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

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

 

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

 

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

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

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

 

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

 

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

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

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

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

 

Вопрос:

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

Пример:

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

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

 

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

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




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

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

 

 

 

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

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

 

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

 

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

 

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




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

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

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

 

 

 

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




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

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

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

 

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





Яндекс.Метрика
Реклама на портале