Tarkvara kvaliteed ja standardid

Реклама
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
i1
i1
• Где i – число условий-предикатов,
определяющих I-й маршрут
Маршруты исполнения
• Маршруты исполнения k-го программного
модуля можно разделить на 2 вида:
– Маршруты исполнения
преимущественно вычислительной
части и преобразования непрерывных
переменных
– Маршруты принятия логических
решений и преобразований логических
переменных
Маршруты вычислительной
части
• Логически проще и короче, чем другие
• Значения вычисляемых переменных
связаны условиями гладкости
• При оценке сложности учитывается число
операндов, участвующих в вычислениях
Скачать