Юзабилититестирование программного
 Скачать 0.61 Mb.
|
Лабораторная работа №3 Тестирование требованийЦель: изучить критерии качества требований, выполнить тестирование требо- ваний к программному обеспечению. Планзанятия: Изучить теоретические сведения. Выполнить практическое задание по лабораторной работе. Оформить отчет и ответить на контрольные вопросы. Теоретическиесведения Качество программного обеспечения во многом зависит от качества сформи- рованных требований, т. к. требования к программному продукту являются базой для разработки и последующего тестирования. Тестирование требований выполняется на предмет их соответствия критери- ям качества требований (рисунок 3.1).  Рисунок 3.1 – Критерии качества требований 22 Завершенность (completeness). Требование является полным и законченным с точки зрения представления в нем всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно». Типичные проблемы с завершенностью: Отсутствуют нефункциональные составляющие требования или ссылки на соответствующие нефункциональные требования (например: «пароли долж- ны храниться в зашифрованном виде», а каков алгоритм шифрования?). Указана лишь часть некоторого перечисления (например: «экспорт осуществляется в форматы PDF, PNG и т. д.», а что следует понимать под «и т. д.»?). Приведенные ссылки неоднозначны (например: «см. выше» вместо «см. раздел 123.45.b»). Атомарность,единичность(atomicity). Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершенности и оно описывает одну и только одну ситуацию. Типичные проблемы с атомарностью: В одном требовании фактически содержится несколько независимых (например: «кнопка “Restart” не должна отображаться при остановленном серви- се, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя» – здесь в одном предложении описаны совершенно разные эле- менты интерфейса в совершенно разных контекстах). Требование допускает разночтение в силу грамматических особенно- стей языка (например: «если пользователь подтверждает заказ и редактирует за- каз или откладывает заказ, должен выдаваться запрос на оплату» – здесь описаны три разных случая и это требование стоит разбить на три отдельных требования во избежание путаницы). Такое нарушение атомарности часто влечет за собой воз- никновение противоречивости. В одном требовании объединено описание нескольких независимых ситуа- ций (например: «когда пользователь входит в систему, должно отображаться при- ветствие; когда пользователь вошел в систему, должно отображаться имя пользователя; когда пользователь выходит из системы, должно отображаться прощание» – все эти три ситуации «заслуживают» того, чтобы быть описанными отдельными и более детальными требованиями). Непротиворечивость,последовательность(consistency). Требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам. Типичные проблемы с непротиворечивостью: Противоречия внутри одного требования (например: «после успешного входа в систему пользователя, не имеющего права входить в систему…» – а как пользователь вошел в систему, если не имел такого права?). 23 Противоречия между двумя и более требованиями, между таблицей и тек- стом, рисунком и текстом, требованием и прототипом и т. д. (например: «712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” всегда должна быть синей» – так все же красной или синей?). Использование неверной терминологии или использование разных терми- нов для обозначения одного и того же объекта или явления (например: «в случае, если разрешение окна составляет менее 800x600…» – разрешение есть у экрана, у окна есть размер). Недвусмысленность(unambiguousness,clearness). Требование описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок и допускает только однозначное объективное понимание. Требование атомарно в плане невозможности различной трактовки сочетания отдельных фраз. Типичные проблемы с недвусмысленностью: Использование терминов или фраз, допускающих субъективное толкование (например: «приложение должно поддерживать передачу больших объемов дан- ных» – насколько «больших»?). Вот лишь небольшой перечень слов и выражений, которые можно считать верными признаками двусмысленности: адекватно, быть способным, легко, обеспечивать, как минимум, быть способным, эффективно, своевременно, применимо, если возможно, будет определено позже, по мере необходимости, если это целесообразно, но не ограничиваясь, быть способно, иметь возможность, нормально, минимизировать, максимизировать, оптимизи- ровать, быстро, удобно, просто, часто, обычно, большой, гибкий, устойчивый, по последнему слову техники, улучшенный, результативно. Использование неочевидных или двусмысленных аббревиатур без расшиф- ровки (например: «доступ к ФС осуществляется посредством системы про- зрачного шифрования» и «ФС предоставляет возможность фиксировать сообще- ния в их текущем состоянии с хранением истории всех изменений» – ФС здесь обозначает файловую систему или какой-нибудь «Фиксатор Сообщений»?). Формулировка требований из соображений, что нечто должно быть всем очевидно (например: «Система конвертирует входной файл из формата PDF в вы- ходной файл формата PNG» и при этом автор считает совершенно очевидным, что имена файлов система получает из командной строки, а многостраничный PDF конвертируется в несколько PNG-файлов, к именам которых добавляется «page-1», «page-2» и т. д.). Эта проблема перекликается с нарушением корректности. Выполнимость(feasibility). Требование технологически выполнимо и может быть реализовано в рамках бюджета и сроков разработки проекта. Типичные проблемы с выполнимостью: «Озолочение» (gold plating) – требования, которые крайне долго и/или дорого реализуются и при этом практически бесполезны для конечных пользова- телей (например: «настройка параметров для подключения к базе данных долж- 24 на поддерживать распознавание символов из жестов, полученных с устройств трехмерного ввода»). Технически нереализуемые на современном уровне развития техноло- гий требования (например: «анализ договоров должен выполняться с применени- ем искусственного интеллекта, который будет выносить однозначное корректное заключение о степени выгоды от заключения договора»). В принципе нереализуемые требования (например: «система поиска долж- на заранее предусматривать все возможные варианты поисковых запросов и кэ- шировать их результаты»). Обязательность, нужность(obligation) иактуальность(up-to-date). Если требование не является обязательным к реализации, оно должно быть просто ис- ключено из набора требований. Если требование нужное, но «не очень важное», для указания этого факта используется указание приоритета. Также исключены (или переработаны) должны быть требования, утратившие актуальность. Типичные проблемы с обязательностью и актуальностью: Требование было добавлено «на всякий случай», хотя реальной потребно- сти в нем не было и нет. Требованию выставлены неверные значения приоритета по критериям важности и/или срочности. Требование устарело, но не было переработано или удалено. Прослеживаемость(traceability). Прослеживаемость бывает вертикальной и горизонтальной. Вертикальная позволяет соотносить между собой требования на различных уровнях требований, горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, архитектурными решениями и т. д. Для обеспечения прослеживаемости часто используются специальные ин- струменты по управлению требованиями и/или матрицы прослеживаемости. Типичные проблемы с прослеживаемостью: Требования не пронумерованы, не структурированы, не имеют оглавления, не имеют работающих перекрестных ссылок. При разработке требований не были использованы инструменты и техники управления требованиями. Набор требований неполный, носит обрывочный характер с явными «про- белами». Модифицируемость(modifiability). Это свойство характеризует простоту внесения изменений в отдельные требования и в набор требований. Можно гово- рить о наличии модифицируемости в том случае, если при доработке требований искомую информацию легко найти, а ее изменение не приводит к нарушению иных описанных в этом перечне свойств. Типичные проблемы с модифицируемостью: 25 Требования неатомарны (см. «атомарность») и непрослеживаемы, а потому их изменение с высокой вероятностью порождает противоречивость. Требования изначально противоречивы. В такой ситуации внесение изме- нений (не связанных с устранением противоречивости) только усугубляет ситу- ацию, увеличивая противоречивость и снижая прослеживаемость. Требования представлены в неудобной для обработки форме (например, не использованы инструменты управления требованиями и в итоге команде прихо- дится работать с десятками огромных текстовых документов). Проранжированностьповажности, стабильности, срочности(ranked forimportance,stability,priority). Важность характеризует зависимость успеха проек- та от успеха реализации требования. Стабильность характеризует вероятность то- го, что в обозримом будущем в требование не будет внесено никаких изменений. Срочность определяет распределение во времени усилий проектной команды по реализации того или иного требования. Типичные проблемы с проранжированностью состоят в ее отсутствии или не- верной реализации и приводят к следующим последствиям. Проблемы с проранжированностью по важности повышают риск неверного распределения усилий проектной команды, направления усилий на второсте- пенные задачи и конечного провала проекта из-за неспособности продукта выполнять ключевые задачи с соблюдением ключевых условий. Проблемы с проранжированностью по стабильности повышают риск выпол- нения бессмысленной работы по совершенствованию, реализации и тестированию требований, которые в самое ближайшее время могут претерпеть кардинальные изменения (вплоть до полной утраты актуальности). Проблемы с проранжированностью по срочности повышают риск нарушения желаемой заказчиком последовательности реализации функциональности и ввода этой функциональности в эксплуатацию. Корректность(correctness) ипроверяемость(verifiability). Фактически эти свойства вытекают из соблюдения всех вышеперечисленных (или можно сказать, что они не выполняются, если нарушено хотя бы одно из вышеперечисленных). В дополнение можно отметить, что проверяемость подразумевает возможность со- здания объективного тест-кейса (тест-кейсов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию. К типичным проблемам с корректностью также можно отнести: опечатки (особенно опасны опечатки в аббревиатурах, превращающие одну осмысленную аббревиатуру в другую также осмысленную, но не имеющую отно- шения к некоему контексту; такие опечатки крайне сложно заметить); наличие неаргументированных требований к дизайну и архитектуре; плохое оформление текста и сопутствующей графической информации; 26 грамматические, пунктуационные и иные ошибки в тексте; неверный уровень детализации (например, слишком глубокая детализация требования на уровне бизнес-требований или недостаточная детализация на уровне требований к продукту); требования к пользователю, а не к приложению (например: «пользователь должен быть в состоянии отправить сообщение» – мы не можем влиять на состоя- ние пользователя). Техникитестированиятребований Одной из наиболее активно используемых техник анализа требований яв- ляется просмотр или рецензирование. Данная техника может быть реализована в форме: беглого просмотра (показ автором своей работы коллеге; самый быстрый, самый дешевый и наиболее широко используемый вид просмотра); технического просмотра (выполняется группой специалистов, каждый из которых представляет свою область знаний: просматриваемый продукт не может считаться достаточно качественным, пока хотя бы у одного просматривающего остаются замечания); формальной инспекции (структурированный, систематизированный и до- кументируемый подход к анализу документации, для выполнения которого при- влекается большое количество специалистов, само выполнение занимает доста- точно много времени, и потому этот вариант просмотра используется достаточно редко, как правило, при получении на сопровождение и доработку проекта, созда- нием которого ранее занималась другая компания). Следующей техникой тестирования и повышения качества требований яв- ляется (повторное) использование такой техники выявления требований, как фор- мулировка вопросов. Если хоть что-то в требованиях вызывает непонимание или подозрение, задавайте вопросы. Хорошее требование является проверяемым, а значит, должны суще- ствовать объективные способы определения того, верно ли реализовано требова- ние. Продумывание чек-листов или даже полноценных тест-кейсов в процессе анализа требований позволяет определить, насколько требование проверяемо. По- мимо использования для тестирования требований, в дальнейшем такие чек-листы и тест-кейсы могут составить основу тестовой документации. Рисунки, схемы. Чтобы увидеть общую картину требований целиком, очень удобно использовать рисунки, схемы, диаграммы, интеллект-карты и т. д. Графическое представление удобно одновременно своей наглядностью и кратко- стью (например, UML-схема базы данных, занимающая один экран, может быть описана несколькими десятками страниц текста). Исследование поведения и прототипирование. Можно сказать, что прото- типирование часто является следствием создания графического представления и 27 анализа поведения системы. С использованием специальных инструментов можно очень быстро сделать наброски пользовательских интерфейсов, оценить применимость тех или иных решений и даже создать не просто «прототип ради прототипа», а заготовку для дальнейшей разработки, если окажется, что реализо- ванное в прототипе (возможно, с небольшими доработками) устраивает заказчика. Практическоезадание: Получить у преподавателя спецификацию с требованиями к программному продукту. Протестировать спецификацию методом просмотра на предмет соответ- ствия критериям качества требований. Для обнаруженных дефектов указать, какой критерий качества нарушен, и аргументировать свою точку зрения. Для обнаруженных дефектов сформулировать уточняющие вопросы к за- казчику для выработки качественных требований. Оформить отчет и защитить лабораторную работу. Содержаниеотчета: Цель работы. Отчет по тестированию спецификации. Выводы по работе. ний. Контрольныевопросы: Какие выделяют критерии качества требований? Какие требования являются завершенными? Перечислите основные проблемы, связанные с завершенностью требова- Какие требования являются атомарными? Перечислите основные проблемы, связанные с атомарностью требований. Какие требования являются непротиворечивыми? Перечислите основные проблемы, связанные с непротиворечивостью тре- бований. Какие требования являются недвусмысленными? Перечислите основные проблемы, связанные с недвусмысленностью тре- бований. Какие требования являются выполнимыми? Перечислите основные проблемы, связанные с выполнимостью требова- ний. Какие требования являются обязательными, нужными и актуальными? 28 Перечислите основные проблемы, связанные с обязательностью и акту- альностью требований. Какие требования являются прослеживаемыми? Перечислите основные проблемы, связанные с прослеживаемостью тре- бований. Какие требования являются модифицируемыми? Перечислите основные проблемы, связанные с модифицируемостью тре- бований. Какие требования считаются проранжированными по важности? Какие требования считаются проранжированными по стабильности? Какие требования считаются проранжированными по срочности? Перечислите основные проблемы, связанные с проранжированностью требований по важности. Перечислите основные проблемы, связанные с проранжированностью требований по стабильности. Перечислите основные проблемы, связанные с проранжированностью требований по срочности. Какие требования являются корректными? Перечислите основные проблемы, связанные с корректностью требова- ний. Какие существуют техники тестирования требований? В чем особенности каждой из них? 29 |