Tarkvara kvaliteed ja standardid
advertisement
Tarkvara kvaliteed ja standardid. 6 Качество и стандарты программного обеспечения L.Joonas 2004 Инспекция ПО Задачи V&V • Verification & validation должны подтвержать то, что ПО отвечает своим задачам • Это не означает то, что ПО совершенно не имеет дефектов • Тем не менее, онго должно быть достаточно хорошо для предполагаемого использования и тип использования должен определять уровень необходимой ответственности Конфиденциальность V & V • Зависит от целей системы, ожиданий пользователя и маркетингового окружения – Функции ПО • Уровень достоверности (конфиденциальности) зависит от того, насколько критично ПО для организации – Ожидания пользователя • Пользователи могут мало ожидать от некоторых видов ПО – Маркетинговое окружение • Выпуск продукта на рынок раньше может быть важнее, чем нахождение дефектов программ Тестирование и отладка • Тестирование дефектов и отладка – два абсолютно различных процесса • Verification + validation касаются установления существования дефектов в программах • Отладка занимается локализацией и устранением этих дефектов Процесс отладки Test results Locate error Test cases Specification Design error repair Repair error Re-test program Планирование V & V • Аккуратное планирование необходимо для получения максимального результата от тестирования и инспекции • Планирование должно начинаться как можно раньше в процессе разработки • План должен определить баланс между статической верификацией и тестированием • Планирование тестов – это скорее определение стандартов для процесса тестирования, чем описание тестов V-образная модель развития Requirements specification System specification System integration test plan Acceptance test plan Service System design Acceptance test Detailed design Sub-system integration test plan System integration test Sub-system integration test Module and unit code and tess Структура плана тестирования ПО • Процесс тестирования • Возможность отслеживания требований • Тестируемые единицы • График тестирования • Процедура записи тестов • Аппаратные и программные требования • Ограничения Инспекции ПО • Позволяет экзаменовать код с целью нахождения там аномалий и дефектов • Не требуется работоспособности всей системы, так что может быть использовано до внедрения • Может быть испольовано для любого представления системы (требования, дизайн, тестовые данные и т.д.) • Очень эффективная методика поиска ошибок Достоинства инспекции • Может быть найдено множество различных дефектов в течение одной инспекции. • При тестировании один эффект может покрывать собой несколько, так что требуются повторные тесты • Использует обычные знания программирования, чем похожа на обычное вычитывание кода в поисках обычных ошибок Инспекции и тестирование • Инспекции и тестирование дополняют друг друга • Обе методики могут быть использованы во время процесса V & V • Инспекции могут проверить соответствие спецификации, но не реальные требования пользователя • Инспекции не могут проверить нефункциональные характеристики, такие как производительность, юзабильность и т.д. Инспекции программ • Формальные методики для просмотра документов • Предназначены для нахождения дефектов, но не для их исправления • Дефекты могут быть логическими ошибками, аномалиями кода, которые могут соответствовать ошибочным ситуациям (например, неописанные переменные) или несоответствия стандартам Предусловия инспекции • Необходимо наличие точной спецификации • Члены команды должны быть знакомыми со стандартами организации • Должен быть достeпен синтаксически корректный код • Должен быть подготовлен чек-лист ошибок • Руководство должно осознавать, что инспекции увеличивают стоимость разработки на раннем этапе • Руководство не должно использовать инспекции для оценки персонала Процесс инспекции Planning Overview Follow-up Individual preparation Rework Inspection meeting Процедура инспекции • Инспекционной команде представляют обзор системы • Между членами инспекционной команды распределяется код и связанные с ним документы • Проводится инспекция и отмечаются обнаруженные ошибки • Осуществляется доработка всоответствии с найденными ошибками • Может быть проведена повторная инспекция Инспекционная команда • Состоит по меньшей мере из 4 человек: • Автор инспектруемого кода • Инспектор, который находит ошибки и несоответствия • Ридера, который читает код команде • Модератора, оторый ведет собрание и отмечает ображенные ошибки • Секретарь и Главный модератор Fault class Data faults Contro l fau lts Inpu t/output faults Interface faults Storage management fau lts Exception management faults Ins pection check Are all pro gram variables in itialised b efore their values are us ed? Have all cons tants been n amed? Sho uld th e lower bo und o f arrays be 0, 1, or s omethin g else? Sho uld th e u pper bound of arrays be eq ual to the s ize of the array or Size -1? If character strings are us ed, is a d elimiter exp licitly as signed ? For each cond itional s tatement, is th e condition correct? Is each loop certain to termin ate? Are comp ound statements correctly b racketed? In cas e s tatements , are all p oss ible cases accoun ted for? Are all in put v ariables us ed ? Are all ou tput variables ass igned a value b efore they are outp ut? Do all fun ction an d procedu re calls h ave the co rrect number of p arameters ? Do formal an d actual parameter types match? Are the parameters in the righ t order? If components acces s shared memo ry, do they have the same model o f the shared memory s tructure? If a lin ked stru cture is mo dified, have all links been co rrectly reas sign ed? If dy namic sto rage is us ed, has s pace b een allocated co rrectly? Is space explicitly de-allocated after it is no longer req uired? Have all po ss ible erro r con dition s b een taken into acco unt? Расчет скорости работы • 90-125 операторов в час • Дорогостоящий процесс • Проверка 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 Fault class Data faults Static analysis check Variables used before initialisation Variables declared but never used Variables assigned twice but never used between assignments Possible array bound violations Undeclared variables Control faults Unreachable code Unconditional branches into loops Input/output faults Variables output twice with no intervening assignment Interface faults Parameter type mismatches Parameter number mismatches Non-usage of the results of functions Uncalled functions and procedures Storage management Unassigned pointers faults Pointer arithmetic Тестирование структуры программных компонентов Принципы тестирования структуры программных компонентов • Цель – проверка корректности выделенных маршрутов исполнения программ и обнаружение логических ошибок формирования маршрутов • На практике до 50% маршрутов оказываются пропущенными при тестировании • Первая задача – получение информации о полной совокупности реальных маршрутов исполнения Сложность программы • Определяется числом взаимодействующих компонентов, числом связей между компонентами и сложностью их взаимодействия • Зависит, в первую очередь, от числа отдельных путей исполнения программы • Определяет сложность тестирования Сложность тестирования • Большое число маршрутов обработки информации в программах • Графовые модели программ Две задачи планирования тестирования • Формирование и отбор критериев для выделения маршрута при тестировании • Выбор стратегий упорядочения выделенных маршрутов при подготовке тестов Критерии выделения маршрутов • Соответствуют критериям определения структурной сложности программных модулей • Критерии: – Покрытия графа программы минимальным количеством маршрутов, охватывающих дугу графа хотя бы один раз (Х1) – Выделения линейно-независимых марщрутов, отличающихся хотя бы одной дугой (Х2) – Выделения всех маршрутов при всех возможных комбинациях дуг, входящих в маршруты (Х3) Критерии выделения маршрутов (2) • Часть маршрутов может быть нереализуемой из-за противоречий в условиях • Выбор критерия или использование критериев последовательно по возрастанию Стратегии упорядочения маршрутов • Учитывают сложность маршрута м тестов для их проверки Количество операторов Количество условных переходов Количество циклов Частоту исполнения маршрута при рабочем фуекционарованииПС – Сложность получения эталонных данных и т.д. – – – – Стратегии упорядочения маршрутов (2) • В первую очередь целесообразно проводить проверку основной части маршрутов – Предел ресурсов для тестирования • Используются три основные характеристики программных модулей Основные характеристики программных модулей • Число строк текста в выделенных маршрутах или расчетная длительность их реализации (стратегия 1) • Число альтернатив (предикатов) или условных переходов, определяюзих образование каждого маршрута (стратегия 2) • Вероятность исполнения маршрутов при реальном функционировании программы Стратегия 1 • Первичному тестированию подлежат маршруты, наиболее длинные по числу строк и по времени исполнения (с наибольшим объемом вычисления и преобразования переменных) • Целесообразна при планировании тестирования программ, имеющих вычислительный характер обработки данных при небольшом числе маршрутов • Выбранные маршруты не обязательно самые сложные Стратегия 2 • Приоритет отдается наиболее сложным маршрутам по числу анализируемых условий ветвления • Предпочтительна при тестировании логиченских программ с небольшим объемом вычисления Стратегия 1 и 2 • На завершающем этапе тестируются более постые по объему вычислений и логике маршруты • В конце используют более простые тесты • Позволяет выявить в начале наиболее критические участки программы – активно функционирующие компоненты и редко исполняемые части программы Стратегия 3 • Сложность в оценке вероятности ветвления в условных переходах и переключениях и в оценке числа исполняемых циклов • Наиболее полное планирование тестирования Автоматизирование планирования тестирования • Задача автоматизированных систем – выделение маршрутов по одному или нескольким критериям с упорядочением по определенной стратегии • Группы маршрутов, подлежащих первоочередной проверке • Расчет полноты проверки, оценка корректности программы по каждому из критериев Сложность тестирования структуры программных модулей • Экспериментально подтверждена адекватность использования структурной сложности программ для оценки трудоемкости тестирования, а так же вероятность наличия не выявленных ошибок и затрат на разработку программных модулей в целом. Сложность тестирования структуры программных модулей(2) • Сложность тестирования оценивается по числу маршрутов M k , необходимых для их проверки или по суммарному числу k условий которые необходимо задать в тестах для прохождения всех маршрутов k-ой программы E Сложность тестирования структуры программных модулей (3) Mk Ek Ei Mk Ek Ei i1 i1 • Где i – число условий-предикатов, определяющих I-й маршрут Маршруты исполнения • Маршруты исполнения k-го программного модуля можно разделить на 2 вида: – Маршруты исполнения преимущественно вычислительной части и преобразования непрерывных переменных – Маршруты принятия логических решений и преобразований логических переменных Маршруты вычислительной части • Логически проще и короче, чем другие • Значения вычисляемых переменных связаны условиями гладкости • При оценке сложности учитывается число операндов, участвующих в вычислениях
