Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 71
Текст из файла (страница 71)
Эта информация обеспечнвается трассировкой. Трассировка при проверке правильности Прн проверке правнльностн трасснровка должна ответить на два важных вопроса. 1. Достаточно лн тестов, чтобы проверить все, что нуждается в тестировании? 2. Нет лн лнщннх нлн ненужных тестов? В процессе провсркн правильности выясняется, действительно лн продукт работает так, как предполагалось. На этом этапе болыпе не проверяются отношения рэзлнчных спецификаций н элементов проектирования; вместо этого рассматриваются отттощення между тестами (н нх результатами) н тестируемой системой.
Как н прн верификации, цель состоит в том, чтобы удостовериться, что все элементы, которые в этом нуждаются, тестируются на соответствне требованиям. Основанное на требованиях тестирование Как определить, что нуждается в тестнрованнн? Один достаточно распространенный подход заключается в тестировании продукта посредством проверки правильности реалнзацнн содержащихся в нем функций. Зачастую к тестированию подходят следующим образом: "Вот некая выполняемая ф)чткцня, скажем менеджер базы данных, протестнруем ее с помощью шггерфейсов менеджера базы данных". Хотя такой подход н правомерен, все же оп выполняет только половнну работы.
328 Часть 6. Построение правилыюй системы Высокого качества можно добиться, только протестировав систему на соответствие ее требованиям. Рабочий пример. Тестирование прецедентов Написание тестовых примеров, как и сбор требований, является одновременно и наукой, н искусством. Нзм не хотелось бы исследовать данный предмет чересчур глубоко, однако бу. дет полезно хотя бы в общих чертах рассмотреть, как составляются тестовые примеры на основании функциональных воэможностей, представленных прецедентами и требованиями, с помощью которых мы описали систему, Для этого вернемся к нашему рабочему примеру и рассмотрим разработанный в части 5 прецедент "Управление освещением".
Описание тестового примера 1 В табл. 32.1 представлен образец тестового примера для прецедента "Управление освещением". Тестовый пример 1 предназначен для тестирования экземпляров прецедента "Управление освещением". Он используется только для тестирования тех кнопок пульта (Управление включением), которые отвечают эа набор осветительных приборов, допускающих изменение яркости. Таблица 32.1. Тестовый пример 1 (упрощенное представление) 1В ситуации Описание события Ввод! Ввод 2 Ожидаемый результат Осиаевей вееиж Жилец нажи- 200! Любая допустимая кнопка Перел нажатием ююпки свет был включен (тестолог должен запомнить уровень).
Свет мает кнопку пульта выключается Перед нажатием кнопки свет был зы- Свет включается с уровнем ярко- спю Ов!.ете1 ключен Чтобы добиться высокого качества, необходимо протестировать систему на соотвег ствие требсванвам. Конечно, может оказаться полезным провести тестирование модулей для различных элементов проекта, таких как менеджер базы данных. Но тестирование отдельных модулей не может гарантировать, что сксжема е целом работает так, как нужно.
Многие сложные разработки успешно проходили все тесты модулей, но не выдерживали испытаний в качестве системы. Почему? Потому, что модули взаимодействуют в более сложных вариантах поведения, а результирующая система не была адекватно протестирована на соответствие системным требованиям. Посмотрим, как можно использовать методы, разработанные нами применительно к верификации, для проверки правильности системы. Вернемся к рассмотрению нашего рабочего примера.
Окоячати таба. 32. ! Ожидаемый результат Ввод 2 1В ситуацмн Описание Ввод 1 событии Остается выключенным Жилец отпус- кает кнопку в течение 1 секунды Свет включен Остается валю. ченныи с прежнин уровнем яр. кости (Оп1.стс1) Свет выключен Та же кнопка, что Перед этим свет выи в 200$ каючсн Жилец пажи. наст кнопку снова и отпус- кает в течение 1 секунды. Свет включается с тем же уров- нем яркости, что н в 2002 Свет выключа- ется Жилец ншки- нает кнопку вновь н отпус- кает в течение 1 секунды Перед этны свет вюпочсн Автбэяаткэамй ясттг Допустииая кнопка Перед этии свет вы- ключен Кнопка удср.
жиаается в на- патон положе. нин дольше 1 секунды Жилец отпускает кнопку Яркость остается иа последнем достипсутом уровне Залсчаэаи. Тест выполняется много раз при разнои времени нажатия кнопки, чтобы проверить, что система правильно эапоиннает уровень яркости Оп1.сэе1. Жилец отпус- кает кнопку в течение 1 секунды. (Этим закан. чнвается пер- вый путь пре- цедента.) Глава 32. Проверка правильности системы 329 Свет включает- ся.
Яркость воз- растает до мак- симального уровня (по 10% в секунду), а за- теи убывает (по 10% в секунду) до минимально- го уровня, после чего снова воз- растает. 1(нклы иродолааются, пока нажата кнопка 330 Часть 6. Построение правильной системы Тестовый прил~ер 1 предназначен для тестирования взаимодействий с системой, кс» торые достаточно точно имитируют реальный поток событий, описанный в прецеденте ткправлепие освещением". Таким образом, прецедент служит шаблоном того, как тестировать систему. Это одно из основных преимуществ метода прецедентов. Полная версия этого тестового примера приводится в приложении А нместе с другими артефактами системы НО).1$.
Тестовый пример 2, описанный в приложепинА, предназначен для тестирования целого набора дискретных требований, а не отдельного прецедента. Мы рассмотрим оба тестовых примера в следующем разделе, посвященном трассировке. Трассировка тестовых примеров Трассировка помогает убедиться, что тестовые примеры покрывают все требуемые функциональные возможности. Методы трассировки позволяют убедиться, что тестовые примеры полностью покрывают все необходимые функциональные возможности системы.
Нужно просто создать последовательности планов тестирования, которые можно связать с исходными систем. ными требованиями и прецедептамп. Предположим, у нас имеется матрица трассировки, сопоставляющая тесты и прецеденты (рис. 32.2). Так же, как и при проведении верификации, можно исследовать дан. пую матрицу, чтобы убедиться, что тестовые примеры надлежащим образом покрывают все системные спецификации. Аналогично можно связать тестовые примеры с прецедентами, как зто показано на рис. 32.3. Рис. 33.3.
Тесты и и)мяедентм Тестирование дискретных требований Мы использовали отношения трассировки, чтобы связать прецеденты с тестовыми примерами. Трассировку можно также применять для задания отношений л|ежду дискретными (обособленными) требованиями и последующего пх связывания с тестовыми примерами. 11а рнс. 32.4 показан фрагмент матрицы трассировки тестовых примеров. В Глава 32. Проверка правильности системы 331 нем присутствует тестовый пример 2 ("ТС2. Двустороннее сооГ>щснис..."), который свя.
зан с требованиями к программному обеспечению ЬК5-пакета 110!.1Б. Заметим, что трактовка тестовых примеров нс отличается от трактовки других элементов, трассирусмых при верификации и проверке правильности. сыс. 32З. Прови) виты и тес>поные нрав>еры 1>»с. 32.4. Фромены мптривы трассиротси тестовых приперев Итак, мы внесли тестовые примеры в матрицы трассировки. Теперь нужно исследовать заданные связи, как это делалось при верификационных просмотрах. Пропущенные отношения проверки правильности Для выявления пропущенных отношений нужно искать сн>1>оки матрицы трассировки, нз которых видно, что определенная функция (или трсГ>ованис) не связана ни с какил> тестом. На рис.
32.5, например, прсцсдснт 2 (1>С2) не связан нп с олним тестовым прил>ерим (ТС). (Связи для прецедента 1)СЗ тоже отс)тствуют, но в процессе верификации л>ы уже пришли к решению, что данный прецедент вообще нс нужен.) 332 Часть б, Построение правильной системы эЪс. 33.5. эураяуяэеиный тестовый пример Выявив такую "дыру" в отношениях, необходимо проверить исходный набор требс» вани й к продукту и соответствующие прецеденты. ° Если окажется, что связь случайно пропущена при задании трассировки, нужно просто добавить новую связь и пересчитать матрицу трассировки. Подобные пропуски часто возникают на ранних стадиях задания трассировки проверки правильности.
В Если обнаружится, что при разработке тестовых примеров просто не удалось протестировать одну из необходимых функций продукта, может понадобиться пересмотреть проект, чтобы добавить подходящие тесты, соответству|ощие данной функции. В от. личие от аналогичного случая прн верификации, мы яе )Эекаиендукк отмечать прону. щепные тестовые примеры как "будущие" действия. Если есть непротестнрованная функция, можно не сомневаться, что закаэчик будет ее тестировать (часто с неприят.
нылщ для вас последствиями). Кроме того, регулируемые разработки, такие как контролируемая Р)ЭА разработка программного обеспечения для медицинских целей, пе допускают откладывания проведения необходимых тестов. При проверке правильности трассировка помогает удостовериться, что никакие связи не пропущены и все тесты продукта надлежащим образом связаны с более высоко. уровневыми требованиями к продукту. "Лишние" отношения проверки правильности Как и при верификации, в ходе проверки правильности можно при просмотре сюолбкок трассировочной матрицы обнаружить столбцы, пе связанные ни с одним элементом строки. Например, па рис. 32.3 тестовый пример 3 (ТС3) пе связан ни с одним прецедентом.
Из рис. 32.4 также видно, что он не связан ни с каким программным требованием. Это означает, что был создан тестовый пример, для которого не существует связанной с ним функции продукта. Иначе говоря, тест выглядит лищним, Как и ранее, следует рассмотреть отношения трассировки. ° Возможно, связь была случайно пропущена при задании трассировки.
Если так, нужно просто добавить новую связь и пересчитать матрицу трассировки. Такие пропуски часто возникают на ранних стадиях задания трассировки проверки правильности. Глава З2. Проверка правильности системы ЗЗЗ ° Может оказаться, что при разработке функций продукта просто не были учтены потребности одного из необходимых программных тестов. Это может произойти в том случае, если определенные нефункциональные требования к реализации фактически меняют функции продукта.
Тогда может понадобиться пересмотреть проект, чтобы учесть досгижимость и необходимость требований. Как н при верификации, команде нужно будет принять рещение, нужен ли данный тест вообще и, если нужен, какие трассировочные связи необходимы. Тестирование ограничений проектирования Таблица З2.2. Способы проверки ограничений проектирования Способ проверки Ограничеииепроектнрования "Писать программу на ЧВ З.О" "Приложение должно осноаыаагыя на архи- тектурных шаблонах Рнй Рго~есс" "Использовать библиотеку классов Веге!орег'з Бйогагу 99-724 корпорации ХЪ'Е Со~рогасюп" Проверить исходный код Выявить жаблоны моделей проектирования Рнрй сравнить с архитектурой теьущего проекта Проверить записи о заказах и получении; про.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
