Если задача вернется в редев несколько раз - придется столько же раз делать и позитивное тестирование - и чаще всего совершенно безосновательно. С современными средствами разработки, даже у джуна редко получается сделать не то, "что надо", да и, в общем-то, это плохой тон, отдать задачу в тестирование, вообще не проверяя, что ты сделал. Проблемы начинаются, когда мы делаем шаг (а может даже и шажок) в сторону от того, "как надо". Поэтому сначала - если уж задача дошла до тестирования - те кейсы, которые вероятнее всего найдут ошибку. Да, это вполне могут быть и позитивные тесты - но, в них ошибки все-таки попадаются реже. А вот после того, как все баги исправлены, перед тем, как двинуть задачу в деплой - да, вот здесь проверка основного сценария просто обязательна
Что вы понимаете под строгой типизацией? В общем, C/C++ - не строго (не сильно) типизированные языки. Да, типизация явная и статическая, но не строгая. В отличие от того же Python, где все наоборот
Все-таки, кажется, что у нас разное понимаение API)) Те апи, при помощи которых фронт общается с бэком - по умолчанию доступны тому самому пользователю, который делает манипуляции в браузере. Да, content-type может быть не application/json, а какой-нибудь application/x-www-form-urlencoded . Да, авторизация точно будет не базовой, а, скорее всего, по куке. Да, вы можете не увидеть этот запрос в консоли разработчика в браузере. Но, все это решается - и решается точно быстрее чем через селениум. И работать точно будет быстрее и стабильнее
Мне стало очень интересно, что такое API в вашем понимании? Запросы из браузера - с фронта - уходят на бэк. Уходят через какой-то... хм... интерфейс)) Значит этот интерфейс можно использовать без браузера
Т.е. бэка вообще нет, форма с фронта инсертит прямо в БД?)) Даже если и так - все может быть, я действительно могу не знать - все-равно проще сделать реализацию на более низком уровне, т.е. инсертить в БД без посредничества драйвера и фронта.
Видел два комментария сверху, видел ответы на них - долго, нет времени. Но, всё-таки задам тот же вопрос - зачем здесь селениум? Без селениума как раз все будет быстрее проще и надёжнее. Почему нельзя дергать те же api, но без посредников в виде драйвера и браузера?
Если делить одну из теорем Вейерштрасса на 1 и 2 (так действительно делают) - то первая будет о том, что непрерывная функция, таки ограничена на компакте. О том, что она достигает максимума и минимума на этом компакте - это уже вторая теорема. Но, вопрос о значимости меня так же ставит в тупик. Ну и вопрос о том, почему люки круглые... простите, об отличиях REST и SOAP - зачем сравнивать архитектурный стиль и протокол? Ну спросите чем SOAP отличается от XML-RPC, если нет более важных вопросов на собеседовании
Если мы делаем велосипеды, то проверка того, есть ли у него колеса, руль, тормоза, из какого материала сделана рама, правильными ли болтами и гайками все скручено и куча всего остального в том же духе - это верификация. А когда мы берём готовое изделие и начинаем проверять может ли оно ехать в принципе и как ехать - это валидация. Всё.
Лучший тренажёр - https://istqb-training.ru/ Да, возможно, вопросы не самые свежие - для силлабуса 2011 года. Перевод оставляет желать лучшего (но можно проходить тесты на английском). Но, учитывая, что сделано это все на голом энтузиазме - автору огромный респект
Слабо себе представляю сценарий, который можно реализовать с помощью Gatling и нельзя с помощью JMeter. И для JMeter есть два официальных плагина для работы с веб-сокетами.
Я понимаю ваше сарказм. Но мне приходилось работать с самыми разными типами авторизации, получением токенов и т.д. Выполненный JS в любом случае что-то куда-то отсылает и получает в ответ токен. Да, не всегда это получается прямо и без бубна, но получается всегда. Даже если нет готового решения всегда можно его написать. Благо JMeter поддреживает java, js и groovy (я не говорю о написании своего плагина — трудозатраты возможно не будут сопоставимы с выгодой). Кроме того, если без браузера никак — можно запускать его прямо из сценария JMeter, получать токен и снова выключать — это будет меньшим костылем, но все-таки костылем
А в чем проблема получить токен с помощью постпроцессора JMeter? "Открываем" нужную страницу, ищем на ней токен, записываем в переменную и используем ее там, где необходимо. Может быть я не понял задачу, но я всегда делаю именно так
Тест-дизайн, тест-анализ… чо уж там там говорить про какое-нибудь формальное рецензирование… «автоматизация — отличный инструмент для облегчения и оптимизации тестирования» — грамотно написанная ПМИ сэкономит вам гораздо больше времени и нервов
Потому что неважно, есть дети у Ольги или нет). Если нет, то Иван с детьми смотрит на Ольгу без детей. Если есть, то Ольга с детьми смотрит на Андрея без детей. Так что ответ однозначный — да.
Подход хороший и, как мне кажется, правильный, у себя в компании движемся в том же направлении. Только вот какой вопрос — что если вместо привычной ноды или php (говорю опять-таки за себя) проект будет написан на условном go? И времени на освоение новой технологии нет? Это ведь разработчики имеют какую-то специализацию — фронт, бэк, реакт, C#… — тестировщик же будет тестировать проект независимо от стека. Как бы вы решили такой вопрос, Ирина?
>ВСЕГДА сначала позитивное тестирование
Если задача вернется в редев несколько раз - придется столько же раз делать и позитивное тестирование - и чаще всего совершенно безосновательно. С современными средствами разработки, даже у джуна редко получается сделать не то, "что надо", да и, в общем-то, это плохой тон, отдать задачу в тестирование, вообще не проверяя, что ты сделал. Проблемы начинаются, когда мы делаем шаг (а может даже и шажок) в сторону от того, "как надо". Поэтому сначала - если уж задача дошла до тестирования - те кейсы, которые вероятнее всего найдут ошибку. Да, это вполне могут быть и позитивные тесты - но, в них ошибки все-таки попадаются реже. А вот после того, как все баги исправлены, перед тем, как двинуть задачу в деплой - да, вот здесь проверка основного сценария просто обязательна
Что вы понимаете под строгой типизацией? В общем, C/C++ - не строго (не сильно) типизированные языки. Да, типизация явная и статическая, но не строгая. В отличие от того же Python, где все наоборот
Смальян? Смаллиан жи... Задача из его шедевра "Как же называется эта книга?"
Все-таки, кажется, что у нас разное понимаение API)) Те апи, при помощи которых фронт общается с бэком - по умолчанию доступны тому самому пользователю, который делает манипуляции в браузере. Да, content-type может быть не application/json, а какой-нибудь application/x-www-form-urlencoded . Да, авторизация точно будет не базовой, а, скорее всего, по куке. Да, вы можете не увидеть этот запрос в консоли разработчика в браузере. Но, все это решается - и решается точно быстрее чем через селениум. И работать точно будет быстрее и стабильнее
Согласен. Инсертов в БД не может быть по определению. По определению у вас там есть API))
Мне стало очень интересно, что такое API в вашем понимании? Запросы из браузера - с фронта - уходят на бэк. Уходят через какой-то... хм... интерфейс)) Значит этот интерфейс можно использовать без браузера
Т.е. бэка вообще нет, форма с фронта инсертит прямо в БД?)) Даже если и так - все может быть, я действительно могу не знать - все-равно проще сделать реализацию на более низком уровне, т.е. инсертить в БД без посредничества драйвера и фронта.
Видел два комментария сверху, видел ответы на них - долго, нет времени. Но, всё-таки задам тот же вопрос - зачем здесь селениум? Без селениума как раз все будет быстрее проще и надёжнее. Почему нельзя дергать те же api, но без посредников в виде драйвера и браузера?
Если делить одну из теорем Вейерштрасса на 1 и 2 (так действительно делают) - то первая будет о том, что непрерывная функция, таки ограничена на компакте. О том, что она достигает максимума и минимума на этом компакте - это уже вторая теорема. Но, вопрос о значимости меня так же ставит в тупик. Ну и вопрос о том, почему люки круглые... простите, об отличиях REST и SOAP - зачем сравнивать архитектурный стиль и протокол? Ну спросите чем SOAP отличается от XML-RPC, если нет более важных вопросов на собеседовании
Если мы делаем велосипеды, то проверка того, есть ли у него колеса, руль, тормоза, из какого материала сделана рама, правильными ли болтами и гайками все скручено и куча всего остального в том же духе - это верификация. А когда мы берём готовое изделие и начинаем проверять может ли оно ехать в принципе и как ехать - это валидация. Всё.
Лучший тренажёр - https://istqb-training.ru/ Да, возможно, вопросы не самые свежие - для силлабуса 2011 года. Перевод оставляет желать лучшего (но можно проходить тесты на английском). Но, учитывая, что сделано это все на голом энтузиазме - автору огромный респект
Чем REST отличается от SOAP... Почему от SOAP, а не от, скажем, RPC?
Слабо себе представляю сценарий, который можно реализовать с помощью Gatling и нельзя с помощью JMeter. И для JMeter есть два официальных плагина для работы с веб-сокетами.
А в чем проблема получить токен с помощью постпроцессора JMeter? "Открываем" нужную страницу, ищем на ней токен, записываем в переменную и используем ее там, где необходимо. Может быть я не понял задачу, но я всегда делаю именно так
Для 1С изобрели такое чудо техники, как Ванесса. Что это за чудо, честно скажу — не знаю.
Потому что неважно, есть дети у Ольги или нет). Если нет, то Иван с детьми смотрит на Ольгу без детей. Если есть, то Ольга с детьми смотрит на Андрея без детей. Так что ответ однозначный — да.
Мне кажется это не имеет значения, если оба эти варианта — неправильные