Кейс следующий: есть компьютер, который привязан к определенному пользователю. При открытии определенной страницы - происходит автологин (т.е. никакой страницы логина нет) в веб-приложение. Ограничение на права доступа (изменение сертификатов и т.п.) присутствует аки в банковской сфере.
Нужно: запустить тесты под пользователем TestLogin:TestPassword.
Запускать браузеры под разными профилями не вариант т.к. всегда логинит под дефолтными данными. В идеале открыть браузер сразу под TestLogin при этом ничего не меняя в настройках системы. Запускать под FireFox.
Возможно ли это? Если да, то где, примерно, копать?
Каждый начинающий тестировщик слышал о методах тестирования black-box, white-box и gray-box (методы трех «ящиков»). В сети можно найти много информации о «черном» и «белом ящиках», но статьи о методе «серого ящика» встречаются редко. Такая ситуация кажется мне не совсем справедливой, ведь многие из нас используют в работе именно эту стратегию. Я попытаюсь немного исправить сложившееся положение, подробно рассмотрев плюсы и минусы «серого ящика» по сравнению с двумя другими методами и выяснив, в каких случаях его применение будет наиболее эффективным. Тестирование «серого ящика» сочетает в себе элементы black-box и white-box тестирования, а потому я начну свой рассказ с краткой характеристики каждого из методов.
Фреймворки семейства xUnit -- это основа основ автоматизированного тестирования. Они используются для организации и запуска тестов и сбора информации о результатах тестирования, то есть решают одну из ключевых задач автоматизации тестирования.
Однако наши многочисленные тренинги по автоматизации уделяют недостаточно внимания этому важнейшему аспекту разработки автотестов, поэтому мы решили добавить в линейку тренинг, специально посвященный эффективному использованию тестовых фреймворков.
В этом тренинге рассматриваются два наиболее популярных тестовых фреймворка для языка программирования Java -- JUnit и TestNG.
Начать работать с этими фреймворками несложно. Однако опыт показывает, что большинство автоматизаторов использует лишь незначительную часть возможностей, которые предоставляют тестовые фреймворки.
Но может быть эти “продвинутые” возможности просто не нужны, поэтому и не используются?
Увы, часто тестировщики-автоматизаторы строят сложные конструкции из “костылей” и изобретают самодельные велосипеды, не подозревая о том, что нужная функциональность может быть реализована гораздо более простым способом.
Из тренинга вы узнаете, как организовывать тесты в группы, как их запускать в нужном порядке, как правильно описывать зависимости между тестами, как реализовать “мягкие” и “жесткие” проверки, как сделать тесты параметризованными, как реализовать загрузку данных из разных источников и применять подход DDT (data-driven testing), как автоматически перезапустить упавшие тесты и ещё многое другое.
Материал разбит на два уровня сложности: использование встроенных возможностей тестового фреймворка и расширение функциональности фреймворка через специально предусмотренные интерфейсы расширения.
Здравствуйте ув. тестироващики, хочу обратится к Вам с советом. Возможно глупый вопрос, но нигде не могу найти освещение данного вопроса.
У нас back end пишут на Java, я разрабатываю API тесты на python (pytest+requests)
Возникла необходимость написать mock (наша система обращается к 3-й системе (CUCM Cisco Unified Communications Manager для проверки некоторых данных).
Тест состоит из таких шагов: 1) я отправляю post запрос,
2)система делает запрос в CUCM проверяет есть ли там данные
3)присылает ответ,
Могу ли я используя средства python сам написать эту "заглушку"(например или они обязательно должны быть на родном языке), чтобы убрать 3-ю систему из 2-го шага?