Home

Спонсор: Compuware

Перевод: RedRoxx Technologies

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

Гарантия производительности и масштабируемости сложных распределенных приложений, работающих на платформах Microsoft или Java, — непростая задача, встающая перед участниками процесса разработки. Сложность этой задачи усугубляется еще и тем, что тe, кто находят проблемы производительности, в редких случаях могут разобраться, чем они обусловлены, и наоборот, те, кто способны исследовать подобные проблемы, редко является теми, кто их ищет.

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

Публикация компании SEADMEX

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

Панкратов Вячеслав, при активном участии консультанта проекта Дмитрия Шевченко.

Содержание: 

• Схема + определение ролей
• Действующие лица
• Создание виртуальных пользователей (V-Users)
• Создание сценариев

Автор: Дмитрий Демченко

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

Автор: Владимир Дудченко

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

Oracle JDE Enterprise One

Автор: Дмитрий Демченко

В этой статье я продолжу описание инструментов тестирования ERP системы JD Edwards OneWorld. К моменту, когда я заканчивал писать статью, ERP систему успели переименовать несколько раз. Сейчас ее название Oracle JDE Enterprise One (Oracle JDE E1). В дальнейшем для краткости я буду называть ее ERP JD.

В этой статье речь пойдет о следующих инструментах:

• D. Edwards Virtual Script Editor — инструмент создания скриптов для «виртуальных» пользователей (для нагрузочного, стресс и тестирования производительности);
• J. D. Edwards VSMEditor —инструмент создания одного «виртуального» скрипта из нескольких.
• J. D. Edwards Virtual Runner — инструмент запуска скриптов, созданных в Virtual Script Editor(для нагрузочного, стресс- и тестирования производительности).

Автор: Алексей Мишуловин

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

Публикация компании IT-Online, автор Дмитрий Сатин

Оригинальная публикация

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

Автор: Сергей Мартыненко

Термин «нагрузочное тестирование» обычно используют в значении «тестирование производительности». А что же тогда есть собственно нагрузочное тестирование?

RUP:

Load testing is a performance test which subjects the target-of-test to varying workloads to measure and evaluate the performance behaviors and ability of the target-of-test to continue to function properly under these different workloads. The goal of load testing is to determine and ensure that the system functions properly beyond the expected maximum workload. Additionally, load testing evaluates the performance characteristics (response times, transaction rates, and other time sensitive issues).

Вольный перевод.

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