И то, и другое — интерпретаторы командной строки в линуксе. То есть если вы откроете командную строку и введете любую команду, да хоть:
cd /home
То именно интерпретатор ее расшифрует и скажет компьютеру «он хочет перейти в директорию /home». Компьютер ведь не понимает команды на русском / английском языке. Ему нужны байтики. Этим и занимается интерпретатор — переводом с «нашего» на «компьютерный» язык.
Так что «cd /home» — это shell-команда! Или bash. Смотря какой интерпретатор установлен в вашей системе. В каждой операционной системе установлен интерпретатор по умолчанию. У них есть какие-то различия, но есть и набор базовых команд, которые понимают все: cd, mv, cp, ls…(в винде эти команды немного другие)
А что такое shell-скрипт тогда? Это просто текстовый документ, внутри которого написан набор команд! Это не обязательно должны быть «сложные» команды, которые делают что-то супер-навороченное. Это любые команды, которые вы выполняете в консоли.
Автор: Филип Рик (Filip Hric) Оригинал статьи Перевод: Ольга Алифанова
Я часто сталкиваюсь с необходимостью протестировать панель навигации, дабы убедиться, что все ссылки в ней правильно работают. Это симпатичный тестовый случай, к которому можно применять разнообразные подходы. В этой статье я хочу их осветить и показать, как применять их в Cypress.
Сначала посмотрим, что мы будем тестировать. У нас есть простая панель навигации, направляющая нас на различные страницы нашего сайта. Как обычно, можно воспользоваться примером в моем репозитории.
State & Transition Diagram (сокращенно S&T) — схема состояний и переходов. Техника для визуализации ТЗ. Она наглядно показывает, как некий объект переходит из одного состояния в другое.
Вот объект находился в состоянии А, потом произошло какое-то действие, и он попал в состояние В. Потом он попадет в состояние С и другие... Принцип не меняется, было одно состояние, стало другое.
Мы рисуем:
кружочки — состояния объекта;
стрелочки — то, благодаря чему из состояния А в состояние В. Это действие, но его может совершить не только пользователь, но и система сама. Например, задача запустилась автоматически в 10 часов вечера.
Такая схема позволяет нам сразу визуально оценить, какие переходы вообще возможны и что надо протестировать. Ведь нам надо протестировать и эту стрелку, и эту... Так что стрелочки — это наши готовые тест-кейсы!
Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Недавно мне задали вот такой вопрос (я его перефразировал для ясности):
Хорошая ли практика – одновременно использовать несколько тест-фреймворков? К примеру, я работаю над Python-проектом. Я хочу применять BDD c behave для фича-тестирования, но pytest лучше подойдет для юнит-тестирования. Можно ли использовать и то, и другое? Если можно, как мне структурировать мой проект?
Краткий ответ: да, нужно использовать фреймворки, наилучшим образом подходящие под конкретные цели. Обычно применение нескольких фреймворков несложно настроить. Разберемся подробнее.
В автоматизации тестирования я уже более 11 лет. Скажу сразу, что являюсь поклонником старомодного тестирования на Java и очень настороженно отношусь к различным готовым фреймворкам. Если вы придерживаетесь такого же мнения или только задумываетесь об использовании Robot Framework, в этой статье я постараюсь рассказать вам о его ограничениях и, конечно же, опишу все его достоинства.
Я столкнулся с Robot Framework около года назад. Перед нами стояла задача силами двух инженеров автоматизировать довольно большой объем тестов в сжатые сроки, т.к. ручная регрессия перестала влезать в разумные рамки. Сам проект связан с пожарной безопасностью. Тестировать предстояло Web-часть в трех браузерах и Mobile-часть на множестве iOS и Android телефонов и планшетов. Помимо этого, в наличии были тесты, которые взаимодействовали и с Web, и с Mobile. Конечно, это не ракету построить, но и не совсем тривиально. Честно скажу, я сопротивлялся, мы долго думали и в итоге, по совокупности внутренних и внешних факторов, выбрали Robot Framework.
Майндмап, Майнд карта, интеллект-карта, ассоциативная карта, диаграмма связей и т.д. – устоявшегося русскоязычного термина пока нет. Как, зачем, когда и надо ли?
Материал готовила для начинающих, но возможно и более опытные найдут полезные моменты.
На Хабре уже не раз писали о том, что у Selenium Grid есть проблемы, которые не решить простым способом (например: раз, два, три). В этой статье мы поделимся нашим опытом и расскажем, как нам в Wrike удалось построить стабильную инфраструктуру для Selenium-тестов.
TLDR: Мы написали своё open source решение и полностью заменили им Selenium Grid.
Мы уже рассказывали о том, как масштабировали свою Selenium-ферму с помощью Google Cloud Engine и Kubernetes. От очередей на запуск тестов мы избавились, но из QA-департамента регулярно поступали жалобы на нестабильность тестовой инфраструктуры.
Автор: Ноэми Феррера (NoemiFerrera) Оригинал статьи Перевод: Ольга Алифанова
В своем докладе на Heisenbug я демонстрировала два примера автоматизации в виртуальной реальности - Unium и Poco (Airtest). Мои объяснения были довольно поверхностными, поэтому я решила расширить их в этой статье.
Всем хорошего дня, я backend-разработчик компании Uma.Tech. Сегодня я хочу рассказать, как однажды нашему отделу разработки поступила задача от отдела тестирования: локально развернуть сервис создания заглушек для http-запросов. Если интересно, как проходил поиск, сравнение разных opensource и не только инструментов, до чего мы в итоге докатились и причём тут попугай на картинке — прошу под кат.
Оговоримся сразу: мы не рекламируем ни один из приведенных ниже инструментов, а просто делимся своим опытом.
TLDR: Если нет желания читать много букв, в конце общая сводная таблица по всем инструментам.
Автор: Тоби Стид (Toby Steed) Оригинал статьи Перевод: Ольга Алифанова
В первой статье этого нового цикла мы научились добавлять Cypress в новый проект и настраивать его, и закончили созданием первого теста. Поздравляю, теперь вы находитесь в той точке, в которой нечестные люди пополняют свое резюме в разделе технических навыков. Однако нам еще многому надо научиться, и в этот раз мы улучшим наш тест, внедряя в Cypress Page Objects.
Cypress, как практически все тест-инструменты и фреймворки, поддерживает разные паттерны дизайна. В этой статье, расширяя предыдущую, мы будем использовать Page Objects. Надеюсь, это поможет вам разобраться с парой моментов. Во-первых, вы увидите, как похож код с Page Objects в Cypress на Selenium (помимо синтаксиса), а во-вторых, как здорово Cypress позволяет быстро писать чистый и читабельный код.
