Уровень 15
Сценарии автоматизации тестирования
Привет! Мы, звездные роботы, научим тебя думать как робот, тестировать как робот, действовать как робот
В этом уровне мы рассмотрим принципы составления автоматизированных сценариев тестирования, методологии подхода к автоматизации. И действительно, ты обнаружишь, что для того чтобы составлять авто-тесты нужно думать не как человек, а как робот. Не в плане двигаться рывками под электронную музыку, а в плане того, что все действия должны быть детерминированны (четко определены и измерены количественно). Роботу не скажешь - проверь ка мне, что сайт выглядит хорошо, ему нужно сказать - проверь, что размер хеадера 300 х 500 пикселей. Об этом и поговорим.
Автоматизированное тестирование это процесс который требует большое количества времени и квалификации
Этапы автоматизированного тестирования:
-
Ручное тестирование функционала (изучение)
-
Выбор инструмента автоматизации
-
Изучение этого инструмента
-
Выбор стратегии автоматизации
-
Оценка временных рамок и создание плана автоматизации
-
Написания программного кода тестов
-
Отладка и внедрение тестов
Определение автоматизированного тестирования
Автоматизированное тестирование это:
Набор практик, подходов и методов, которые в совокупности позволяют автоматизировать тестовые сценарии (при помощи сторонних по отношению с системе утилит или программных продуктов, включая среду разработки), а также обеспечивают выполнение активностей направленных на тестирование ПО.
Практические соображения:
-
Автоматизированное тестирование это вид тестов, а не фаза тестирования
-
Автоматизация тестирования не начинается после какого-то другого этапа тестирования, а является независимым этапом
-
Потенциально практически любой тест может быть автоматизирован
-
Не все тесты должны быть автоматизированы
-
Рекомендутеся проектный подход в задачах автоматизированного тестирования.
-
Проектный подход в задачах автоматизированного тестирования:
-
Автоматизация тестирования – проект внутри проекта по разработке тестов
-
Unit-тестирование – часть автоматизации тестирования, выполняемая самими программистами
-
Автоматизация требует проектного подхода к ее этапам: планирование, выделение ресурсов, проектирование, выполнение и анализ полученных результатов
-
Результаты проекта по автоматизации должны покрывать определённые заранее аспекты качества системы находящейся под тестом
-
Роботы всегда готовы тебе помочь, главное обучи нас, запрограммируй мы сделаем, все то попросишь!
Виды автоматизированного тестирования
В зависимости от объектов тестирования выделяют следующие виды автоматизированного тестирования:
-
Функциональное тестирование
-
Нефункциональное тестирование или тестирование производительности
-
GUI тесты
-
Тестирование баз данных
Функциональное тестирование позволяет:
-
Определить соответствие заявленных функциональных требований реализованной в системе под тестом функциональности
-
Определить насколько система регрессировала по отношению к предыдущему зафиксированному состоянию
-
Убедиться в том, что выявленные и исправленные ранее ошибки не проявляются вновь
-
Выполнить прогон тестов под максимально возможным количеством поддерживаемых аппаратно-программных конфигураций
-
Использовать для прогона тестов нерабочее время тестировщиков
-
Выделить тестирование устоявшегося функционала и новой функциональности
Тестирование производительности позволяет:
-
Определить время реакции приложения
-
Определить, какое количество пользователей может поддерживать система
-
Определить оптимальную конфигурацию системы
Нагрузочное тестирование позволяет:
-
Проверить производительность на различных программно-аппаратных конфигурациях
-
Проверить производительность системы при различных объёмах данных
-
Определить поведение системы при стрессовой нагрузке
Понимание автоматизированного сценария
-
Фундамент автоматизированного сценария
-
Бизнес-транзакции
-
Действия/операции
-
Данные и параметризация
-
Результаты и контрольные точки
-
Обработка исключительных ситуаций
-
Анализ полученных результатов
-
Практические соображения
Фундамент автоматизированного сценария
-
Автоматизированный сценарий по структуре аналогичен тестовому сценарию для ручного тестирования
-
Основой для автоматизации является только заранее спроектированный тест, который покрывает заявленную функциональность системы
-
Вспомогательная тестовая функциональность, например, возвращающая систему в консистентное состояние после сбоя, должна реализовываться отдельными по отношению к тестовым скриптам модулями. Такая функциональность не должна включаться в анализ тестового покрытия.
Бизнес-транзакции
-
Бизнес-транзакции: последовательность действий и операций направленных на достижение значимого для бизнеса или этапа технологического процесса результата. Характеристики бизнес-транзакций наследуются от характеристик транзакций из теории баз данных
-
Бизнес-транзакция – рекомендованная величина измерения результатов автоматизированного тестового покрытия
-
Наиболее критическим с точки зрения нагрузочного тестирования параметром бизнес-транзакции выступает время
-
Бизнес-транзакции в информационных системах, как правило, приводят к созданию, удалению или изменению данных
-
Бизнес-транзакции в системе – критерий измерения результатов нагрузочного тестирования
Слава роботам!
Действия/операции
-
Операция – последовательность шагов/действий реализуемая конечным пользователем, системным агентом или процессом, или же сторонним по отношению к системе актером, выполнение которой приводит к значимому для пользователя, системы или автоматизируемого процесса результату
-
Операция или конечное действие в системе - атомарная единица автоматизации, которая может использоваться при планировании
Результаты и контрольные точки
-
Результаты выполнения тестового сценария и время/«место» контроля полученных результатов должны быть определены во время проектирования тестирования
-
Именно сопоставление ожидаемых и полученных результатов и является основной задачей автоматизированного сценария
Данные и параметризация
-
Входные данные и параметры тестов должны быть определены на этапе проектирования тестирования
-
Внешние по отношению к автоматизированному скрипту данные должны храниться во внешних подключаемых файлах под версионным контролем
Обработка исключительных ситуаций
-
Тест, кроме непосредственно логики выполнения операций «конечным пользователем», должен включать в себя логику обработки исключительных ситуаций, а также иметь связанную с ним специальную функциональность, возвращающую систему в консистентное состояние
Анализ полученных результатов
-
Идеальным, с точки зрения анализа результатов тестирования, можно считать тест, который предоставляет для анализа в случае сбоя рабочие данные (значения внутренних тестовых переменных и «маркеры» тестовых данных) и «снимок» рабочего состояния системы (последние N строк лога, скриншоты, дамп памяти и т.п.)
Практические соображения
-
Автоматизированный тест, который требует присутствия тестировщика для оценки результата тестирования (ситуация когда тест не даёт однозначного ответа пройдён он или нет) или для приведения системы в консистентное состояние не является законченным и не может выполнятся многократно без участия «оператора».
-
Обратите внимание на аккуратное описание тест-кейсов, предназначенных для автоматизации
Не смей недооценивать роботов, мы настолько крутые что нам даже поклонались египтяни!
Когда тестирование и разработка объединяются
Тестирование на ранней стадии, например, во время написания кода – это когда-то инновационная идея, все больше приживается в массах, так как приводит к значительному повышению качества кода. Напишите тесты заранее – и вы имеете шанс выиграть "кристаллическую звезду" победителя галактического первенства. Кроме того, возможности для проверки функционирования кода и его предварительной отладки, без всякого сомнения, повышают скорость разработки.
Но даже зная все это, мы еще очень далеки от того времени, когда написание тестов до-написания кода станет общим стандартом. Точно так же как TDD стало следующим этапом эволюции развития экстремального программирования (eXP) и выдвинуло на первый план инфраструктуру для unit-тестирования, следующий скачок эволюции был сделан с того уровня, где находится TDD. В этом случае эволюционировали от TDD к его интуитивному родственнику: behavior-driven development (BDD) – разработке, основанной на функционировании. Но давайте обо всем по порядку.
Все эти методики относятся к гибким методологиям разработки программного обеспечения. Напомним, что гибкая методология разработки (Agile) - это серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп (Dev, QA, Product ...). Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD, TDD, BDD, но нас интересуют только те из них, которые связанные с тестированием
Разработка через тестирование - TDD
Разработка через тестирование (англ. test-driven development, TDD) - это современный стандарт разработки программного обеспечения, который основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Кент Бек, считающийся изобретателем этой техники, утверждал в 2003 году, что разработка через тестирование позволяет быть уверенным продкутивности своего кода, что в конечном счете уменьшает общее время разработки. В 1999 году при своём появлении разработка через тестирование была тесно связана с концепцией «сначала тест» (англ. test-first), применяемой в экстремальном программировании, однако позже выделилась как независимая методология. В основе лежит unit-Тест это программная процедура, которая позволяет либо подтвердить, либо опровергнуть работоспособность кода.
Технику TDD легко представить данной схемой:
Теперь я более подробно объясню как это работает:
1. На основе спецификации, мокапов и другой исходной документации пишется тест. Для программы которая еще даже не написана. Если запустить такой тест, логично что он упадет.
2. Программист пишет код, создает программу, при этом тест будет индикатором. Как только тест будет пройден - код готов.
3. Рефакторинг. Тест доделывается/переделывается в результате изменившихся требований, добавляются новые параметры если нужно. Редко когда фича принимается с первого раза.
Данный цикл может повторятся n раз, до того как программа не достигнет желаемого состояния.
Хмм... Прекрасная техника! Я всегда считал, что первым был тест, за тем уже код. Но я вот, не понимаю, в чем тут роль тестировщика, если TDD, это подход для программирования?
Замечательный вопрос для такой жестянки как ты! Ну во первых, мы изучаем процесс автоматизации, а во вторых нам необходимо научится процессу разработки-через-поведение, в основе которого как раз лежит TDD. Кроме того мы вступаем в новую эру разработки, в которой тестировщик пишет тесты еще до того, как получил программу в работу. Собственно, наш падаван уже научился этому при работе с тест планом.
Разработка, основанная на поведении
После того как мы узнали, что современные методики разработки объединяются с тестированием образуя TDD. Далее TDD эволюционировало образовав BDD (behavior-driven development) или разработка через поведение. Скорее всего вас уже запутали эти аббревиатуры и все слилось в сплошное BDSM.
Но давайте обратимся к мнению экспертов.
Мэтт Уинн, один из разработчиков интерпритатора BDD для фреймворка Cucumber Limited передает суть технологии так:
«Практикующие BDD исследуют, обнаруживают, определяют, а затем воплощают это поведение программного обеспечения, используя общение, конкретные примеры и автоматизированные тесты».
Я как всегда спешу, спасать галактику от ситхов, но у меня есть минутка все разложить по полочкам. Вот представь, вместе в связке работают всегда: продакт менеджер, тестировщик и программист и заказчик. И нужно написать тесты так чтобы:
a) Они были понятны каждому из них
б) Они были структурированы по "зарезервированным фразам", так чтобы к тесту можно было привязать код автотеста
в) Тесты были бы лаконичны
г) Шаги были бы универсальны и их можно было переиспользовать в следующих тестах.
Как ты думаешь, что из изученной тобой документации подходит под эти критерии?
Хан, мне кажется, или это сложная тема? Давай присядем и все хорошенько обдумаем. Для начала, хотелось бы узнать, как вообще пришли к идее BDD?
Давай перебирать все по порядку:
1) Тест кейс. Я думаю он не подойдет по лаконичности - они обычно весьма длинны и подробны, так и по структурированности, они годятся только для ручного тестирования
2) Чек лист лаконичен, но понятен в основном только тестировщику, да и не структурирован как надо. Тоже нет.
3) Также не подойдет use case/use story, это больше для продактов.
Хан Соло, вариантов нет, нам нужно что-то новое!
Ты верно мыслишь! К такому же выводу и пришли те кто практиковал BDD. Нужен подход который объеденит тестировщиков, программистов, продактов, бизнес-аналитиков, заказчиков и даст им документацию которую использует и понимает каждый. Давай же попросим магистра пролить на нас мудрость BDD.
Как вы поймете из схемы ниже, BDD это технология создания тестовых сценариев которая накладывается на TDD тесты и делает их понятными всем!
В подходе BDD нет ничего революционного. Это просто эволюционное ответвление подхода TDD, где слово "тест" заменено словом "должен". Если отложить в сторону слова, то многие найдут понятие "должен" более естественным для процесса разработки, чем понятие "тест". Мышление в терминах функциональности (того, что код должен делать), приводит к подходу, когда сначала пишутся классы для проверки спецификации, которые, в свою очередь, могут оказаться очень эффективным инструментом реализации.
Как вы уже сам выяснили, подход BDD состоит в том, чтобы попытаться выяснить, что ваш клиент или бизнес хочет от программного обеспечения, прежде чем начать работать над ним. Первый способ сделать это - фактически сотрудничать с этими людьми.
Как только мы получим это сотрудничество, нужно как-то записать то, что имеет смысл для любого, кто его просматривает, так чтобы любой мог прийти и посмотреть на него позже, понять, и если он захочет, прокомментировать его. Чтобы достичь этого, нужно использовать общепонятный язык.
Люди часто используют слова "Given", "When", "Then", "And" (рус. "Дано", "Когда", "Тогда", "И"), для того чтобы построить цепочку логических рассуждений. Так давайте же применять эти слова, как ключевые для построение наших тестов понятных всем.
Итак, наш тестовый документ будет будет называться сценарием и будет использовать только ключевые фразы для каждого шага. В начале мы дадим перевод, но далее будет использовать только английские фразы. Наш сценарий будет строится по такой структуре:
GIVEN <context>
WHEN <event>
THEN <outcome>
Как это работает:
Дано <я привожу тестируемую систему в исходное состояние для теста>
Когда <Я произвожу действие>
Тогда <Я проверяю результат>
А теперь пример:
GIVEN Я залогинен в систему как пользователь
WHEN Я открываю список входящих сообщений
THEN Я вижу 20 последних сообщений
Магистр, а как мне быть, если я хочу произвести два действия для одного из состояний и не хочу из совмещать, потому, что общего у них ничего нет
В таком случае используют ключевое слово AND. Таким образом можно добавить вспомогательный шаг к любому из ключевых слов. Но не стоит злоупотреблять словом AND, ведь если у вас слишком много дополнений, то скорее всего вам нужно разбить ваш большой сценарий на более мелкие.
Пример использования AND:
GIVEN Я удаляю пользователя <username> из Базы Данных
AND Я регистрирую пользователя <username> на сайте
WHEN Я захожу на сайте с новым пользователем
THEN Я вижу приветствие нового пользователя
AND Я закрываю окно приветствия
Параметризация сецнариев
Подскажите, уважаемый магистр, а было ли у вас в жизни ситуация, когда вам нужно было повторить один и тот же тест, но с разными входными данными?
Я пока не понимаю к чему ты клонишь, падаван. Да ранее мы многократно в тест-кейсах выполняли похожие проверки с одинаковыми шагами но разными входными данными, и записывали их копируя шаги.
Все верно, и я так делал в третьем уровне, но мне всегда казалось, что это можно это как то унифицировать и сократить. Я придумывал разные таблицы с шагами, и данными, но ничего из
этого не выглядело достаточно привлекательным, чтобы стать эталоном.
Так то он и было, пока не стали активно использовать BDD. Тогда при использовании небольших автотестов, понадобилась их параметризация, чтобы избежать многократного дублирования. Придумали контурный сценарий (Scenario outline). Он ничем не отличается от обычного, кроме того, что значения параметров для теста меняются каждый круг на следующие по списку.
Что-то мне захотелось выпить свежего сока, давай напишем сценарий для робота который, готовит яблочный фреш. При этом как фрукты для сока, так и ожидаемый результат мы укажем как параметр в самом тесте.
Feature: Обучение 03. Свежий фреш.
Scenario: Изготавливаем фреш
Given Я ложу "яблоки" в блендер
When Я включаю блендер
Then яблоки должны преобразоваться в "яблочный сок"
Данный пример теста содержит, внешнюю параметризацию, вместо яблока можно вписать любой фрукт и его сок, и при этом тест останется корректным. Главное выполнить шаги так, чтобы они были универсальны. Зачастую в таких случаях оперируют вводимыми данными.
Хотя это было бы, слишком накладно ограничиваться лишь яблоками, пускай робот умеет готовить любой фреш. Для того, чтобы сделать тест по настоящему параметрическим, мы заменим конкретные яблоки, на абстрактные фрукты. А, чтобы отличать циклически-параметрический сценарий от не-циклического, будем называть его Scenario Outline (Циклический сценарий). Давайте ка попробуем заказать роботу сок из "фрукта". Важно понять, что любой циклический сценарий должен быть параметризированным.
Feature: Обучение 04. Параметрический фреш.
Scenario: Изготавливаем фреш из любого "фрукта"
Given Я ложу "фрукты" в блендер
When Я включаю блендер
Then Фрукты должны преобразоваться в "cок"
Examples: Соки
| фрукт | сок |
| яблоко | яблочный сок |
| тасилианский огурец | тасилианский сок |
Examples: Электроприборы
| устройство | сок |
| Iphone X | токсический сок |
| Samsung Galaxy S9 | токсический сок |
Как вы видите из данного примера, подавать в тест в виде параметров можно любые данные, но и результат должен быть соответствующим (иначе тест не провалится). При запуске теста, каждый круг он будет проходить с новым параметром из таблицы, пока не пройдет их все.
Примеры рабочих сценариев магистра
@login @settings @onboarding
Feature: chorus log in tests for all available ways: login/pass, google, microsoft, self-serve
BDD тест может быть простым, содержа только Дано, Когда, Тогда;
@login
Scenario: Login tests with via email and password
Given I restart driver And I go to home page
When I do log in with registered email user
Then I check I am at account page
Но часто, необходимы вспомогательные шаги, которые добавляются через And;
@xray
@pop
Scenario: opening first card on X-ray page leads to popup containing relevant trackers
Given I am on xray tab of target call
When I click on the first Card
Then corespondent card is displayed
And all trackers are collapsed
And displayed moments count matches actual amount
And I close x-ray moment Popup
Как мы изучили бывает, внешняя параметризация сценария тестовыми данными;
@account_page
Scenario: share transcript item
Given I am at transcript of a target call
When I select "3" transcript item
And I open the transcript's menu
And I select "Share Moment" from transcript menu
When click edit share
Then Start time for share equals to moment time
And I close share popup window by clicking "X"
Также вполне может использоваться вместе просто параметризация, и цикличная параметризация. Одни параметры просто передаются, а другие меняются в каждом цикле.
@account_search_bar_mobile
Scenario Outline: I search the calls for <search_text> via search bar and clear with x
Given I am at mobile account page starting state
When I go to call "4 - Needs Analysis" on the mobile account page
And I search for "<search_text>"
Then I find expected results for "<search_text>" search
And Mobile section "transcript" is active
And I make sure transcript search bar is closed and cleared by clicking on clear search
Examples: Text Searches
| search_text |
| hi |
| pricing OR okay |
И в данном примере, мы наблюдаем использование только циклической параметризации
@moments
@moments_search
Scenario Outline: Search for specific moment, adds result to legend
Given I am at moments search starting state
And I set timeframe filter to "Last 52 Weeks"
And I click apply for filter popup
When I input and select in search <moment_name>
And I select <moment_name> suggestion
Then <moment_name> appear in search bar
And For each moment from search bar exists graph name
Examples: moments names
| moment_name |
| Citizenship |
| Goals |
Анализ результатов запуска автотестов
Далее представлен ознакомительный фрагмент результатов запуска автоматизированных сценариев в формате BDD. И сегодня я научу тебя понимать язык роботов. Для этого r2d2 расшифрует все значения лог файлов. После этого ты научишься понимать и анализировать результаты автотестов.
Мой все еще юный джедай тестирования, хочу обрадовать тебя, тем, что язык роботов всегда однозначен. У нас не бывает намеков либо двусмысленностей. Все так как оно есть. Разве, что нюанс в том, что на анйглийском, этот язык признан основным для всех роботов. Далее я дам пояснения для всех важных команд и этапов в баг репорте.
Перед тем как мой не терпеливый робо-друг произведет анализ баг репорта. Я расскажу немного о его истории. Данный лог был получен при запуске автотеста на одном из моих дааавнешних проектов. Мы тогда занимались преобразованием человеческой речи. Так вот, эта система позволяет объединять записи речи в плейлисты, вот для этой фичи и был создан данный тест сьют названный playlists_page. Тесты записаны с помощью методики BDD, а выполнены на языке python.
Тебе бы, лишь поболтать! Не так важно к какому проекту и языку относятся автотетсы, нам важно сейчас научиться читать логи, ведь практически все и использую фреймворк Selenium, и ошибки которые возникают при падении тестов практически одинаковы для всех языков! Итак, перейдем к разбору лога! По ходу я буду давать тебе ссылки на технологические системы которые использовались, просто для ознакомления.
Running with gitlab-runner 10.0.1 (e991d1b4)
on gitlab-runner-18.194.129.84 (be743b2e)
Using Docker executor with image docker.affectlayer.com:5000/al/automation-ci:5.0 ...
Using docker image sha256:53e5a6b45f119e089b21856075b2ae0e8605eb2edebd725869ec4a7da3813dca for predefined container...
Pulling docker image docker.affectlayer.com:5000/al/automation-ci:5.0 ...
Using docker image docker.affectlayer.com:5000/al/automation-ci:5.0 ID=sha256:80a33c4c7b02376166eb6fb1fae24073a8590fd631e35a13e93e4774b38ed43e for build container...
Running on runner-be743b2e-project-26-concurrent-3 via 1b70c615557b...
Cloning repository...
Cloning into '/builds/affectlayer/system_tests'...
Checking out d03637d8 as system_tests#54-new-pipeline...
Skipping Git submodules setup
$ export DBUS_SESSION_BUS_ADDRESS=/dev/null
$ echo $FRONTEND_LINK
$ mkdir -p dist
$ if [ -z "$FRONTEND_LINK" ];then CHORUS_LINK=$PROD_LINK; else CHORUS_LINK="${FRONTEND_LINK}"; fi
$ if [ -z "$RUN_MODE" ];then RUN_MODE='@self_service'; else RUN_MODE="${RUN_MODE}"; fi
$ if [ $RUN_MODE != '@self_service' ];then RUN_MODE='@nothing'; fi
$ echo $FRONTEND_LINK
$ echo $CHORUS_LINK
hello.chorus.ai
$ export TZ=$TIME_ZONE
$ Xvfb :1 -screen 5 1920x1200x8 &
$ export DISPLAY=:1.5
$ behave --tags=$RUN_MODE -k -D build_id=$BUILD_ID -D username=selfserve8@selfservechorus.com -D password=aA1\!aA1\!a -D user_type=self-serve -D chorus_link=$CHORUS_LINK -D timeout=$TIMEOUT || behave @rerun_failing.features --tags=$RUN_MODE -k -D build_id=$BUILD_ID -D username=selfserve8@selfservechorus.com -D password=aA1\!aA1\!a -D user_type=self-serve -D chorus_link=$CHORUS_LINK -D timeout=$TIMEOUT
waiting for version to update...600 seconds
@self_service @all @playlists
Feature: playlists # features/playlists.feature:4
@all @playlists @self_service @new_playlist @playlists_page
Scenario: Creating a new playlist via playlists page # features/playlists.feature:11
Given I am in playlists page # features/steps/playlists.py:15
When I create a new playlist # features/steps/playlists.py:30
Then toast pops up and disappears # features/steps/playlists.py:38
And a new empty playlist is created # features/steps/playlists.py:49
@self_service @playlists_page @existing_playlist
Scenario: It should not be possible to add a playlist with existing playlist's name # features/playlists.feature:20
Given I am in playlists page # features/steps/playlists.py:15
When I create a new playlist with existing name # features/steps/playlists.py:67
Then "existing playlist" error message appears # features/steps/playlists.py:81
And created playlist exists only once # features/steps/playlists.py:92
@self_service @playlists_page @deleting_playlist
Scenario: When I delete a playlist I created it is deleted # features/playlists.feature:29
Given I am in playlists page # features/steps/playlists.py:15
Given I create a playlist # features/steps/playlists.py:128
When I delete last created playlist # features/steps/playlists.py:134
Then last created playlist is deleted, even after refreshing the page # features/steps/playlists.py:145
And I delete all created playlists # features/steps/playlists.py:139
@all @self_service @playlists_page @search_playlist
Scenario: Only relevant playlists appear when searching playlists # features/playlists.feature:49
Given I am in playlists page # features/steps/playlists.py:15
Given a list with more than one playlist # features/steps/playlists.py:99
When I search for the exact name of one of them (that does not contain the other) # features/steps/playlists.py:105
Then only playlists with relevant names appear # features/steps/playlists.py:118
Test for feature [u'self_service', u'all', u'playlists'] completed
waiting for version to update...600 seconds
@self_service @all @playlists-mobile
Feature: playlists # features/playlists_mobile.feature:4
@self_service @all @playlists-mobile
Scenario: Check pre-defined playlist # features/playlists_mobile.feature:18
Given I am at playlist mobile starting state # features/steps/playlists_mobile.py:12
When I select playlist Default_not_empty_playlist # features/steps/playlists_mobile.py:29
Then I check Playlsit moments list as expected # features/steps/playlists_mobile.py:50
Assertion Failed: Incorrect opp of first moment
And I check name is Default_not_empty_playlist and owner of playlist is the main header user # None
@self_service @all @playlists-mobile
Scenario: Play playlist # features/playlists_mobile.feature:27
Given I am at playlist mobile starting state # features/steps/playlists_mobile.py:12
When I select playlist Default_not_empty_playlist # features/steps/playlists_mobile.py:29
And I activate account ghost # features/steps/playlists_mobile.py:98
And I press the playlist play button # features/steps/playlists_mobile.py:116
Then Playlist is played # features/steps/playlists_mobile.py:104
When I press the playlist pause button # features/steps/playlists_mobile.py:122
And Playlist is paused # features/steps/playlists_mobile.py:110
@self_service @all @playlists-mobile
Scenario: Only relevant playlists appear when searching playlists # features/playlists_mobile.feature:39
Given I am at playlist mobile starting state # features/steps/playlists_mobile.py:12
When I search for Default_not_empty_playlist of in mobile playlists # features/steps/playlists_mobile.py:76
Then I check search result is Default_not_empty_playlist # features/steps/playlists_mobile.py:86
Test for feature [u'self_service', u'all', u'playlists-mobile'] completed
waiting for version to update...600 seconds
@self_service @trial
Feature: Trial for self serve # features/trial.feature:3
@self_service @trial
Scenario: when i log into chorus with a user on trial top right corner should show remaining trial time # features/trial.feature:7
Given I am at chorus logged in as self serve # features/steps/trial.py:7
When I set end time for five days on self serve user # features/steps/trial.py:44
When I am logged in as self serve i see trial bar # features/steps/trial.py:13
Then I click on extend trial # features/steps/trial.py:19
And I move to trial page # features/steps/trial.py:26
No handlers could be found for logger "behave"
@self_service @trial
Scenario: when i go to chorus trial page and invite sales reps # features/trial.feature:34
Given I am at chorus logged in as self serve # features/steps/trial.py:7
When I set end time for five days on self serve user # features/steps/trial.py:44
Then I click on extend trial # features/steps/trial.py:19
And I click on invite sales reps # features/steps/trial.py:75
And I set end time for five days on self serve user # features/steps/trial.py:44
........ тут еще куча пройденных тестов ......
@self_service @trial_mobile
Scenario: when i go to chorus mobile trial and change trial time to unlimited # features/trial_mobile.feature:34
Given I am at chorus mobile logged in as self serve # features/steps/trial_mobile.py:8
When I set end time to unlimited on self serve user # features/steps/trial.py:51
Then web time will show unlimited on mobile # features/steps/trial_mobile.py:28
Test for feature [u'self_service', u'trial_mobile'] completed
Failing scenarios:
features/playlists_mobile.feature:18 Check pre-defined playlist
@self_service @all @playlists-mobile
Scenario: Check pre-defined playlist # features/playlists_mobile.feature:18
Given I am at playlist mobile starting state # features/steps/playlists_mobile.py:12
When I select playlist Default_not_empty_playlist # features/steps/playlists_mobile.py:29
Then I check Playlsit moments list as expected # features/steps/playlists_mobile.py:50
Assertion Failed: Incorrect opp of first moment
Test for feature [u'self_service', u'all', u'playlists-mobile'] completed
And I check name is Default_not_empty_playlist and owner of playlist is the main header user # None
@all @login
Scenario: Login tests with sales force credentials # features/login.feature:8
Given I restart driver # features/steps/onboarding_selfserve.py:23
And I go to chorus page # features/steps/login.py:12
When I log in with registered sfdc user # features/steps/login.py:68
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/behave/model.py", line 1329, in run
match.run(runner.context)
File "/usr/local/lib/python2.7/dist-packages/behave/matchers.py", line 98, in run
self.func(context, *args, **kwargs)
File "features/steps/login.py", line 80, in sfdc_login
login_page.login_to_sfdc(Constants.SFDC_ONBOARDING_EMAIL, Constants.SFDC_ONBOARDING_PASSWORD)
File "/builds/affectlayer/system_tests/drivers/landing_page/new_login_page.py", line 76, in login_to_sfdc
sf_login_page.name_input().add_text(username)
File "/builds/affectlayer/system_tests/drivers/landing_page/sales_force_login_page.py", line 15, in name_input
return Input(self.wait_component_to_load((By.ID, "username")))
File "/builds/affectlayer/system_tests/drivers/basic_components/page_base.py", line 20, in wait_component_to_load
EC.visibility_of_element_located(by_locator))
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/support/wait.py", line 71, in until
value = method(self._driver)
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/support/expected_conditions.py", line 127, in __call__
return _element_if_visible(_find_element(driver, self.locator))
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/support/expected_conditions.py", line 398, in _find_element
return driver.find_element(*by)
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/remote/webdriver.py", line 843, in find_element
'value': value})['value']
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/remote/webdriver.py", line 306, in execute
response = self.command_executor.execute(driver_command, params)
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/remote/remote_connection.py", line 464, in execute
return self._request(command_info[0], url, body=data)
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/remote/remote_connection.py", line 488, in _request
resp = self._conn.getresponse()
File "/usr/lib/python2.7/httplib.py", line 1136, in getresponse
response.begin()
File "/usr/lib/python2.7/httplib.py", line 453, in begin
version, status, reason = self._read_status()
File "/usr/lib/python2.7/httplib.py", line 417, in _read_status
raise BadStatusLine(line)
httplib.BadStatusLine: ''
@xray @play
Scenario: playing a moment from x-ray card # features/call_xray.feature:41
Given I am on xray tab of target call # features/steps/x-ray.py:16
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/behave/model.py", line 1329, in run
match.run(runner.context)
File "/usr/local/lib/python2.7/dist-packages/behave/matchers.py", line 98, in run
self.func(context, *args, **kwargs)
File "features/steps/x-ray.py", line 22, in step_impl
context.account_page.wait_until_account_page_finished_loading()
File "/builds/affectlayer/system_tests/drivers/account_page/account_page_executor.py", line 301, in wait_until_account_page_finished_loading
self.wait_for_chorus_page_to_load()
File "/builds/affectlayer/system_tests/drivers/basic_components/page_base.py", line 60, in wait_for_chorus_page_to_load
self.wait_for_component_disappear((By.CSS_SELECTOR, 'div.chorus-loading'), 60)
File "/builds/affectlayer/system_tests/drivers/basic_components/page_base.py", line 40, in wait_for_component_disappear
.until(EC.invisibility_of_element_located(by_locator))
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/support/wait.py", line 80, in until
raise TimeoutException(message, screen, stacktrace)
selenium.common.exceptions.TimeoutException: Message:
3 features passed, 1 failed, 28 skipped
13 scenarios passed, 1 failed, 230 skipped
5 steps passed 9, 1 failed, 1519 skipped,
Took 4m33sec
Привет, я думаю, что ты прекрасно понял материал. Но если быть честным, у меня остались вопросы, по всем этим TDD, BDD фразочкам. Говорят материал, лучше усваивается, если его объяснить другому. Я хотел бы знать:
Домашнее задание и практика
В практическом задании тебе прийдется показать, что ты можешь думать как робот. Стать мастером-над-роботами. Для имплементации автотеста в уровне 17, тебе прийдется вначале написать автоматизированные сценарии. Автоматизировать мы будем наш любимый сайт печенек! Создать нужно сценарии для проверки:
-
Проверить работу галереи на главной (увеличение картинки)
-
Проверить отправку сообщения на странице contact us
-
Проверка навигации по меню
-
Заказа одной из конфет (свойства параметры)
-
Заказ печенья (тип параметр)
-
Изменения количества товаров в корзине (количество параметр)
-
Оформление заказ в корзине
В данном задании тебе нужно написать 7 BDD сценариев в гуглдоке, задание отправляй через форму. Кстати у магистра для тебя тоже есть заданьеце.
Для перехода на уровень 17, необходимо набрать минимум 15 баллов (60%) за задания уровня 16.
У меня для тебя есть тоже интересное задание. Я всю ночь запускал автотесты на проекте, и очень устал. Помоги мне пожалуйста проанализировать их результаты. Логи тестов я загрузил сюда. Ответ запиши в гугл доке. В таком формате:
1. Тест Scenario Outline: Displaying pricing moments modal dialog упал в месте
"features/steps/login.py", line 44, in browse_to_login
base_page.wait_for_chorus_page_to_load()
с ошибкой
selenium.common.exceptions.WebDriverException: Message: chrome not reachable
Хром не доступен. Сайт завис при попытке залогинится.
