• Тестирование в Яндексе. Как сделать отказоустойчивый грид из тысячи браузеров

      Любой специалист, причастный к тестированию веб-приложений, знает, что большинство рутинных действий на сервисах умеет делать фреймворк Selenium. В Яндексе в день выполняются миллионы автотестов, использующих Selenium для работы с браузерами, поэтому нам нужны тысячи различных браузеров, доступных одновременно и 24/7. И вот тут начинается самое интересное.



      Selenium с большим количеством браузеров имеет много проблем с масштабированием и отказоустойчивостью. После нескольких попыток у нас получилось элегантное и простое в обслуживании решение, и мы хотим поделиться им с вами. Наш проект gridrouter позволяет организовать отказоустойчивый Selenium-грид из любого количества браузеров. Код выложен в open-source и доступен на Github. Под катом я расскажу, на какие недостатки Selenium мы обращали внимание, как пришли к нашему решению, и объясню, как его настроить.
      Читать дальше →
    • Курс от Яндекса о том, что должен знать каждый разработчик, который хочет делать большие системы. Модное слово DevOps и другое

        Всю рутину, которую можно отдать роботам, нужно отдать роботам. Большие системы без этого невозможны. В разработке и тестировании очень много похожих задач, которые не требуют высокой квалификации, но отнимают много времени. Человек, который умеет обеспечить разработку, тестирование и деплой – это редкий специалист и его на количество страничек никак не масштабируешь.

        В Яндексе тестировщику невозможно без автоматизации. Мы даже развиваем экспериментального робота, который способен брать на себя функциональное тестирование. В какой-то момент мы поняли, что не так много людей осознают, сколько сейчас есть возможностей работать не 12 часов, а головой. Собрав весь свой опыт в тестировании и деплое, мы открыли в питерском офисе Яндекса Школу автоматизации процессов разработки. У нас получилась школа, где каждый, кто пишет код, может получить базовый набор знаний о том, как собрать, запустить и поддерживать сервис в продакшене так, чтобы это стоило недорого.



        Курс открывает моя лекция о том, зачем вообще автоматизировать процесс разработки. Из нее вы получите представление о то, что будут рассказывать мои коллеги.

        Сейчас занятия закончились, и мы, как и обещали, выкладываем записи лекций, которые перемежаются с мастер-классами, для всех желающих. Понятно, что наш опыт и знания – не 42, но мы надеемся, что они принесут вам пользу.
        Читать дальше →
      • Как внедрить у себя back-to-back-тестирование. Опыт Яндекса

          При ускорении разработки возникает потребность ускорить и написание автотестов. К числу подходов, позволяющих покрывать тестами значительные куски функциональности за небольшое время, относится back-to-back-тестирование. Одна из наиболее распространенных разновидностей подобного тестирования для веб-сервисов – это сравнение скриншотов. Мы рассказывали о том, как используем его в тестировании поиска Яндекса. Если у вас имеется протестированная версия продукта, то создать набор автотестов для следующих версий достаточно просто и на это не потребуется много времени. Основная трудность состоит в том, чтобы в разных версиях сервиса воспроизводились идентичные ситуации. Для этого зачастую приходится поддерживать большое количество тестовых данных в нескольких средах.



          Когда задумываешься об использовании back-to-back-подхода, первое, что приходит в голову, – проводить сравнение со стабильной средой. Но как эталон она подходит для очень ограниченного круга продуктов, потому что данные в стабильном и тестовом окружении зачастую расходятся. Нередко, убедившись, что проводить сравнение со стабильной средой не удастся, исследователь отказывается от использования back-to-back-тестирования. Читайте под катом о паре стандартных способов внедрения данного подхода, которые мы используем для сервисов Яндеса и которые решают многие проблемы, возникающие при использовании стабильной среды. Также мы расскажем об их достоинствах и недостатках, которые мы обнаружили.
          Читать дальше →
          • +38
          • 18.4k
          • 9
        • Allure — фреймворк от Яндекса для создания простых и понятных отчётов автотестов [для любого языка]

            Прежде чем начать рассказ про наш очередной opensource-инструмент, давайте я поясню, для чего мы его сделали. Я довольно много общаюсь с коллегами-тестировщиками и разработчиками из разных компаний. И, по моему опыту, автоматизация тестирования ─ один из самых непрозрачных процессов в цикле разработки ПО. Посмотрим на типичный процесс разработки функциональных автотестов: ручные тестировщики пишут тест-кейсы, которые нужно автоматизировать; автоматизаторы что-то делают, дают кнопку для запуска; тесты падают, автоматизаторы разгребают проблемы.



            Я вижу здесь сразу несколько проблем: ручные тестировщики не знают, насколько автотесты соответствуют написанным тест-кейсам; ручные тестировщики не знают, что именно покрывается автотестами; автоматизаторы тратят время на разбор отчётов. Как ни странно, но все три проблемы вытекают из одной: результаты выполнения тестов понятны только автоматизаторам — тем, кто эти тесты писал. Именно это я и называю непрозрачностью.

            Однако существуют и прозрачные процессы. Они построены таким образом, что вся необходимая информация доступна в любой момент. Создание таких процессов может потребовать некоторых усилий на старте, но эти затраты быстро окупаются.

            Именно поэтому мы разработали Allure — инструмент, позволяющий внести прозрачность в процесс создания и выполнения функциональных тестов. Красивые и понятные отчёты Allure помогают команде решить перечисленные выше проблемы и начать наконец разговаривать на одном языке. Инструмент имеет модульную структуру, позволяющую легко интегрировать его с уже используемыми инструментами автоматизации тестирования.
            Читать дальше →
          • Тестирование в Яндексе. Сам себе web-service over SSH, или как сделать заглушку для целого сервиса

              Вы практикующий маг менеджер. Или боевой разработчик. Или профессиональный тестировщик. А может быть, просто человек, которому небезразличны разработка и использование систем, включающих в себя клиент-серверные компоненты. Уверен, вы даже знаете, что порт это не только место, куда приходят корабли, а «ssh» это не только звук, издаваемый змеёй. И вы в курсе, что сервисы, расположенные на одной или нескольких машинах, активно между собой общаются. Чаще всего по протоколу HTTP. И от версии к версии формат этого общения нужно контролировать.



              Думаю, каждый из вас при очередном релизе задавался вопросами: «Точно ли мы отсылаем верный запрос?» или «Точно ли мы передали все необходимые параметры этому сервису?». Всем должно быть известно и о существовании негативных сценариев развития событий наравне с позитивными. Это знание должно активно порождать вопросы из серии «Что если..?». Что если сервис станет обрабатывать соединения с задержкой в 2 часа? Что если сервис ответит абракадабру вместо данных в формате json?

              О таких вещах нередко забывается в процессе разработки. Из-за сложности проверки проблем подобного рода, маловероятности таких ситуаций и еще по тысяче других причин. А ведь странная ошибка или падение приложения в ответственный момент могут навсегда отпугнуть пользователя, и он больше не вернётся к вашему продукту. Мы в Яндексе постоянно держим подобные вопросы в голове и стремимся максимально оптимизировать процесс тестирования, используя полезные идеи. О том, как мы сделали такие проверки легкими, наглядными, автоматическими и пойдет речь в этой статье.
              Читать дальше →
              • +41
              • 20.8k
              • 2
            • Плагинизация с использованием Maven и Eclipse Aether

                Когда конечными пользователями вашего продукта являются разработчики, способные не только предложить вам идеи для его улучшения, но и горящие желанием всячески поучаствовать в его расширении, вы начинаете задумываться о том, как бы предоставить им подобную возможность. При этом вы не хотите давать полную свободу, ровно как и доступ к репозиторию с исходным кодом. Как в этом случае позволить сторонним разработчикам вносить изменения исключая необходимость изменения исходников, компиляции и перевыкладки системы?
                Подробности
              • Опыт от Яндекса. Как делать свой отчет для автотестов

                • Tutorial
                Хочу поделиться опытом, о том, как создавать хорошие отчёты об автотестах и одновременно пригласить вас на первое мероприятие Яндекса специально про тестирование.

                Сначала пару слов о событии. 30 ноября в Санкт-Петербурге мы проведём Тестовую среду — своё первое мероприятие специально для тестировщиков. Там мы расскажем, как у нас устроено тестирование, что мы сделали для его автоматизации, как работаем с ошибками, данными и графиками и о многом другом. Участие бесплатное, но мест всего 100, поэтому надо успеть зарегистрироваться.

                Тестовая среда для нас в первую очередь — площадка для общения. Мы хотим не только рассказать о себе, но и поговорить с участниками о том, как работают они, обменяться знаниями, ответить на какие-то вопросы. Думаем, общих тем будет много, но чтобы вы начали обдумывать их уже сейчас, мы начинаем серию публикаций о тестировании в Яндексе.

                Автоматизации тестирования на Тестовой среде будет посвящено несколько докладов, в том числе мой. Итак, начну.
                image
                Бывают unit-тесты, а бывают высокоуровневые. И когда их количество начинает расти, анализ результатов запусков становится проблемой. Скажите честно, кто из вас не думал сделать свой отчет?
                Читать дальше →
                • +54
                • 19.9k
                • 6
              • Как мы тестируем поиск в Яндексе. Screenshot-based тестирование блоков результатов

                  Чем крупнее и сложнее становится сервис, тем больше времени приходится уделять тестированию. Поэтому желание автоматизировать и формализовать этот процесс вполне законно.

                  Чаще всего для автоматизации тестирования веб-сервисов применяется Selenium WebDriver. Как правило, с его помощью пишут функциональные тесты. Но, как всем хорошо известно, функциональные тесты не могут решить задачу тестирования верстки сервиса, что требует проведения дополнительных ручных, зачастую кроссбраузерных, проверок. Как тест может оценить корректность верстки? Чтобы обнаружить регрессионные ошибки верстки, тесту потребуется некоторый эталон, в качестве которого может выступать изображение корректной верстки, взятой, например, с продакшен-версии сервиса. Этот подход носит название screenshot-based testing. Подход этот применяется достаточно редко, и чаще всего верстку все же тестируют вручную. Причина этому – ряд достаточно строгих требований к сервису, к среде выполнения тестов и к самим тестам.

                  Расширенные ответы сервисов Яндекса в результатах поиска — мы у себя внутри по старой традиции называем их «колдунщиками» — дополнительное звено, в котором что-то может сломаться.

                  На примере тестирования колдунщиков в поиске мы расскажем, какими особенностями должен обладать тестируемый сервис, какие проблемы возникают у нас при использовании screenshot-based testing, и как мы их решаем.

                  image
                  Читать дальше →
                • Тестирование в Яндексе. Фреймворк HTML Elements: чего не хватает в Page Object, и как это исправить

                    Если вы занимаетесь тестированием веб-интерфесов, то наверняка задумывались о том, как сделать взаимодействие с веб-страницами в тестах максимально удобным. Среди тестировщиков очень широко известен шаблон проектирования Page Object. Но, несмотря на множество плюсов, у этого подхода есть и некоторые недостатки, которые сильно затрудняют его применение.

                    Наиболее существенные из них:
                    • невозможность повторного использования кода page-объектов для страниц с одинаковыми элементами;
                    • плохая читаемость и отсутствие наглядности кода для страниц с большим количеством элементов;
                    • отсутствие типизации элементов.

                    Из этого поста вы узнаете, как мы в Яндексе решаем эти проблемы с помощью фреймворка с открытым исходным кодом HTML Elements. Он расширяет концепцию шаблона Page Object и позволяет сделать взаимодействие с элементами на веб-страницах простым, гибким и удобным.

                    Мы не будем останавливаться на описании самого паттерна и его принципов, поскольку большинству из вас он наверняка хорошо знаком. Если же кто-то с ним не встречался, то узнать о нём можно из этого поста или мастер-класса. Также, говоря о применении паттерна Page Object, мы будем подразумевать его Java-реализацию в фреймворке Selenium WebDriver.

                    Повторное использование кода


                    Представьте, что вам понадобилось написать тесты не на какую-то отдельную страницу, а на весь веб-сервис. На его страницах наверняка будут встречаться общие блоки элементов: хедеры, футеры, возможно, какие-то одинаковые формы и т.д. Например, на главной странице Яндекса есть форма поиска, которая сохраняется и при переходе на страницу с поисковой выдачей.

                    image
                    Читать дальше →