Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 2. Анализ требований и тестирование 45 средняя длительность промежутка времени между двумя неисправностями? Ка ким должно быть максимальное время простоя? и Сопровождение. Эти требования определяют, как производится устранение проблем, обнаруженных в системе, как усовершенствованные версии системы поставляются заказчику и как пользователи должны переходить на усовершен ствованную версию системы. • План поставки версий. Если требованиям назначены приоритеты, возможно, необходимо будет определить временной график поставки версий, который показывает, реализации каких требований уделяется внимание в конкретной версии. Выполняя статическое тестирование на документах с формулировками требова ний, возможно, возникнет желание воспользоваться приведенным выше списком с целью обеспечения полноты тестирования. Если вы ведете предысторию статиче ского тестирования сразу нескольких проектов, этот список можно расширить таким образом, чтобы он соответствовал номенклатуре программных продуктов, создавае мых вашей компанией. Если обстоятельства заставляют вас проводить тестирование в условиях неполного набора требований, на основе предложенного списка, скорее всего, придется определить, какие тесты нужны помимо тех, что образуют покрытие задокументированных требований. П р и м е р ы требований. Пример, содержащий несколько функциональных требований, приводится на рис. 2.4. Этот пример относится к гипотетическому про дукту, который мы будем "разрабатывать" на протяжении практически всей книги. Указанный демонстрационный программный продукт, который мы назовем ком плектом ТМТ (Test Management Toolkit — инструментальные средства управления тестами), представляет собой приложение, предназначенное для тестовых групп, которым необходимы автоматизированные инструментальные средства для под держки планирования тестирования, разработки тестовых случаев и выполнения тестов. Определение требований к комплекту ТМТ можно найти в третьей части книги. Требования, представленные на рис. 2.4, касаются некоторых ключевых свойств программного продукта. Спецификация требований Спецификация требований описывает то же, что и документ определения требова ний, однако спецификация предназначена для системных разработчиков и представ лена на языке или в обозначениях, ориентированных на разработчиков. Специфика цию требований часто называют системной функциональной спецификацией, не смотря на то что ее область действия распространяется за пределы на функциональ ных требований системы. Спецификация требований, или функциональная спецификация, — это далеко не примитивный перевод определений требований на технический язык. Специфика ция может проводить дальнейшее разбиение требований по категориям, а также до бавлять подробности за счет формулирования некоторого набора производных тре бований. Например, в исходном определении требований может быть указано, что 46 Часть I. Процесс быстрого тестирования система должна работать в заданном диапазоне температур, в то время как в специ фикации могут быть определены различные режимы эксплуатации системы в раз личных температурных диапазонах. В какой-то мере определение требований пред ставляет собой объявление того, что заказчику необходимо и что он хотел бы полу чить, а спецификация есть ответное предложение группы специалистов, содержащее описание того, что будущая система будет способна делать. Требования к инструментальным средствам управления тестами 2.2.1 Приложение должно предоставить средства создания, модификации, просмотра, хранения и поиска документов, имеющих отношение к планированию тестирования. 2.2.2 Приложение должно предоставить средства создания, модификации, просмотра, хранения и поиска списка тестов, подлежащих выполнению. В этом документе список этих средств будет называться "списком прогона". 2.2.3 Приложение должно предоставить средства создания, модификации, просмотра, хранения и поиска индивидуальных тестов, которые могут состоять из таких компонентов как проце дура установки, список оборудования, методика испытаний, контрольные данные и тесто вые процедуры очистки. 2.2.4 Приложение должно предоставить такие средства для выполнения тестов из списка прого на, чтобы для каждого теста можно было создавать результаты тестирования и регистра ционные журналы. 2.2.5 Приложение должно предоставить средства создания, модификации, просмотра, сортиров ки, хранения и поиска сообщений о дефектах. 2.2.6 Приложение должно предоставить средства для генерации отчетов, в которых подводятся итоги состояния тестирования, результатов тестирования и сообщений о дефектах. Рис. 2.4. Пример определения требований Составители спецификации требований могут использовать естественный язык либо выбрать язык или обозначения из широкого набора языков, разработанных специально для написания спецификации требований. Поскольку термины в естест венном языке могут интерпретироваться различными способами, их применение может усилить взаимное непонимание между заказчиком и разработчиком, если не предпринять специальных мер по уточнению значений отдельных слов, таких как, например, "производительность", "практичность", "надежных" и т.п. Особенности привлечения для формулирования требований языков, отличных от естественных, описано в [42]. Готовая формальная спецификация требований должна быть подвергнута стати ческому тестированию с целью проверки, что каждое требование, зафиксированное в документе определения требований, отражено в спецификации требований, а каж дое требование одного документа отображается или отслеживается из другого доку мента. Окончательная редакция спецификации должна пройти статическое тестиро вание с тем, чтобы убедиться, что требования спецификации обладают свойствами полноты, непротиворечивости, осуществимости, контролепригодности, однознач ности и релевантности. Глава 2. Анализ требований и тестирование 47 Матрица прослеживаемости требований Назначение матрицы прослеживаемости требований заключается в отображении каждого требования на проектные компоненты, программные коды и тестовые слу чаи. Пример матрицы прослеживаемости требований показан на рис. 2.5. В этом примере каждое требование, фигурирующее в документе определения требований, отображается на одно или большее количество требований из спецификации, на проектные компоненты и программные коды, а также на тестовые случаи модульного тестирования, проверки взаимодействия и функционирования компонентов про граммного продукта, системных и приемочных испытаний. Для нумерации требова ний используется "десятичная нотация Дьюи". Эта нотация позволяет отобразить исходные требования из документа определения требований на производные требо вания и различные виды тестов в отношении "один-ко-многим" (например, одно тре бование соотносится с некоторым множеством системных тестов). Даже если про ектная информация и данные о программных кодах не включены в эту матрицу, по лезно поддерживать ее упрощенный вариант, который соотносит каждое требование с соответствующими системными и приемочными тестами. Эти идентификаторы отображают требования из документа определения требований на требования из спецификации требований. Эти идентификаторы отображают все тесты обратно на требования. Идентификатор требования в документе определения требований RD2 2 4 RD2 2 4 RD2 2 4 RD2 2 4 Идентификатор требования в спецификации требований RS2 2 4 1 RS2 2 4 2 RS2 2 4.3 RS2 2 4 4 Идентификатор проектного компонента D 2 2 4 1 D2 2 4 2 D2 2 4 3 D2 2 4 4 Идентификатор , программного компонента СС2 2 4 1 СС2 2 4 2 СС2 2 4 3 ' СС2 2 4 4 Идентификатор тестового случая на этапе модульного тестирования UT2 2 4 1 UT2 2 4 2 UT2 2 4 3 UT2 2 4 4 Идентификатор тестового случая на этапе проверки взаимодействия компонентов продукта IT2 2 4 IT2 2 4 IT2 2 4 IT2 2 4 Идентификатор тестового случая на этапе системных испытаний ST2 2 4 ST2 2 4 ST2 2 4 ST2 2 4 Идентификатор тестового случая на этапе приемочных испытаний АТ2 2 4 АТ2 2 4 АТ2 2 4 АТ2 2 4 Эти идентификаторы прослеживают происхождение всех проектных и программных компонентов до соответствующих требований. Рис. 2.5. Примерный формат матрицы отслеживания требований Тестирование требований Завершающим действием процесса формулирования требований является статиче ское тестирование требований. Одна из целей статического тестирования преду сматривают проверку требований на полноту, непротиворечивость, осуществимость, а также на возможность тестирования (статического или динамического) в процессе реализации. Дополнительная цель такого статического тестирования заключается в проверке того, что требования, представленные в окончательном виде, соответству- 48 Часть I. Процесс быстрого тестирования ют пожеланиям заказчика, выраженных им на стадии выявления требований. Пра вильно выполненное статическое тестирование оборачивается серьезным выигры шем в смысле экономии средств и времени. Напомним, что согласно данным группы Standish, рассматриваемым в начале главы, проблемы, возникающие на этапе форму лирования требований, порождают более 50% проектных ошибок и перерасхода ре сурсов. Статическое тестирование требований представляет собой наиболее эффек тивный способ обнаружения этих дефектов еще до того, как они окажут неблагопри ятное влияние на планы выполнения работ и сметные расходы. Существует множество способов выполнения статического тестирования, однако тремя наиболее распространенными являются инспекции, сквозной контроль и экс пертные оценки. Иногда названия этих методов звучат по-другому; инспекции из вестны как технический анализ, а экспертные оценки нередко называют "партнер ским контролем". Характерные особенности каждого из этих типов статического тестирования приводятся в таблице 2.1. Более подробную информацию о методах статического тестирования можно найти во врезке 2.2 и в главе 9. Таблица 2.1. Характерные особенности избранных методов статического тестирования [28] Презентатор Число участников Подготовка Сбор данных Отчет по результатам Достоинства Недостатки Инспекции Любой, но не автор 1-6 человек Да Да Да Максимальная эффективность Наибольшие затраты Сквозной контроль Любой 5 или более Только презентатор Не обязательно Не обязательно Большее число участников Обнаруживает меньше дефектов, чем другие способы Экспертные оценки Нет 1 или два Нет Нет Словесный комментарии или комментарий по электронной почте Минимальные затраты Обнаруживает минимальное число дефектов по сравнению с другими способами Из таблицы 2.1 следует, что в то время, как затраты на проведение инспекций больше, чем на реализацию других методов, они обеспечивают наивысшую эффек тивность обнаружения дефектов в проверяемом рабочем продукте. Поскольку очень важно найти как можно больше дефектов на стадии формулирования требований, мы настоятельно рекомендуем инспекции как основной метод анализа требований. Глава 2. Анализ требований и тестирование 49 СТАТИЧЕСКИЕ МЕТОДЫ ТЕСТИРОВАНИЯ Наиболее распространенными методами статического тестирования являются инспекции, сквозной контроль и экспертные оценки. Основные характеристики каждого метода приводятся ниже в данном разделе. Инспекции Основной организационной формой инспекции является совещание, на котором рабочий продукт анализируется с целью обнаружения дефектов. Каждый участник специально готовится к совещанию, а само совещание проводится в соответствии со специальным набором правил. Обнаруженные дефекты документируются, итоги совещания публику ются. Практика показала высокую эффективность таких сообщений с точки зрения обна ружения дефектов. Данные, опубликованные Бремом [28], показывают, что если на ин спекции приходится 20% трудозатрат на программирование, то из инспектируемого про граммного кода будет изъято примерно 80% ошибок на уровне программных модулей. Первоначально рекомендации по проведению инспекций были сформулированы Фейга- ном [16] из компании IBM, причем с течением времени другие организации приняли их в качестве стандартов или рекомендаций для практической деятельности. Сквозной контроль Сквозной контроль представляет собой менее формальное мероприятие, чем инспек ции, в том смысле, что ни от одного из его исполнителей не требуется специальной под готовки, за исключением разве что презентатора. Кроме того, никаких итоговых отчетов при этом не требуется. Поскольку сквозной контроль формализован в меньшей степени, нежели инспекции, то он может охватывать больше материала. В то же время он не об- • ладает такой эффективностью обнаружения и документирования дефектов, как инспекции. Экспертные оценки Экспертные оценки требуют немного больше, чем просто передача рабочего продукта коллеге по работе и выслушивание его мнения по этому поводу. Экспертная оценка может быть выражена словесно либо передана по электронной почте. Формальные процедуры экспертных оценок отсутствуют, эффективность поиска и документирования • дефектов, свойственная этому методу, меньше, чем эффективность двух других методов. Врезка 2.2. Критерии, используемые при тестировании требований Существует шесть базовых критериев, которые должны использоваться во время ста тического тестирования спецификаций требований. Критерии требуют, чтобы каж дое требование отвечало принципам полноты, однозначности, непротиворечивости, прослеживаемости, осуществимости и контролепригодности. П о л н о т а . Набор требований считается полным, если все его составные части представлены и каждая такая часть выполнена в полном объеме. При тестировании набора требований на полноту необходимо обратить особое внимание на следующие моменты: • Требования не должны содержать выражений типа "подлежит определению", "и так далее", "и прочие" и им подобных. • Требования не должны ссылаться на несуществующую справочную информа цию, такую как, например, несуществующая спецификация. • Требование не должно ссылаться на функциональные средства, которые еще не определены. 50 Часть I. Процесс быстрого тестирования Однозначность. Каждое требование должно быть точно и ясно сформулирова но; оно должно допускать единственное толкование. Требование должно быть удобо читаемым и понятным. Если требование отличается особой сложностью, для облег чения понимания может быть привлечен вспомогательный материал, такой как, диа граммы или таблицы. Если для пущей убедительности используются выражения на подобие "это очевидно" или "само собой разумеется", то вполне возможно, что автор пытается отвлечь ваше внимание от того или иного двусмысленного утверждения. Непротиворечивость. Требования не должны противоречить друг другу или действующим стандартам. Если требования конфликтуют друг с другом, то нужно вводить приоритеты с целью разрешения таких конфликтов. Умение обнаруживать дефекты, обусловленные противоречиями требований, предполагает хорошее зна ние всего документа, содержащего требования, и знакомство с существующими стан дартами или другими внешними техническими условиями. Прослеживаемость. Каждое требование должно иметь уникальный иденти фикатор, который позволяет прослеживать его разработку на протяжении всего жизненного цикла. В рабочих продуктах, которые появляются на более поздних эта пах жизненного цикла, таких как план тестирования, каждая ссылка на свойство сис темы должна прослеживаться до определения и спецификации требований. Матрица прослеживаемости требований, обсуждавшаяся ранее в этой главе, является отлич ным инструментальным средством для решения упомянутой задачи. Осуществимость. Каждое требование должно ставить перед системой задачу обеспечить такие средства, которые целесообразно разрабатывать и поддерживать. Если заказчик предъявляет к системе нереальные требования в смысле затрат време ни и средств на разработку тех или иных функций либо же требует разработки функ ций, которые окажутся ненадежными и опасными в эксплуатации, необходимо опре делить риски и принять соответствующие меры. По сути дела, разрабатываемая сис тема должна быть экономически осуществимой, надежной, удобной в эксплуатации и сопровождении. Контролепригодность. Мы должны уметь разрабатывать экономически обос нованные и удобные для использования тесты для каждого требования с целью про демонстрировать, что тестируемый программный продукт обладает необходимыми функциональными возможностями, рабочими характеристиками и соответствует действующим стандартам. Это означает, что каждое требование должно быть изме ряемым или поддаваться количественному определению и что тестирование должно выполняться в приемлемых условиях. Использование прототипов В качестве дополнения к методам статического тестирования для проверки и под тверждения требований с большой пользой могут быть использованы прототипы программного продукта. Прототип (prototype), будь то макет на бумаге или модель про граммного продукта, дает вам возможность предложить заказчику варианты и полу чить обратную реакцию, которая позволяет сделать формулировки требований более точными. Прототипы часто позволяют выявить дефекты в полноте, непротиворечи- Глава 2. Анализ требований и тестирование 51 вости или в осуществимости спецификаций требований, и в силу этого обстоятельст ва могут служить хорошим дополнением статического тестирования. Существуют два подхода к использованию прототипов. В рамках одного из них производится построение одноразового прототипа (throwaway prototype), который используется исключительно для определения требований; прототип не поставляет ся заказчику в виде программного продукта. Второй подход предусматривает созда ние эволюционного прототипа (evolutionary prototype), который применяется на на чальной стадии процесса для выявления и анализа требований, и в то же время под вергается многократным усовершенствованиям, постепенно превращаясь в продукт, который уже можно поставлять заказчику. Тестирование эволюционного прототипа программного продукта рассматривается в следующем разделе. Один из способов встраивания прототипа в жизненный цикл разработки показан на рис. 2.6 [42]. В рамках этого подхода прототипы могут быть построены на стадии формулирования требований и на стадии проектирования цикла разработки. Прото типы используются во время анализа требований для уточнения и тестирования тре бований. На стадиях системного проектирования и проектирования программ раз работчики могут применять прототипы для оценки альтернативных стратегий про ектирования. Программный код, разработанный для прототипа, в такой модели раз работки может как использоваться, так и отбрасываться за ненадобностью. Рис. 2.6. Прототипу добавленные в каскадную модель жизненного цикла. Взято из [42]; измерения внесены с разрешения издательства Prentice Hall 52 Часть I. Процесс быстрого тестирования Чтобы получить преимущество в начале тестовых работ, тестовая группа может воспользоваться прототипами, разработанными на стадии анализа требований. Можно разработать предварительные испытания и выполнить их на прототипе с це лью подтверждения правильности основных требований. Эти тесты будут совершен ствоваться на более поздних стадиях в процессе формирования ключевого набора тестов для этапов системного тестирования и приемочных испытаний. Подобно то му, как прототип помогает сделать требования "более реалистичными" с точки зре ния заказчика и разработчика, этот прототип позволяет тестовой группе "увидеть", как следует определять набор тестов для системы. Если прототипом является модель на бумаге или набор эскизов, то ему придется пройти долгий путь, пока он начнет приносить тестовой группе реальную помощь в понимании того, как получить полез ный набор тестов. Применение прототипов не только помогает получить тестовой группе преиму щества на старте, оно поддерживает статическое или динамическое тестирование на стадии формулирования требований. Прототипы могут использоваться в качестве вспомогательного средства для определения полноты, непротиворечивости, осуще ствимости и релевантности требований. Прототипы используют в моделях жизненных циклов, отличных от каскадных. По существу, в случае эволюционного прототипа оно может стать основой процесса раз работки. Одной из наиболее сложных моделей жизненного цикла является спираль ная модель, разработанная Боемом [42]. Спиральная модель реализует подход, учи тывающий риски, она разбивает проект на некоторую последовательность "мини- проектов", каждый из которых решает ту или иную крупную задачу. После того как все основные риски будут учтены, модель завершается обычной каскадной разработ кой конечного программного продукта. Тестирование в рамках жизненного цикла эволюционного прототипирования Создание эволюционных прототипов представляет собой метод поэтапной разработ ки системы, при этом каждый этап определяется ответной реакцией заказчика и ре зультатами тестирования. Прототипы особенно полезны, когда вы испытываете за труднения при определении основных требований на начальной стадии проекта и в то же время имеете возможность многократно контактировать с заказчиком, чтобы понять, что ему нужно. На каждой итерации цикла разработки приходится прибегать к помощи как статического, так и динамического тестирования. Пример жизненного цикла показан на рис. 2.7. В эволюционной модели разработка начинается с определения исходного прото типа. Если разработка ведется по спиральной модели, то в центре внимания исход ной модели может находиться оценка основных рисков проекта. В других случаях исходным прототипом может быть макет пользовательского интерфейса, в условиях которого пользователи образуют обратную связь в рамках функциональных возмож ностей и удобства и простоты обслуживания системы. Статическое тестирование следует применять в отношении разработки исходного прототипа в виде экспертиз или совместного с заказчиком рабочего совещания, например, JAR-сеанса. Глава 2. Анализ т р е б о в а н и й и т е с т и р о в а н и е 53 Рис. 2.7. Тестирование в рамках жизненного цикла эволюционного прототипирования 54 Часть I. Процесс быстрого тестирования Как только определение прототипа завершается, группа разработчиков выполня ет проектирование, кодирование и тестирование прототипа, в то время как группа тестирования параллельно разрабатывает планы тестирования, создает тесты и вы полняет их прогон. Эта модель требует тесного взаимодействия между коллективом разработчиков и группой тестирования с тем, чтобы каждый прототип подвергся тестированию в достаточных объемах перед его демонстрацией пользователю. Если функциональные возможности системы возрастают с каждой итерацией, группа тес тирования должна иметь возможность выполнить регрессионное тестирование на каждом шаге цикла разработки. Другими словами, необходимо прогонять специаль ные тесты, чтобы убедиться, что старые функциональные средства не разрушены или не деградировали в результате добавления новых функциональных возможностей. Автоматизация может оказаться исключительно полезной для регрессионного тес тирования. Если количество тестов, выполняемых вручную, возрастает с каждым циклом разработки, трудозатраты на тестирования существенно возрастают и- требу ют все больше и больше времени. По завершении достаточно большого числа циклов разработки перед передачей конечного программного продукта заказчику потребуется провести завершающие системные и приемочные испытания продукта. Из примера 2.7 нетрудно видеть, что все основные функции динамического тестирования (планирование тестирования, проектирования, реализации и выполнение) выполняются в рамках жизненного цикла эволюционного прототипирования, но они выполняются в итеративном ре жиме, что обусловливает необходимость регрессионного тестирования. Что дальше В данной главе были проведены исследования стадии формулирования требований процесса разработки с точки зрения специалиста по тестированию систем. Мы обна ружили два основных фактора, обусловливающих участие группы тестирования на стадии формулирования требований: • Необходимость получения спецификаций, служащих основой планов тести рования и проектирования тестов. • Необходимость статического тестирования спецификаций требований с целью предотвращения перетекания дефектов на более поздние стадии разработки. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ В продаже можно найти несколько программных инструментальных средств, которые можно использовать на этапе формулирования требований. Программные инструмен тальные средства особенно полезны в плане выявления требований и обеспечения про- слеживаемости требований на протяжении процесса разработки. Примерами средств управления требованиями являются DOORS и Requisite Pro. Инструментарий DOORS - э т о инструментальное средство, разработанное компанией Quality System and Softwaie (QSS) Ltd. Еще одно средство — это модуль Requisite Pro, который продается компани ей Rational Software. Компания Atlantic Systems Guild, Inc. занимается независимыми ис следованиями инструментальных средств управления требованиями, результаты которых публикуются на Web-сайте http://www.systemguild.com. Врезка 2 3 |