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

Тестирование REST API
онлайн, начало 2 ноября
Тестирование безопасности
онлайн, начало 28 октября
Практикум по тест-дизайну 2.0
онлайн, начало 30 октября
Автоматизатор мобильных приложений
онлайн, начало 28 октября

Evgenii163

Регистрация: 26 янв 2018
Offline Активность: 08 июн 2020 07:27
*----

Мои темы

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

28 апреля 2020 - 10:20

Всем привет.

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

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

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

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

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

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

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

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


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

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

 

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

 

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

 

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


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

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


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

15 июля 2019 - 14:41

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

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

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

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

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

 

Вопрос:

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


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

26 июня 2019 - 08:28

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

 

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

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

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

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

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

 

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

 

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

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

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

 

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

 

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

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

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

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

 

Вопрос:

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

Пример:

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

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

 

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

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


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