КритиЧно длЯ бизнеса
Многие из нас склонны оптимистично воспринимать новые технологии. Мы с восторженными криками бросились от мэйнфреймов к клиент-серверной архитектуре, думая, что этот прекрасный новый мир будет безукоризненным. Но это оказалось не так. Ладно, теперь мы снова с воплями восторга бежим к Web, полагая, что существенно упростится разработка приложений. И здесь все не так просто. Разработка в Web также полна опасностей, как и на мэйнфреймах или в клиент-серверной среде.
Чтобы разработать действительно замечательное приложение для Web или приложение, позволяющее работать в Web, необходимо по-прежнему выполнять грязную работу - проводить тестирование. Web-приложения во многом имеют те же проблемы, что и их клиент-серверные двойники, включая проблемы с производительностью, временем отклика, стабильностью и масштабируемостью. Недостаточная производительность или нехватка знаний о том, как использовать приложение, способны загубить его.
Это возвращает нас назад к вечной проблеме - тестированию. Надеюсь, что к настоящему моменту все вы используете средства автоматического тестирования. Они пригодились вам в клиент-серверной среде, и точно так же они позарез нужны вам в новом клиент-серверном мире Web.
Полноценная автоматическая проверка качества ПО должна охватывать восемь областей: нахождение ошибок, изменение производительности, полнота тестирования, управление тестированием, фиксация дефектов, тестирование графического интерфейса пользователя, тестирование при больших нагрузках и удаленный доступ к данным.
Многие компании играют в различных углах этой “песочницы тестирования”. Проверьте, все ли основные моменты охватывают ваши инструменты или наборы инструментов. Очень важно, чтобы средства, применяемые вами, могли использоваться с мощными промышленными приложениями, будь они чисто клиент-серверными или клиент-серверными для Web. При выборе инструментальных средств убедитесь, что они способны выполнять следующее (в дополнение к восьми аспектам тестирования, упомянутым выше):
- поддерживать любое сочетание клиентов, начиная с программ просмотра, Windows, Motif и заканчивая OS/2, с сочетанием сетей или модемов любого быстродействия. Кроме того, они должны поддерживать любую комбинацию серверов и взаимодействовать с любой комбинацией популярных протоколов;
- транслировать трафик, соответствующий HTTP (транспортному протоколу передачи гипертекста), в язык сценариев на английском языке. Это заметно упростит тестирование клиентов Web, обеспечит переход всех “горячих” связей к верным URL (универсальным указателям ресурсов) и корректный вызов Java-приложений или Netscape;
- выполнять тестирование с множеством виртуальных пользователей. Необходимо выяснить, какое “узкое место” возникает при возрастании числа параллельных пользователей иногда до тысяч (для приложений для внутренних сетей), а то и до миллионов (для Internet-приложений). Для тестирования с виртуальными пользователями требуется только одна ведущая машина (ПК или рабочая станция). Мало кто из нас имеет ресурсы, чтобы создать собственную многомашинную лабораторию для тестирования или скоординировать миллион параллельных участников тестирования;
- отслеживать действия пользователя. Необходимо фиксировать, какие страницы Web посещают пользователи, как долго они взаимодействуют с узлом, как часто они пользуются им и где они находятся, когда покидают узел, и все с очень низкими (5% или менее) накладными расходами;
- определять, какое максимальное число пользователей одновременно может поддерживать наш узел.
Продукты Pure Software (http://www.pure.com) наиболее соответствуют перечисленным критериям тестирования клиент-серверных Web-приложений. Испытайте их. И помните: если вы планируете иметь приложения для важных задач, поддерживающие работу в Web, подумайте над развитием способа тестирования, который вы используете в настоящее время, ничего не оставляйте без тестовых испытаний. Будьте оптимистичны, но реалистичны.
Кристина Комафорд
Разрабатываете ли вы ПО для мэйнфреймов или для Web, проблемы остаются теми же
