Автоматизация функционального тестирования: что это такое и как это может быть полезно

    В том, что тестирование ПО необходимо, к счастью, никто уже не сомневается. Но так как сама отрасль тестирования достаточно молодая, в ней еще не сформировались общепринятые методологии и правила, как в отрасли разработки ПО. Как обычно производится функциональное тестирование приложений, систем и т.п. Процесс можно разбить на следующие стадии:
    1. Сбор требований (справедливо для «внешнего тестирования»)
    2. Создание тестовой модели (что и как тестируем)
    3. Проведение тестирования
    4. Отчет о тестировании (дефекты, проблемы и т.п)

    Каждая стадия включает в себя исключительно ручной труд. И для каждой новой версии приложения необходимо проводить регрессионное тестирование — повторять следующие стадии:
    1. Дополнение тестовой модели
    2. Проведение тестирования
    3. Отчет
    Причем стадия «Проведение тестирования» включает в себя тестирования всего объема функциональности – и старого, и нового. Таким образом получается, что с ростом функциональности растет и объем ручного тестирования, причем тестирование «старого» функционала совершенно справедливо вызывает у тестировщика отторжение – «я уже 10 раз это смотрел». Следовательно, падает и качество тестирования (снижение внимания), и скорость проведения полного тестирования системы. Регрессионное тестирование ведет к регрессу тестировщиков. Автоматизация призвана и ускорить процесс тестирования, и избежать деградации тестировщиков.


    Рассмотрим тестовый сценарий, состоящий из ввода данных в форму из 10 полей и контроля результата – таблицы из 20+ строк, в которой нас интересует одна строка, содержащая только что введенные нами данные. Посчитаем и сравним временные затраты на запуск автотеста и ручного теста.

    Ручное тестирование:
    1. Ввод данных, ~10*5 секунд = 50 секунд
    2. Отображение таблицы – 2 секунды
    3. Поиск нужной строки – 5-15 секунд
    4. Проверка соответствия введенных данных и строки – 10*3 = 30 секунд
    Итого на один запуск – 87-102 секунды
    Автотест:
    1. Ввод данных — ~10*0.1 = 1 секунда
    2. Отображение таблицы – 2 секунды
    3. Поиск нужной строки – 0.5 секунды
    4. Проверка соответствия введенных данных – 0.5 секунды
    Итого на один запуск – 4 секунды.

    Таким образом временная экономия на запусках составляет 83 секунды или 25 раз (автотесты работают практически со скоростью ответа сервера). И это простейший тест-кейс из одного шага. А если у нас 100 тесткейсов по 10-15 шагов в каждом? Тогда человекомесяцы превращаются в один календарный день. Впечатляет? И дело здесь не только в экономии средств, но и того, чего никогда не хватает – времени.

    Но есть и «подводные камни». Я не случайно заостряю внимание на экономии на запусках – сам автотест необходимо еще и написать. Обычно именно это является основной причиной нежелания внедрения автоматизации тестирования. Доводы приводятся следующие: «сейчас у меня 10 тестировщиков низкой квалификации по n-денег, а автоматизация потребует двоих, но за n*4. Экономии практически никакой, а проблем с внедрением много.» Но если продукт растет, то через какое-то время нужно будет уже не 10, а 15-20-30 тестировщиков, а количество автоматизаторов, если и вырастет, то незначительно. Автотесты же не нужно переписывать все, нужно только создавать новые и поддерживать в актуальном состоянии существующие в случае изменения покрываемого ими функционала. И экономия уже не будет такой эфемерной, даже исключая расходы на управление всеми этими 15-20-30 ручными тестировщиками.

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

    Возьмем классический для «Я пиарюсь» пример – стартап. Свойство таких проектов – очень быстрое развитие. Если при внедрении новых возможностей начнут сбоить те, которые были изначально и являются, собственно, изюминкой проекта, то пользователи уйдут. Если тестировать новые возможности и существующие изюминки, то это займет существенное время и пользователи уйдут. И в этом случае автоматизация может выступить как волшебная палочка.

    Автоматизация тестирования – не страшный и дорогой нечто, доступое только избранным, а реальное средство для уменьшения энтропии :)

    P.S. В качестве средств автоматизации могу порекомендовать:


    Комментарии 24

      +1
      Мало :) Еще давайте )
        +1
        О чем? :) об автоматизации в общем или о чем-то конкретном с примерами?
          0
          Если будет и о том, и о другом, будет отлично. А если примеры применения бесплатных тулов из жизни приведете, да еще и с рекордерами, да еще и для Win32 — вообще цены не будет.
          А то мы, например, самописьками на AutoIt пользуемся, стыдно признаться.
            +1
            AutoIt в любом случае лучше чем руками :)

            С рекордерами в бесплатных тулзах, я боюсь, очень плохо, но попробую.

        +1
        Лично от себя могу порекомендовать WatiN для .NET или WatiJ для Java(последний как-то не очень развивается). В селениуме одновременно плюсом и минусом является запуск тестов через прокси, то есть через сам селениум, который является Java приложением. Минусом является то, что требуется запускать его(прокси) помимо основного теста, тогда как в WatiN можно тест скомпилировать в один exe файл и давать людям как раз из разряда «тестировщиков низкой квалификации по n-денег». Давно хочу написать про WatiN\WatiJ, но вот как то с кармой в прошлом накосячил(Данное предложение ни в коем случае не является просьбой поднять карму :), лучше скажите как в песочницу написать)
          0
          Автотест:

          1. Ввод данных — ~10*0.1 = 1 секунда
          2. Отображение таблицы – 2 секунды
          3. Поиск нужной строки – 0.5 секунды
          4. Проверка соответствия введенных данных – 0.5 секунды

          Информация не совсем верная :) Такое мы получаем в идеальном случае. В реальном приложении всё будет несколько медленной. Например есть веб-страница, на страничке есть AJAX запрос, так что иногда приходится ждать пока произойдет взаимодействие с сервером etc.
            0
            в этом случае ждать приходится и человеку тоже.
              0
              Ручному тестировщику тоже нужно будет сделать AJAX запрос к чашке кофе или в аську. :) Так что для него тоже приведен идеальный вариант. Автоматизация же не призвана ускорять приложение — для этого есть нагрузочное тестирование :)
                +1
                Вы меня чуть чуть не поняли. Например, какой нибудь абстрактный «босс» прочитает ваш пост и подумает: «Круто! В разы уменьшает время тестирования!». Потом он дает команду QA сделать автотесты, но в приложении встречается пара таких палок в колёса по типу AJAX. QA справляется с ними, добавляя что-то типо waitForComplete(), но потом на это смотрит «Босс» и говорит: «Эй! Что это у вас так всё медленно! Я читал что на это тратится всего 4 секунды! А у вас целых 20! Что за фигня! Вы ничего не умеете!» etc. В конце концов достается QA отделу, и лично тому кто делал тесты.
                  0
                  Спасибо. Добавлю (не меняется) к времени открытия страницы. Надеюсь, что так боссам будет понятнее.
              +1
              Есть очень много других средст тестирования как платных, так и бесплатных.
              Из своего опыта могу поделиться такой программой как BadBoy — бесплатная программа для тестирования веб-сайтов. Мы ее активно используем для ежедневной проверки наших главный сайтов. Небольшая, простая в использовании, хорошо документированная, немногожко глюков конечно есть, но жить можно :).
              Также большой список различных средств тестирования веб-сайтов доступен тут.
              Могу еще порекомендовать TestComplete. Хоть он и платный, но очень хорошо подходит для тестирования как веб-сайтов, так и Win приложений.
                +1
                На BadBoy посмотрю, спасибо.

                Что касается TestComplete, то у него по сравнению с QTP есть один недостаток — «из коробки» он не интегрируется в HP (Mercury) Quality Center, который является практически отраслевым стандартом средств поддержки процесса тестирования в больших организациях. Сам по себе он, безусловно, хорош.
                +1
                Нужен обзор средств автоматического тестирования. Плюсы-минусы.

                Про указанных в списке могу сказать только про Selenium — удобный, но неразвитый продукт. В частности записанный тест кейс спотыкается на iframe и редакторах, которые их используют. И если для фрейма можно допилить напильником, то редактор победить не удалось, похоже не умеет генерировать события правильно.

                Также напильник нужен для AJAX-а. И вообще тесты требуют напильника и знаний/опыта как это работает. Рекламируемая простота — только для банальных хомяков.

                Иногда тесты с отслеживанием событий, проверками и действиями с ожиданием, почему-то может не работать на Fast. Может быть и на Slow что-то не работает.
                Не умеет работать с запросам к серверу, то есть GETы можно прописать вручную, но это наиболее легкая для автоматизации часть полностью упущена. Что-то есть для

                А вообще тулза супер! :) Простые вещи делаются быстро, сложные — по-разному, как и бывает обычно. Добавить автоматическое тестирование запросов к серверу с параметризацией — цены бы ему не было.
                Открытые исходники дают возможность допилить самому.
                Не проверял, но рекламируется возможность удаленного тестирования на сервере и организовывать кластеры.
                  0
                  Для небанальных хомяков существуют коммерческие средства автоматизации. Например, упомянутые уже Testcomplete и QTP от HP. В селениуме мне понравилось наличие рекордера, что его как-то сближает с коммерческими инструментами. Некоторые вещи, как справедливо было замечено, можно делать очень быстро.

                  Правда и в коммерческих тулзах простые вещи делаются очень быстро, а сложные — как обычно :) Особенно часто это проявляется, если на странице есть «нестандартные» элементы управления, например, набор дивов, который выглядит и ведет себя как combobox. Помучиться пришлось изрядно %(

                  0
                  > Причем стадия «Проведение тестирования» включает в себя тестирования всего объема функциональности – и старого, и нового.
                  Вот с этим не согласен. Я например смотрю, какие изменения выложил разработчик в SVN (обычно с пометками, что добавлено/исправлено/изменено) и уже этот функционал и гоняю, потом когда подходит время релиза или просто нечего делать — приступаю к тестированию всего функционала, т.е. одно и тоже проверять по несколько раз не стоит, всё должно подчинятся какой-то логике…
                    +1
                    Об этом и речь. Вы не прогоняете regression tests руками — тесты, которые проверяют, а не отвалился ли существующий/старый функционал при добавлении нового. Это не делают по разным причинам, основная — по мере разработки слишком дофига функционала нужно перетестировать, ресурсов ручного тестирования просто не хватает.

                    В идеале же test automation позволяет записывать все ваши тесты: разработчик выполняет тест вручную 1 раз для каждого нового функционала; тест записывается; и затем на каждый коммит можно в автоматическом режиме проверить, не ломает ли он что-либо уже существующего.
                      0
                      >>разработчик выполняет тест вручную
                      простите, тестер, конечно же
                      0
                      В теории, должен существовать набор smoke-тестов, то есть таких тестов, который покрывают минимальный общий функционал, без которых дальнейшее тестировании бессмысленно. Обычно это небольшой тест, который прогоняется после каждой сборки приложения
                      0
                      Apache Maven создавался для управления полным жизненным циклом приложений — от создания до внедрения, с модульными и интеграционными тестами.
                        +2
                        >>Автотесты же не нужно переписывать, нужно только создавать новые
                        Это грубая ошибка. Я бы сказал даже так, что автотесты при большинстве случаев приходится переписывать под новую бизнес логику, а писать автотесты на уже законченный и более не разрабатываемый продукт смысла не имеет.
                        Вы как то упускаете автоматизацию функционального тестирования десктоп приложений. А при этом типе автоматизации тоже очень много инструментария.
                          0
                          Формулировка не совсем точная, согласен. Поправлю.

                          Автотесты нужны для регрессионного тестирования. Регрессионное тестирование — тестирование неизменного для данного релиза/патча/исправления функционала. Если меняется бизнес-логика — это значит изменился и функционал. В этом случае, естественно, что старые автотесты для данного участка не подойдут. Но полное изменение бизнес-логики бывает достаточно редко, согласитесь.

                          Возьмем пример: толстый клиент управления складом. Текущее количество бизнес-процессов, скажем 10. Заказчик хочет внедрить еще один процесс и изменить 2 существующих. В этом случае мы оставляем 8 автотестов в неизменном виде. Изменяем 2 (обычно изменения незначительные) и создаем один новый.

                          Для автоматизации десктоп приложений существует множество инструментов, в этом я с Вами согласен: и silktest, и testcomplete, и Ranorex и т.д. Но профессионально использовал только QTP и White. А я как-то не привык рекомендовать что-то о чем мало знаю :)
                            0
                            я и не имел в виду полное изменение автотестов.
                            Я специально цитировал высказывание которое считал ошибочным. По остальным пунктам и не собирался даже :)
                          0
                          10 Причин провала автоматизации

                            0
                            Сорри, вот линк sqadotby.blogspot.com/2009/06/10.html

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое