Мы же можем отслеживать, по каким путям ходим (через тот же requests) и какой результат получаем? От этого можно оттолкнуться.
Про покрытия и проверки. Для первой итерации можно зайти с другой стороны - смотреть на статус коды. И 200 будут для нас приоритетным и главными(happy path). И так же проверять условные остальные 401/403 и 400. Или можно составить список, какие статус коды мы ожидаем от эндпоинта и их проверять (это и будет покрытие).
Во второй итерации уже можно так же смотреть на обязательные/необязательные и типы полей. И строить покрытие через это.
Писать руками тс по покрытию api тестов это как будто не про автоматизацию.
Спасибо. Тогда такой вопрос. У вас, например, 1000 тестов. Как тогда быть? Например, вы используете голый python + request на выходе или у вас есть какая-то структура (фреймворк) под который вы подстраиватесь?
То есть идея проверять здесь и сейчас понятна, но что делать с перспективой на будущее, когда тестов станет много?
Расскажите, пожалуйста, как вы получаете api тесты и надо ли после gpt их переписывать/адаптировать? Были ли случаи, когда gpt совершал ошибки? Вы как-то проверяете за ним результат?
Пришлось пожертвовать одной платформой (это мобильное приложение), так как веб был более важнее (по словам бизнес-аналитиков). Разработчики iOS и Android терпеливо ждали тестирования функционала.
у них же есть (наверное) опыт и компетенции, что бы протестировать самим и не терять время (время деньги(с)) в ожидании тестировщика Я всей картины не знаю, но как будто тут вопрос в процессах
Почему бы не посадить на тестирование dev команду? Фронты вполне могут покрывать автотестами ui и проводить приемку. Не совсем понимаю, зачем так "насиловать" тестировщика
В python из коробки неудобно пользоваться словарём, особенно при большой вложенности. Используете ли вы библиотеки, например attrs, marshmallows и подобные ? Как вы валидируете ответ в response, например обязательные поля, тип и длину ?
Добрый день! А такой вопрос - не стал ли ваш фреймфорк узким местом для ваших клиентов? И не придётся ли им каждый раз, при изменении системы, возвращаться к вам?
Был такой вариант, при котором они могли бы отдать тестирование своим разработчикам, думаю, плюс/минус они смогли бы написать e2e сценарии и своб систему они знают лучше (кто где после себя оставляет в базе)?
тестового пользователя, для условных get запросов, через тестовый фреймворк и дёргать его там , а не через бд? Или хранить пользователя в своей бд и оттуда его брать? Хранить id пользователя в файле при запуске тестов, если тесты особенно параллельны. И так далее.
Просто не было понятно, почему вы пришли к такому решению с redis, ещё и не совсем надёжном, так как с ваших слов кто-то может из тестеров "поломать" пользователя. Почему не рассматривалм "стандартные" решения для вашей проблемы и если рассматривали, то к чему пришли/какие проблемы были?
Раньше на каждый чих вы создавали нового пользователя и это было долго. Поэтому вы переиспользуете старых пользователей, которые "чистые" и их можно брать для тестов ?
https://github.com/berpress/swagger-coverage
Мы же можем отслеживать, по каким путям ходим (через тот же requests) и какой результат получаем? От этого можно оттолкнуться.
Про покрытия и проверки. Для первой итерации можно зайти с другой стороны - смотреть на статус коды. И 200 будут для нас приоритетным и главными(happy path). И так же проверять условные остальные 401/403 и 400. Или можно составить список, какие статус коды мы ожидаем от эндпоинта и их проверять (это и будет покрытие).
Во второй итерации уже можно так же смотреть на обязательные/необязательные и типы полей. И строить покрытие через это.
Писать руками тс по покрытию api тестов это как будто не про автоматизацию.
А если щайти со стороны сваггера и вызовов в api тестах и там проверять, что мы покрыли?
Добрый день! Вы тест кейсы создаёте руками ?
Спасибо. Тогда такой вопрос. У вас, например, 1000 тестов. Как тогда быть? Например, вы используете голый python + request на выходе или у вас есть какая-то структура (фреймворк) под который вы подстраиватесь?
То есть идея проверять здесь и сейчас понятна, но что делать с перспективой на будущее, когда тестов станет много?
Добрый день! Спасибо за статью!
Расскажите, пожалуйста, как вы получаете api тесты и надо ли после gpt их переписывать/адаптировать? Были ли случаи, когда gpt совершал ошибки? Вы как-то проверяете за ним результат?
Классно ! Используете ли вы дашборды Allure ? Или полностью на Grafana ?
Сможет ли это решить проблему? У вас потенциально 5–7 автотестеров-разработчиков, почему бы их не использовать? За качество вы же все отвечаете.
Но решать, конечно, вам.
у них же есть (наверное) опыт и компетенции, что бы протестировать самим и не терять время (время деньги(с)) в ожидании тестировщика
Я всей картины не знаю, но как будто тут вопрос в процессах
Почему бы не посадить на тестирование dev команду? Фронты вполне могут покрывать автотестами ui и проводить приемку.
Не совсем понимаю, зачем так "насиловать" тестировщика
Добрый день !
1) почему именно Java? Сравнивали с другими языками? Какие плюсы?
2) какие сложности были в процессе обучения ? Хватило ли времени на обучение?
3) какого уровня специалисты вышли (джун, мидл)? Как они развивались дальше? Появился ли у них опытный тимлид?
4) что стало с их зп?
Добрый вечер. Спасибо статью!
В python из коробки неудобно пользоваться словарём, особенно при большой вложенности. Используете ли вы библиотеки, например attrs, marshmallows и подобные ? Как вы валидируете ответ в response, например обязательные поля, тип и длину ?
Добрый день! А такой вопрос - не стал ли ваш фреймфорк узким местом для ваших клиентов? И не придётся ли им каждый раз, при изменении системы, возвращаться к вам?
Был такой вариант, при котором они могли бы отдать тестирование своим разработчикам, думаю, плюс/минус они смогли бы написать e2e сценарии и своб систему они знают лучше (кто где после себя оставляет в базе)?
А рассматривали варианты, сделать
тестового пользователя, для условных get запросов, через тестовый фреймворк и дёргать его там , а не через бд? Или хранить пользователя в своей бд и оттуда его брать? Хранить id пользователя в файле при запуске тестов, если тесты особенно параллельны. И так далее.
Просто не было понятно, почему вы пришли к такому решению с redis, ещё и не совсем надёжном, так как с ваших слов кто-то может из тестеров "поломать" пользователя. Почему не рассматривалм "стандартные" решения для вашей проблемы и если рассматривали, то к чему пришли/какие проблемы были?
Я тогда не совсем понял, какую задачу вы решали (
Раньше на каждый чих вы создавали нового пользователя и это было долго. Поэтому вы переиспользуете старых пользователей, которые "чистые" и их можно брать для тестов ?
Добрый день! Я правильно понимаю, что для тестов вы используете только Postman, без авто ?
Статья перевод из 2018 ?)
спасибо. очень жду, жаль, что поздно уивидел объявление
Добрый день. Аможно где-то в записи посмотреть ?
Забить можно на всё, было бы желание)
Но с графаной вы в разы гибче настраиваете дашбоард, который приносит (для меня) пользу, а не дашборд ради дашборда