Home

Автор: Алексей Лянгузов ( Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript )

Слайдкаст: http://www.slideshare.net/LeshaL/ss-4686660

Какое-то время назад, несколько наших проектов вышли в мир ПО с открытым исходным кодом. За эти годы было выпущено и протестировано несколько версий и накоплен вполне солидный опыт.

Данная статья рассказывает о том, какие особенности встречаются при тестировании программ с открытым исходным кодом. Что нужно для этого знать и уметь. К чему надо готовиться, чего ожидать, а чего опасаться и избегать. Ещё статья затрагивает тему того, как минимизировать затраты на тестирование.

Готовя статью, я практически не нашёл материалов по тестирование программ с открытым кодом в интернете. В частности, не нашёл ничего про то, что же отличает тестирование открытых программ от обычных.

Возможно считается, что тут нет никакой разницы? Или люди думают, что проекты с открытым кодом не нуждаются в тестировании, в традиционном его понимании?

Прочитайте статью, если вы так думаете или если вы собираетесь тестировать ПО с открытым кодом, и вероятно какие-то вопросы перестанут быть для вас вопросами.

Введение

Для начала предлагаю определиться с терминологией и той ситуацией, которую мы будем рассматривать.

Терминология

В статье будут использоваться словосочетания ПО (или программа) с открытым (исходным) кодом или открытое ПО, которые следует понимать в соответствии со статьёй википедии «Открытое программное обеспечение».

Так же, мы будем говорить о свободном и о бесплатном ПО. Определения данных видов вы можете найти в википедии, в статьях «Свободное программное обеспечение» и «Freeware».

Разница между открытым, свободным и бесплатным ПО

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

Таблица 1: Взаимосвязь бесплатного и открытого ПО

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

Программы, попадающие в квадрант (1) называются свободными. Примеры многих таких программ могут быть найдены на порталах таких как http://sourceforge.net или http://java.net или других, им подобных.

Программы из квадранта 2, также хорошо известны. Например, браузер Opera или виртуальная машина Java (до появления OpenJDK).

В (3) попадают более экзотические программы. Примером, может служить архиватор Win RAR. ПО выпускаемое нами тоже попадает именно в эту категорию, но в отличие от RAR-a, доступного всем, у нас есть ограниченное число пользователей, заинтересованных в программе и имеющих доступ к исходному коду. Таким образом, для нас тестирование исходного кода не было в новинку.

И последний, 4-й квадрант включает в себя разного вида коммерческое собственническое ПО.

Открытость процесса разработки ПО

Для тестирования немаловажно то, как ведётся процесс разработки ПО. Что нам нужно для разработки открытого ПО? Да тоже самое, что и для коммерческого! Из основных инструментов — хранилище исходного кода и система отслеживания дефектов.

При разработке бесплатного и свободного ПО возможны два полюса. Первый полюс, когда программа разрабатывается внутри компании, а потом, как и с обычными коммерческими программами — на сайт для скачивания выкладывается архив, содержащий и запускаемый и исходный код программы. Другой полюс, когда разработка полностью ведется в мире открытого ПО, например на уже упомянутом java.net. Эрик Рэймонд называет эти подходы Собором и Базаром соответственно. Очевидно, что могут быть промежуточные ситуации, например, закрытая разработка и открытая система отслеживания дефектов.

Рассматриваемая ситуация

Это ещё не всё. Скоро начнём говорить про тестирование, а пока надо завершить вводную. В добавление к вышесказанному, взглянем на три варианта развития продукта с открытым кодом:

Вариант 1. Разработка открытая, выпускается только один дистрибутив в виде свободного ПО.

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

Вариант 3. Это вариант №2, при котором функциональные возможности программы с открытым кодом отличаются (обычно в худшую сторону) от коммерческого дистрибутива. Пример — XSLT процессор Saxon для версии XSL 2.0.

По ходу статьи мы будем рассматривать Вариант 2. Во-первых, потому что это был наш случай. Во-вторых, Вариант №1 есть подмножество Варианта №2, а соответственно меньше особенностей. В-третьих, Вариант №3 не добавляет ничего нового с точки зрения тестирования открытого ПО. Разница в дистрибутивах присуща обычным коммерческим программам. Например, Home, Standard, Professional и Enterprise версии MS Office.

Еще, хочу отметить, что у нас не писался какой-то продукт с нуля, а происходил именно выход в мир свободного ПО с уже работающим продуктом. В результате, у нас получилось, что мы имеем два продукта, попадающие в квадранты 1 и 3 (это может быть 1 и 4, как мы можем видеть на примере программы Saxon).

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

Особенности тестирования

Исходный код

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

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

Инспекция кода

Про различные виды инспекций кода можно найти много советов, начиная с того, какие надо заполнять документы и вплоть до того, как рассесться в специальной комнате для инспекций. Вы можете воспользоваться этими советами. Я рекомендую более простой и открытый способ, а именно неформальная экспертная оценка коллег (peer review). При этом не должно быть скрытых коммуникаций. У нас такой подход замечательно работает. Следует учесть, что он введён самими разработчиками, а не насажен извне. Могу сказать, что много ошибок отлавливается на этой стадии. Основное правило такое — без рецензии, изменённый код не попадает в хранилище системы контроля версий, а автор кода и основной рецензент несут одинаковую ответственность за ошибки в коде. (примеры: check-in комментарий с указанным ревьювером и обсуждение перед check-in-ом приведшее к откату фикса).

Автоматизированные проверки, не зависящие от языка программирования или технологий

Вы можете выработать набор статических проверок кода, которые могут применяться исходным файлам разного вида. Например, проверка опечаток (spell-checking) или поиск плохих слов (profanity checking). Так же, может возникнуть необходимость убрать нежелательные слова. Это может быть какая-то внутренняя информация (см. ниже) или названия фирм и так далее. Например, если в вашем коммерческом продукте допустим комментарий «Данный код вставлен по просьбе компании No-Name», то выносить наружу информацию о сотрудничестве с компанией No-Name может быть запрещено или неэтично. Проверка того, что нет файлов с идентичными именами, но с разным регистром букв, что допустимо на файловых системах в Unix, но запрещено в Windows. Проверка того, что все файлы имеют одинаковые концы строк (например, '\n', как в Unix). Поиск непечатных символов в текстовых файлах.

Автоматизированные проверки, зависящие от языка программирования или технологий

Например, аудит кода – мы используем такие инструменты как Check Style и Find Bugs, хотя последний и ищет ошибки в класс-файлах. Для XML технологий это может быть проверка валидности документов. Поиск некорректного использования Java API, плохих практик кодирования. Поиск классов, которые имеют одинаковую сигнатуру (package prefix + class name). Так же, к этой категории можем отнести проверку правильности и логичности расположения исходных файлов как в системе контроля версий, так и в выпускаемом продукте, если исходники поставляются в виде архива.

Копирайты

С копирайтами может возникнуть две проблемы. Во-первых, они должны быть в исходном коде. Во-вторых, они должны быть правильными. Какие копирайты правильные, где они должны располагаться и прочая подобная информация, в идеале, должна поступать от руководства проекта или юристов. Какие ситуации самые плохие?

1)Отсутствие копирайта в файле. Опасно тем, что ваша компания может потерять контроль над содержимым данного файла. Например, данный файл может быть кем-либо заимствован и позднее выпущен с другим продуктом, но с более свободной или наоборот закрытой лицензией.

2)Наличие в коммерческой версии копирайта, соответствующего какой-либо свободной или открытой лицензии. Может привести к необходимости открытия исходного кода для всего продукта с закрытым кодом.

3)Наличие коммерческого копирайта в свободной версии. Может быть расценено как несоответствие лицензии или формально может не дать возможность клиентам воспользоваться вашим «свободным» продуктом.

4)Удаление копирайта или изменение оного с чужого на свой. Это есть прямое нарушение законодательства во многих странах мира и может привести к штрафам и потери репутации (см. например тут).

Учтите, копирайты лучше проверять ДО того, как они попали в открытое хранилище контроля версий!

Внутренняя информация

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

Не все инструменты и библиотеки годятся

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

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

Изменение инфраструктуры

При вынесении разработки в мир открытого ПО, и делая сам процесс разработки открытым, меняется и инфраструктура. Уйдут привычные, удобные, мощные и настроенные «под себя» инструменты, появятся какие-то другие. Изучите площадку, на которой предполагается вести открытую разработку. Например, узнайте, если возможность навесить, например, pre-commitили start-commit hook на SVN. Это поможет вам проверять исходники до того, как они появились во внешнем мире и стали достоянием общественности.

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

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

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

Культурные изменения

Приготовьтесь к тому, что открытость разработки может потребовать культурных изменений. Каких-то вещей, которые не приняты при закрытой разработке. Например, общение на форуме и поддержка сообщества (community).

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

При этом, помните о внутренней информации. Что-то нельзя разглашать, кому-то нельзя ответить так как хочется (а ещё надо быть вежливым), где-то надо объяснять, используя терминологию, отличную от той, что принята внутри компании.

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

Если у вас в компании не принято оставлять имена авторов. Или даже принято избавляться от них, так как код принадлежит компании, то в мире открытого ПО вы не имеете права убирать имена авторов, особенно если этот код написан кем-то из сообщества (contribution).

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

Открытость тестирования

Сразу, с самого начала, надо задаться вопросом: будет ли тестирование открытым процессом или нет. Если да, то будут ли только публиковаться результаты или тесты и тестовая документация тоже будут доступны и выложены в открытый доступ.

Почему об этом стоит задуматься изначально? Потому, что после того как вы наладите процесс тестирования открытого ПО, проходящий внутри компании, при котором никакие артефакты не выдаются наружу, то потом, при необходимости, будет не так и просто выходить со всем этим тестовым барахлом в мир открытого тестирования. Окажется, что формат HTML отчётов работает правильно только в FireFox-e и не хочет отображаться в IE. Или что нельзя использовать какой-то инструмент потому, что он только для внутреннего использования, как мы обсуждали ранее. Или вам попросту будет стыдно.

Процедура построения продукта (build)

Проверяете ли вы в обычных условиях процедуру построения продукта? Или пользуетесь ей? Скорее всего — нет. При выпуске открытого ПО такую проверку придется делать. И на разных платформах и с разными опциями. Немаловажный момент, это всякие сопутствующие программы, библиотеки или данные, которые используется во время построения. Они тоже должны быть доступны пользователям вне вашей фирмы. Более того, все они, каким-то образом, должны быть описаны и должны легко настраиваться с помощью «локальных» или «пользовательских» файлов конфигурации процедуры построения.

Ещё интересно то, что пользователи должны получать те же самые запускаемые файлы, что и после «официальной» процедуры, выполняемой внутри вашей фирмы. Иначе говоря, все используемые библиотеки и шаги должны быть примерно одинаковыми. Не должно использоваться какое-либо уникальное оборудование.

Сайт

Для проектов, разработка которых происходит в открытую, появляется веб-сайт. Обычно это специальное место в хранилище исходного кода. Это требует тестирования самого веб-сайта и его контента. Чем сложнее и объёмнее этот сайт — тем больше тестировать.

Мы используем такие инструменты как linklint и HTML Tidy. Ну и конечно глаза и руки.

Минимизация затрат на тестирование

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

Таблица 2: Факторы влияющие на сложность тестирования

Если ваша цель всего лишь предоставить возможность свободного использования ПО, и вы не хотите тратить много сил на тестирование, то рассмотрите возможность закрытой разработки и тестирования и выпуск в свободное пользование только выполняемых файлов программы. Пусть это будет разработка по принципу «собора», а не «базара».

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

Обсудить в форуме