))). Я бы не против увидеть статью с практическими примерами создания AGI за 10-15 минут. Быть может создание сервера с использованием существующего API некого AGI вполне возможно, но нужно немного разобраться в этой теме.
Я думаю если рассматривать вариант оптимального решения задачи тестирования API, вероятно вы предложили лучшее решение и существует еще несколько. Данный пример можно рассматривать как возможный вариант использования, но не как рекомендацию для достижения максимальной производительности.
Playwright может быть использован и как инструмент для тестирования бекэнда, так и данный пример может быть частью какого-то более сложного сценария с использованием UI.
На самом деле в ваших словах есть доля правды, cucumber уже давно не является популярным инструментом для тестирования. Но все же попробую донести мысль на следующем примере.
Существует некое веб приложение. Оно имеет множество схожих страниц с различными данными. Существуют таблицы с различными колонками и одинаковыми типом данных Стоит задача покрыть тестами данную часть приложения используя некую методику и использовать множество вариаций тестовых данных.
Пример веб приложения
Достаточно создать основу с 1 тестом для 1 страницы одному опытному QA.
@test1
Scenario: Test 1 - Section 1 Page 1 - Verify table values and manufacturer filter
Given DB service insert data "Section_one_page_one.json"
When PageOne open page
Then PageOne verify table values
| Model | Type | Color |
| Test model 1 | Test type 1 | Test color 1 |
When PageOne select filter "Manufacturer" value
| Test manufacturer 1 |
Then PageOne verify table values
| Model | Type | Color |
| Test model 2 | Test type 2 | Test color 2 |
Далее задача покрыть все страницы тестами может быть передана менее опытному тестировщику. Который в последующем к примеру исходя из базы тест кейсов напишет тесты для имеющейся страницы используя определенный набор тестовых данных - просто копируя имеющиеся шаги в файле .feature и изменяя вводные данные
Scenario: Test 2
...
When PageOne select filter "Manufacturer" value
| Test manufacturer 2 |
Then PageOne verify table values
| Model | Type | Color |
| Test model 3 | Test type 3 | Test color 3 |
Scenario: Test 20
...
When PageOne select filter "Date" value
| 09-09-2024 |
Then PageOne verify table values
| Model | Type | Color |
| Test model 50 | Test type 50 | Test color 50 |
Для тестирования следующих, практически идентичных по строению страниц, но с немного другими элементами, достаточно создать новые файлы в step_definitions и page_objects которые будут почти идентичны имеющимся созданным для первой страницы К примеру изменения будут выглядеть:
let PageOne: Page_One -> let PageTwo: Page_Two await PageOne.openPage(); - > await PageTwo.openPage();
Продолжить писать тесты по аналогии в .feature
Scenario: Test 100
...
When PageTwo select filter "Side" value
| Test side 10 |
Then PageTwo verify table values
| Box | Type | Date |
| Test box 3 | Test type 3 | 01-01-2001 |
Scenario: Test 501
...
When PageSix select filter "Color" value
| Red |
Then PageOne verify table values
| User | Date | Work |
| Test user 5 | 01-01-2001 | Done |
Надеюсь в данном примере мысль более детально раскрыта.
С первого взгляда тоже напомнило Base64, насколько я помню в месте с protobuf можно сделать кастомный шифр Base64, который без спец. файла с инструкциями корректно не расшифровать. Еще вариант обезопасить свои сообщения - на Эльфийском переписываться. Если схватят за зад - язык то выдуманный какие могут быть претензии))
Информация
В рейтинге
Не участвует
Откуда
Россия
Зарегистрирован
Активность
Специализация
Test Automation Engineer, Quality Assurance Engineer
))). Я бы не против увидеть статью с практическими примерами создания AGI за 10-15 минут. Быть может создание сервера с использованием существующего API некого AGI вполне возможно, но нужно немного разобраться в этой теме.
Я думаю если рассматривать вариант оптимального решения задачи тестирования API, вероятно вы предложили лучшее решение и существует еще несколько. Данный пример можно рассматривать как возможный вариант использования, но не как рекомендацию для достижения максимальной производительности.
Playwright может быть использован и как инструмент для тестирования бекэнда, так и данный пример может быть частью какого-то более сложного сценария с использованием UI.
Приветствую amarkina17.
На самом деле в ваших словах есть доля правды, cucumber уже давно не является популярным инструментом для тестирования. Но все же попробую донести мысль на следующем примере.
Существует некое веб приложение. Оно имеет множество схожих страниц с различными данными. Существуют таблицы с различными колонками и одинаковыми типом данных Стоит задача покрыть тестами данную часть приложения используя некую методику и использовать множество вариаций тестовых данных.
Достаточно создать основу с 1 тестом для 1 страницы одному опытному QA.
Далее задача покрыть все страницы тестами может быть передана менее опытному тестировщику. Который в последующем к примеру исходя из базы тест кейсов напишет тесты для имеющейся страницы используя определенный набор тестовых данных - просто копируя имеющиеся шаги в файле .feature и изменяя вводные данные
Для тестирования следующих, практически идентичных по строению страниц, но с немного другими элементами, достаточно создать новые файлы в step_definitions и page_objects которые будут почти идентичны имеющимся созданным для первой страницы
К примеру изменения будут выглядеть:
let PageOne: Page_One
-> let PageTwo: Page_Twoawait PageOne.openPage();
- > await PageTwo.openPage();Продолжить писать тесты по аналогии в .feature
Надеюсь в данном примере мысль более детально раскрыта.
С первого взгляда тоже напомнило Base64, насколько я помню в месте с protobuf можно сделать кастомный шифр Base64, который без спец. файла с инструкциями корректно не расшифровать.
Еще вариант обезопасить свои сообщения - на Эльфийском переписываться. Если схватят за зад - язык то выдуманный какие могут быть претензии))