ТЕСТИРОВАНИЕ ПО

Генеральный директор Джерри Рудисин стремится упростить создание программного кода

По мере все большего усложнения корпоративных приложений возрастает и потребность в инструментах для их тестирования и обеспечения качества программного кода. Калифорнийская компания Agitar Software (www.agitar. com) специализируется на автоматизации тестирования фрагментов кода, когда разработчики проверяют код по ходу его написания. Джерри Рудисин, генеральный директор и президент Agitar, рассказал старшему редактору еженедельника eWeek Дэррилу Тафту о том, какое значение имеет тестирование и как оно может способствовать повышению качества ПО и развитию бизнеса.

eWeek: Что такое тестирование фрагментов кода?

Джерри Рудисин: Это практика, в соответствии с которой разработчики тестируют каждый модуль создаваемого ими кода изолированно (отсюда термин "фрагмент"), по мере его написания, а затем распространяют вместе с набором тестов, которые определяют и проверяют правильное поведение отдельных модулей.

Джерри Рудисин

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

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

Тестирование фрагментов кода представляет собой старую идею, хотя ее популярность росла на протяжении последних пяти лет. Системы с открытым исходным кодом, такие как JUnit (для Java) и NUnit (для .Net), предоставили стандартные методы тестирования, стимулировав тем самым тестирование фрагментов. Это лучший способ повышения экономической эффективности разработки ПО и ускорения работы команд программистов.

Некоторые организации пытаются применять метод тестирования фрагментов. В результате небольшой процент программистов заражается этой идеей: они считают создание тестов для фрагментов кода совершенно естественной работой и пользуются всеми их преимуществами. Однако большинство разработчиков сохраняет отрицательное отношение к тестам. Они пробуют тестировать фрагменты, но полагая, что эта задача слишком сложна, затем отказываются от нее. Иметь в своем распоряжении тесты для фрагментов гораздо важнее, чем тестировать их. Таким образом, вопрос заключается в следующем: как тем, кто отрицательно относится к тестированию, получить тесты для фрагментов их кода и как предоставить сторонникам тестирования возможность проводить его более тщательно и с меньшими затратами ручного труда?

eWeek: Какие преимущества дает тестирование фрагментов по сравнению с другими видами тестирования?

Дж. Р.: Весь смысл тестирования фрагментов заключается в том, чтобы повышать качество кода, а не искать ошибки, и при этом гарантировать, что каждый модуль делает то, для чего предназначен. Оно снижает число ошибок, помогая выявлять дефекты на ранних стадиях разработки и быстро изолировать повинный в них модуль, а также легко и с минимальным риском вносить изменения в программный код независимо от того, идет ли речь о новых или унаследованных системах. Каждая ошибка, предотвращенная или исправленная на этапе разработки, означает, что сотрудникам, занимающимся обеспечением качества кода (quality assurance, QA. - Прим. ред.), не придется столкнуться с ошибкой при тестировании интерфейса GUI, функционирования, производительности и поведения системы в условиях пиковых нагрузок.

Многие сотрудники подразделений по обеспечению качества кода жалуются, что разработчики считают их лишним звеном. Если предоставлять им программы, которые успешно прошли тестирование фрагментов, это позволит службам QA сосредоточиться на тестировании интеграции и подлинных проблем системного уровня, поскольку им придется меньше времени тратить на поиск и изоляцию ошибок. Код, прошедший через тестирование фрагментов, предоставляет командам разработчиков возможность выпускать программные системы, работающие значительно быстрее. Тестирование фрагментов дает реальные преимущества как с точки зрения качества продукта, так и с точки зрения времени выхода на рынок.

eWeek: Чем Agitar отличается от конкурентов? Иначе говоря, что делает вашу компанию уникальной в своем роде?

Дж. Р.: AgitarOne, флагманский продукт компании Agitar, представляет собой всеобъемлющее серверное решение для тестирования фрагментов кода Java. Он построен на базе пакета Agitator - отмеченной наградами новаторской разработки, которая позволяет проводить уникальный динамический и статический анализ кода. Этот пакет обеспечивает прокладку в программе множества маршрутов, приводя к интересным выводам относительно того, что именно делает код в нормальных и исключительных условиях, в том числе о таких вещах, о которых разработчик даже не задумывался или которые он считал слишком трудоемкими. Разработчики могут использовать Agitator, чтобы проверить эти выводы в интерактивном режиме и передать их для возвратного тестирования либо опубликовать с помощью AgitarOne в виде стандартных тестов JUnit.

eWeek: Почему разработчику лучше использовать инструменты Agitar, а не JUnit, который является бесплатным продуктом?

Дж. Р.: Примерно 95% клиентов Agitar начинают с JUnit и продолжают пользоваться им даже после того, как стали применять AgitarOne. Это верно и в отношении самой компании Agitar. У нас имеется огромный набор подготовленных с помощью Agitator заключений и тестов JUnit. Мы проверяем свои программы 24 часа в сутки 7 дней в неделю, применяя непрерывную интеграцию и тестирование. Но если ваша организация использует JUnit, AgitarOne будет ценным дополнением.

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

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

Имеется слишком много кода на языке Java, который не проходил тестирование фрагментов, поскольку сделать это вручную слишком сложно. AgitarOne позволяет автоматизировать решение этой задачи, беря на себя выполнение рутинной работы и высвобождая время для интеллектуального труда.

eWeek: Какую дополнительную нагрузку создает технология Agitar для разработчиков? Я имею в виду затраты времени, ресурсов, дополнительные виды работ или усложнение процесса...

Дж. Р.: Хотя преимущества тестирования фрагментов совершенно очевидны, многие разработчики рассматривают его как изменение привычного порядка работы и сопротивляются этому. AgitarOne призван упростить, насколько это возможно, создание хорошего набора тестов для фрагментов кода и расширить либо развить тестовые процедуры, которые так или иначе проводят хорошие программисты.

Вы можете установить дополнительную программу AgitarOne Eclipse для создания тестов JUnit, выбрать проект на Java, нажатием кнопки переслать код Java на сервер AgitarOne и получить готовые тесты. Таким образом, буквально за несколько минут вы приступите к созданию хороших тестов с описанием поведения ПО. Можно просматривать их, чтобы изучить поведение своего кода, или зарегистрировать и обращаться к ним только тогда, когда они перестанут выполняться после изменения кода.

Конечно, при этом можно писать и тесты JUnit. Написав несколько простых вспомогательных методов, которые сообщат AgitarOne, как создавать необходимые вашему коду объекты, вы повысите скрупулезность тестов, созданных вручную. Другие клиентские программы AgitarOne поддерживают интерактивное поисковое тестирование [exploratory testing], проверку правил написания кода и подготовку с помощью "приборной панели" отчетов о степени тщательности и тенденциях проведенного тестирования.

eWeek: Помогает ли Agitar разработчикам создавать более безопасный код?

Дж. Р.: Множество проблем безопасности возникает из-за неожиданного или недокументированного поведения кода. А AgitarOne способен обнаруживать и показывать многие из этих неожиданных проблем типа "что, если...". Кроме того, AgitarOne требует соблюдения правил написания кода, что позволяет организациям легко выявлять и устранять опасные типы кода.

По словам Джерри Рудисина, тестирование фрагментов представляет собой способ повышения качества программного кода.

AgitarOne дополняет инструменты статического анализа, которые сканируют код на предмет обнаружения уже известных дыр в системе безопасности. Как и в области обеспечения качества кода, максимальная безопасность ПО лучше всего достигается при сочетании различных приемов защиты. Применительно к Java начинать следует с отбора отдельных фрагментов ПО в виде классов и методов, прошедших проверку на отсутствие пробелов в защите, которые могут быть использованы для нарушения безопасности.

eWeek: Как опыт вашей работы в компании Rational, ныне называемой IBM Rational, помог подготовиться к нынешней роли в Agitar?

Дж. Р.: Каждый, кто участвовал в создании Rational, может гордиться достижениями за 23 года ее истории в качестве самостоятельно компании. Я пришел в Rational, когда она была частной фирмой и закончила очередной год с доходом примерно в 28 млн. долл. А покинул, когда ее годовой доход составил 412 млн. долл. То есть за это время произошел колоссальный рост. Agitar пока не является столь же крупной компанией, но мы на это рассчитываем.

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

У вас появились замечания или предложения? Напишите нам по адресу: editorial@pcweek.ru.

Версия для печати