9.6 Заключение

Эта глава представляет метод извлечения функциональных тестовых сценариев (test cases) из сценариев использования (use cases). Несколько преимуществ этого подхода:

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

• Уход от дублирования тестовых сценариев.

• Достигается больший охват тестового пространства.

• Легкость мониторинга тестового процесса.

• Легкость распределения работы между тестерами.

• Легкость регрессионного тестирования.

• Раннее обнаружение пропущенных требований.

Созданные Вами тестовые сценарии могут быть использованы для ручного тестирования, также как и для автоматического тестирования с использованием таких инструментов, как IMB Rational Robot или IBM Rational Functional Tester.

Этот подход применяется к функциональным требованиям. Следующая глава описывает, как тестировать нефункциональные требования.

Ссылки

[HEU01a] Heumann, Jim. From Use Cases to Test Cases: Ensuring Quality from the Beginning,

RUC, 2001.

[HEU01b] Heumann, Jim. “Using Use Cases to Create Test Cases.” The Rational Edge, June

2001.

Глава 10

Создание

Тестовых Сценариев (Test Cases)

из Дополнительных Требований

В предыдущей главе был представлен метод, который может применяться к любому сценарию использования (use case) для получения тестовых сценариев (test cases). Данная глава рассматривает получение тестовых сценариев из дополнительных требований (см. Рисунок 10.1). Однако что касается дополнительных требований, то для них не существует единого подхода, т.к. эти требования различны по своей природе и их тестирование требует довольно разных методик. Эта глава представляет следующие методы создания тестовых сценариев:

• Выполнение выбранных тестовых сценариев в различных программных средах.

• Добавление дополнительной проверки во все сценарии использования.

• Проверка и обновление определенных сценариев использования.

• Выполнение задач.

• Список проверок.

• Анализ.

• Тестирование по принципу «Стеклянного Ящика».

• Автоматическое тестирование.

Эта глава также охватывает использование IBM Rational Robot и IBM Rational Test Manager для автоматического тестирования. Один из самых последних инструментов IBM, заменивший предыдущие версии Test Manager, называется ClearQuest Test Manager. Эти инструменты могут также использоваться для функционального тестирования, а не только для тестирования производительности, описанного в данной главе.

Рисунок 10.1. Извлечение тестовых сценариев (test cases) из дополнительных требований.

10.1 Выполнение Выбранных Тестовых Сценариев в Различных Программных Средах

Некоторые требования указывают, что приложение должно работать в различных средах:

Веб-приложение должно запускаться под браузерами: Internet Explorer (версии 6.0 и выше) и Netscape (версии 6.0 и выше).

Наилучший подход к работе с таким типом требований - это выбрать некоторый большой тестовый сценарий (в нашем случае, им может быть один из тестовых сценариев относительно основного потока сценария использования Бронирование рейса) и выполнить его в различных программных средах. Это означает, что один тестовый сценарий будет полностью пройден с использованием сначала браузера Internet Explorer, а затем Netscape.

Достаточно часто требование относится к операционным системам, на которых должно работать приложение:

Система должна запускаться на операционных системах: Windows XP, Windows и Vista Solaris 10.

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

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

Система должна отображать данные согласно формату, хранимому в настройках веб-браузера.

В этом случае тестирование включает следующие шаги:

1. Проверить настройки веб-браузера.

2. Запустить полный тестовый скрипт на этих настройках.

3. Изменить настройки веб-браузера (например, на Французский формат отображения даты).

4. Запустить полный тестовый скрипт на новых настройках.

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

Рисунок 10.2. Выбранный сценарий тестируется в различных программных средах.

10.2 Добавление Дополнительной Проверки во Все Сценарии Использования

Многие требования описывают появление или поведение некоторых элементов управления пользовательского интерфейса. Несколько примеров:

На каждой странице кнопка Next (Далее) должна определять основной сценарий работы приложения.

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

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

Поля ввода на одной странице должны быть выровнены вертикально.

При открытии диалогового окна акцент должен быть на первом поле ввода.

Для каждого неверного ввода пользователем система должна отображать соответствующее сообщение об ошибке объясняющее, какого формата должно быть вводимые данные.

Денежные расчеты должны выполняться и храниться с точностью до двух десятых.

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

На страницах, где приводятся данные пользователя, должна быть ссылка на страницу с политикой конфиденциальности.

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

Рисунок 10.3. Дополнительные проверки, добавленные во все тестовые сценарии.

Каждый раз при появлении нового диалогового окна или экранной формы нам нужно вводить список проверок в тестовый сценарий.

Некоторым требованиям нужна проверка только однажды для страницы, а другие требуют тестирование всех элементов управления определенного типа. Несколько примеров:

• Одна проверка для страницы:

  • Присутствует ли кнопка Next (Далее), представляющая основной сценарий работы приложения?

  • Существуют ли страницы с многочисленными полями на них? Выровнены ли эти поля по вертикали?

  • Доступен ли справочник из меню?

• Проверка определенных элементов управления:

  • Есть ли у всех обязательных полей звездочка?

  • Доступен ли всплывающий календарь для каждого поля ввода даты?

  • Все поля ввода валюты принимаются и отображаются в формате до двух десятых?

10.3 Проверка и Обновление Определенных Сценариев Использования

Даже некоторые из требований, описанные в Supplementary Specification (Дополнительной Спецификации), связаны с некоторыми определенными сценариями использования. Так может случиться, если эта часть функциональности не относится к главному сценарию использования, но играет административную роль или роль сопровождения. Как пример рассмотрим требования относительно защиты и доступ с защитой паролем к некоторым частям приложения:

Должен быть предоставлен пароль для доступа к экранным формам администратора.

Для предоставления своих услуг представители гостиниц, агенты по найму автомобилей и представители авиалиний должны войти в систему, используя свои ID (идентификаторы) и пароли.

Пользователи должны выбирать свой ID и предоставлять пароль при покупке билета.

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

Рисунок 10.4. Некоторые дополнительные требования влияют на сценарии использования, а также на все сценарии (алгоритмы) и тестовые сценарии, извлеченные из них.

10.4 Выполнение Задач

Довольно часто нам нужно выполнить действие, описанное в требовании. Во многих случаях задача не требует создания формальных сценариев (алгоритмов) и тестовых сценариев.

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

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

Иногда требования относятся к среднему времени, требуемому на выполнение задач:

Представитель Службы Услуг должен иметь возможность обучиться пользованию системой за час.

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

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

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

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

Среднее время восстановления должно быть менее часа.

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

Вполне нормально выполнять только однажды тесты, требующие много времени, пока мы не обнаружим некоторые проблемы:

Время развертывания на новой версии WebSphere Application Server должно занимать не более чем один день.

Если тестовая установка системы на новой версии WAS занимала 15 часов, то нет необходимости проверять это еще раз. Но если первый тест занял 40 часов, мы должны проанализировать причину и пройти тест заново после устранения проблемы.

Другой пример требования, которое может быть проверено простым выполнением задачи:

Пользовательский интерфейс не должен содержать компонентов, препятствующих автоматическому тестированию с использованием IBM Rational Functional Tester.

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

Функциональность бронирования билета на самолет должна быть доступна с домашней страницы.

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

10.5 Список Проверок

Некоторые требования не нуждаются в сложном тестировании, так что Вы можете просто проверить, реализованы ли они. Например:

В качестве базы данных должен быть использован Oracle.

Был ли использован Oracle или нет – просто пометьте в списке проверок.

Некоторые другие примеры такого рода тестирования могут включать следующее:

Все системные ошибки должны быть записаны и быть доступными для администратора.

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

Система должна быть основана на архитектуре J2EE.

Если архитектура требует сервер приложения, должен быть использован IMB WebSphere.

Руководство Администратора должно быть доступно в формате PDF.

Для основной функциональности должны присутствовать отдельные закладки.

10.6 Анализ

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

Для использования системы пользователи не должны обладать специальными техническими навыками (кроме умения пользоваться браузером).

Система должна быть доступной 24 часа 7 дней в неделю.

В процессе анализа последнего требования, мы можем задать следующие вопросы:

• Существует ли что-то, препятствующее приложению работать постоянно?

• Существует ли управление расписанием работы, которое может сделать приложение недоступным на некоторый период времени?

Многие функциональные особенности такого типа требуют анализа архитектуры. Имеет смысл включить архитектора системы в этот анализ:

Не должна требоваться установка на клиентском рабочем месте. Все системные обновления и новые релизы должны осуществляться на сервере.

Система должна автоматически бронировать билет с Airline Reservation System без необходимости вмешательства человека.

Смена базы данных системы в будущем не должно требовать перезаписи логики приложения.

Некоторый архитектурный анализ может поддерживаться простой демонстрацией:

Главная функциональность системы (бронирование рейса, покупка билета на самолет, бронирование номера в гостинице, бронирование автомобиля) должна быть отражены в компонентах, которые могут быть использованы в приложении клиент/сервер (не через Интернет).

Может быть создано очень простое тестовое клиентское приложение, которое доказывает, что компоненты могут использоваться в других приложениях

10.7 Тестирование по Принципу «Стеклянного Ящика»

Часть тестирования должно быть выполнено со знанием кода приложения или других составных частей приложения. Это называется тестированием по принципу «Стеклянного Ящика» или структурным тестированием.

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

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

Довольно часто тестирование требует проверки правильности применения определенных алгоритмов:

Список рейсов, возвращаемый системой после поиска, должен содержать рейсы, вычисленные с помощью алгоритма Dijkstra’s Shortest Path

10.8 Автоматическое Тестирование

Автоматическое тестирование очень полезно при проверке производительности и надежности требований, таких как следующие:

Среднее время ответа системы должно быть менее двух секунд.

Система должна обрабатывать 1000 процедур бронирования билетов в минуту.

Система должна обслуживать 5000 пользователей одновременно.

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

Система может быть недоступна не более чем одну минуту за 24 часа

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

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

Для анализа последствий одновременного доступа определенного количества пользователей тот же самый скрипт должен быть выполнен на разном количестве пользователей, например – на 1, 10, 1000 и 1000. Фактические значения могут изменяться в зависимости от приложения и требуемого максимального количества пользователей.

Для тестирования среднего времени между состояниями неработоспособности мы должны запустить систему на долгое время – по крайней мене на 48 часов.

Некоторые вопросы, на которые могут быть получены ответы при использовании автоматического тестирования:

• Каково время ответа при нормальных условиях?

• Как много пользователей может поддерживать система, перед тем как становится недоступной?

• Как система ведет себя при максимальном количестве пользователей?

• Если количество пользователей больше чем максимально допустимое, у системы снижается производительность, или она становится неработоспособной?

• Как производительность и надежность системы зависят от ресурсов системы (доступной памяти, дискового пространства)?

• Как производительность системы зависит от времени дня (вечер по сравнению с утром, выходные по сравнению с буднями)?

Автоматическое тестирование также полезно для функционального регрессионного тестирования. В этом случае стоит создать скрипты для многих сценариев.

Основные инструменты для тестирования представляет IBM: Rational Robot, Rational Test Manager, Rational ClearQuest Test Manager, Rational Functional Tester и Rational Performance Tester. В качестве примера, следующий пункт показывает, как создавать и выполнять скрипты, используя Rational Robot и Rational Test Manager.

10.9 Использование Robot и Test Manager для Автоматического Тестирования

IBM Rational Robot [IBM03a] может использоваться для разработки двух типов скриптов:

• Скрипты пользовательского интерфейса для функционального тестирования (GUI scripts).

• Виртуальные сессии пользователей для тестирования производительности (Virtual session – VU).

IBM Rational Test Manager [IBM03b] – это инфраструктура для планирования, проектирования, реализации, выполнения, а также оценки тестирования. Мы можем создать пакет (suite), выполняющий скрипты для многих виртуальных пользователей. Недавно был выпущен новый инструмент – IBM Rational ClearQuest Test Manager.

Обычный подход к выполнению тестирования заключается в записи скриптов с помощью Robot, а затем использовании Test Manager (ClearQuest Test Manager) для планирования и перезапуска этих скриптов.

Запись скрипта VU (Виртуальных Сессий)

Запись скриптов VU (виртуальных сессий) с помощью Rational Robot осуществляется довольно просто. Выполните следующие действия:

1. Запустите Rational Robot, выбрав All Programs>Rational Software>Rational Robot (Все Программы>Rational Software>Rational Robot).

2. Введите имя пользователя и пароль, как показано на Рисунке 10.5. Пароль для администратора был установлен при настройке проекта Rational (см. Главу 4 «Настройка Проекта», Рисунок 4.12).

3. Выберите проект из списка.

4. Нажмите ОК.

5. Нажмите на круг, помеченный как VU, как показано на Рисунке 10.6.

Рисунок 10.5. Диалоговое окно Rational Test Login.

Рисунок 10.6. Начальное окно Rational Robot.

6. Назовите сессию, как показано на Рисунке 10.7. Вы можете использовать название сценария использования (use case), сценария (алгоритма, scenario) или тестового сценария (test case).

Рисунок 10.7. Выбор названия для сессии.

7. Выберите путь к IE в поле Executable (Выполнимый), все остальные поля оставьте пустыми (см. Рисунок 10.8). Как правило, путь должен быть следующим: C:\Program Files\Internet Explorer\IEXPLORE.EXE

Рисунок 10.8. Выбор приложения. В случае Интернет-приложений выбирается запускаемый браузер.

8. Начните запись всех шагов тестового сценария (test case). Появится панель инструментов Session Record (Запись Сессии). Она содержит четыре иконки, как показано на Рисунке 10.9:

   • Stop recording (Остановить запись).

   • Open Robot window (Открыть окно Robot).

   • Split session into scripts (Разделить сессию на скрипты).

   • Open Session Insert toolbar (Открыть панель инструментов Session Insert - Вставка Сессии).

Рисунок 10.9. Панель инструментов Session Record (Запись Сессии).

Нажав на иконку «Открыть панель инструментов Session Insert (Вставка Сессии)», Вы откроете панель инструментов, показанную на Рисунке 10.10. Она содержит следующие иконки:

Run (Запуск) Start timer (Запустить таймер)	Synchronization point (Точка синхронизации)
Stop timer (Остановить таймер)	Start block (Начать блокировку)
Comment (Комментарии)	Stop block (Остановить блокировку)

Рисунок 10.10. Панель инструментов Session Insert (Вставка Сессии).

9. Если Вы хотите выяснить время, за которое выполняется определенная операция, запустите таймер, нажав на светло-зеленую иконку (вторая справа) на панели инструментов Session Insert (Вставка Сессии). Назовите таймер, как показано на Рисунке 10.11. Остановите таймер, нажав красную иконку (третья справа), когда операция будет завершена. Когда Вы останавливаете таймер, Вам нужно выбрать таймер из списка, как показано на Рисунке 10.12, т.к. одновременно может быть запущено много таймеров.

Рисунок 10.11. Определение названия таймера.

Рисунок 10.12. Выбор таймера, который необходимо остановить.

10. Когда Вы закончите с записью скрипта, нажмите темно-синий квадрат на панели инструментов Session Record - Запись Сессии (первая иконка слева на Рисунке 10.9).

11. Назовите скрипт, как показано на Рисунке 10.13. Вполне нормально, если Вы введете то же название, которое использовали в сессии на шаге 6.

Рисунок 10.13. Выбор названия для только что записанного скрипта.

12. Нажмите ОК в диалоговом окне Stop Recording (Остановить Запись). Появится окно с кодом языка VU, как показано на Рисунке 10.14.

Как Запустить Пакет в Rational Test Manager

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

• Сессия, записанная с использование Robot.

• Скрипт, импортированный из Quality Architect.

• Написанный с помощью Java или Visual Basic, следуя требуемым условиям.

• Написанный в любом языке для скриптов (в этом случае должен быть написан адаптер).

Рисунок 10.14. Код записанного скрипта.

Эта глава использует сессию, записанную в Robot. Для создания и запуска тестового пакета, выполните следующие действия:

1. Запустите Test Manager, выбрав All Programs>Rational Software>Rational Test Manager (Все Программы>Rational Software>Rational Test Manager), как показано на Рисунке 10.15.

Рисунок 10.15. Главное окно Test Manager.

2. Если появляется диалоговое окно входа в систему, введите Вашу информацию в поля User Name (Имя Пользователя) и Password (Пароль).

3. Из главного окна Test Manager, выберите File>Open Suite (Файл>Открыть Пакет).

4. В диалоговом окне New Suite (Новый Пакет) выберите Performance Testing Wizard (Мастер Тестирования Производительности), как показано на Рисунке 10.16, и нажмите ОК.

Рисунок 10.16. Диалоговое окно New Suite (Новый Пакет).

5. Выберите Local computer, как показано на Рисунке 10.17.

Рисунок 10.17. Performance Testing Wizard - Computers (Мастер Тестирования Производительности - Компьютеры).

6. Нажмите кнопку Add to List (Добавить к списку).

7. Нажмите кнопку Next (Далее).

8. Выберите скрипты. Вы видите диалоговое окно, показанное на Рисунке 10.18.

9. Нажмите кнопку Add to List (Добавить к списку).

10. Нажмите кнопку Finish (Закончить).

11. Правой кнопкой мышки нажмите на VU User Group 1, как показано на Рисунке 10.19, и выберите Run Properties (Запустить Свойства).

Рисунок 10.18. Выбор тестовых скриптов.

Рисунок 10.19. Дерево представления тестового пакета.

12. В диалоговом окне Run Properties of User Group (Запустить Свойства), как показано на Рисунке 10.20, установите максимальное количество пользователей. Другими словами, установите количество одновременных виртуальных пользователей, которое Вы хотите имитировать. Нажмите ОК.

13. Правой кнопкой мышки нажмите на иконке, представляющей скрипт (на Рисунке 10.19. она называется Бронирование рейса - Book a flight) и выберите Run Properties (Запустить Свойства).

Рисунок 10.20. Диалоговое окно Run Properties of User Group, где устанавливается максимальное количество пользователей.

14. В диалоговом окне Run Properties of Test Script, показанном на Рисунке 10.21, установите количество итераций – как много раз Вы хотите повторить скрипт для одного и того же пользователя. Нажмите ОК.

15. Сохраните пакет, выбрав File>Save As (Файл>Сохранить как), как показано на Рисунке 10.22.

16. Запустите пакет, выбрав File>Run Suite (Файл>Запустить Пакет).

Рисунок 10.21. Диалоговое окно Run Properties of Test Script (установление количества итераций).

Рисунок 10.22. Сохранение пакета.

17. Вы можете настроить количество пользователей для текущего запуска, как показано на Рисунке 10.23.

Рисунок 10.23. Диалоговое окно Run Suite (Запустить Пакет) - установка параметров для текущего запуска.

Анализ Результатов

Когда закончится тестирование, на экране показывается результат (см. Рисунок 10.24) со статусом выполненных команд. На этом экране Вы видите красные и зеленые колонки. Зеленые означают успешное прохождение теста, красные – неудачное.

Рисунок 10.24. Отчет со статусом команд, выполненных в ходе успешного запуска тестирования.

Чтобы увидеть результаты производительности, нажмите на кнопку Perf наверху экрана. Рисунок 10.25. показывает пример результатов одной итерации для одного пользователя, а Рисунок 10.26. показывает результаты пяти итераций другого тестового скрипта. Колонки содержат следующую информацию:

• Номер команды.

• Идентификатор команды

• Число выполнений команды.

• Среднее время по всем пользователям (в секундах).

• Стандартное отклонение (средняя разница времени по отношению к среднему времени).

• Минимальное время.

• Пять колонок с процентами: 50, 70, 80, 90 и 95.

• Максимальное время.

Рисунок 10.25. Результаты производительности (одна итерация).

Вторая колонка - Идентификатор команды. Она генерируется путем взятия первых семи символов из названия скрипта и добавления к ним тильды (~) и трехзначного последовательного номера. Вот почему идентификаторы команды для скрипта Бронирование рейса (Book a flight) называются «Book a~001», «Book a~002» и т.д.

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

Показанный на Рисунке 10.25. результат взят с одной итерации для одного пользователя, так что все времена равны (среднее, максимальное и минимальное). В процессе работы, результаты которой показаны на Рисунке 10.26, каждая команда была выполнена пять раз, поэтому мы видим разницу между максимальным и минимальным временем. Эти таблицы содержат время от всех ответов системы. Эта информация бесполезна, т.к. мы не знаем, каким операциям они соответствуют. Более полезно время, полученное для каждой операции между началом и окончанием таймера, т.к. у нас была возможность присвоить им названия., отражающие смысл

Рисунок 10.26. Результаты производительности (пять итераций).

Мы можем скопировать информацию из таблицы результатов производительности, вставить ее в Microsoft Excel и убрать ненужные строки.

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

Таблица 10.1. Сценарии, Выбранные для Тестирования Сценария Использования Бронирование Рейса.

Операция	Номер	Среднее	Отклонение	Мин	50	70	80	90	95	Макс
Поиск рейсов	5	5.88	0.69	5.11	5.92	6.09	6.31	6.66	6.84	7.02
Поиск рейсов вылета	5	3.06	0.28	2.72	2.91	3.26	3.36	3.4	3.42	3.44
Поиск рейсов прибытия	5	3.61	1.97	1.92	2.16	4.68	5.57	6.1	6.37	6.63
Выбор мест	5	3.45	0.38	2.74	3.69	3.7	3.71	3.72	3.73	3.74
Покупка билета	5	4.57	0.55	4.05	4.23	5.03	5.23	5.25	5.25	5.26