Учебник по тестированию. Guide to Software Test Design
 Скачать 2.51 Mb.
|
|
Литература Beizer, Boris (1990). Software Testing Techniques . Van Nostrand Reinhold. Binder, Robert V. (1999). Testing Object-Oriented Systems: Models, Patterns, and Tools . Addison-Wesley. 96 Глава 9. Тестирование вариантов использования "Генерал насекомых-хранителей, сидя на зависшей в воздухе гигантской тле, осмотрел поле боя, от которого несло смрадом разложения, и которое тихо резонировало гулом разорванных умирающих мутантов роя, складывающих свои лапки к небу, перед возвращением к своему создателю, со словами "Повелитель, ваши мухи погублены." Эндрю Винсент Введение До сих пор мы исследовали техники разработки тестовых сценариев для частей системы — входные переменные с их диапазонами и границами, бизнес-правила, представленные в виде таблиц решений, а также поведения системы, представленные с помощью диаграмм состояний и переходов. Теперь пришло время рассмотреть тестовые сценарии, которые используют системные функции с начала и до конца путем тестирования каждой из их индивидуальных операций. Определение выполняемых системой операций является жизненно важной частью процесса определения требований. В прошлом использовались различные подходы к документированию этих операций. Примеры включают блок-схемы, HIPO-диаграммы и текст. Сегодня самым популярным подходом является диаграмма вариантов использования. Как и таблицы решений и диаграммы состояний и переходов, диаграммы вариантов использования обычно создаются разработчиками для разработчиков. Но, как и другие техники, диаграммы вариантов использования содержат много полезной информации и для тестировщиков. Варианты использования были созданы Иваром Якобсоном и объяснены в его книге " Объектно-ориентированная разработка программ: подход, основанный на вариантах использования ". Якобсон определил " вариант использования" как сценарий, который описывает использование системы действующим лицом для достижения определенной цели. Под "действующим лицом" мы понимаем пользователя, играющего роль с уважением к системе, старающегося использовать систему для достижения чего-то важного внутри конкретного контекста. Действующими лицами в основном являются люди, хотя действующими лицами также могут выступать другие системы. "Сценарий" - это последовательность шагов, которые описывают взаимодействия между актером и системой. Заметьте, что варианты использования определены с точки зрения пользователя, а не системы. Заметьте также, что операции, выполняемые внутри системы, хоть и важны, но не являются частью определения вариантов использования. Набор вариантов использования составляет функциональные требования системы. В нотации UML варианты использования выглядят следующим образом: 97 Рисунок 9-1: Варианты использования для некоторого Государственного Университета Человечки представляют действующих лиц, эллипсы - варианты использования, а стрелки - какие действующие лица инициируют использование каких вариантов использования. Важно отметить, что несмотря на то, что варианты использования были созданы в контексте объектно-ориентированных систем, они также полезны при определении функциональных требований в других парадигмах разработки. Польза вариантов использования в том, что они: ● позволяют выявить функциональные требования системы с точки зрения пользователя несмотря на техническую перспективу и независимо от того, какая парадигма разработки использовалась. ● Могут быть использованы для активного вовлечения пользователей в процесс сбора требований и определений. ● Предоставляют базис для идентификации ключевых компонентов системы, структур, баз данных и связей. ● Служат основанием для разработки тест-кейсов системы на приемочном уровне. Методика К сожалению, уровень детализации, указанный в вариантах использования, недостаточен либо для разработчиков, либо для тестировщиков. Алистер Коберн в книге " Написание эффективных сценариев использования " предложил подробный шаблон для описания вариантов использования. Его лишь нужно адаптировать к своей работе. Компонент варианта использования Описание Номер или идентификатор варианта использования Уникальный идентификатор для этого варианта использования Название варианта В названии должна содержаться цель, сформулированная 98 использования в виде короткой фразы с глаголом в форме активного залога Цель ситуации Более подробное описание цели, если это необходимо Область Общий | Система | Подсистема Уровень Итог | Первичное задание | Подфункция Главное действующее лицо Название роли или описание этого главного действующего лица Предусловия Состояние системы, требуемое для выполнения варианта использования Условия успешного выполнения Состояние системы при успешном выполнении этого варианта использования Условия не успешного выполнения Состояние системы при не успешном выполнении этого варианта использования Операция Действие, которое инициирует выполнение варианта использования Главный успешный сценарий Шаг Действи е 1 2 Расширения Условия, при которых главный успешный сценарий будет меняться, а также описание этих изменений Вариации Вариации, которые не влияют на основной поток, но должны быть рассмотрены Приоритет Критичность Время отклика Время, доступное для выполнения этого варианта использования 99 Частота Как часто этот вариант использования выполняется Каналы для главного действующего лица Интерактивный | Файл | База данных | ... Дополнительные действующие лица Другие действующие лица, которые нуждаются в выполнении этого варианта использования Каналы для дополнительных действующих лиц Интерактивный | Файл | База данных | ... Дата завершения Информация о расписании Полнота уровня Вариант использования определен (0.1) | Главный сценарий определен (0,5) | Все расширения определены (0,8) | Все поля заполнены (1.0) Открытые вопросы Нерешенные вопросы, ожидающие решения Таблица 9-1: Шаблон варианта использования. Пример Рассмотрим следующий пример из Регистрационной системы Государственного университета. Студент хочет зарегистрироваться на курс, используя систему онлайн регистрации (СОР). Компонент варианта использования Описание Номер или идентификатор варианта использования SURS1138 Название варианта использования Регистрация на курс (учебные занятия на факультете) Цель ситуации Область Система Уровень Основная задача Главное действующее лицо Студент Предусловия Отсутствуют Условия успешного выполнения Студент зарегистрирован на курс - в список курсов 100 студента добавлен данный курс Условия не успешного выполнения Список курсов студента не изменился Операция Студент выбирает курс и нажимает кнопку "Регистрироваться" Главный успешный сценарий (A: Действующее лицо S: Система) Шаг Действие 1 A: Выберите "Регистрация на курс" 2 А: Выберите курс (например, Математика 1060) 3 S: Отобразится описание курса 4 А: Выберите секцию (пн-ср 9:00 утра) 5 S: Отобразятся дни и время секции 6 А: Подтвердите 7 S: Курс/секция добавятся к списку курсов студента Расширения Номе р Описание 2а Курс не существует S: Отобразится сообщение и работа будет закончена 4а Раздел не существует S: Отобразится сообщение и работа будет закончена 4b Раздел полон S: Отобразится сообщение и работа будет закончена 6a Студент не подтверждает 101 S: Отобразится сообщение и работа будет закончена Вариации Студент может использовать: ● интернет ● телефон Приоритет Критический Время отклика 10 секунд или меньше Частота Около 5 курсов х 10000 студентов за более чем 4-недельный период Каналы для главного действующего лица Интерактив Дополнительные действующие лица Отсутствует Каналы для дополнительных действующих лиц Не определены Дата завершения 1 февраля Полнота уровня 0.5 Открытые вопросы Отсутствуют Таблица 9-2: Пример варианта использования. Надеемся, каждый вариант использования был проверен перед тем, как был реализован. Основное правило для тестирования реализации - это создать как минимум один тест-кейс для основного успешного сценария, и как минимум по одному тест-кейсу для каждого ответвления. Так как в вариантах использования не указываются входные данные, тестировщик должен выбрать их сам. Обычно используются методики тестирования классов эквивалентностей и анализ граничных значений, описанные раньше. Полезным способом для документирования тестов является Domain Test Matrix (пример см. в главе "Тестирование областей определения"). Важно учитывать риск от выполнения операции и в зависимости от этого включать варианты ее тестирования. Менее рискованные операции заслуживают меньшего тестирования. Более рискованные операции должны получать дополнительное тестирование. Для них рассмотрим следующий подход. Для того, чтобы создать тест-кейсы, начните с обычных данных для наиболее часто используемых операций. Затем переместитесь к граничным значениям и некорректным данным. Затем выберите операции, которые, несмотря на нечастое использование, жизненно важны для успеха системы (например, "Выключить ядерный реактор"). Убедитесь, что у вас есть, по крайней мере, один тест-кейс для каждого 102 Расширения в варианте использования. Попробуйте операции с необычными параметрами. Нарушьте предусловия (если это может произойти в реальных условиях эксплуатации). Если операция содержит циклы, то проверьте не просто один или два цикла - будьте более изобретательными. Посмотрите на длинный, наиболее извилистый путь для выполнения операции и попробуйте его. Если операции должны быть выполнены в каком-то логическом порядке, попробуйте другой порядок. Вместо ввода данных сверху вниз, попробуйте ввести снизу вверх. Создайте "тупые" тест-кейсы. Если вы не пробуете делать странные вещи, то знайте, что ваши пользователи будут это делать. Всегда помните о необходимости оценки риска каждого варианта использования и расширения и создания в соответствии с этим необходимых тест-кейсов. Большинство путей, которые можно выполнить с помощью операций, создать легко. Они соответствуют корректным и некорректным вводимым данным. Более сложными являются пути, которые могут возникнуть из-за какого-то исключительного состояния - нехватки памяти, заполнения диска, потери подключения, отсутствия драйвера и т.д. Тестировщику может потребоваться очень много времени для того, чтобы создать или имитировать эти условия. К счастью, доступен инструмент Holodeck, созданный Джеймсом Уиттакером и его соратниками из Флоридского Технологического института, который помогает тестировщику имитировать эти проблемы. Holodeck контролирует взаимодействие между приложением и операционной системой. Он регистрирует каждый системный вызов и позволяет тестировщику имитировать неудачные системные вызовы. Таким образом, диск может "стать заполненным", сетевые соединения могут "стать отсоединенными", передача данных может "быть искажена", а также смоделирован ряд других проблем. Скачать Holodeck можно с сайта http://www.sisecure.com/holodeck/holodeck-trial.aspx Одним из основных компонентов тестирования операций являются тестовые данные. Борис Бейзер предполагает, что от 30 до 40 процентов усилий в тестировании операций является созданием, получением и извлечением тестовых данных. Не забудьте включить ресурсы (время и людей) для этой работы в бюджет вашего проекта. Можно выделить отдельную группу тестирования, которую можно назвать "царь данных", единственной обязанностью которой будет является предоставление тестовых данных. Применение и ограничения Обычно тестирование операций является краеугольным камнем системы и приемо-сдаточных испытаний. Они должны использоваться каждый раз, когда операции системы были четко определены. Если системные операции пока не определены, то занимайтесь пока полировкой своего резюме или CV. При создании как минимум одного теста для основного успешного сценария и, по крайней мере, по одному для каждого расширения, которые обеспечивают некоторый уровень тестового покрытия, ясно, что, независимо от того, сколько мы стараемся, большинство входных комбинаций останутся непроверенными. В этот момент не будьте самоуверенными насчет качества системы. Резюме 103 ● Вариант использования - это сценарий, который описывает использование системы действующим лицом для достижения определенной цели. "Действующим лицом" является пользователь, играющий свою роль с уважением к системе, который стремится использовать систему для достижения чего-то важного внутри конкретного контекста. Сценарий представляет собой последовательность шагов, которые описывают взаимодействия между действующим лицом и системой. ● Основным компонентом тестирования операций являются тестовые данные. Борис Бейзер предполагает, что от 30 до 40 процентов усилий в тестировании операций являются генерация, получение и извлечение тестовых данных. Не забудьте включить ресурсы (время и людей) для этой работы в бюджет вашего проекта. ● При создании как минимум одного теста для основного успешного сценария и, по крайней мере, по одному для каждого расширения, которые обеспечивают некоторый уровень тестового покрытия, ясно, что, независимо от того, сколько мы стараемся, большинство входных комбинаций останутся непроверенными. В этот момент не будьте самоуверенными насчет качества системы. Практика 1. Используя вариант использования "регистрация на курс" для Регистрационной системы Государственного университета, описанный ранее, создайте такой набор тестов, в котором основной успешный сценарий и каждое из расширений будут проверены как минимум один раз. Выберите «интересные» тестовые данные, используя техники разбиения на классы эквивалентностей и поиск граничных значений. Литература Beizer, Boris (1990). Software Testing Techniques (Second Edition). Van Nostrand Reinhold. Beizer, Boris (1995). Black-Box Testing: Techniques for Functional Testing of Software and Systems . John Wiley & Sons. Cockburn, Alistair (2000). Writing Effective Use Cases . Addison-Wesley. Fowler, Martin and Kendall Scott (1999). UML Distilled: A Brief Guide to the Standard Object Modeling Language (2 nd Edition) . Addison-Wesley. Jacobsen, Ivar, et al. (1992). Object-Oriented Systems Engineering: A Use Case Driven Approach Addison-Wesley. 104 Секция II. Методы тестирования белого ящика Определение Тестирование белого ящика - это стратегия, основанная на внутренних путях, структуре и реализации тестируемого программного обеспечения. В отличии дополняющего его тестирования черного ящика, тестирование белого ящика обычно требует хороших навыков программирования. Основной процесс тестирования белого ящика заключается в следующем: ● Анализируется реализация программы. ● В программе определяются возможные маршруты. ● Выбираются такие входные данные, чтобы программа выполнила выбранные пути. Это называется сенсибилизацией путей . Заранее определяются ожидаемые результаты для входных данных. ● Тесты выполняются. ● Фактические результаты сравниваются с ожидаемыми результатами. ● Принимается решение о надлежащем или ненадлежащем функционировании программы. Применимость Тестирование белого ящика применимо на всех уровнях разработки системы - модульном, интеграционном и системном. В основном, тестирование белого ящика приравнивается к модульному тестированию, которое выполняется разработчиками. Несмотря на то, что это утверждение неоспоримо, тем не менее это узкий взгляд на тестирование белого ящика. Тестирование белого ящика - это больше, чем тестирование кода: это тестирование путей. Обычно тестируемые пути находятся внутри модуля (модульное тестирование). Но мы можем применить эту же методику для тестирования путей между модулями внутри подсистем, между подсистемами внутри систем, и даже между целыми системами. Недостатки В тестировании белого ящика можно выделить четыре недостатка: 105 ● Во-первых , количество выполняемых путей может быть настолько большим, что не удастся проверить их все. Как правило, попытка протестировать все пути выполнения с помощью тестирования белого ящика так же невозможна, как и тестирование всех комбинаций всех входных данных при тестировании черного ящика. ● Во-вторых , выбранные тест-кейсы могут не содержать данные, которые будут чувствительны к ошибкам. Например: p=q/r; может выполняться корректно, за исключением случая, когда r=0. y=2*x // подразумевалось y=x 2 - тест не выявит ошибок в случаях, когда x=0, y=0 и x=2, y=4 ● В-третьих , тестирование белого ящика предполагает, что поток управления правильный (или близок к правильному). Поскольку эти тесты основаны на существующих путях, с помощью нельзя обнаружить несуществующие пути. ● В-четвертых , тестировщик должен обладать навыками программирования для того, чтобы понять и оценить тестируемое программное обеспечение. К сожалению, многие сегодняшние тестировщики не имеют такой базы. Преимущества Применяя тестирование белого ящика, тестировщик может быть уверен, что будет определен и проверен каждый путь в тестируемой программе. 106 Глава 10. Тестирование потока управления "Это было первобытным источником допотопной страсти, из которой возникает моя история, как круглая земля, разглаженная на карте, как линейная проекция иносказательной и чрезвычайно плодовитой, не плоской, не нравоучительной, самопереворачивающей конструкции, чей мракобесный геотропизм лиминальности за разумным сомнением." Мелинда Банерджи |