Роман Пучкин

Целью разработки и сопровождения прикладного программного обеспечения (ППО) является создание надежной информационной системы (ИС), удовлетворяющей требованиям конечного пользователя. Поэтому, каким бы ни был жизненный цикл разработки ППО, в соответствии с международным стандартом по управлению качеством ПО ISO 9000-3 в нем всегда будет присутствовать фаза тестирования.

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

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

Одни организации предпочитают работать по старинке и тестировать разрабатываемое ППО вручную без использования автоматизированных инструментов.

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

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

Данная статья написана с целью популяризировать в России проведение тестирования прикладного ПО сторонними организациями. К слову сказать, эта услуга широко развита на Западе, особенно в США, где насчитывается несколько десятков тестовых лабораторий.

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

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

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

Виды тестирования прикладного ПО

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

Схема работы PerformanceStudio

Тестирование сложных ИС следует тщательно планировать, чтобы уложиться в установленные сроки.

Основные виды тестирования информационных систем с графическим интерфейсом пользователя (ГИП):

- проверка ГИП;

- функциональное тестирование;

- проверка производительности;

- регрессионное тестирование.

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

Для проведения функционального тестирования необходимо формализовать критерии качества и эффективности функционирования ППО. Иными словами, создать эталон.

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

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

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

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

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

И, наконец, пару слов о регрессионном тестировании, т. е. повторном испытании системы. Регрессионное тестирование выполняется после внесения изменений, чтобы проверить корректность работы всей системы. При этом все протестированные ранее свойства и функции проверяются заново. обратите внимание на средство автоматизированного тестирования приложений Rational PerformanceStudio. С помощью данного средства, разработанного американской фирмой Rational Software Corporation, можно провести все виды функционального и нагрузочного тестирования как крупных, так и средних приложений.

Общая характеристика Rational PerformanceStudio

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

- как система будет работать в реальных условиях при разных конфигурациях аппаратной платформы?

- возможно ли предсказать время ее реакции на запросы конечного пользователя?

- как зафиксировать узкие места в производительности приложения при их возникновении?

Основные возможности Rational PerformanceStudio.

- Тестирование качества, производительности и стабильности клиент-серверных приложений и Web-приложений под большой рабочей нагрузкой.

- Генерация максимальной сетевой и серверной нагрузки с использованием минимальных ресурсов.

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

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

- Технология DataSmart Recording создает сценарии тестов и тестовые данные без программирования.

- Технология ServerSmart Playback проверяет правильность выполнения теста динамически изменяющейся Web-страницы.

- Технология LoadSmart Scheduling моделирует сложные пользовательские сценарии без программирования.

- Технология ClientSmart Pacing автоматически создает многопользовательскую нагрузку во время выполнения тестов.

В отличие от других автоматизированных средств тестирования производительности ППО в клиент-серверной архитектуре PerformanceStudio позволяет осуществлять запись скриптов тестов как через ГИП, API, так и “по проводам”, когда аппаратная и программная платформа клиента не играет никакой роли, так как запись происходит через сетевое оборудование. PerformanceStudio поддерживает как двухзвенную, так и трехзвенную архитектуру клиент-сервер.

Поддерживаемые платформы

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

После записей сценариев тестов формируются сценарии выполнения, причем на одной и той же тестовой станции можно одновременно выполнить и виртуальные, и ГИП-тесты. При создании сценариев выполнения имеется возможность вставки времен задержек и точек синхронизации сценариев тестов.

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

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

C автором можно связаться по E-mail: puchkin@argussoft.ru.