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

Инспекция ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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