Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 2. Анализ требований и тестирование 37 Опубликованный группой Standish G r o u p анализ данных, который имеет целью определить причины неудачного завершения проектов и стоимость устранения де фектов не на ранних, а на поздних стадиях цикла разработки, недвусмысленно свиде тельствует в пользу применения статического тестирования на стадии формулирова ния требований с тем, чтобы предотвратить проникновение дефектов на более позд ние стадии. Две причины для привлечения тестовой группы для участия на ранней стадии формулирования требований могут быть определены следующим образом: • Тестовая группа заинтересована в как можно более раннем получении макси мально точной спецификации, на основе которой можно составлять план тес тирования и проектировать тесты. Это основное условие, без выполнения ко торого тестирование на ранних стадиях не дает положительного эффекта. • Тестовая группа должна проводить статическое тестирование спецификаций требований с тем, чтобы предотвратить попадание дефектов на более поздние стадии разработки. Успешное статическое тестирование на стадии формулиро вания требований позволяет сэкономить время и затраты. В данной главе мы обсуждаем процесс формулирования требований с точки зре ния специалиста по тестированию. Обсуждение начинается с опроса пользователя с целью выявления требований и анализа задач, определения конкретных рабочих продуктов и точек этого процесса, в которых можно применить статическое тестиро вание. Мы также рассмотрим типы требований, необходимых для обеспечения полноты, и предложим возможные способы тестирования требований. Кроме того, обсуждается возможность использования прототипов программного продукта при анализе требова ний, равно как и роль тестирования жизненного цикла, основанного на прототипах. Процесс формулирования требований Проекты по созданию программного обеспечения начинают свой жизненный цикл, когда у заказчика возникает необходимость заменить существующую систему или по требность в совершенно новой системе. Заказчиком может быть любой отдел вашей компании, отдельная компания или агентство, которое заключает с вами договор на выполнение работ. В качестве заказчика может также выступать рынок товаров мас сового производства с активным спросом на готовые программные продукты. По требности заказчика могут быть представлены набором требований, где под требова нием (requirement) понимается описание того, что способна выполнять система, либо описание некоторых условий функционирования, которые необходимо обеспечить с тем, чтобы система могла выполнять свои задачи. Требования определяют то, что должна выполнять система, но не то, как она должна это выполнять. Последнее озна чает, что в центре внимания требования находится задача заказчика и его деловая активность, но не то, как достигается ее решение. Рисунок 2.2 служит иллюстрацией процесса формулирования требований к систе ме программного обеспечения. Мы исследуем этот процесс с точки зрения специали стов по тестированию, которые стремятся получить информацию, поддерживающую планирование тестирования на ранних стадиях разработки, стремятся обнаружить дефекты уже в самих требованиях, чтобы они не инициировали лавину ошибок на более поздних стадиях разработки. 38 Часть I. Процесс быстрого тестирования • На стадию проектирования Рис. 2.2. Процесс формулирования требований Первым на рис. 2.2 показан опрос заказчика с целью выявления требований, ко торые он предъявляет к программному продукту. Выявление требований выполняет ся в форме вопросов и ответов. С использованием слайдов, макетов и прототипов заказчику предлагаются различные варианты. Сбор пожеланий со стороны заказчика может осуществляться в виде серии интервью или путем использования технологии FAST (Facilitated Application Specification Techniques - технология упрощенной спе цификации приложения), представляющей собой специальный тип собеседований с заказчиком, который облегчает выявление его требований. По мере получения от пользователя, требования должны фиксироваться в виде документа, известного как документ определения требований (requirements definition docu ment). Этот документ оформляется в виде списка требований, сформулированных в результате собеседований с заказчиком. Он представляет собой соглашение между заказчиком и организацией, выполняющей разработки, о том, что должно создавать ся. Определение требований представляет собой письменный документ на естест венном языке, вполне понятный как заказчику, так и коллективам, которые занима ются разработкой и сопровождением системы. Достоинство документа определения требований состоит в том, что его легко по нять, но в то же время ему не хватает точности и технических деталей, необходимых для проектирования и разработки программного продукта. В силу этого обстоятель ства должен быть подготовлен другой документ, известный как спецификация требова ний (requirement specification) или функциональная спецификация (functional specification). Хорошим пособием для первого знакомства с основными понятиями и терминологи- Глава 2. Анализ требований и тестирование 39 ей, используемой при подготовке спецификаций требований, могут служить публи кации [47], [43] и [42]. Как только документ определения требований и спецификации требований будут готовы, можно приступать к построению матрицы прослеживаемости требований (re quirements traceability matrix). Назначение этой матрицы состоит в том, чтобы поставить в соответствие каждому требованию тесты, компоненты проекта и программный код. В идеальном случае в этой работе принимают участие коллективы разработчиков и специалистов по тестированию, в результате чего со временем появятся связанные с каждым требованием проектные компоненты, тесты программных модулей, тесты комплексных и приемочных испытаний. При правильном использовании матрица прослеживаемости требований представляет собой инструментальное средство, ко торое помогает каждому специалисту, принимающему участие в процессе разработ ки, выполнять работу, непосредственно связанную с потребностями заказчика, и не тратить понапрасну время на решение ненужных задач. С точки зрения группы тес тирования этот инструмент может с успехом использоваться для планирования тес тирования и проектирования тестов, обеспечивающих хорошее тестовое покрытие. В нескольких следующих разделах мы проведем более подробное изучение видов деятельности и рабочих продуктов процесса формулировки требований в перспекти ве тестирования. Выявление требований Обмен информацией между заказчиком и разработчиком в процессе определения требований к программному продукту настолько важен для успеха всего проекта, что для достижения его эффективности затрачиваются значительные усилия и средства. Одним из факторов, способных снизить эффективность такого обмена, является не достаточный объем знаний заказчиком методов разработки программных продуктов. Довольно часто заказчик не настолько разбирается в процессе разработки программ ного обеспечения, чтобы быть способным выразить свои требования в форме, по нятной специалисту по разработке системы. Процесс определения системы программного обеспечения можно сравнить с проектированием дома по индивидуальному проекту: может случиться так, что вы не настолько хорошо разбираетесь в строительстве, чтобы точно сказать, что вам нуж но. Обмен мнениями, по всей видимости, должен включать осмотр уже построенных домов, изучение планировки помещений с целью выбора понравившейся, а также изучение некоторого множества других индивидуальных проектов и чертежей. Что касается систем программного обеспечения, то часто полезно продемонстрировать в работе существующее программное обеспечение, ознакомиться с соответствующими документами или прототипами программного продукта и обсудить рабочую среду, в которой будет использоваться программный продукт. Результаты такой работы с за казчиком вызывают непосредственный интерес и у группы, проводящей тестирова ние. Специалисты этой группы желают знать, как заказчик намерен использовать программное обеспечение, дабы спроектировать реалистичные тесты для системных и приемочных испытаний. Один из классов методов, которые могут быть использованы для выявления тре бований, получил название технологии FAST (Facilitated Application Specification Techniques— упрощенной спецификации приложения). Наиболее распространен- 40 Часть I. П р о ц е с с быстрого тестирования ным подходом в рамках реализации технологии FAST является разработанный ком панией IBM метод JAD (Joint Application Development — совместная разработка при ложения) [43]. Другой метод, JAR (Joint Application Requirement — совместная разра ботка требований к приложению), был предложен Гэри Коббом (Gary Cobb) и описан в главе 8. Обычно во время сеанса технологии FAST рекомендуется следовать тому или иному набору условий из числа приведенных ниже [43]: • И заказчики, и разработчики принимают участие в совещании, посвященном вопросам определения требований. • Установлены правила подготовки и участия в совещании, которым следуют обе стороны. Должна быть установлена атмосфера, содействующая успеху совеща ния. • Совещание проводится под управлением посредника. Таким посредником мо жет быть заказчик, разработчик или кто-то посторонний, приемлемый для обеих сторон. • Для фиксации требований используются такие средства, как лекционные пла каты с рейкой, настенные индикаторные панели или простая ленточная бумага. • Цель совещания — определить задачи или потребности заказчика, предложить решение, обсудить различные подходы и определить набор требований. Настоятельно рекомендуется участие в этом совещании специалиста по отладке или даже несколько упростить регламент совещания по технологии FAST с таким расчетом, чтобы в этом совещании могли использоваться элементы статического тестирования. Технология JAR, описанная в главе 8, особо благоприятствует встро енному статическому тестированию, которое в терминологии JAR называется "вспо могательная поддержка". Одним из видов информации, которую можно извлечь в результате проведения мероприятий по выявлению требований, является соглашение между заказчиком и разработчиком относительно приоритетов требований. Например, каждое требова ние может быть отнесено в одну из следующих категорий: • Наиболее важные требования. • Требования, выполнение которых крайне желательно. • Требования, выполнение которых желательно, но не обязательно. Благодаря такому распределению приоритетов упрощается выполнение плана разработок. Например, можно составить план, который ставит выполнение наиболее важных требований в рамках первой версии программного продукта, реализация же лательных требований во второй версии и всех остальных — в третьей версии. Ана логично, группа тестирования может начать разработку тестов для требований с наи большим приоритетом в первую очередь. Такой тип нарастающих поставок или по ставок версиями, часто используется в тех случаях, когда решающее значение имеет соблюдение временного графика работ. Нужно рассмотреть специальный случай, когда от специалистов по тестированию требуется провести испытание программных продуктов, к которым не предъявлено никаких требований, либо случай, когда не все требования выявлены. К сожалению, Глава 2. Анализ требований и тестирование 41 упомянутые ситуации встречаются довольно часто; достаточно вспомнить данные группы Standish G r o u p , приведенные в начале главы, в которых первой из причин неудачи проекта или нарушение сроков его разработки была названа неполнота тре бований. Один из авторов этой книги вспоминает исключительную ситуацию, когда специалисту по тестированию передали компакт-диск с программой и попросили вы полнить ее тестирование — но там не было никакой документации, не говоря уже об описании набора требований. В ситуации, когда спецификация требований отсутствует, у вас, возможно, не ос тается другого выбора, как только написать собственный документ определения тре бований. В зависимости от того, сколько времени выделено на завершение тестовых работ, полученное определение требований может оказаться не таким исчерпываю щим, как этого бы хотелось, но очень важно, чтобы были определены все ключевые требования. Невозможно тестировать программное обеспечение, если нет более- менее точных определений необходимых функциональных средств. Если вы столкну лись с затруднениями при определении требований, возможно, потребуется провес ти JAR-сеанс с генеральным разработчиком и, желательно, с представителями группы маркетинга и заказчиком. По меньшей мере, можно будет взять интервью у предста вителей разработчика и группы маркетинга и сформулировать по возможности пол ные определения требований, насколько это позволяет отпущенное вам время. ВЫЯВЛЕНИЕ ТРЕБОВАНИЙ ПРИ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ РАЗРАБОТКЕ -В условиях объектно-ориентированного похода требования определяются через случаи использования. Случай использования (use case) есть описание того, как функция должна выполняться с точки зрения внешнего пользователя или системы. Совокупность - всех возможных случаев использования описывает функциональные возможности систе мы в целом. Каждый случай использования обычно представлен в формате диаграммы, показываю- щей используемые объекты плюс текстовое описание (получившее название текста сце- нария) того, как выполняется соответствующая функция. Обычно проще всего опреде- лить системные испытания через случай использования, поскольку такой случай не дает никакого представления о том, как система выполняет соответствующую функцию, зато четко определяет, какие функциональные возможности должны быть реализованы. Сле довательно, в основу проекта системных испытаний непосредственно могут быть поло- жены случаи использования, при этом для каждого случая использования разрабатывает ся, по меньшей мере, один тест. Информация о тестировании случаев использования изложена в главе 10. Врезка 2.1 42 Часть I. Процесс быстрого тестирования Определение требований Документ определения требований содержит все требования, предъявляемые к сис теме и сформулированные на естественном языке, благодаря чему они становятся понятными и заказчику, и тем, кто принимает участие в разработке проекта. В пер спективе тестирования мы заинтересованы в получении из этого документа инфор мации, достаточной для того, чтобы иметь возможность приступить к планированию и разработке тестов. Для наших целей определения требований должны обладать следующими свойствами: • Каждое требование должно быть снабжено уникальным идентификатором, чтобы можно было однозначно ссылаться на него при планировании тестового покрытия, при проектировании тестовых случаев и в отчетах по результатам тестирования. • Требования должны быть представлены с точки зрения пользователя системы. Системные и приемочные испытания должны быть спроектированы на основе определений требований, следовательно, эти определения должны быть сфор мулированы в перспективе системного уровня. Этот принцип препятствует по явлению требований, затрагивающих внутренние свойства системы и требую щих детальных знаний программного кода для успешного тестирования. Такие требования должны возникать на поздних стадиях разработки и охватываться модульным тестированием и проверкой взаимодействия и функционирования компонентов системы. • Должны быть включены как функциональные (functional), так и нефункциональные (nonfunctional) требования. Функциональные требования суть требования, опи сывающие услуги и функции, которые должна выполнять разрабатываемая сис тема. Нефункциональные требования описывают ограничения, накладываемые на работу системы, например, количество одновременно работающих пользо вателей, и стандарты, которым должна соответствовать система. • Документ определения требований должен находится под управлением конфи гурациями. Это, по меньшей мере, означает, что данный документ подпадает под управление версиями и что все версии документа должны быть помещены в безопасное хранилище, подобное, например, каталогу, содержимое которого обычно дублируется. Если требования подвергаются изменениям, мы должны иметь возможность проследить, чтобы соответствующие изменения были вне сены в тестовые случаи системных и приемочных испытаний. Оглавление одного из возможных вариантов документа, содержащего системные требования, представлено на рис. 2.3. Это оглавление соответствует стандарту IEEE Standard 830: The IEEE Guide to Software Requirements Specifications [23] — Руководящие принципы IEEE по составлению спецификации требований к программному обеспе чению. Пример документа определения требований, соответствующего рис. 2.3, при водится в третьей части книги. Этот пример может принести определенную пользу, если вы окажетесь в ситуации, когда необходимо будет составить собственный доку мент определения требований. Кроме того, он может оказаться полезным при прове дении статического тестирования различных документов, основанных на определе нии требований. Глава 2. Анализ требований и тестирование 43 Документ определения требований (Requirements Definition Document) Оглавление (Table of content) 1. Введение (Introduction) 4 1.1. Назначение (Purpose) 4 1.2. Область применения (Scope) 4 1.3. Обзор (Overview) 4 2. Общее описание (General Description) 4 2.1. Перспектива продукта (Product perspective) 4 2.2. Функция продукта (Product function) 4 2.3. Характеристика пользователя (User Characteristics) 4 2.4. Ограничения общего характера (General Constraints) 4 2.5. Допущения и зависимости (Assumption and Dependencies) 5 3. Особые требования (Specific Requirements) 5 3.1. Функциональные требования (Functional Requirements) 5 3.2. Требования внешнего интерфейса (External Interface Requirements) 5 3.3. Требования к производительности (Performance Requirements) 5 3.4. Проектные ограничения (Design constraints) 5 3.5. Атрибуты (Attributes) 6 3.6. Другие требования (Other Requirements) 6 Ссылки (References) 7 Приложение 1. Сокращения (Appendix 1 —Acronyms) 7 Приложение 2. Терминология (Appendix 1 — Definition of Terms) 7 Рис. 2.3. Пример оглавления документа определения требований к программному продукту. Составлен в соответствии со стандартом IEEE Standard 830: The IEEE Guide to Software Requirements Specifications [23]. Все права защищены. Документ определения требований, показанный на рис. 2.3, включает общее опи сание, которое показывает, какими достоинствами обладает данный продукт перед другими продуктами этого типа, и описание его функциональных возможностей. В нем дано краткое описание основных свойств продукта и указано, какой квалифика цией должен обладать пользователь, чтобы работать с ним. В то же время документ не содержит подробного описания функциональных средств. Раздел специальных требований содержит определения функциональных требований, требований к про изводительности, к интерфейсам и ряд других требований. Рассматриваемый доку мент должен содержать определения сокращенных обозначений (акронимов) и тех нической терминологии, используемой для описания продукта. Как только документ определения требований будет написан, он должен быть подвергнут статическому тестированию с целью проверки требований на полноту, непротиворечивость, осуществимость, контролепригодность, однозначность и реле вантность. Типы требований. Выше мы определили требования как описание того, что способна сделать система, либо как условия эксплуатации, которые необходимо обеспечить для того, чтобы система была способна выполнять возложенные на нее задачи. Это подразумевает использование широкого диапазона различных сведений, 44 Часть I. Процесс быстрого тестирования поэтому полезно разбить требования на категории. Пример набора таких категорий представлен следующим списком: • Функциональные средства. Этот набор требований определяет, какие функ ции должен выполнять данный программный продукт на системном или поль зовательском уровне. Для ясности может быть указано, чего ие должен делать данный продукт. • Интерфейсы. Эта категория требований описывает входы, получаемые из внешних систем, и выходы, направляемые во внешние системы. Накладывают ся ли на эти интерфейсы какие-то ограничения, связанные с форматами дан ных и носителями информации? • Данные. Эти требования описывают входные и выходные данные системы. Какой при этом используется формат? Какие данные нужно сохранять? Какой объем данных поступает в систему и из системы, и с какой скоростью передачи? С какой точностью должны выполняться вычисления? • Производительность. Требования этой категории описывают проблемы мас штабирования и синхронизации, например, сколько пользователей одновре менно должна обслуживать система, сколько транзакций должна выполнять система в единицу времени, как долго пользователь должен ждать ответа на свой запрос. Следует соблюдать особую осторожность при выражении этих требований в числовых значениях, поскольку в дальнейшем их придется под тверждать. • Пользователи и человеческий фактор. Эта категория требований предъявля ется к тем, кто будет работать с системой в смысле их квалификации и опыта. О н и также определяют необходимый уровень удобства и простоты использо вания программного продукта, например, сколько отдельных действий требу ется для выполнения рутинной операции в системе? Насколько отчетливо вы ражена обратная связь после каждого действия? • Физическая среда. Эта категория требований определяет, где должно функ ционировать оборудование. Установлено ли оборудование более чем в одном месте? Имеют ли место ограничения по температуре, влажности или другие ог раничения, связанные с окружающей средой? • Безопасность. Эта категория требований описывает, как осуществляется дос туп к системе и как осуществляется управление ее данными. Данная категория является подходящим местом для описания, как должны дублироваться систем ные данные. Как часто следует выполнять дублирование? На каких носителях сохраняются дублированные данные? • Документация. Эта категория требований связана с документацией и тем, должна ли она быть представлена в печатном виде или выдается в интерактив ном режиме. Кроме того, здесь же определяется категория лиц, для которых эта документация предназначена. • Устранение неисправностей. Эта категория требований описывает, как сис тема реагирует на возникновение неисправностей. Будет ли система обнару живать неисправность и выдавать аварийные сигналы? Какой должна быть |