Файл: Методические указания по организации практических занятий и самостоятельной работы по мдк. 02. 01 Технология разработки программного обеспечения.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 11.01.2024
Просмотров: 588
Скачиваний: 5
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
{А = 3, В = 0, Х = 3} — в первом случае и {А = 2, В = 1, Х = 1} — во втором. Однако путь, где X не меняется, будет проверен с вероятностью 50 %: если во втором условии вместо условия Х > 1 записано Х < 1, то ошибка не будет обнаружена двумя тестами.
Результаты тестирования приведены в таблице.
Таблица. Результат тестирования методом покрытия решений
Пример метода покрытия условий
В рассматриваемом примере имеем условия: {А> 1, B = 0}, {А = 2, Х> 1}. Следовательно, требуется достаточное число тестов, такое, чтобы реализовать ситуации, где А > 1, А < 1, В= О и В<> 0 в точке а и А = 2, А<> 2, Х> 1 и Х< 1 в точке b. Тесты, удовлетворяющие критерию покрытия условий, и соответствующие им пути:
а) А = 2, B = 0, Х=4 АСЕ;
б) А = 1, B = 1, Х=0 АBD.
Таблица. Результаты тестирования методом покрытия условий
Метод покрытия решений/условий
Так, в рассматриваемом примере два теста метода покрытия условий
а) А = 2, B = 0, Х = 4 АСЕ;
б) A = 1, В = 1, Х = 0 ABD
отвечают и критерию покрытия решений/условий. Это является следствием того, что одни условия приведенных решений скрывают другие условия в этих решениях. Так, если условие А > 1 будет ложным, транслятор может не проверять условия B=0, поскольку при любом результате условия ,B=0 результат решения ((А> 1)&(B=0)) примет значение ложь. То есть в варианте на рисунке не все результаты всех условий выполнятся в процессе тестирования.
Рассмотрим реализацию того же примера. Наиболее полное покрытие тестами в этом случае осуществляется так, чтобы выполнялись все возможные результаты каждого простого решения. Для этого нужно покрыть пути ACEG (тест А = 2, B=0, X=4), ACDFH (тест A = 3, B= 1,X=0), ABFH (тест A = 0, B = 0, Х= 0), ABFI (тест А = 0, B= 0, Х= 2).
Протестировав алгоритм на рисунке выше, нетрудно убедиться в том, что критерии покрытия условий и критерии покрытия решений/условий недостаточно чувствительны к ошибкам в логических выражениях.
Метод комбинаторного покрытия условий
В рассматриваемом примере должны быть покрыты тестами следующие восемь комбинаций:
1. A > 1, B = 0.
2. A > 1,B <> 0.
3. A < 1, B = 0.
4. A < 1, B <> 0.
5. А = 2, Х > 1.
6. А = 2, Х < 1.
7. А <> 2, Х > 1.
8. A <> 2, X < 1.
Для того чтобы протестировать эти комбинации, необязательно использовать все 8 тестов. Фактически они могут быть покрыты четырьмя тестами
• А = 2, B= 0, Х= 4 {покрывает 1, 5};
• А = 2, B= 1, Х= 1 {покрывает 2, 6};
• А = 0,5, B = 0, Х= 2 {покрывает 3, 7};
•A=1, B=0, Х= 1 {покрывает 4, 8}.
Таблица. Результаты тестирования методом комбинаторного покрытия условий
Задание самостоятельной работы
В соответствии с индивидуальным вариантом, выбрать алгоритм для тестирования, обозначить буквами или цифрами ветви этих алгоритмов. Выписать пути алгоритма, которые должны быть проверены тестами для выбранного метода тестирования. Записать тесты, которые позволят пройти по путям алгоритма. Протестировать разработанную вами программу. Результаты оформить в виде таблицы:
Перечень индивидуальных вариантов приведен в приложении В.
Контрольные вопросы
Оценка программных средств с помощью метрик
Цель: знакомство с ГОСТ 28195-89 «Оценка качества программных средств. Общие положения»; определить способы получения информации о ПС; формирование информационно-правовых компетенции обучающихся.
Форма отчета:
−выполнить задание;
−показать преподавателю;
−ответить на вопросы преподавателя.
Теоретические сведения
Необходимая документация: ГОСТ 28.195-89
Одной из важнейших проблем обеспечения качества программных средств является формализация характеристик качества и методология их оценки. Для определения адекватности качества функционирования, наличия технических возможностей программных средств к взаимодействию, совершенствованию и развитию необходимо использовать стандарты в области оценки характеристик их качества.
Показатели качества программного обеспечения устанавливают ГОСТ 28.195-89 «Оценка качества программных средств. Общие положения» и ГОСТ Р ИСО/МЭК 9126 «Информационная технология. Оценка программной продукции. Характеристика качества и руководства по их применению». Одновременное существование двух действующих стандартов, нормирующих одни и те же показатели, ставит вопрос об их гармонизации. Ниже рассмотрим каждый из перечисленных стандартов.
ГОСТ 28.195-89 «Оценка качества программных средств. Общие положения» устанавливает общие положения по оценке качества программных средств, номенклатуру и применяемость показателей качества.
Оценка качества ПС представляет собой совокупность операций, включающих выбор номенклатуры показателей качества оцениваемого ПС, определение значений этих показателей и сравнение их с базовыми значениями.
Методы определения показателей качества ПС различаются: по способам получения информации о ПС – измерительный, регистрационный, органолептический, расчетный; по источникам получения информации – экспертный, социологический.
Измерительный метод основан на получении информации о свойствах и характеристиках ПС с использованием инструментальных средств. Например, с использованием этого метода определяется объем ПС - число строк исходного текста программ и число строк - комментариев, число операторов и операндов, число исполненных операторов, число ветвей в программе, число точек входа (выхода), время выполнения ветви программы, время реакции и другие показатели.
Регистрационный метод основан на получении информации во время испытаний или функционирования ПС, когда регистрируются и подсчитываются определенные события, например, время и число сбоев и отказов, время передачи управления другим модулям, время начала и окончания работы.
Органолептический метод основан на использовании информации, получаемой в результате анализа восприятия органов чувств (зрения, слуха), и применяется для определения таких показателей как удобство применения, эффективность и т. п.
Расчетный метод основан на использовании теоретических и эмпирических зависимостей (на ранних этапах разработки), статистических данных, накапливаемых при испытаниях, эксплуатации и сопровождении ПС. При помощи расчетного метода определяются длительность и точность вычислений, время реакции, необходимые ресурсы.
Определение значений показателей качества ПС экспертным методом осуществляется группой экспертов-специалистов, компетентных в решении данной задачи, на базе их опыта и интуиции. Экспертный метод применяется в случаях, когда задача не может быть решена никаким другим из существующих способов или другие способы являются значительно более трудоемкими. Экспертный метод рекомендуется применять при определении показателей наглядности, полноты и доступности программной документации, легкости освоения, структурности.
Социологические методы основаны на обработке специальных анкет-вопросников.
Показатели качества объединены в систему из четырех уровней. Каждый вышестоящий уровень содержит в качестве составляющих показатели нижестоящих уровней (рисунок 1).
Стандарт ИСО 9126 (ГОСТ Р ИСО/МЭК 9126) «Информационная технология. Оценка программной продукции. Характеристика качества и руководства по их применению».
Определенные настоящим стандартом характеристики дополнены рядом требований по выбору метрик и их измерению для различных проектов ПС. Они применимы к любому типу ПС, включая компьютерные программы и данные, содержащиеся в программируемом оборудовании. Эти характеристики обеспечивают согласованную терминологию для анализа качества ПС. Кроме того, они определяют схему для выбора и специфицирования требований к качеству ПС, а также для сопоставления возможностей различных программных продуктов, таких как функциональные возможности, надежность, практичность и эффективность.
Все множество атрибутов качества ПС может быть классифицировано в структуру иерархического дерева характеристик и субхарактеристик. Самый высший уровень этой структуры состоит из характеристик качества, а самый нижний уровень – из их атрибутов. Эта иерархия не строгая, поскольку некоторые атрибуты могут быть связаны с более чем одной субхарактеристикой. Таким же образом, внешние свойства (такие, как пригодность, корректность, устойчивость к ошибкам или временная эффективность) влияют на наблюдаемое качество. Недостаток качества в использовании (например, пользователь не может закончить задачу) может быть прослежен к внешнему качеству (например, функциональная пригодность или простота использования) и связанным с ним внутренним атрибутам, которые необходимо изменить.
Внутренние метрики могут применяться в ходе проектирования и программирования к неисполняемым компонентам ПС (таким, как спецификация или исходный программный текст). При разработке ПС промежуточные продукты следует оценивать с использованием внутренних метрик, которые измеряют свойства программ, и могут быть выведены из моделируемого поведения. Основная цель внутренних метрик – обеспечивать, чтобы было достигнуто требуемое внешнее качество. Внутренние метрики дают возможность пользователям, испытателям и разработчикам оценивать качество ЖЦ программ и заниматься вопросами технологического обеспечения качества задолго до того, как ПС становится готовым исполняемым продуктом.
Внутренние метрики позволяют измерять внутренние атрибуты или формировать признаки внешних атрибутов путем анализа статических свойств промежуточных или поставляемых программных компонентов. Измерения внутренних метрик используют категории, числа или характеристики элементов из состава ПС, которые, например, имеются в процедурах исходного программного текста, в графе потока управления, в потоке данных и в представлениях изменения состояний памяти. Документация также может оцениваться с использованием внутренних метрик.
Внешние метрики используют меры ПС, выведенные из поведения системы, частью которых они являются, путем испытаний, эксплуатации или наблюдения исполняемого ПС или системы. Перед приобретением или использованием ПС его следует оценить с использованием метрик, основанных на деловых и профессиональных целях, связанных с использованием, эксплуатацией и управлением продуктом в определенной организационной и технической среде. Внешние метрики обеспечивают заказчикам, пользователям, испытателям и разработчикам возможность определять качество ПС в ходе испытаний или эксплуатации.
Результаты тестирования приведены в таблице.
Таблица. Результат тестирования методом покрытия решений
Пример метода покрытия условий
В рассматриваемом примере имеем условия: {А> 1, B = 0}, {А = 2, Х> 1}. Следовательно, требуется достаточное число тестов, такое, чтобы реализовать ситуации, где А > 1, А < 1, В= О и В<> 0 в точке а и А = 2, А<> 2, Х> 1 и Х< 1 в точке b. Тесты, удовлетворяющие критерию покрытия условий, и соответствующие им пути:
а) А = 2, B = 0, Х=4 АСЕ;
б) А = 1, B = 1, Х=0 АBD.
Таблица. Результаты тестирования методом покрытия условий
Метод покрытия решений/условий
Так, в рассматриваемом примере два теста метода покрытия условий
а) А = 2, B = 0, Х = 4 АСЕ;
б) A = 1, В = 1, Х = 0 ABD
отвечают и критерию покрытия решений/условий. Это является следствием того, что одни условия приведенных решений скрывают другие условия в этих решениях. Так, если условие А > 1 будет ложным, транслятор может не проверять условия B=0, поскольку при любом результате условия ,B=0 результат решения ((А> 1)&(B=0)) примет значение ложь. То есть в варианте на рисунке не все результаты всех условий выполнятся в процессе тестирования.
Рассмотрим реализацию того же примера. Наиболее полное покрытие тестами в этом случае осуществляется так, чтобы выполнялись все возможные результаты каждого простого решения. Для этого нужно покрыть пути ACEG (тест А = 2, B=0, X=4), ACDFH (тест A = 3, B= 1,X=0), ABFH (тест A = 0, B = 0, Х= 0), ABFI (тест А = 0, B= 0, Х= 2).
Протестировав алгоритм на рисунке выше, нетрудно убедиться в том, что критерии покрытия условий и критерии покрытия решений/условий недостаточно чувствительны к ошибкам в логических выражениях.
Метод комбинаторного покрытия условий
В рассматриваемом примере должны быть покрыты тестами следующие восемь комбинаций:
1. A > 1, B = 0.
2. A > 1,B <> 0.
3. A < 1, B = 0.
4. A < 1, B <> 0.
5. А = 2, Х > 1.
6. А = 2, Х < 1.
7. А <> 2, Х > 1.
8. A <> 2, X < 1.
Для того чтобы протестировать эти комбинации, необязательно использовать все 8 тестов. Фактически они могут быть покрыты четырьмя тестами
• А = 2, B= 0, Х= 4 {покрывает 1, 5};
• А = 2, B= 1, Х= 1 {покрывает 2, 6};
• А = 0,5, B = 0, Х= 2 {покрывает 3, 7};
•A=1, B=0, Х= 1 {покрывает 4, 8}.
Таблица. Результаты тестирования методом комбинаторного покрытия условий
Задание самостоятельной работы
В соответствии с индивидуальным вариантом, выбрать алгоритм для тестирования, обозначить буквами или цифрами ветви этих алгоритмов. Выписать пути алгоритма, которые должны быть проверены тестами для выбранного метода тестирования. Записать тесты, которые позволят пройти по путям алгоритма. Протестировать разработанную вами программу. Результаты оформить в виде таблицы:
Перечень индивидуальных вариантов приведен в приложении В.
Контрольные вопросы
-
Что такое тестирование по принципу «белого ящика»? -
Назовите критерии покрытия кода. -
Что такое метод покрытия операторов? -
Что такое метод покрытия решений (покрытия переходов)? -
Что такое метод покрытия условий? -
Что такое метод покрытия решений/условий?
Практическая работа №9
Оценка программных средств с помощью метрик
Цель: знакомство с ГОСТ 28195-89 «Оценка качества программных средств. Общие положения»; определить способы получения информации о ПС; формирование информационно-правовых компетенции обучающихся.
Форма отчета:
−выполнить задание;
−показать преподавателю;
−ответить на вопросы преподавателя.
Теоретические сведения
Необходимая документация: ГОСТ 28.195-89
Одной из важнейших проблем обеспечения качества программных средств является формализация характеристик качества и методология их оценки. Для определения адекватности качества функционирования, наличия технических возможностей программных средств к взаимодействию, совершенствованию и развитию необходимо использовать стандарты в области оценки характеристик их качества.
Показатели качества программного обеспечения устанавливают ГОСТ 28.195-89 «Оценка качества программных средств. Общие положения» и ГОСТ Р ИСО/МЭК 9126 «Информационная технология. Оценка программной продукции. Характеристика качества и руководства по их применению». Одновременное существование двух действующих стандартов, нормирующих одни и те же показатели, ставит вопрос об их гармонизации. Ниже рассмотрим каждый из перечисленных стандартов.
ГОСТ 28.195-89 «Оценка качества программных средств. Общие положения» устанавливает общие положения по оценке качества программных средств, номенклатуру и применяемость показателей качества.
Оценка качества ПС представляет собой совокупность операций, включающих выбор номенклатуры показателей качества оцениваемого ПС, определение значений этих показателей и сравнение их с базовыми значениями.
Методы определения показателей качества ПС различаются: по способам получения информации о ПС – измерительный, регистрационный, органолептический, расчетный; по источникам получения информации – экспертный, социологический.
Измерительный метод основан на получении информации о свойствах и характеристиках ПС с использованием инструментальных средств. Например, с использованием этого метода определяется объем ПС - число строк исходного текста программ и число строк - комментариев, число операторов и операндов, число исполненных операторов, число ветвей в программе, число точек входа (выхода), время выполнения ветви программы, время реакции и другие показатели.
Регистрационный метод основан на получении информации во время испытаний или функционирования ПС, когда регистрируются и подсчитываются определенные события, например, время и число сбоев и отказов, время передачи управления другим модулям, время начала и окончания работы.
Органолептический метод основан на использовании информации, получаемой в результате анализа восприятия органов чувств (зрения, слуха), и применяется для определения таких показателей как удобство применения, эффективность и т. п.
Расчетный метод основан на использовании теоретических и эмпирических зависимостей (на ранних этапах разработки), статистических данных, накапливаемых при испытаниях, эксплуатации и сопровождении ПС. При помощи расчетного метода определяются длительность и точность вычислений, время реакции, необходимые ресурсы.
Определение значений показателей качества ПС экспертным методом осуществляется группой экспертов-специалистов, компетентных в решении данной задачи, на базе их опыта и интуиции. Экспертный метод применяется в случаях, когда задача не может быть решена никаким другим из существующих способов или другие способы являются значительно более трудоемкими. Экспертный метод рекомендуется применять при определении показателей наглядности, полноты и доступности программной документации, легкости освоения, структурности.
Социологические методы основаны на обработке специальных анкет-вопросников.
Показатели качества объединены в систему из четырех уровней. Каждый вышестоящий уровень содержит в качестве составляющих показатели нижестоящих уровней (рисунок 1).
Стандарт ИСО 9126 (ГОСТ Р ИСО/МЭК 9126) «Информационная технология. Оценка программной продукции. Характеристика качества и руководства по их применению».
Определенные настоящим стандартом характеристики дополнены рядом требований по выбору метрик и их измерению для различных проектов ПС. Они применимы к любому типу ПС, включая компьютерные программы и данные, содержащиеся в программируемом оборудовании. Эти характеристики обеспечивают согласованную терминологию для анализа качества ПС. Кроме того, они определяют схему для выбора и специфицирования требований к качеству ПС, а также для сопоставления возможностей различных программных продуктов, таких как функциональные возможности, надежность, практичность и эффективность.
Все множество атрибутов качества ПС может быть классифицировано в структуру иерархического дерева характеристик и субхарактеристик. Самый высший уровень этой структуры состоит из характеристик качества, а самый нижний уровень – из их атрибутов. Эта иерархия не строгая, поскольку некоторые атрибуты могут быть связаны с более чем одной субхарактеристикой. Таким же образом, внешние свойства (такие, как пригодность, корректность, устойчивость к ошибкам или временная эффективность) влияют на наблюдаемое качество. Недостаток качества в использовании (например, пользователь не может закончить задачу) может быть прослежен к внешнему качеству (например, функциональная пригодность или простота использования) и связанным с ним внутренним атрибутам, которые необходимо изменить.
Внутренние метрики могут применяться в ходе проектирования и программирования к неисполняемым компонентам ПС (таким, как спецификация или исходный программный текст). При разработке ПС промежуточные продукты следует оценивать с использованием внутренних метрик, которые измеряют свойства программ, и могут быть выведены из моделируемого поведения. Основная цель внутренних метрик – обеспечивать, чтобы было достигнуто требуемое внешнее качество. Внутренние метрики дают возможность пользователям, испытателям и разработчикам оценивать качество ЖЦ программ и заниматься вопросами технологического обеспечения качества задолго до того, как ПС становится готовым исполняемым продуктом.
Внутренние метрики позволяют измерять внутренние атрибуты или формировать признаки внешних атрибутов путем анализа статических свойств промежуточных или поставляемых программных компонентов. Измерения внутренних метрик используют категории, числа или характеристики элементов из состава ПС, которые, например, имеются в процедурах исходного программного текста, в графе потока управления, в потоке данных и в представлениях изменения состояний памяти. Документация также может оцениваться с использованием внутренних метрик.
Внешние метрики используют меры ПС, выведенные из поведения системы, частью которых они являются, путем испытаний, эксплуатации или наблюдения исполняемого ПС или системы. Перед приобретением или использованием ПС его следует оценить с использованием метрик, основанных на деловых и профессиональных целях, связанных с использованием, эксплуатацией и управлением продуктом в определенной организационной и технической среде. Внешние метрики обеспечивают заказчикам, пользователям, испытателям и разработчикам возможность определять качество ПС в ходе испытаний или эксплуатации.