Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 72

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 72)

смотреть полученную документацию продукта и номера рслахозгй; проверить, что библиотеки правильно загружены и правильно используются Итак, теперь понятно, как обращаться с тестами для прецедектов и требований. Но возникает вопрос: "Как тестировать ограничения проектирования?". В части б мы отмечали, что хотя ограничения проектирования имеют свои особенн~ сти, наиболее простым способом их трактовки является просто рассматривать их как требования. Другими словами, их связи трассируются так же и их верификация тоже производится аналогичным образом.

Было бы логично учитывать ограничения проектирования и при проверке правильности и тестировать их наравне со всем остальным. Многие ограничения проектирования тестируются с помощью элементарного просмотра. Например, ограничение, требующее, чтобы программа была написана на Чззцй Ваяс (ЧВ), можно протестировать, просто посмотрев на исходный код.

Так как проверка многих ограничений проектирования будет элементарной, следует иметь для ннх сокращенную процедуру тестирования. Нет необходимости испольэовать сложные формы, перечисляющие калиброванное оборудование, процедуры по устаноа. ке, настройки среды и т.д. Вместо этого можно использовать упрощенную форму, свидетельствукнцую, что была проведена проверка кода нли другого артефакта и обнаружено, что он удовлетворяет ограничению проектирования. Некоторые способы тестирования ограничений проектирования перечислены в табл.

З2.2. 334 тэаеть б. Построение правильной системы Далее... Щафикайкл представляет собой аналитический процесс, выполняемый на всех стадиях разработан проекта с целью убедиться, что вы все делаете правильно. П~оэгрка яраеиемакюк ~оайкяюя) позволяет убедиться, что система работает тэк, как предполагалось, т.е. удовлетворяет как документированным требованиям клиента, так и реальным сценариам использования. Вместе верификация н проверка правильности помогают команде убедитыя, что она действительно "правильно сссщает "правильную" систему". Но кое-что осталось невывсненным. Возникает вопрос: "Как определить, каким должен быть объем работ по верификации и проверке правильности (ЧЙЧ) г".

Ответ на этот вопрос вы найдете в следующей главе. Глава ЗЗ Применение метода анализа дивидендов для определения объема У8сУ-действий Осмоппые пояоженмц ! ° Глубина верификации элемента системы может варьироваться от про-, ' смотра (который обеспечивает минимальную глубину) до сквозного кон-. троля, независимой ревизии, тестирования черного ящика (имитацпи) и прозрачного тестирования (тестирования каждой строки кода). : ° Зона действия (покрытие) отражает, для какой части элементов системы ,' ' . проводится верификация и проверка правильности.

' ° Имеет смысл проводить выборочные испытания, если известно, зачем вы их проводите п в чем состоят риски. " ,° При анализе рисков необходимо принять решеиие о том, какие ошибки . нужно предотвратить и какой объем действий по верификации и проверке ' правильности необходим, чтобы гарантировать, что они не возникнут. Как и все остальное, инициирование и проведение ЧбсЧ-действий требуют определенных затрат. Естественно возникает вопрос: "Как провести анализ затрат/прибыли, чтобы увидеть, действительно ли полученные результаты того стоят?".

Данная глава по может составить план действий по проведению испытаний с помощью неких квазиэкономических понятий для ответа на вопрос о затратах/прибыли. Мы будел~ планировать наши ЧйЧ-действия, исходя из ответов на следующие два вопроса. 1. Какими будут социальные или экономические последствия сбоя системы? 2. Какой необходим объем ЧЙЧ-действий, чтобы гарантировать, что эти последствия не возникнут? Безусловно, не очень приятно по окончании проекта обнаружить, что было проведено слишком много всяких проверок, результаты которых имели для него мпнимзльное значение.

Еще более неприятно. если окажется, что проведенных проверок недостаточно. Это может привести даже к возврату продукта. (Представьте себе, что значит отщ звать первые 10000 экземпляров НО(.1$, которые уже установлены в домах.) Следователыю, нужно постараться найти аналитический подход, который поможет выбрать со. 366 Часть 6. Построение правильной системы ответствующий объем ЧбгЧ-действий до июго, как мы к ним приступим. Мы начнем с рассмотрения вопросов "глубины" и "покрытия '.

Глубина и покрытие ГЛУбИНа У86У Глубина определяет уровень детализации при проведении проверки элелзснта системы. Глубина задает уровень детализации, выбранный для верификации или оценки элемента системы. В среднем, чем болынс глубина, тем больше понадобится времени и средств для выполнения этих действий. Поэтому полезно убедиться, что для каждого элемента выбрана глубина проверки, которая соответствует важности элемента.

Не все элементы нуждаются в одинаковой глубине проверки. Например, для неосновных элементов может быть достаточно просмотра или простого системного теста, а для критических может понадобиться масштабное прозрачное тестирование. В главе 2б, "Неоднозначность и уровень конкретизации," мы говорили, что выбранный уровень конкретизации будет определять как глубину, так и количество задаваемых требований, Выбор правильного уровня конкретизации (глубины) будет также определять и глубину проведения ЧбгЧ. Рассмотрим некоторые методы проверки и предлагаемую ими глубину.

° Просмоязр ~Ехаяилшзои). Просматривается код или осупзествляются некие измерения. Суть просмотра в том, что тестируемые элементы подвергиотся заранее определенному минимально глубокому рассмотрению. Это считается минимальной глубиной проверки элемента. ° Сквозной контроль ~Иайгг)гоиб)з). Осуществляющая проверку гр)тзпа рассматривает все этапы работы элемента. В некотором смысле этот процесс является структурированным просмотром, выполняемым более широкой группой, которая ищет недостатки, упущения и т,п. в коде. Такой тип проверки обеспечивает большую глубину, чем простой просмотр.

° Нсзпвнсиммс )зггизан (!псмузггзг)гзн нчззмшз). Этот метод аналогичен двум предыдущим. Группа независимых специалистов просматривает элемент и выявляет недоработки. В результате такая проверка может высветить дополнительные вопросы, которые пс были замечены группой проекта. ° Тестирование черного ягйиха <б!ас)з-Зох Згзг). В данном случае элемент рассматривается как модуль, внутренняя структура которого неизвестна. Таким образом, можно поставлять сму вводы и наблюдать его выводы, чтобы убедиться, что элемент работает в соответствии с требуемыми стандартамн.

Такие тесты обычно выполняются с помощью специального контрольного кода или системных эмуляторов, а также других средств имитации и записи функционирования систслзы. ° Прозрачное тестиузованис ~шлгуг-Ьох !гз!). Прн таком тестировании позволено "открыть ящик" и исследовать внутрепнес устройство элемента. Большинство моделей кода нмсст слишком много комбинаций возможных вариантов развития Глава ЗЗ. Применение метода анализа дивидендов для определения... ЗЗ7 процесса вычислений, чтобы их можно было протестировать за разумное время. Поэтому, чтобы не тратить па прозрачное тестирование слитвком много времени, необходимо применить к нему некую разумную концепцию тестирования. Общепринятым компромиссом является исследование каждой строки кода, по пс всех возможных комбинаций магистральных путей.

Такой тип проверки ооычно требует значительного объема ресурсов и привлечения дополнительного персонала. ч8с T-покрытие Покрытие определяет, какая часть элементов системы подвергается ве- рификации и проверке правильности. Покрытие (зона действия, аллнтйе) означает степень покрытия элементов системы ЧЗЧ- действиями. Как обсуждалось в предыдущих двух главах, в рамках ЧЗсЧ-деятельттостн можно применить к различным элементам лтетоды трассировки.

Нанример, можно трассировать требования к тестовым примерам, функции к прецедентам, прецеденты к реализации и т.д. Ксяичесшзо задаваемых трзссировок и уровень конкрепюзации требований являются основными факторами при определении ЧЗсЧ-покрытия. Иными словами, нужно ревтить, какие требования (как текстовые, так и в виде прецедентовт, элементы реализации, тестовые примеры и т.д.

необходимо рассмотреть. Кроме того, может понадобиться исследовать, верифицировать н проверить правильность программного обеспечения, поставляемого другими, такого кзк закупаемые компоненты н операционная система, выполняющая приложение. Что подвергать верификации и проверке правильности Итак, при составлении плана ЧЗсЧ необходимо решить, какие элементы следует подвергать верификации и проверке правильности, чтобы создать высококачественный продукт и при этом минимизировать общие затраты на его разработку. Есть несколько способов решения этого вопроса.

Вариант 1. Верифицировать и проверять правильность всех элементов В неболыних проектах, где требуется достаточно высокий уровень качества предоставляемого продукта, можно выполнять ЧзсЧ-процессы практически для всех элементов приложения. Преимущество данного подхода в его понятности и в одинаковой трактовке элементов разработки. Кроме того, не нужно проводить анализ перед началом разработки и строить предположения относительно стоимостных элелтентов ЧЗсЧ.

При выборе такой политики команда вскоре приходит к соглашению, что пст ттсобходплюсти проводить испьггаиия некоего элемента, посколъку он слив~колл тривиален, чтобы о нем беспокоиться. В принципе, такой подход допустим, но, как правило, такнс решения чаще принимгются, когда исчерпывается бюджет или подходит к концу отведенный срок. 338 Часть 6. Построеыне правильной системы Допустимо выборочное проведение ЧКсЧ, если известно, в чем состоят риски. Выборочное проведение ЧЗсЧ допустимо в тех случаях, когда известно, почему оыи проводятся и в чем состоят риски.

Характеристики

Список файлов книги