03.07.2017 06:38
antonsobolev 10 3800 Источник
Добрый день. Помнится, в одном сериале про заучек ребята рулили стерео-системой, находящейся в пределах доступности собственной руки, из компьютера, передавая сигнал посредством интернета через всю планету. Здравомыслящая девушка, которую они хотели удивить, впечатлена не была, ибо полагала, что обычный ПДУ дешевле и проще.

image

Тем не менее, есть хорошая новость: incredible machine все-таки может быть полезна. Например, для тестирования программных систем.

Работая над большой ERP-системой OpenPapyrus, которая, в числе прочего, должна уметь выводить изображения штрихкодов разных стандартов и свойств, мы подключили популярную библиотеку zint для рендеринга штрихкодов. Библиотека интегрировалась и заработала. Но тестировать результат все равно надо.

Самым подходящим вариантом для теста будет тестирование посредством обратной функции:

image

на вход подаются случайные данные, преобразуются функцией $f$, затем к результату применяется функция $f^{-1}$, обратная к $f$ и сравнивается выход с исходными данными. Тестируются сразу две функции с бронебойным доказательством правильности работы (не алгоритмов, конечно, а реализации).

Обратной функцией к рендерингу штрихкода очевидно будет распознавание изображения штрихкода. Сказано — сделано. Взяли еще одну open source библиотеку zbar. Инегрировали — заработала.

image

Теперь схема тестирования оформилась вполне четко: входные данные это — текстовое представление штрихкода и его стандарт (ean-13, ean-8, upc-a, code-39, qr и т.п.). Это представление преобразуется в изображение, которое тут же распознается и в результате мы получаем, опять же, текстовое представление и стандарт.

Таким образом мы протестировали следующие компоненты:

  • Библиотеку zint
  • Библиотеку libpng (при выводе и распознавании кода в формате png)
  • Библиотеку zlib (она используется libpng и множеством иных подсистем)
  • Библиотеку libjpeg (при выводе и распознавании кода в формате jpeg)
  • Библиотеку zbar
  • Собственную инфраструктуру, которая все это интегрирует и связывает

Нам остался еще один шаг: zint умеет выводить штрихкод в векторном формате svg, однако же zbar своими средствами этот формат не понимает, но у нас есть собственная инфраструктура для чтения и рендеринга svg-изображения. Добавим в нашу схему еще один узелок и включим в тест. Все работает.

image

Теперь к списку протестированных компонентов можем добавить:

  • Модуль чтения svg-файлов и преобразования их во внутренний векторный формат
  • Модуль рендеринга векторных изображений

Краткое итого


Описанный тест примечателен тем, что использует значительное число модулей различного назначения, реализованных независимо друг от друга. Еще одним его ценным свойством является преобразование данных между качественно различными формами (текст — векторное изображение — растровое изображение — текст).

И ложка дегтя: такой тест, имея великолепную демонстративность, не является достаточным. Он верифицирует функционал компонентов в весьма узком диапазоне областей определения каждого из них. То есть, рассчитывать на полноту тестирования методом «incredible machine» (интересно, ранее кто-нибудь использовал этот термин в таком контексте?), увы, нельзя. Детальные тесты отдельных функций он не отменяет.

Спасибо за внимание.
Поделиться с друзьями
-->

Комментарии (10)


  1. LoadRunner
    03.07.2017 09:54
    #10294938
    +1

    Я тут до КДПВ докопаться хочу. В смысле, до самой схемы.
    1. Камень прилетает в лоб.
    2. Автор машины не знает про устройство смыва в бачке — механическая рука опустится вниз, колено не там должно быть.
    3. Зачем вентилятор — я не понял. Сдуть тряпочку, которая закрывает обзор кролику?
    4. Кролик прыгнет, а не побежит.
    5. Хана телевизору при падении подставки для свечи.
    6. Так и вижу, как рыбка насаживается на гвоздь.
    7. Брызги во все стороны.
    8. Интересно посмотреть на реакцию обрызганного кота, который не пытался ловить рыбку в пакетике.
    9. Вряд ли усилий хватит для нажатия, но вот сопротивления нажатию хватит для переворачивания.

    P. S.

    Помнится, в одном сериале про заучек
    ТБВ же?


    1. vesper-bot
      03.07.2017 13:33
      #10295310
      +1

      Вы явно не играли в оригинал The Incredible Machine. Там есть несколько нюансов (с).


      1. У качелей фиксированная сила, прилагаемая к предмету на второй стороне качелей, поэтому правильно выбранный предмет полетит со строго заданной скоростью. (Правда, в случае конкретно TIM он полетит в сторону телевизора и разобьет его. :))
      2. Рука приделана к палке, которая поднимается вверх с приводом от весов (и там по идее строго слайдер, т.е. одна степень свободы).
      3. Да, точнее, приподнять её, чтобы кролик увидел морковку.
      4. Не хватает клетки и колеса, а также приводного ремня между транспортером и колесом. Иначе кролик действительно упрыгает с транспортера. Но эффект будет все-таки, за счет того, что транспортер под кроликом провернется.
      5. С этой стороны телевизор не разобьется, а отпрыгнувшая свечка прилетит аккурат коту по голове, заставив того ломануться вперед без всякой рыбы в аквариуме.
      6. Решается укорочением плеча, на котором висит гвоздь. Возможно, машина не совсем в масштабе. Кроме того, рыба в шарике — объект относительно мобильный, может и пронесет.
      7. Ага, и телеку хана третий раз — закоротит.
      8. Кстати да, кот реагирует на рыбку ВНЕ аквариума, т.е. чтобы активировать кота, аквариум с рыбой надо разбить. Но это не проблема, свечка активирует кота лучше.
      9. Точка приложения силы достаточно высоко, т.е. усилий на нажатие таки хватит. Но эффект будет явно большой БУМ, а не работающий телевизор. :)


      1. LoadRunner
        03.07.2017 13:38
        #10295320

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

        И дополнение к пункту 6. Более вероятен прокол — дырочка, а не разрыв оболочки. Вода вытечет, рыбка умрёт.


  1. majorius
    03.07.2017 10:52
    #10295022
    +1

    image


  1. aamonster
    03.07.2017 13:15
    #10295282

    Меня, как программиста, подобные сложносочинённые тесты напрягают. Я мечтаю, чтобы тестировщики как можно точнее локализовали ошибку, а тут будешь только знать, что в системе из 50 звеньев что-то пошло не так — и ищи, где...


    1. mayorovp
      03.07.2017 14:06
      #10295350

      Зато у такого теста отличная воспроизводимость — можно любое число раз пройти всю цепочку в отладчике.


      1. aamonster
        03.07.2017 14:52
        #10295436

        Спасибо. Объяснить, что будет с тестировщиком, предложившим подобное? Правильно, он пойдёт воспроизводить баг заново, пока не напишет нормальный тикет.
        Итого, ему всё равно придётся делать короткие тесты — т.е. выполнять вдвое больше работы.


        Написание подобной цепочки оправдано в одном случае: прога отлажена до упора, новый функционал в неё не вносится — а значит, вероятность поломки минимальна (и можно не делать коротких тестов, пока всё не сломается).


        Ну и более-менее приемлем вариант "написать длинный тест и проверять результат на каждом шаге". Он позволяет малой кровью изолировать баг (у кого тестирование организовано на виртуалке — может быть, можно отдать программистам систему в состоянии "сейчас сломается"). Но тут опять же неприятный момент — когда система дорабатывается и её поведение меняется.


        1. mayorovp
          03.07.2017 15:06
          #10295446

          Не надо проверять результат на каждом шаге, пока ничего не сломалось в целом, в этом нет смысла. Вот когда итог не сошелся — тогда можно уже смотреть промежуточные результаты. Первый шаг, на котором произошла ошибка, и станет потом обычным тестом.


          1. GlukKazan
            03.07.2017 15:59
            #10295526

            Серьёзно? У меня не раз бывали случаи, когда одни ошибки маскировали другие.


            1. mayorovp
              03.07.2017 16:05
              #10295546

              Значит, такая ошибка не будет ловиться этим семейством тестов. Печально, конечно — но это просто означает что надо писать разные тесты, а не гонять по кругу один и тот же.


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