юзабилити тестирование. Юзабилититестирование программного обеспечения
 Скачать 3.74 Mb.
|
|
Объект тестирования: указать Вид тестирования Краткое определение вида тестирования Тестовые проверки Functional Testing Safety Testing Security Testing Compatibility Testing GUI Testing Usability Testing Accessibility Testing Internationalization Testing Performance Testing Stress Testing Negative Testing Black Box Testing Automated Testing Unit/Component Testing Integration Testing Содержание отчета: 1. Цель работы. 2. Разработанные проверки выбранного объекта реального мира для различ- ных видов тестирования. 3. Тестовые активности для сформулированных задач. 4. Выводы по работе. Контрольные вопросы: 1. Что такое тестирование? 2. Что такое качество программного обеспечения? 3. Что такое дефект? 4. Назовите три условия обнаружения дефекта. 5. Какие существуют виды тестирования в зависимости от объекта тестиро- вания? Дайте характеристику каждому. 6. Какие существуют виды функционального тестирования? Дайте характе- ристику каждому. 7. Какие существуют виды нефункционального тестирования? Дайте харак- теристику каждому. 8. Какие существуют виды тестирования в зависимости от глубины покры- тия? Дайте характеристику каждому. 14 9. Какие существуют тестовые активности? Дайте характеристику каждому. 10. Какие существуют виды тестирования в зависимости от знания кода? Дайте характеристику каждому. 11. Какие существуют виды тестирования в зависимости от степени автома- тизации? Дайте характеристику каждому. 12. Какие существуют виды тестирования в зависимости от изолированности компонентов? Дайте характеристику каждому. 13. Какие существуют виды тестирования в зависимости от подготовленно- сти? Дайте характеристику каждому. 14. Какие существуют виды тестирования в зависимости от места и времени проведения? Дайте характеристику каждому. 15. Какие этапы составляют процесс тестирования? 16. Какая композиция тестов выполняется для первой поставки программного продукта? 17. Какая композиция тестов выполняется для последующих поставок про- граммного продукта? 15 Лабораторная работа №2 Разработка требований Цель: выявить и описать пользовательские требования в виде вариантов ис- пользования (Use Cases). План занятия: 1. Изучить теоретические сведения. 2. Выполнить практическое задание по лабораторной работе. 3. Оформить отчет и ответить на контрольные вопросы. Теоретические сведения Требование (Requirement) – описание того, какие функции и с соблюдением каких условий должен выполнять программный продукт в процессе решения по- лезной для пользователя задачи. Требования позволяют понять, что и с соблюдением каких условий система должна делать; предоставляют возможность оценить масштаб изменений и управ- лять изменениями; являются основой для формирования плана проекта (в том числе плана тестирования); помогают предотвращать или разрешать конфликтные ситуации; упрощают расстановку приоритетов в наборе задач; позволяют объек- тивно оценить степень прогресса в разработке проекта. Работа над требованиями включает следующие этапы: выявление требований; анализ требований (моделирование бизнес-процессов, прототипирование интер- фейсов, приоритизация требований, результат этапа – визуализация требований); документирование требований (результат этапа – спецификация); тестирование (валидация) требований. Работу с требованиями на этапах выявления, анализа, до- кументирования, как правило, выполняет бизнес-аналитик. Тестирование требова- ний выполняет тестировщик. В иерархии требований существует три уровня: уровень бизнес-требований, уровень пользовательских требований, уровень продуктных требований (функци- ональные и нефункциональные требования). Бизнес-требования выражают цель, ради которой разрабатывается продукт (зачем он нужен, какая от него ожидается польза). Пользовательские требования описывают задачи, которые пользователь мо- жет выполнять с помощью разрабатываемой системы, и по своей сути представ- ляют собой недетализированные функциональные требования. Поскольку здесь уже появляется описание поведения системы, требования этого уровня могут быть 16 использованы для оценки объема работ, стоимости проекта, времени разработки. Пользовательские требования оформляются в виде вариантов использования (Use Cases), пользовательских историй (User Stories), пользовательских сценариев (User Scenarios). Функциональные требования описывают поведение системы, т. е. ее действия (вычисления, преобразования, проверки, обработку и т. д.). Нефункциональные требования описывают свойства системы (удобство использования, безопасность, надежность, расширяемость и т. д.), которыми она должна обладать при реализа- ции своего поведения. Выявление и описание требований: Use Case Вариант использования (Use Case) продукта описывает последовательность взаимодействия системы и внешнего действующего лица. Действующим лицом может быть человек, другая система ПО или аппаратное устройство, взаимодей- ствующее с системой для достижения некой цели. Варианты использования меняют традиционный подход к сбору информации: пользователей не спрашивают, что, с их точки зрения, должна делать система, а выясняют, какие задачи собирается с ее помощью решать пользователь. Цель та- кого подхода – описать все подобные задачи. До включения каждого варианта ис- пользования в утвержденную версию требований заинтересованные в проекте ли- ца проверяют, не выходит ли он за границы проекта. Теоретически в конечный набор вариантов использования должна входить вся желаемая функциональность системы. Описание варианта использования включает следующие категории: уникальный идентификатор; имя, кратко описывающее задачи пользователя в формате «глагол + объ- ект», например «разместить заказ»; краткое текстовое описание на естественном языке; список предварительных условий, которые должны быть удовлетворены до начала разработки варианта использования; выходные условия, описывающие состояние системы после успешного завершения разработки варианта использования; пронумерованный список действий, иллюстрирующий последователь- ность этапов взаимодействия лица и системы от предварительных условий до вы- ходных условий. Пример варианта использования приведен в таблице 2.1. 17 Таблица 2.1 – Пример варианта использования Категории варианта использования Описание 1 2 Идентификатор и название UC-1 Запросить химикат Основное действующее лицо Сотрудник, разместивший заказ на химикат Описание Сотрудник, разместивший заказ на химикат, указывает в запросе необходимый химикат, вводя его название или идентификатор или импортируя его структуру из со- ответствующего графического средства. Система выполняет запрос, предлагая контейнер с химикатом со склада или позволяя создать запрос на заказ у поставщика Триггер Сотрудник указывает, что хочет заказать химикат Предварительные условия PRE-1. Личность пользователя аутентифицирована. PRE-2. Пользователь имеет право запрашивать химикаты. PRE-3. База данных по запасам химикатов доступна Выходные условия POST-1. Запрос сохраняется в Chemical Tracking System. POST-2. Запрос отправлен на склад химикатов или поставщику Нормальное направление развития варианта использования 1.0 Запросить химикат со склада 1.0.1 Сотрудник указывает требуемый химикат. 1.0.2 Система перечисляет контейнеры с необходимым химиктом, имеющиеся на складе. 1.0.3 Сотрудник может просмотреть историю любого контейнера. 1.0.4 Сотрудник выбирает определенный контейнер или просит отправить запрос поставщику (см. п. 1.1). 1.0.5 Сотрудник вводит остальную информацию, чтобы завершить запрос. 1.0.6 Система сохраняет запрос и отправляет его на склад химика- тов 18 Продолжение таблицы 2.1 1 2 Альтернативное направление развития варианта использования 1.1 Запросить химикат у поставщика 1.1.1 Сотрудник ищет химикат по каталогам поставщика (см. п. 1.2). 1.1.2 Система отображает список поставщиков, где также указаны размеры, класс и цена контейнеров. 1.1.3 Сотрудник выбирает поставщика, размер, класс и количество контейнеров. 1.1.4 Сотрудник вводит остальную информацию, необходимую для запроса. 1.1.5 Система сохраняет запрос и перенаправляет его поставщику Исключения 1.2 Химиката нет в продаже 1.2.1 Система отображает сообщение «У поставщиков нет такого химиката». 1.2.2 Система предлагает сотруднику запросить другой химикат или выйти из программы. 1.2.3.1 Сотрудник просит запросить другой химикат (см. п. 1.2.3.2). 1.2.4.1 Система заново начинает нормальное направление варианта использования. 1.2.3.2 Сотрудник решает выйти из системы. 1.2.4.2 Система завершает вариант использования Бизнес-правила BR-28, BR-31 Существует несколько сценариев варианта использования (см. таблицу 2.1). Один сценарий считается нормальным направлением развития (normal course) варианта использования, его также называют основным направлением, главным успешным сценарием и благоприятным путем. Нормальное направление для вари- анта использования «Запрос химиката» – запрос химиката, который есть на складе. Другие допустимые сценарии из варианта использования называются альтер- нативными направлениями (alternative courses) или вторичными сценариями (sec- ondary scenarios). Они также могут привести к успешному выполнению задания и удовлетворяют выходным условиям варианта использования. Однако они пред- ставляют вариации решения задачи или диалоговой последовательности, необхо- димой для выполнения задачи. В определенной точке принятия решений в диало- говой последовательности нормальное направление может перейти в альтернатив- ное, а затем вернуться обратно в нормальное. Условия, препятствующие успешному завершению задания, называются ис- ключениями (exceptions). Если в процессе сбора информации не указано, как об- рабатывать исключение, то возможны два пути: 19 1) разработчики предложат лучший по их мнению способ обработки исклю- чений; 2) при генерации пользователем неверного условия произойдет сбой системы, т. к. никто не предусмотрел такой ситуации. Иногда исключения рассматриваются как тип альтернативного направления, однако эти понятия следует разделять. Не обязательно реализовывать каждое аль- тернативное направление, которое определяют для варианта использования; кроме того, можно отложить его реализацию до следующего выпуска. Однако необхо- димо реализовать исключения, из-за которых завершение сценариев может ока- заться неуспешным. Расширение (extend) и включение (include) При составлении вариантов использования часто можно столкнуться с ситуа- цией, когда альтернативное направление варианта использования само по себе можно выделить в автономный вариант использования. В таком случае можно расширить (extention) нормальное направление, включив этот отдельный вариант использования в нормальный поток. Пример. Вариант использования «Запросить химикат» может включать в себя поиск по каталогу поставщика. Но при этом запросить химикат можно и без поис- ка по каталогам, а поиск по каталогу может выполняться как отдельная бизнес- задача пользователей. Поэтому логично расширить вариант использования «За- просить химикат» отдельным вариантом использования «Поиск по каталогам по- ставщика». Иногда же несколько вариантов использования имеют общие наборы этапов. Чтобы избежать повторения этих этапов в каждом варианте использования, можно определить отдельный вариант использования и указать, что он включен (include) в другие варианты использования как подвариант. Пример. Если покупатель совершает покупку товара, то он обязательно дол- жен его оплатить. При этом процесс оплаты сам по себе достаточно сложный, включающий различные шаги и альтернативные варианты (оплата различными способами). Поэтому логично его выделить в отдельный вариант использования, при этом включить в вариант использования «Покупка товара». Определение вариантов использования Определить варианты использования можно несколькими способами: сначала определить действующие лица, а затем бизнес-процессы, в кото- рых каждое лицо участвует; выразить бизнес-процессы в терминах определенных сценариев, обоб- щить сценарии в варианты использования и определить действующие лица для каждого варианта; определить внешние события, на которые система должна реа- 20 гировать, а затем соотнести эти события с участвующими лицами и определенны- ми вариантами использования; определить вероятные варианты использования на основе функциональ- ных требований; если какие-либо требования невозможно проследить до какого- либо варианта использования, необходимо задуматься, нужны ли они. Как правило, пользователи сначала определяют самые важные варианты ис- пользования, поэтому порядок предлагаемых тем позволит получить представле- ние о приоритетах. Преимущества применения вариантов использования состоят в том, что каждый вариант сосредоточен на поставленной задаче и пользователе. Тщательное изучение этапов взаимодействия лица и системы помогает еще на ранних стадиях разработки выявить неясности и неточности, а также позволяет составить вариан- ты тестирования на основе вариантов использования. Способ с применением ва- риантов использования позволяет выявить функциональные требования, с помо- щью которых пользователи будут выполнять конкретные задачи. Кроме прочего, варианты использования облегчают расстановку приоритетов требований. Выс- шим приоритетом обладают те функциональные требования, которые созданы на основе вариантов использования с высшим приоритетом. Высший приоритет назначается по следующим причинам: варианты использования описывают один из основных бизнес-процессов, активизируемых системой; многие пользователи часто обращаются к ним; их запросил привилегированный класс пользователей; они предоставляют возможности, необходимые для соответствия требова- ниям; функции других систем зависят от их наличия. Существуют также и преимущества технического характера. С помощью ва- рианта использования можно выявить некоторые важные объекты предметной об- ласти и их взаимоотношения. Разработчики, использующие объектно- ориентированные методы проектирования, могут преобразовать варианты исполь- зования в объектные модели, такие как диаграммы классов и диаграммы последо- вательностей. Практическое задание: 1. Получить у преподавателя задание, содержащее идею и бизнес-цели под- лежащего разработке программного продукта. 2. Определить действующие лица и сформулировать наиболее вероятные ва- рианты использования подлежащего разработке программного продукта. 21 3. Полностью описать три варианта использования подлежащего разработке программного продукта. 4. Для каждого варианта использования указать уникальный идентификатор; имя в формате «глагол + объект»; краткое текстовое описание; предварительные условия; выходные условия; пронумерованный список действий нормального направления развития. 5. Для каждого варианта использования при необходимости указать прону- мерованный список действий альтернативного направления (направлений) разви- тия. 6. Для каждого варианта использования при необходимости указать исключе- ния. 7. Оформить отчет и защитить лабораторную работу. Содержание отчета: 1. Цель работы. 2. Описание вариантов использования подлежащего разработке программно- го продукта. 3. Выводы по работе. Контрольные вопросы: 1. Что такое требование? 2. Какое значение имеют требования в проекте по разработке программного обеспечения? 3. Какие существуют этапы работы над требованиями? 4. Кто выполняет работу с требованиями? 5. Какие существуют уровни требований? 6. Что такое вариант использования? 7. Для чего нужен вариант использования? 8. Какие элементы входят в состав описания варианта использования? 9. Что такое основной сценарий варианта использования? 10. Что такое альтернативный сценарий варианта использования? 11. Что описывают в исключениях варианта использования? 12. В чем отличие альтернативного сценария от исключения в описании вари- анта использования? 22 Лабораторная работа №3 Тестирование требований Цель: изучить критерии качества требований, выполнить тестирование требо- ваний к программному обеспечению. План занятия: 1. Изучить теоретические сведения. 2. Выполнить практическое задание по лабораторной работе. 3. Оформить отчет и ответить на контрольные вопросы. Теоретические сведения Качество программного обеспечения во многом зависит от качества сформи- рованных требований, т. к. требования к программному продукту являются базой для разработки и последующего тестирования. Тестирование требований выполняется на предмет их соответствия критери- ям качества требований (рисунок 3.1). Рисунок 3.1 – Критерии качества требований 23 Завершенность (completeness). Требование является полным и законченным с точки зрения представления в нем всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно». Типичные проблемы с завершенностью: 1. Отсутствуют нефункциональные составляющие требования или ссылки на соответствующие нефункциональные требования (например: «пароли долж- ны храниться в зашифрованном виде», а каков алгоритм шифрования?). 2. Указана лишь часть некоторого перечисления (например: «экспорт осуществляется в форматы PDF, PNG и т. д.», а что следует понимать под «и т. д.»?). 3. Приведенные ссылки неоднозначны (например: «см. выше» вместо «см. раздел 123.45.b»). Атомарность, единичность (atomicity). Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершенности и оно описывает одну и только одну ситуацию. Типичные проблемы с атомарностью: 1. В одном требовании фактически содержится несколько независимых (например: «кнопка “Restart” не должна отображаться при остановленном серви- се, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя» – здесь в одном предложении описаны совершенно разные эле- менты интерфейса в совершенно разных контекстах). 2. Требование допускает разночтение в силу грамматических особенно- стей языка (например: «если пользователь подтверждает заказ и редактирует за- каз или откладывает заказ, должен выдаваться запрос на оплату» – здесь описаны три разных случая и это требование стоит разбить на три отдельных требования во избежание путаницы). Такое нарушение атомарности часто влечет за собой воз- никновение противоречивости. 3. В одном требовании объединено описание нескольких независимых ситуа- ций (например: «когда пользователь входит в систему, должно отображаться при- ветствие; когда пользователь вошел в систему, должно отображаться имя пользователя; когда пользователь выходит из системы, должно отображаться прощание» – все эти три ситуации «заслуживают» того, чтобы быть описанными отдельными и более детальными требованиями). Непротиворечивость, последовательность (consistency). Требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам. Типичные проблемы с непротиворечивостью: 1. Противоречия внутри одного требования (например: «после успешного входа в систему пользователя, не имеющего права входить в систему…» – а как пользователь вошел в систему, если не имел такого права?). 24 2. Противоречия между двумя и более требованиями, между таблицей и тек- стом, рисунком и текстом, требованием и прототипом и т. д. (например: «712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” всегда должна быть синей» – так все же красной или синей?). 3. Использование неверной терминологии или использование разных терми- нов для обозначения одного и того же объекта или явления (например: «в случае, если разрешение окна составляет менее 800x600…» – разрешение есть у экрана, у окна есть размер). Недвусмысленность (unambiguousness, clearness). Требование описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок и допускает только однозначное объективное понимание. Требование атомарно в плане невозможности различной трактовки сочетания отдельных фраз. Типичные проблемы с недвусмысленностью: 1. Использование терминов или фраз, допускающих субъективное толкование (например: «приложение должно поддерживать передачу больших объемов дан- ных» – насколько «больших»?). Вот лишь небольшой перечень слов и выражений, которые можно считать верными признаками двусмысленности: адекватно, быть способным, легко, обеспечивать, как минимум, быть способным, эффективно, своевременно, применимо, если возможно, будет определено позже, по мере необходимости, если это целесообразно, но не ограничиваясь, быть способно, иметь возможность, нормально, минимизировать, максимизировать, оптимизи- ровать, быстро, удобно, просто, часто, обычно, большой, гибкий, устойчивый, по последнему слову техники, улучшенный, результативно. 2. Использование неочевидных или двусмысленных аббревиатур без расшиф- ровки (например: «доступ к ФС осуществляется посредством системы про- зрачного шифрования» и «ФС предоставляет возможность фиксировать сообще- ния в их текущем состоянии с хранением истории всех изменений» – ФС здесь обозначает файловую систему или какой-нибудь «Фиксатор Сообщений»?). 3. Формулировка требований из соображений, что нечто должно быть всем очевидно (например: «Система конвертирует входной файл из формата PDF в вы- ходной файл формата PNG» и при этом автор считает совершенно очевидным, что имена файлов система получает из командной строки, а многостраничный PDF конвертируется в несколько PNG-файлов, к именам которых добавляется «page-1», «page-2» и т. д.). Эта проблема перекликается с нарушением корректности. Выполнимость (feasibility). Требование технологически выполнимо и может быть реализовано в рамках бюджета и сроков разработки проекта. Типичные проблемы с выполнимостью: 1. «Озолочение» (gold plating) – требования, которые крайне долго и/или дорого реализуются и при этом практически бесполезны для конечных пользова- телей (например: «настройка параметров для подключения к базе данных долж- 25 на поддерживать распознавание символов из жестов, полученных с устройств трехмерного ввода»). 2. Технически нереализуемые на современном уровне развития техноло- гий требования (например: «анализ договоров должен выполняться с применени- ем искусственного интеллекта, который будет выносить однозначное корректное заключение о степени выгоды от заключения договора»). 3. В принципе нереализуемые требования (например: «система поиска долж- на заранее предусматривать все возможные варианты поисковых запросов и кэ- шировать их результаты»). Обязательность, нужность (obligation) и актуальность (up-to-date). Если требование не является обязательным к реализации, оно должно быть просто ис- ключено из набора требований. Если требование нужное, но «не очень важное», для указания этого факта используется указание приоритета. Также исключены (или переработаны) должны быть требования, утратившие актуальность. Типичные проблемы с обязательностью и актуальностью: 1. Требование было добавлено «на всякий случай», хотя реальной потребно- сти в нем не было и нет. 2. Требованию выставлены неверные значения приоритета по критериям важности и/или срочности. 3. Требование устарело, но не было переработано или удалено. Прослеживаемость (traceability). Прослеживаемость бывает вертикальной и горизонтальной. Вертикальная позволяет соотносить между собой требования на различных уровнях требований, горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, архитектурными решениями и т. д. Для обеспечения прослеживаемости часто используются специальные ин- струменты по управлению требованиями и/или матрицы прослеживаемости. Типичные проблемы с прослеживаемостью: 1. Требования не пронумерованы, не структурированы, не имеют оглавления, не имеют работающих перекрестных ссылок. 2. При разработке требований не были использованы инструменты и техники управления требованиями. 3. Набор требований неполный, носит обрывочный характер с явными «про- белами». Модифицируемость (modifiability). Это свойство характеризует простоту внесения изменений в отдельные требования и в набор требований. Можно гово- рить о наличии модифицируемости в том случае, если при доработке требований искомую информацию легко найти, а ее изменение не приводит к нарушению иных описанных в этом перечне свойств. Типичные проблемы с модифицируемостью: 26 1. Требования неатомарны (см. «атомарность») и непрослеживаемы, а потому их изменение с высокой вероятностью порождает противоречивость. 2. Требования изначально противоречивы. В такой ситуации внесение изме- нений (не связанных с устранением противоречивости) только усугубляет ситу- ацию, увеличивая противоречивость и снижая прослеживаемость. 3. Требования представлены в неудобной для обработки форме (например, не использованы инструменты управления требованиями и в итоге команде прихо- дится работать с десятками огромных текстовых документов). Проранжированность по важности, стабильности, срочности (ranked for importance, stability, priority). Важность характеризует зависимость успеха проек- та от успеха реализации требования. Стабильность характеризует вероятность то- го, что в обозримом будущем в требование не будет внесено никаких изменений. Срочность определяет распределение во времени усилий проектной команды по реализации того или иного требования. Типичные проблемы с проранжированностью состоят в ее отсутствии или не- верной реализации и приводят к следующим последствиям. Проблемы с проранжированностью по важности повышают риск неверного распределения усилий проектной команды, направления усилий на второсте- пенные задачи и конечного провала проекта из-за неспособности продукта выполнять ключевые задачи с соблюдением ключевых условий. Проблемы с проранжированностью по стабильности повышают риск выпол- нения бессмысленной работы по совершенствованию, реализации и тестированию требований, которые в самое ближайшее время могут претерпеть кардинальные изменения (вплоть до полной утраты актуальности). Проблемы с проранжированностью по срочности повышают риск нарушения желаемой заказчиком последовательности реализации функциональности и ввода этой функциональности в эксплуатацию. Корректность (correctness) и проверяемость (verifiability). Фактически эти свойства вытекают из соблюдения всех вышеперечисленных (или можно сказать, что они не выполняются, если нарушено хотя бы одно из вышеперечисленных). В дополнение можно отметить, что проверяемость подразумевает возможность со- здания объективного тест-кейса (тест-кейсов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию. К типичным проблемам с корректностью также можно отнести: опечатки (особенно опасны опечатки в аббревиатурах, превращающие одну осмысленную аббревиатуру в другую также осмысленную, но не имеющую отно- шения к некоему контексту; такие опечатки крайне сложно заметить); наличие неаргументированных требований к дизайну и архитектуре; плохое оформление текста и сопутствующей графической информации; 27 грамматические, пунктуационные и иные ошибки в тексте; неверный уровень детализации (например, слишком глубокая детализация требования на уровне бизнес-требований или недостаточная детализация на уровне требований к продукту); требования к пользователю, а не к приложению (например: «пользователь должен быть в состоянии отправить сообщение» – мы не можем влиять на состоя- ние пользователя). Техники тестирования требований 1. Одной из наиболее активно используемых техник анализа требований яв- ляется просмотр или рецензирование. Данная техника может быть реализована в форме: беглого просмотра (показ автором своей работы коллеге; самый быстрый, самый дешевый и наиболее широко используемый вид просмотра); технического просмотра (выполняется группой специалистов, каждый из которых представляет свою область знаний: просматриваемый продукт не может считаться достаточно качественным, пока хотя бы у одного просматривающего остаются замечания); формальной инспекции (структурированный, систематизированный и до- кументируемый подход к анализу документации, для выполнения которого при- влекается большое количество специалистов, само выполнение занимает доста- точно много времени, и потому этот вариант просмотра используется достаточно редко, как правило, при получении на сопровождение и доработку проекта, созда- нием которого ранее занималась другая компания). 2. Следующей техникой тестирования и повышения качества требований яв- ляется (повторное) использование такой техники выявления требований, как фор- мулировка вопросов. Если хоть что-то в требованиях вызывает непонимание или подозрение, задавайте вопросы. 3. Хорошее требование является проверяемым, а значит, должны суще- ствовать объективные способы определения того, верно ли реализовано требова- ние. Продумывание чек-листов или даже полноценных тест-кейсов в процессе анализа требований позволяет определить, насколько требование проверяемо. По- мимо использования для тестирования требований, в дальнейшем такие чек-листы и тест-кейсы могут составить основу тестовой документации. 4. Рисунки, схемы. Чтобы увидеть общую картину требований целиком, очень удобно использовать рисунки, схемы, диаграммы, интеллект-карты и т. д. Графическое представление удобно одновременно своей наглядностью и кратко- стью (например, UML-схема базы данных, занимающая один экран, может быть описана несколькими десятками страниц текста). 5. Исследование поведения и прототипирование. Можно сказать, что прото- типирование часто является следствием создания графического представления и 28 анализа поведения системы. С использованием специальных инструментов можно очень быстро сделать наброски пользовательских интерфейсов, оценить применимость тех или иных решений и даже создать не просто «прототип ради прототипа», а заготовку для дальнейшей разработки, если окажется, что реализо- ванное в прототипе (возможно, с небольшими доработками) устраивает заказчика. Практическое задание: 1. Получить у преподавателя спецификацию с требованиями к программному продукту. 2. Протестировать спецификацию методом просмотра на предмет соответ- ствия критериям качества требований. 3. Для обнаруженных дефектов указать, какой критерий качества нарушен, и аргументировать свою точку зрения. 4. Для обнаруженных дефектов сформулировать уточняющие вопросы к за- казчику для выработки качественных требований. 5. Оформить отчет и защитить лабораторную работу. Содержание отчета: 1. Цель работы. 2. Отчет по тестированию спецификации. 3. Выводы по работе. Контрольные вопросы: 1. Какие выделяют критерии качества требований? 2. Какие требования являются завершенными? 3. Перечислите основные проблемы, связанные с завершенностью требова- ний. 4. Какие требования являются атомарными? 5. Перечислите основные проблемы, связанные с атомарностью требований. 6. Какие требования являются непротиворечивыми? 7. Перечислите основные проблемы, связанные с непротиворечивостью тре- бований. 8. Какие требования являются недвусмысленными? 9. Перечислите основные проблемы, связанные с недвусмысленностью тре- бований. 10. Какие требования являются выполнимыми? 11. Перечислите основные проблемы, связанные с выполнимостью требова- ний. 12. Какие требования являются обязательными, нужными и актуальными? 29 13. Перечислите основные проблемы, связанные с обязательностью и акту- альностью требований. 14. Какие требования являются прослеживаемыми? 15. Перечислите основные проблемы, связанные с прослеживаемостью тре- бований. 16. Какие требования являются модифицируемыми? 17. Перечислите основные проблемы, связанные с модифицируемостью тре- бований. 18. Какие требования считаются проранжированными по важности? 19. Какие требования считаются проранжированными по стабильности? 20. Какие требования считаются проранжированными по срочности? 21. Перечислите основные проблемы, связанные с проранжированностью требований по важности. 22. Перечислите основные проблемы, связанные с проранжированностью требований по стабильности. 23. Перечислите основные проблемы, связанные с проранжированностью требований по срочности. 24. Какие требования являются корректными? 25. Перечислите основные проблемы, связанные с корректностью требова- ний. 26. Какие существуют техники тестирования требований? В чем особенности каждой из них? |