Скачать презентацию Tarkvara kvaliteed ja standardid 6 Качество и стандарты Скачать презентацию Tarkvara kvaliteed ja standardid 6 Качество и стандарты

659b35e1902029277ab967ea40b8a002.ppt

  • Количество слайдов: 41

Tarkvara kvaliteed ja standardid. 6 Качество и стандарты программного обеспечения L. Joonas 2004 Tarkvara kvaliteed ja standardid. 6 Качество и стандарты программного обеспечения L. Joonas 2004

Инспекция ПО Инспекция ПО

Задачи V&V • Verification & validation должны подтвержать то, что ПО отвечает своим задачам Задачи V&V • Verification & validation должны подтвержать то, что ПО отвечает своим задачам • Это не означает то, что ПО совершенно не имеет дефектов • Тем не менее, онго должно быть достаточно хорошо для предполагаемого использования и тип использования должен определять уровень необходимой ответственности

Конфиденциальность V & V • Зависит от целей системы, ожиданий пользователя и маркетингового окружения Конфиденциальность V & V • Зависит от целей системы, ожиданий пользователя и маркетингового окружения – Функции ПО • Уровень достоверности (конфиденциальности) зависит от того, насколько критично ПО для организации – Ожидания пользователя • Пользователи могут мало ожидать от некоторых видов ПО – Маркетинговое окружение • Выпуск продукта на рынок раньше может быть важнее, чем нахождение дефектов программ

Тестирование и отладка • Тестирование дефектов и отладка – два абсолютно различных процесса • Тестирование и отладка • Тестирование дефектов и отладка – два абсолютно различных процесса • Verification + validation касаются установления существования дефектов в программах • Отладка занимается локализацией и устранением этих дефектов

Процесс отладки Процесс отладки

Планирование V & V • Аккуратное планирование необходимо для получения максимального результата от тестирования Планирование V & V • Аккуратное планирование необходимо для получения максимального результата от тестирования и инспекции • Планирование должно начинаться как можно раньше в процессе разработки • План должен определить баланс между статической верификацией и тестированием • Планирование тестов – это скорее определение стандартов для процесса тестирования, чем описание тестов

V-образная модель развития V-образная модель развития

Структура плана тестирования ПО • Процесс тестирования • Возможность отслеживания требований • Тестируемые единицы Структура плана тестирования ПО • Процесс тестирования • Возможность отслеживания требований • Тестируемые единицы • График тестирования • Процедура записи тестов • Аппаратные и программные требования • Ограничения

Инспекции ПО • Позволяет экзаменовать код с целью нахождения там аномалий и дефектов • Инспекции ПО • Позволяет экзаменовать код с целью нахождения там аномалий и дефектов • Не требуется работоспособности всей системы, так что может быть использовано до внедрения • Может быть испольовано для любого представления системы (требования, дизайн, тестовые данные и т. д. ) • Очень эффективная методика поиска ошибок

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

Инспекции и тестирование • Инспекции и тестирование дополняют друга • Обе методики могут быть Инспекции и тестирование • Инспекции и тестирование дополняют друга • Обе методики могут быть использованы во время процесса V & V • Инспекции могут проверить соответствие спецификации, но не реальные требования пользователя • Инспекции не могут проверить нефункциональные характеристики, такие как производительность, юзабильность и т. д.

Инспекции программ • Формальные методики для просмотра документов • Предназначены для нахождения дефектов, но Инспекции программ • Формальные методики для просмотра документов • Предназначены для нахождения дефектов, но не для их исправления • Дефекты могут быть логическими ошибками, аномалиями кода, которые могут соответствовать ошибочным ситуациям (например, неописанные переменные) или несоответствия стандартам

Предусловия инспекции • Необходимо наличие точной спецификации • Члены команды должны быть знакомыми со Предусловия инспекции • Необходимо наличие точной спецификации • Члены команды должны быть знакомыми со стандартами организации • Должен быть достeпен синтаксически корректный код • Должен быть подготовлен чек-лист ошибок • Руководство должно осознавать, что инспекции увеличивают стоимость разработки на раннем этапе • Руководство не должно использовать инспекции для оценки персонала

Процесс инспекции Процесс инспекции

Процедура инспекции • Инспекционной команде представляют обзор системы • Между членами инспекционной команды распределяется Процедура инспекции • Инспекционной команде представляют обзор системы • Между членами инспекционной команды распределяется код и связанные с ним документы • Проводится инспекция и отмечаются обнаруженные ошибки • Осуществляется доработка всоответствии с найденными ошибками • Может быть проведена повторная инспекция

Инспекционная команда • Состоит по меньшей мере из 4 человек: • Автор инспектруемого кода Инспекционная команда • Состоит по меньшей мере из 4 человек: • Автор инспектруемого кода • Инспектор, который находит ошибки и несоответствия • Ридера, который читает код команде • Модератора, оторый ведет собрание и отмечает ображенные ошибки • Секретарь и Главный модератор

Расчет скорости работы • 90 -125 операторов в час • Дорогостоящий процесс • Проверка Расчет скорости работы • 90 -125 операторов в час • Дорогостоящий процесс • Проверка 500 строк стоит примерно 40 человеко-часов

Automated static analysis • Static analysers are software tools for source text processing • Automated static analysis • Static analysers are software tools for source text processing • They parse the program text and try to discover potentially erroneous conditions and bring these to the attention of the V & V team • Very effective as an aid to inspections. A supplement to but not a replacement for inspections

Static analysis checks Static analysis checks

Тестирование структуры программных компонентов Тестирование структуры программных компонентов

Принципы тестирования структуры программных компонентов • Цель – проверка корректности выделенных маршрутов исполнения программ Принципы тестирования структуры программных компонентов • Цель – проверка корректности выделенных маршрутов исполнения программ и обнаружение логических ошибок формирования маршрутов • На практике до 50% маршрутов оказываются пропущенными при тестировании • Первая задача – получение информации о полной совокупности реальных маршрутов исполнения

Сложность программы • Определяется числом взаимодействующих компонентов, числом связей между компонентами и сложностью их Сложность программы • Определяется числом взаимодействующих компонентов, числом связей между компонентами и сложностью их взаимодействия • Зависит, в первую очередь, от числа отдельных путей исполнения программы • Определяет сложность тестирования

Сложность тестирования • Большое число маршрутов обработки информации в программах • Графовые модели программ Сложность тестирования • Большое число маршрутов обработки информации в программах • Графовые модели программ

Две задачи планирования тестирования • Формирование и отбор критериев для выделения маршрута при тестировании Две задачи планирования тестирования • Формирование и отбор критериев для выделения маршрута при тестировании • Выбор стратегий упорядочения выделенных маршрутов при подготовке тестов

Критерии выделения маршрутов • Соответствуют критериям определения структурной сложности программных модулей • Критерии: – Критерии выделения маршрутов • Соответствуют критериям определения структурной сложности программных модулей • Критерии: – Покрытия графа программы минимальным количеством маршрутов, охватывающих дугу графа хотя бы один раз (Х 1) – Выделения линейно-независимых марщрутов, отличающихся хотя бы одной дугой (Х 2) – Выделения всех маршрутов при всех возможных комбинациях дуг, входящих в маршруты (Х 3)

Критерии выделения маршрутов (2) • Часть маршрутов может быть нереализуемой из-за противоречий в условиях Критерии выделения маршрутов (2) • Часть маршрутов может быть нереализуемой из-за противоречий в условиях • Выбор критерия или использование критериев последовательно по возрастанию

Стратегии упорядочения маршрутов • Учитывают сложность маршрута м тестов для их проверки – – Стратегии упорядочения маршрутов • Учитывают сложность маршрута м тестов для их проверки – – Количество операторов Количество условных переходов Количество циклов Частоту исполнения маршрута при рабочем фуекционаровании. ПС – Сложность получения эталонных данных и т. д.

Стратегии упорядочения маршрутов (2) • В первую очередь целесообразно проводить проверку основной части маршрутов Стратегии упорядочения маршрутов (2) • В первую очередь целесообразно проводить проверку основной части маршрутов – Предел ресурсов для тестирования • Используются три основные характеристики программных модулей

Основные характеристики программных модулей • Число строк текста в выделенных маршрутах или расчетная длительность Основные характеристики программных модулей • Число строк текста в выделенных маршрутах или расчетная длительность их реализации (стратегия 1) • Число альтернатив (предикатов) или условных переходов, определяюзих образование каждого маршрута (стратегия 2) • Вероятность исполнения маршрутов при реальном функционировании программы

Стратегия 1 • Первичному тестированию подлежат маршруты, наиболее длинные по числу строк и по Стратегия 1 • Первичному тестированию подлежат маршруты, наиболее длинные по числу строк и по времени исполнения (с наибольшим объемом вычисления и преобразования переменных) • Целесообразна при планировании тестирования программ, имеющих вычислительный характер обработки данных при небольшом числе маршрутов • Выбранные маршруты не обязательно самые сложные

Стратегия 2 • Приоритет отдается наиболее сложным маршрутам по числу анализируемых условий ветвления • Стратегия 2 • Приоритет отдается наиболее сложным маршрутам по числу анализируемых условий ветвления • Предпочтительна при тестировании логиченских программ с небольшим объемом вычисления

Стратегия 1 и 2 • На завершающем этапе тестируются более постые по объему вычислений Стратегия 1 и 2 • На завершающем этапе тестируются более постые по объему вычислений и логике маршруты • В конце используют более простые тесты • Позволяет выявить в начале наиболее критические участки программы – активно функционирующие компоненты и редко исполняемые части программы

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

Автоматизирование планирования тестирования • Задача автоматизированных систем – выделение маршрутов по одному или нескольким Автоматизирование планирования тестирования • Задача автоматизированных систем – выделение маршрутов по одному или нескольким критериям с упорядочением по определенной стратегии • Группы маршрутов, подлежащих первоочередной проверке • Расчет полноты проверки, оценка корректности программы по каждому из критериев

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

Сложность тестирования структуры программных модулей(2) • Сложность тестирования оценивается по числу маршрутов , необходимых Сложность тестирования структуры программных модулей(2) • Сложность тестирования оценивается по числу маршрутов , необходимых для их проверки или по суммарному числу условий которые необходимо задать в тестах для прохождения всех маршрутов k -ой программы

Сложность тестирования структуры программных модулей (3) • Где i – число условий-предикатов, определяющих I-й Сложность тестирования структуры программных модулей (3) • Где i – число условий-предикатов, определяющих I-й маршрут

Маршруты исполнения • Маршруты исполнения k-го программного модуля можно разделить на 2 вида: – Маршруты исполнения • Маршруты исполнения k-го программного модуля можно разделить на 2 вида: – Маршруты исполнения преимущественно вычислительной части и преобразования непрерывных переменных – Маршруты принятия логических решений и преобразований логических переменных

Маршруты вычислительной части • Логически проще и короче, чем другие • Значения вычисляемых переменных Маршруты вычислительной части • Логически проще и короче, чем другие • Значения вычисляемых переменных связаны условиями гладкости • При оценке сложности учитывается число операндов, участвующих в вычислениях