Автоматизация приёмочного тестирования или FitNesse для повышения качества программного продукта

    image
    Качество программного продукта не в последнюю очередь зависит от актуальной документации и тщательного тестирования. Хотелось бы осветить вопрос разработки и тестирования ПО вообще и с использованием среды FitNesse в частности.

    Intro


    Когда говорят о тестировании ПО, чаще всего подразумевают тестирование, выполненное после того, как изрядное количество кода написано и возникает необходимость проверить «а то ли написали, что хотели».
    Понятно, что покрытие кода тестами, виды и продолжительность тестирования зависят от многих факторов, но в данном случае следует упомянуть именно о модульных тестах и о приёмочных тестах.
    Если модульное тестирование выполняет обычно тот, кто пишет тот или иной кусок кода, то приёмочное тестирование, как правило, выполняет заказчик. И тут уже всё зависит от того, насколько высоки требования заказчика (и, что немаловажно, то насколько он способен качественно тестировать принимаемый им готовый продукт).
    Так вот, модульные тесты обычно автоматизированы по выполнению (они один раз пишутся и много раз прогоняются в автоматическом режиме).
    А приёмочные тесты обычно медленно прогоняются в ручном режиме и постоянно изменяются и обычно достаточно редко фиксируются на бумаге.
    К чему все эти разговоры про тестирование? Правильно организованный процесс тестирования создаваемого программного продукта в конечном счёте позволит сэкономить деньги и время на устранении ошибок, и более того увеличить прибыль от хорошей репутации компании.

    image

    Problem definition


    Обычно при объяснении важности тестирования любят приводить график экспоненциального роста стоимости исправления ошибки в программном продукте в зависимости от этапа её обнаружения.

    image

    Но также нельзя забывать о том, что стоимость тестирования, особенно выполняемого вручную, слишком высока. Так если у нас будет больше 4500 тестов для прогона (что нормально для приёмочного тестирования среднего проекта), то нам потребуется больше 40 человеко-дней на однократное выполнение такого тестирования. А теперь представим, что мы обнаружили ошибку и после исправления этой ошибки необходимо будет заново прогнать 4500 тестов вручную.

    image

    Кроме проблемы с тестирование в ручном режиме существует проблема с поддержанием документации в актуальном состоянии.
    Необходимо обеспечивать синхронизацию следующих документов: требований, спецификаций пользовательских интерфейсов, спецификации тестов и их реализацию.
    Для спецификации пользовательских интерфейсов существует определённая тенденция того, что документацию со временем освобождают от скрин-шотов и проектных схем, чтобы сделать её более устойчивой к возможным ошибкам. Но в тоже время такая документация становится нечитаемой и её становится тяжело понимать. В ней отображается слишком большое количество низкоуровневых сценариев (Use Cases) и её становится тяжело поддерживать. Всё это, в конечном счёте, выливается в то, что у разработчиков исчезает мотивация поддерживать документацию в актуальном состоянии.

    image

    Спецификации тестов обычно полностью дублируют спецификацию пользовательских интерфейсов с конкретными именами, номерами и строками в Use Cases (сценариях). Они более конкретизированные и специфические, нежели спецификация пользовательских интерфейсов. Но всё ещё оставляют возможность для свободного истолкования людьми того, что в них отражено.
    Сложно сохранять мотивацию разработчиков и руководителей поддерживать документацию в актуальном состоянии.
    Идеальным вариантом могло бы быть, конечно, использование робота для ручного прогона тестов и отражения результатов в документации…

    image

    Но эра таких умных штуковин ещё не пришла, поэтому приходится использовать другие методы…

    FitNesse introduction


    Предлагаю к рассмотрению FitNesse

    FitNesse – это в первую очередь инструмент для совместной разработки программного обеспечения.
    FitNesse позволяет клиентам, тестерам, и программистам изучить то, что должно сделать их программное обеспечение, и автоматически сравнить это с тем, что программное обеспечение фактически делает. FitNesse позволяет сравнить ожидания заказчиков с полученным результатом.
    FitNesse – это инструмент для тестирования программного обеспечения.
    Совместно определите AcceptanceTests – web страницы, содержащие простые таблицы входов и ожидаемых выходов. Запустите эти тесты и посмотрите результаты.
    FitNesse – это wiki.
    Можно легко создавать и редактировать страницы.
    FIT (“Framework for Integrated Testing”) является ядром, которое в действительности обрабатывает каждую таблицу FitNesse, используя FixtureCode, относящийся к этой таблице. Разработан Уордом Каннингемом (Ward Cunningham) как расширение среды xUnit. Поддерживает большинство современных языков программирования (.Net, Java, Python, Ruby, C++, …).

    FIT + Wiki + Web Server = FitNesse

    image

    Помимо FIT на сегодняшний день существует поддержка технологии SLIM, о которой можно подробнее почитать на сайте продукта.

    image

    Можно привести пример того, как выглядит fixture code, таблица для теста и результат работы среды.

    Example


    Вот пример fixture кода для тестирования некоего приложения на C#:
    using System;
    using System.Collections.Generic;
    using System.Text;
    using Ranorex;
    namespace NetFit
    {
      public class AddVIPTest : fit.ColumnFixture
      {
      ///
      /// UI Repository instance for VIP Application
        ///
      private VIPRepo repo = VIPRepo.Instance;
      private string gender;
      private string lastName;
      private string firstName;
      ///
      /// Property for FirstName parameter.
      /// By setting the property Ranorex directly clicks
      /// the text box and simulates the keyboard events
      /// Returns the current text value of the text box.
      ///
      public string FirstName
      {
        set
            {
              this.firstName = value;
              repo.VIPApplication.FirstName.Click();
              Ranorex.Keyboard.Press(firstName);
            }
            get
            {
              return repo.VIPApplication.FirstName.TextValue;
            }
        }
        ///
        /// Property for FirstName parameter.
        /// By setting the property Ranorex directly clicks
        /// the text box and simulates the keyboard events
        /// Returns the current text value of the text box.
        ///
        public string LastName
        {
            set
            {
              this.lastName = value;
              repo.VIPApplication.LastName.Click();
              Ranorex.Keyboard.Press(lastName);
            }
            get
            {
              return repo.VIPApplication.LastName.TextValue;
            }
        }
        ///
        /// Property for Gender parameter.
        /// Depending on the given value Ranorex selects
        /// the right radio button.
        /// Returns the currently selected gender
        ///
        public string Gender
        {
          set
          {
            gender = value;
            if (gender.Equals("Female"))
              repo.VIPApplication.Gender.Female.Click();
            else if (gender.Equals("Male"))
              repo.VIPApplication.Gender.Male.Click();
          }
          get
          {
            if (repo.VIPApplication.Gender.Female.Checked)
              return "Female";
            else
              return "Male";
          }
        }
        /// Method is used to simulate a click on
        /// specified button.
        ///
        ///
        /// Specifies the label of the button to press
        ///
        public void Action(string button)
        {
          repo.VIPApplication.Self.FindChild(button).Click();
        }
        ///
        ///
        /// Returns the current text value of
        /// the status bar.
        ///
        public string ValidateStatusBox()
        {
           return repo.VIPApplication.StatusBar.TextValue;
        }
    }


    * This source code was highlighted with Source Code Highlighter.


    Так выглядит таблица для Test Case на FitNesse:

    !|NetFit.AddVIPTest|
    |FirstName|LastName|Gender|Action|ValidateStatusBox?|
    |Marylin|Monroe|Female|Add|VIP count: 1|
    |Bill|Gates|Male|Add|VIP count: 2|
    |Hillary|Clinton|Female|Add|VIP count: 3|

    А так выглядит результат работы этого теста:
    image

    С помощью FitNesse можно создавать наборы для тестирования, что значительно упрощает проведение приёмочного тестирования программного обеспечения. Кроме того, поскольку FitNesse – это WiKi, то в одной среде можно хранить и поддерживать в актуальном состоянии всю документацию по проекту с привязкой к выполненным тестам, как модульным, так и приёмочным.

    В дополнение можно посмотреть видеозапись с конференции по автоматизированному тестированию, где Uffe Overgaard Koch рассказывает про Automated Testing of
    Mobile Handsets.



    Надеюсь, что данный материал будет полезен.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +5
      В бытность работы контактором Motorola работал над проектом по созданию инструментария для тестирования viewfinder (камара) в телефонах для платформы P2k. Мы изучали вопрос о том, что в конечном счёте будет лучше: создать собственную среду на основе бесплатной FitNesse или купить готовый продукт Stride от компании S2 software. Stride показал лёгкость в создании тестовых заданий и вызове низкоуровневых функций телефона, однако на тот момент он возвращал только значения функций. Для большинства функций работы с графикой на языке Си только 2 значения 0, если успешно и, как правило, 1 в противном случае. Нам же для того, чтобы удостовериться, что камера на телефоне отрабатывает корректно, необходимо было загружать полученные изображения и видео. За 2 месяца мы добились того, что наш проект на FitNesse позволял подгружать результат работы камеры сразу на ту же web страницу, где была тестовая таблица, и помещал в эту таблицу фотографию или видеоролик. Таким образом, можно было сразу посмотреть результат и нажать кнопку соответствует он ожидаемому или нет, а потом сохранить результаты тестирования. FitNesse оказался очень мощным инструментом для совместной разработки и тестирования даже в такой специфичной области, как разработка встроенного программного обеспечения.
        +1
        Материал, безусловно, интересный. Такой вопрос: использовали ли вы это средство сами? Если да, то…
        — Какие трудности ожидают при его разворачивании?
        — Какие есть ограничения по функционалу?
        — На каком принципе (на пальцах) можно тестировать интерфейс и поведение программы?

        Как я понял, пишется набор классов, которые имитируют поведение пользователя. Далее, в методах классов что-то возвращается — это потом передается в вики?

        — Как может средство сигнализировать о провалившихся тестах? Или я путаю с модульным тестированием, и в данном случае такого не требуется?

        И в большей степени хотелось бы узнать о вашем или не вашем опыте применения в реальном проекте.

        Спасибо.
          +1
          В догонку.
          Я планирую начать масштабный проект на своей работе — базу данных. (Qt, MS Sql Server, NCReport/eXaro). Ищу подобные средства тестирования. Как быстро, по-вашему, я смогу интегрировать этот продукт в свою работу? Хватит ли, скажем, месяца, или требуется какая-то длительная доводка компонент?
            +2
            Интегрировать можно и за неделю, если проект только начинается. Больше всего времени займёт написание fixture для вашего кода. Хотя, если это будет делаться параллельно с самой разработкой, то процесс будет носить естественный характер и пойдёт быстрее. Я бы назвал оптимистичный сценарий в 2 недели. Неделю на изучение среды и неделю на внедрение в проект.
              +2
              А можно ли как-то подружить FitNesse и doxygen? Например, настроить автоматическую генерацию документации с интегрированием ее в вики FitNesse?
                0
                Я таким вопросом не интересовался, поэтому не могу сказать можно или нет.
            0
            >Такой вопрос: использовали ли вы это средство сами?
            Смотреть мой комментарий выше. Да использовал.

            — Какие трудности ожидают при его разворачивании?
            Особых трудностей нет. На сайте проекта есть подробное описание этого процесса. Понадобится только установить любой web server и запустить специальный батник. Обо всём этом на сайте fitnesse.org написано детально.
            — Какие есть ограничения по функционалу?
            Мне функционала хватало за глаза. Поэтому ограничения зависят от того как собираетесь использовать.
            — На каком принципе (на пальцах) можно тестировать интерфейс и поведение программы?
            Про это лучше всего написано на сайте fitnesse.org и в книге «Fit for Developing Software: Framework for Integrated Tests» by Rick Mugridge, Ward Cunningham
            А на пальцах в любом случае необходима визуальная оценка человека, если речь идёт о графическом интерфейсе. Просто FitNesse позволяет сохранять результаты прогона теста для его дальнейшего анализа.

            — Как может средство сигнализировать о провалившихся тестах? Или я путаю с модульным тестированием, и в данном случае такого не требуется?
            Сигнализирует подкрашиванием соответствующих строк в таблице на страницах FitNesse.
            С помощью FitNesse можно выполнять модульное тестирование.

            И в большей степени хотелось бы узнать о вашем или не вашем опыте применения в реальном проекте.
            Мой опыт рассказывать долго, а про не мой опыт в конце поста есть замечательная запись с конференции Google London Test Automation Conference (LTAC)

              +3
              Благодарю.

              Что ж, буду сам изучать этот инструмент. Вы правы: не потыкав, на одних только рассказах, толком и не составишь представление о продукте. Однако ваш опыт использования так же интересен с человеческой точки зрения, а не только технической. Другими словами, было бы интересно почитать записки разработчика.
            +5
            Описано действительно хорошо.

            Я год назад этим делом пользовался краткосрочно. Почти что «поиграл». Потом надо было, собственно, работать, и пришлось перейти к обычным средствам тестирования.

            Посмотрите, что Алексей Баранцев, программист-тестировщик, когда-то рассказывал о трудностях тестировщиков, которые пытались работать с FitNess.

            Цитата:

            Тестировщики попробовали пользоваться FIT – нет, не айс… Никакого fun нет.

            Почему? Оказалось, что у них разной работы гораздо больше. Помимо unit testing и acceptance testing есть еще и интеграционное тестирование, где надо вглубь системы руки по локоть запускать, и FIT туда не влезает. Есть системное тестирование, условно говоря, его можно назвать acceptance testing, но FIT помогает только если у вас веб-приложение. Если вы зайдете на сайт FIT и посмотрите, какие там есть предопределенные, стандартные fuxtures — вы найдете fuxtures для JDBC и для веб-приложений. Всё!

            А если у вас какие-то сложные протоколы, а если вам надо SMS обмениваться, если у вас нормальный обычный GUI-интерфейс — что вам делать? Нет, там не работает FIT, он doesn’t fit вообще!
              +1
              Само собой, что набор стандартных fixture не покрывает абсолютно все запросы абсолютно всех проектов. При «правильно прикрученных руках» можно заставить FitNesse и интеграционным тестированием заниматься. Мы заставили его тестировать встроенное ПО мобильного телефона, отвечающего за работу MEDL (Multimedia Engine Device abstraction Layer) — т.е. что ни на есть низкоуровневые тесты. Позже при дальнейшем создании fixture под нашу задачу мы сделали из него хороший инструмент для интеграционного тестирования. В статье, которую вы рекомендовали Алексей Баранцев основной упор делает на то, что его якобы «обманули» тем, что FitNesse может стандартным своим наполнением обеспечить весь спектр задач тестировщика. Так не бывает. Но критика должна быть конструктивной. Если вы говорите, что FitNesse — это ерунда, то предложите другое решение. Судя по статье Баранцева — альтернатива FitNesse — полностью всё делать самим с нуля. Но тогда получается, что если вам не нравиться ни один продукт современного автопрома, то вы лучше будете расстояния между городами покрывать пешком… Или изобретать собственный автомобиль (или велосипед)… Когда-то это оправдано, но чаще на этот нет ни времени и ни денег.
                +2
                Прежде, чем ответить на критику моего негативного высказывания в адрес Fitnesse, мне было бы интересно узнать, какими другими инструментами автоматизации автор статьи пользовался в достаточном количестве, чтобы иметь возможность сравнивать их с Fitnesse не на учебных примерах, а «в полевых условиях»? И в чём конкретно Fitnesse у них выиграл? Тогда я хотя бы пойму, какое именно «другое решение» можно предложить, чтобы продолжить обсуждение различных «за» и «против».

                Но, несмотря на мои личные предпочтения по части выбора инструментов, не могу не признать, что статья написана достаточно хорошо, так что мы с удовольствием опубликовали бы её и на нашем сайте, если автор не против.
              0
              Спасибо за материал.
              Попробуем.
                +1
                по-моему, основное назначение fitnesse — это написание тестов со стороны технически неподкованного заказчика, который не очень разбирается во внутренностях системы, а вот внешние ожидания может накидать с помощью этих табличек.
                уже после того как таблички с тестами составлены заказчиком и проверены QA, в дело вступают программеры, пишущие fixtures.

                а вот использовать его для интеграционного тестирования, прогона юнит тестов и для ведения документации по проекту (wiki) — это, мне кажется, не совсем те задачи, для которых fitness будет лучшим решением.

                основная идея (превращение вики-разметки в последовательность вызовов функций) в принципе очень хороша, но fitness сам по себе не настолько функционален, чтобы использовать его «для всего». вот как плагин к уже имеющимся сборщикам, баг тракерам, базам знаний (а-ля confluence) он смотрелся бы шикарно.
                  0
                  основная идея (превращение вики-разметки в последовательность вызовов функций) в принципе очень хороша

                  Чем она так уж сильно лучше простого написания последовательности вызовов функций? Количество текста, который надо написать, совпадает практически один к одному. Среда написания табличек недружелюбная и не следит за отсутствием опечаток и других ошибок, которые в результате благополучно доживают до момента выполнения тестов. Да и вообще wiki-синтаксис не назовёшь сильно удобным.
                  0
                  Интересно выслушать мнение Джеймса Шора (который одно время был координатором проекта Fit): jamesshore.com/Blog/The-Problems-With-Acceptance-Testing.html

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

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