Для поиска эффективных способов тестирования сервис-ориентированной архитектуры необходимо затронуть фундаментальные вопросы тестирования SOA, а также оценить риски и стратегии
Отказ системы SOA на пятом терминале лондонского аэропорта Хитроу, строительство которого обошлось в 8,6 млрд. долл., только за одну неделю привел к убыткам в размере 1,6 млн. фунтов стерлингов (около 3,2 млн. долл.). В чем же заключалась ошибка? Просто по окончании испытаний разработчики забыли удалить фильтр, предназначенный для независимого тестирования системы управления багажом, в результате чего передаваемые сообщения не попадали в смежные и связанные системы.
Ошибка была чисто функциональной, мы даже не успели приступить к проверке порядка взаимодействия и не начали оценивать безопасность, рабочую нагрузку и производительность.
Итак, что же мы тестируем?
Позвольте привести в качестве примера опыт компании Stoic Financial Services, SFS. До недавнего времени сфера интересов SFS была ограничена кредитными картами, но после ряда приобретений она охватила весь сектор финансовых услуг. Теперь SFS занимается ипотекой, страхованием, инвестициями и пенсионным обслуживанием. После сделанных покупок SFS понадобились новые сведения о клиентах, потенциальных покупателях и счетах, а также финансовая информация, которую предстояло перенести в систему головной компании, сохранив при этом работоспособность всех старых средств.
Каждый из унаследованных компонентов предстояло «завернуть» в оболочку Web-служб, с тем чтобы обеспечить интеграцию всех систем без их переписывания. В случае необходимости внесения изменений в какую-либо из систем Web-служба регистрировала эти изменения и уведомляла о них корпоративную сервисную шину (Enterprise Service Bus, ESB). Шина ESB отвечала за распространение изменений в масштабах всей компании.
В результате, когда новый клиент покупал страховой продукт, скажем в городе Скенектади (штат Нью-Йорк), местный офис продаж получал соответствующее уведомление. Кроме того, уведомление о потенциальном клиенте получали и другие бизнес-подразделения, а финансовая система регистрировала транзакцию. Автоматически.
Но как протестировать эти функции?
Уровни транзакций и уровни тестирования
Регистрация нового клиента, о котором шла речь выше, представляет собой пример комплексной обработки — и это определяется архитектурой. Вместо одной здесь выполняется сразу несколько транзакций. В идеале все это должно отслеживаться с учетом определенных заранее требований, но учтите, что SFS планирует расширяться за счет приобретений. В приобретаемых компаниях установлены унаследованные системы, которые с высокой долей вероятности не будут поддерживать общие правила и современные программные технологии.
Наверное, в этих организациях найдутся люди, знающие, каким образом следует вносить изменения в рамках технического сопровождения. Им известны и принципы традиционного автономного тестирования каждой из систем. Но, помимо этого, нужно продумать порядок тестирования взаимодействия с другими компонентами, а наш общий тестовый план должен включать в себя соответствующие пункты.
Разработка проекта внедрения SOA предусматривает определение требований к порядку взаимодействия систем. При этом в каждом отдельно взятом случае прописывается сценарий взаимодействия.
Кроме того, имеет смысл провести тестирование на предельных объемах (volume testing), тестирование в стиле мыльной оперы, предполагающее искусственное создание многочисленных экстремальных жизненных ситуаций в сжатом временном интервале (soap opera testing), тестирование атрибутов (attribute testing), а также исследовательское тестирование (exploratory testing). Суть исследовательского тестирования вытекает из его названия и заключается в изучении продукта в процессе испытаний и выработке стратегии поведения на основе полученных результатов. Чтобы проделать это, необходимо проанализировать сообщения, отправляемые разным системам. Если таковых не обнаружено, нужно имитировать возникновение соответствующей ситуации вручную. Но как?
По существу речь идет о тестировании системы передачи сообщений. Необходимо убедиться в правильности сообщений для каждой транзакции. Если что-то не так, нужно определить, где находится причина: на стороне отправителя или получателя? Может оказаться, что выявить это достаточно сложно. При наличии центрального «концентратора», возможно, имеет смысл проверить журнал входящих и исходящих сообщений. Если ваша компания ограничивается интеграцией готового коммерческого ПО, вы можете протестировать его с помощью инструментов типа Empirix или TKO Lisa. Если же ваш технический персонал создает собственные Web-службы, необходимо разработать также инструментальные средства для отправки сообщений через сервисную шину и контроля за их прохождением. При наличии таких средств у вас появляется возможность регистрировать сообщения, проходящие через канал, и анализировать полученные результаты. Написав соответствующий драйвер, можно имитировать возникающие ситуации — то есть выйти на определенный уровень автоматизированного тестирования.
Если вы располагаете набором средств для проведения тестирования, добавление новой службы превращается в относительно простую задачу. Выполнив все старые тесты, зафиксируйте состояние, к которому вы пришли. Затем выполните новые тесты и оцените достигнутый прогресс. Подобные инструменты особенно полезны в процессе тестирования атрибутов, который мы сейчас и рассмотрим.
Тестирование атрибутов
Допустим, что программное обеспечение работает без ошибок, но насколько быстро оно обрабатывает каждый запрос? И какое быстродействие при этом считать достаточным? А что происходит в конце месяца, когда система обрабатывает счета в пакетном режиме? Если клиент оформляет какой-то заказ, сколько времени уйдет на то, чтобы соответствующая информация появилась на Web-сайте? Несколько минут? Несколько часов? Под атрибутами в данном случае мы понимаем показатели масштабируемости, безопасности и устойчивости — отсюда и термин «тестирование атрибутов».
Безопасность, резервирование ресурсов для создания запаса прочности, обработка отказов, производительность, рабочая нагрузка и объемы информации — все эти моменты следует учитывать при определении рисков, проведении консультаций по вопросам управления и принятии решения о включении соответствующих тестов в план испытаний.
Тестирование в стиле мыльной оперы
Если вы добрались до этого пункта, то, вероятно, уже поняли, что проведение полностью исчерпывающего тестирования — нереальная задача. Поэтому следует искать наилучший вариант из возможных в сложившихся условиях. Как справедливо замечено: «Единственным по-настоящему исчерпывающим тестированием можно считать то, при котором у испытателя не остается больше сил». Наша же цель заключается не в том, чтобы создать «совершенное ПО», а в проектировании программного обеспечения, которое годится для эксплуатации, то есть успешно прошло все заранее определенные испытания.
Для эффективного использования имеющегося в нашем распоряжении времени нам нужны наиболее мощные сценарии тестирования, тесты, в процессе выполнения которых одновременно проверяется множество различных показателей — мы называем это «тестированием в стиле мыльной оперы». Возьмем, к примеру, страховую систему. Допустим, первичная страховка оформляется на мужа с женой. Затем рождается ребенок, а две недели спустя жена уходит от мужа, оставляя при этом себя и ребенка в страховом полисе. Через много лет пропавший сын, который уже учится в институте, возвращается и жена (теперь уже бывшая) соглашается приобрести для него отдельную страховку. А за два дня до своего совершеннолетия (и истечения срока действия полиса)
с ним случается сердечный приступ. Тесты должны показать, выплачивается ли в этом случае страховка. И если да, то кому?
Описанная ситуация напоминает мыльную оперу, не правда ли? Тесты в стиле мыльной оперы проверяют одновременно сразу несколько бизнес-правил, что делает их очень мощными. Логика проста: если базовое тестирование и тестирование в стиле мыльной оперы пройдет успешно, скорее всего программа сможет успешно выполнять возложенные на нее функции.
Тестирование на реальных данных
По словам Джона Макконды, консультанта компании Moser Consulting, многие испытания не доводятся до конца, потому что их разработчики не учитывают необходимость описания заключительного сценария. Последний этап тестирования SOA — проверка «слаженности работы»: все компоненты должны четко взаимодействовать друг с другом в условиях реальной нагрузки. В этом качестве хорошо подойдет, например, цикл обработки ежемесячно выставляемых клиентам счетов. «На практике вам нужно обеспечить нормальную совместную работу существующих систем, — указал Макконда. — Но даже просмотрев все тестовые планы, в которых проверяется каждый отдельно взятый компонент, легко упустить из виду проверку работы системы в целом на реальных данных».
Простейший способ проведения комплексного тестирования на реальной информации заключается в создании копии имеющейся базы данных (возможно, с удалением уникальных идентификаторов типа номеров карточек социального страхования) и выполнении наиболее сложных операций, к которым относятся, например, пакетная обработка выставляемых счетов, полученных претензий и т.д.
Усвоенные уроки
SOA — нечто большее, чем просто технология; это целая философия проектирования. Еще одна основополагающая философия отвергает возможность большого взрыва, предлагая взамен поэтапное, эволюционное развитие. Другими словами, самый простой способ построения крупномасштабной SOA, объединяющей набор слабо связанных друг с другом компонентов, заключается в независимой разработке каждой из систем с последующей их интеграцией на заключительном этапе.
Начните свой проект с создания двух или трех компонентов, которые должны взаимодействовать друг с другом. Их необходимо интегрировать и развернуть в виде готовой системы, после чего можно начать добавлять новые элементы.
Во время тестирования не ограничивайтесь одним прогоном программы. Я вспоминаю один проект, где остатки на счетах сохранялись на основе первого прохождения каждой транзакции. Меня пригласили для диагностики ошибок. Естественно, поисковая процедура завершилась неудачей, ведь ее никто никогда не тестировал.
Общая ошибка при проектировании систем SOA заключается в формировании многократных запросов к Web-службе, что приводит к значительному снижению производительности. Мне, в частности, довелось работать с системой, формировавшей выставляемые клиентам счета. Она запрашивала список всех имеющихся учетных записей, после чего для каждой из них вызывала процедуру «Сформировать счет».
Такой подход приводил к многократному выполнению поисковой процедуры. Мы переписали код таким образом, что система стала вызывать процедуру «Сформировать счета», сохраняя после этого в памяти все полученные клиентом данные. В результате нам удалось резко снизить нагрузку и сократить время обработки запросов на 80%.
По словам Дэвида Кристиансена, специалиста в области управления проектами и тестирования, критически важным моментом для достижения общего успеха является определение ответственных за тестирование отдельных компонентов SOA. Особенно заметно это проявляется на этапе технического сопровождения. Если, к примеру, поставщик услуг внесет какие-то изменения в свою часть системы, вам придется повторно тестировать качество интеграции, а команда, которая занималась в свое время интеграцией, к этому моменту уже может прекратить свое существование.
Объединение компонентов
На то, чтобы протестировать все возможные входные и выходные данные в системе SOA, вам может просто не хватить времени. Сложность тестирования SOA заключается в необходимости правильного подбора тестов — тех из них, которые позволяют получить наибольший объем информации о ПО за ограниченный промежуток времени.
Для тестирования любой SOA нам необходимо протестировать все ее компоненты независимо друг от друга, а также воспроизвести все общие сценарии взаимодействия. Для разработки завершенной стратегии необходимо добавить сюда тестирование в стиле мыльной оперы, исследовательское тестирование и тестирование на больших объемах данных (желательно реальных). Для эффективного решения этой задачи необходимо протестировать как сценарии нормального функционирования системы, так и негативные и деструктивные сценарии, предусматривающие возникновение нештатных ситуаций.
Последовав советам, изложенным в данной статье, и критически оценивая происходящее, вы, наверное, не сможете разработать абсолютно совершенную систему, но при этом вполне реально создать достаточно хороший продукт, подходящий для эксплуатации. Известный специалист в области управления качеством Джозеф Джуран определяет качество как «пригодность к использованию». Именно этого вам и нужно добиться в конечном итоге.
Итак, вперед, приступайте к тестированию!
Matthew Heusser. Testing service-oriented architectures: A primer. CIO.com. 07/31/2008