Static - Static Analysis
Last updated
Last updated
Статичний аналіз: аналіз артефактів розробки програмного забезпечення, таких як вимоги або програмний код, що проводиться без виконання цих програмних артефактів. Статичний аналіз зазвичай виконується з допомогою допоміжних інструментів. (ISTQB)
Статичний аналіз - це аналіз програмних артефактів, як-от програмний код (чи вимоги, дизайн), виконуваний статично, тобто. без запуску і, очевидно, методом білої скриньки. Основна мета цього аналізу – якомога раніше знайти помилки, незалежно від того, чи можуть вони викликати відмови (failures). Як і у випадку з оглядами (reviews), статичний аналіз виявляє помилки (bugs), а чи не відмови. Зазвичай статичний аналіз проводять до формальної перевірки, навіть до unit testing шляхом додавання цих перевірок фахівцями DevOps в пайплайн проекту. Статичний аналіз не пов'язаний із динамічними властивостями вимог, дизайну та коду, такими як покриття тестами (test coverage). Існує безліч інструментів для статичного аналізу, які в основному використовуються розробниками до або під час тестування компонентів або інтеграції (частіше нові та змінені класи та функції), а також дизайнерами під час моделювання програмного забезпечення. Інструменти можуть відображати не лише структурні атрибути, такі як глибина вкладеності або число цикломатичної складності та перевірка на відповідність стандартам кодування, але також графічні зображення потоку управління, взаємозв'язку даних та кількість окремих шляхів від одного рядка коду до іншого. Інформація може використовуватися до формальних методів, які математично підтверджують властивості цієї програми. такі як глибина вкладеності або число цикломатичної складності та перевірка на відповідність стандартам кодування, але також графічні зображення потоку управління, взаємозв'язку даних та кількість окремих шляхів від одного рядка коду до іншого. Інформація може використовуватися до формальних методів, які математично підтверджують властивості цієї програми. такі як глибина вкладеності або число цикломатичної складності та перевірка на відповідність стандартам кодування, але також графічні зображення потоку управління, взаємозв'язку даних та кількість окремих шляхів від одного рядка коду до іншого. Інформація може використовуватися до формальних методів, які математично підтверджують властивості цієї програми.
Інструменти допомагають у виявленні наступних дефектів:
Перемінні, що не використовуються;
Частини коду, які ніколи не виконаються;
Нескінченні цикли;
Змінна з невизначеним значенням;
Неправильний синтаксис;
Неузгоджені інтерфейси між модулями та компонентами, такі як неправильне використання об'єкта, методу чи функції, включаючи неправильні параметри;
Уразливості безпеки, такі як проблеми безпеки, пов'язані з переповненням буфера, що виникає через неможливість перевірити довжину буфера перед копіюванням у буфер;
Різні типи порушення стандартів програмування, як порушення, що створюють ризик фактичного збою, і порушення, які ускладнюють тестування, аналіз і підтримуваність коду;
Методи статичного аналізу :
Аналіз управління (Control Analysis): фокусується на вивченні елементів управління, що використовуються в структурі викликів, аналізі потоку управління та аналізі переходів станів (calling structure, control flow analysis and state transition analysis). Структура виклику пов'язана з моделлю шляхом ідентифікації викликів та їхньої структури. Викликаюча структура може бути процесом, підпрограмою, функцією чи методом. Аналіз потоку управління перевіряє послідовність передачі управління і може виявити неефективні конструкції моделі. Створюється граф моделі (CFG – Control Flow Graph), в якому умовні гілки та стики моделі представлені вузлами. За підсумками можна розрахувати цикломатичну складність програми. Для аналізу потоку управління використані: Абстрактна інтерпретація, Задоволення обмежень, Типізація даних;
Аналіз даних (Data Analysis): забезпечує правильну роботу з об'єктами даних, такими як структури даних та пов'язані списки. Крім того, цей метод забезпечує правильне використання певних даних. Аналіз даних включає два методи, а саме: залежність даних та аналіз потоку даних (data dependency and data flow analysis). Залежність даних необхідна з метою оцінки точності синхронізації між кількома процесорами. Аналіз потоку даних перевіряє визначення та контекст змінних. Види аналізу потоку даних:
Reaching Definitions;
Available Expressions;
Constant Propagation;
Very Busy Expressions;
Live Variables;
Use-Definition & Definition-Use;
Аналіз несправностей/відмов (Fault/Failure Analysis): аналізує несправності (некоректний компонент) та відмову (некоректна поведінка компонента моделі) у моделі. Цей метод використовує опис перетворення вводу-виводу визначення умов, що є причиною збою. Для визначення відмов у певних умовах перевіряється проектна специфікація моделі (model design specification);
Аналіз інтерфейсу (Interface Analysis): перевіряє взаємодіючі та розподілені моделі для перевірки коду. Існує два основних методи аналізу інтерфейсу, і аналіз інтерфейсу користувача досліджує інтерфейси підмоделей і визначає точність структури інтерфейсу. Аналіз інтерфейсу користувача досліджує модель інтерфейсу користувача і запобіжні заходи, що вживаються для запобігання помилкам під час взаємодії користувача з моделлю. Цей метод також фокусується на тому, як точно інтерфейс інтегрований в загальну модель і симуляцію.
Аналіз потоку управління (Control Flow Analysis) та аналіз потоку даних (Data Flow Analysis) взаємозалежні: щоб отримати точні результати для аналізу потоку даних, необхідно враховувати потік управління (оскільки порядок операцій впливає на можливі значення даних у конкретному місці програми). Щоб отримати точні результати для аналізу потоку керування, необхідно враховувати потік даних, оскільки потік динамічного керування (рішення, яке приймається під час виконання) залежить від значень даних у конкретних місцях програми. Однак ці два аналізи мають різні цілі.
Граф потоку керування (Control Flow Graph)
Граф потоку управління (CFG) - це графічне уявлення потоку управління чи обчислень під час виконання програм чи додатків. Графи потоку управління в основному використовуються в статичному аналізі, а також у додатках-компіляторах, оскільки вони можуть точно подавати потік всередині програмного модуля. Характеристики графа потоку управління:
Граф потоку управління процесно-орієнтований (process oriented);
Граф потоку управління показує всі шляхи, які можна пройти під час виконання програми;
Ребра CFG зображують шляхи потоку управління, а вузли CFG зображують базові блоки.
Цикломатична складність (Cyclomatic Complexity)
Цикломатична складність – це метрика для вимірювання складності коду, заснована на графі потоку управління. Незалежний шлях визначається як шлях, що має хоча б одне ребро, яке раніше не проходило в жодному іншому шляху.
Визначення з книги Лі Копланда - “A Practitioner's Guide to Software Test Design”, Глави 10:
Цикломатична складність - це кінцева мінімальна кількість незалежних, нециклічних маршрутів (званих основними маршрутами), які можуть утворювати всі можливі лінійні шляхи програмного модуля.
Цикломатична складність може бути розрахована щодо функцій, модулів, методів чи класів у програмі як вручну, так і за допомогою автоматизованих інструментів.
Математично цикломатична складність структурованої програми визначається за допомогою орієнтованого графа, вузлами якого є блоки програми, з'єднані ребрами, якщо керування може переходити з одного блоку на інший. Тоді складність визначається як
M = E − N + 2P ,
де:
M = цикломатична складність,
E = кількість ребер у графі,
N = кількість вузлів у графі,
P = кількість компонентів зв'язності.
В іншому формулюванні використовується граф, у якому кожна точка виходу з'єднана з точкою входу. У цьому випадку граф є сильнозв'язковим, і цикломатична складність програми дорівнює цикломатичному числу цього графа (також відомому як перше число Бетті), яке визначається як
M = E−N+P .
Це визначення може розглядатися як обчислення числа лінійно незалежних циклів, які існують у графі, тобто тих циклів, які не містять інших циклів. Так як кожна точка виходу з'єднана з точкою входу, існує принаймні один цикл для кожної точки виходу.
Для простої програми, або підпрограми, або методу P завжди дорівнює 1. Однак цикломатична складність може застосовуватися до кількох таких програм або підпрограм (наприклад, до всіх методів у класі), у такому випадку P дорівнює числу підпрограм, про які йдеться, оскільки кожна підпрограма може бути подана як незалежна частина графа.
Може бути показано, що цикломатична складність будь-якої структурованої програми з лише однією точкою входу і однією точкою виходу еквівалентна числу точок розгалуження (тобто операторів if або умовних циклів), що містяться в цій програмі плюс один.
Цикломатична складність може бути поширена на програму з численними точками виходу; у цьому випадку вона дорівнює
π − s + 2 ,
де:
π - кількість точок розгалуження у програмі,
s – число точок виходу.
Застосування:
Обмеження складності при розробці: одне з запропонованих Маккейбом застосувань полягає в тому, що необхідно обмежувати складність програм під час їх розробки. Він рекомендує, щоб програмістів зобов'язували обчислювати складність модулів, що розробляються, і розділяти модулі на дрібніші щоразу, коли цикломатична складність цих модулів перевищить 10. Ця практика була включена НІСТ-ом в методику структурного тестування з зауваженням, що з часу вихідної публікації Маккейба вибір значення 10 отримав вагомі підтвердження, проте в деяких випадках може бути доцільно послабити обмеження і дозволити модулі зі складністю до 15. У даній методиці визнається, що іноді можуть існувати причини для виходу за межі узгодженого ліміту. Це сформульовано як рекомендація:
Застосування для тестування програмного забезпечення: визначення кількості тестів, необхідних для повного покриття коду. Цикломатична складність M має дві властивості, для конкретного модуля:
M - оцінка зверху кількості тестів, які забезпечують покриття умов (точок розгалуження);
M - оцінка знизу кількості маршрутів через граф потоку управління і, таким чином, кількості тестів для повного покриття шляхів.
У складі інших метрик: використовується як один з параметрів в індексі зручності супроводу (англ. maintainability index).
Джерела:
Дод. матеріал:
Граф потоку управління – це граф;
.