Трассировка требований к ПО и требований пользователя

5.3.2. Трассировка требований к ПО и требований пользователя.

Для осуществления проверки требований к ПО и требований пользователя на полноту (поиск всех пропущенных требований), т.е. удовлетворения всех требований пользователя в программном продукте, и отсутствия неоднозначности применяется матрица трассировки.

Соответствие требований проверялось на ранних стадиях ЖЦ программного продукта. Используя матрицу трассировки было установлено полное соответствие между требованиями пользователя и требованиями к ПО, неоднозначности в требованиях обнаружены не были. (см. ТЗ “Матрица трассировки”).

5.3.3. Тестирование внешних функций.

Цель теста внешней функции – найти расхождения между программой и её внешними спецификациями. Необходимым условием успешного тестирования функций является наличие чётких и точных внешних спецификаций. Если внешние спецификации неполны или неоднозначны, результаты тестирования не могут не быть такими же.

Внешние спецификации обычно разбиваются на отдельные внешние функции (например, по типу входных сообщений или команд пользователя), и после тщательного изучения каждой функции строятся тесты. Тесты должны строиться для всех входных условий и вариантов, а также на границах всех областей допустимых значений на входе и области изменения на выходе. Тесты должны также проверять поведение программы у функциональных границ и в случаях и в случаях ввода недопустимых или непредусмотренных данных. Рассмотрим методологию проектирования тестов, основанную на функциональных диаграммах (cause-effect graphing).

Тестирование функций – процесс контроля, поскольку оно обычно выполняется в моделируемой среде (в противоположность обстановке реальной). Другими словами, тестирование функций обычно выполняется для компонент системы прежде, чем она будет собрана воедино. Например, могут быть недоступны определённые устройства ввода-вывода, вследствие чего потребуется написать специальные программы для имитации их работы, могут отсутствовать или быть неполными отдельные компоненты программного обеспечения, что также потребует имитации или применения вспомогательных программ.

Метод функциональных диаграм [11], предлагает способ перевода спецификаций, написанных на естественном языке, на язык формальный. Это способствует проектированию высокорезультативных тестов, не страдающих избыточностью, и обнаруживающих случаи неполноты и неоднозначности во входных спецификациях. Метод предполагает анализ семантического содержания внешних спецификаций и перевод их на язык логических отношений между входными данными (ситуациями) и выходными данными и преобразованиями (эффектами), представленных в виде логической диаграммы (“и- или”-графа), называемой функциональной диаграммой.

Диаграмма снабжается примечаниями в виде синтаксических правил и ограничений внешней среды и затем преобразуется в таблицу решений с ограниченным входом. Каждый столбец таблицы соответствует будущему тесту.

Последовательность применения метода:

¨   Первый шаг: разбить внешние спецификации на отдельные функции, комбинаторные свойства которых и должны тестироваться;

¨   Второй шаг: проанализировать спецификации в поисках всех явных и неявных ситуаций (условия на входе) и эффектов (действия на выходе). Лучше всего делать это, подчёркивая каждую ситуацию и каждый эффект, по мере того как они встречаются при чтении спецификаций. Все ситуации и эффекты нумеруются произвольным образом.

¨   Третий шаг: нарисовать функциональную диаграмму. Ситуации изображаются в виде вершин на левом краю листа бумаги, а эффекты – на правом.

¨   Четвёртый шаг: преобразовать диаграмму в таблицу решений с ограниченным выходом. Для этого нужно выбрать некоторый эффект и записать все комбинации ситуаций, которые его вызывают, затем выписать также состояния всех остальных эффектов при этих комбинациях ситуаций.

5.3.4. Тестирование модуля.

Целью тестирования модуля является нахождение несоответствия между логикой и сопряжениями модуля, с одной стороны, и его внешними спецификациями (описанием функций, входных и выходных дынных, внешних эффектов), с другой стороны. Процесс проектирования тестов для модуля состоит из следующих четырех шагов:

¨   Руководствуясь внешними спецификациями модуля, были подготовлены тесты для каждой ситуации и каждой возможности, для каждой границы областей допустимых значений всех входных данных, областей изменения данных, для всех недопустимых условий.

¨   Был проверен текст программы, чтобы убедиться, что все условные переходы были выполнены в каждом направлении. (Текст программы определялся с использованием созданного логического анализатора).

¨   Для циклов модулей были проведены тесты, соответствующие пути без выполнения тела циклов, с его однократным выполнением и максимальным числом повторений.

¨   Был проверен текст программы на её чувствительность к отдельным особым значениям входных данных и были добавлены соответствующие тесты.

Следует отметить, что компиляцию модуля также можно рассматривать как часть процесса тестирования, поскольку компилятор обнаруживает большинство синтаксических ошибок, а также некоторые семантические и логические ошибки.

В результате реализации данного типа тестирования было зафиксировано, что все условные переходы выполняются в каждом направлении, не происходит “зацикливания” в модуле при граничных значениях индексов циклов, также как и не обнаружено сбоев в работе модуля при невыполнении тела какого-либо из циклов, система реагирует на граничные значения водимых данных корректно.

Похожие работы

Организация обработки информации на ЭВМ по формированию плана поставок готовой продукции

Скачать

28952

3

0

... оно осуществляет свою деятельность, чем больше на предприятие осуществляется поставок, тем более стабильно работает данное предприятие. При осуществлении поставок на предприятие производится обработка и хранение большого количества информации, связанной с поставками, которая в себя включает: своевременное и правильное оформление документов и контроль за каждой операцией поступления товаров от ...

Организация учета и контроля реализации готовой продукции и анализ финансовых результатов от реализации

Скачать

175607

38

8

... продукции для столицы Беларуси. На предприятии внедрены передовые технологии и высокопроизводительное оборудование ведущих отечественных и зарубежных фирм, которые позволяют добиваться высоких производственных показателей. 2. ОРГАНИЗАЦИЯ УЧЕТА И КОНТРОЛЯ РЕАЛИЗАЦИИ ГОТОВОЙ ПРОДУКЦИИ 2.1. Документальное оформление операций по реализации готовой продукции Первичный учет представляет собой ...

Проектирование и разработка информационной системы на примере магазина "Computer Master"

Скачать

29909

2

6

... создания. Ответственность за разработку ТЗ несет основной разработчик. 3.1 Общие сведения Полное наименование АИС: Информационная система по автоматизации учёта товаров и денежных потоков на предприятии «Computer Master». Условное обозначение: АИС – «Computer Master». Разработка ведется на основании договора №1 от 09.11.09 между заказчиком (Виктором Ивановичем директор «Computer Master») ...

Автоматизация учета продажи товаров в ООО Мастер-СД

Скачать

114116

18

0

... существующей технологии можно отнести отсутствие связи с бухгалтерией и таких отчетных форм, как прайс-лист по наличию товаров на складе, т.к. он наглядно показывает наличие замков. 1.5. Постановка задачи автоматизации учета продажи товаров в ООО "Мастер-СД" 1.5.1. Цель автоматизированного решения задачи учета продажи товаров   Назначением реализации проекта "Автоматизация учета продаж в ООО ...