Техніки статичного тестування

Загалом можна виділити дві великі групи технік статичного тестування – це перевірки або перегляди (Reviews) та статичний аналіз.

Процес перевірки документації

Перевірки (reviews) документації варіюються від неофіційних до офіційних. Неофіційні перевірки характеризуються відсутністю визначеного процесу та офіційно задокументованих результатів. Для формальних перевірок характерна участь команди, задокументовані результати перевірки та задокументовані процедури проведення перевірки. Формальність процесу перевірки пов’язана з такими факторами, як модель життєвого циклу розробки програмного забезпечення, зрілість процесу розробки, складність робочого продукту, який перевіряється, будь-які законодавчі чи нормативні вимоги.

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

Стандарт ISO (ISO/IEC 20246) містить більш поглиблений опис процесу перевірки робочих продуктів, включаючи ролі та методи перевірки.

Процес перевірки (reviews) включає такі основні дії:

• Планування
• Початок перегляду
• Індивідуальна підготовка
• Комунікація проблем та аналіз
• Виправлення та звітування

Планування

• Визначення обсягу, який включає мету перевірки, які документи або частини документів перевіряти, а також якісні характеристики, що підлягають оцінці 
• Оцінка зусиль і часових рамок
• Визначення характеристик перевірки, таких як тип перевірки з ролями, видами діяльності та контрольними списками
• Вибір людей для участі в огляді та розподіл ролей
• Визначення критеріїв входу та виходу для більш формальних типів огляду
• Перевірка відповідності критеріям входу (для більш формальних типів перевірки)

Початок перегляду

• Розповсюдження робочого продукту (фізично чи за допомогою електронних засобів) та інших матеріалів, таких як логи, контрольні списки та інші відповідні робочі продукти
• Пояснення учасникам обсягу, цілей, процесу, ролей і результатів роботи
• Відповіді на будь-які запитання щодо перевірки, які можуть виникнути в учасників

Індивідуальна підготовка

• Перегляд всього або частини робочого продукту
• Позначення можливих недоліків, рекомендації та запитання

Комунікація проблем та аналіз

• Повідомлення про виявлені потенційні дефекти (наприклад, на оглядовій зустрічі)
• Аналіз потенційних дефектів, визначення права власності та статусу
• Оцінка та документування характеристик якості
• Оцінка результатів перевірки за критеріями виходу для прийняття рішення про перевірку (відхилити; необхідні значні зміни; прийняти, можливо, з незначними змінами)

Виправлення та звітування

• Створення звітів про дефекти для тих знахідок, які потребують змін у робочому продуктіВиправлення дефектів, виявлених (як правило, виконується автором) у перевіреному робочому продукті
• Повідомлення про дефекти відповідній особі або команді
• Запис оновленого статусу дефектів (у формальних перевірках), потенційно включаючи згоду автора коментаря
• Збір показників (для більш формальних типів перевірки)
• Перевірка відповідності критеріям виходу (для більш формальних типів перевірки)
• Прийняття робочого продукту після досягнення критеріїв виходу

Ролі у формальній перевірці

Типов формальна перевірка (formal review) документаці включатиме такі ролі:

• Автор (Author)
• Менеджмент (Management)
• Модератор (Moderator)
• Керівник (лідер) перевірки (Review leader)
• Рецензенти (Reviewers)
• Секретар (Scribe)

Автор

• Створює робочий продукт, що перевіряється
• Виправляє дефекти робочого продукту, що перевіряється (при необхідності)

Менеджмент

• Відповідає за планування перевірки
• Приймає рішення про виконання перевірок
• Призначає персонал, бюджет і час
• Контролює поточну ефективність витрат
• Виконує контрольні рішення у разі неадекватних результатів

Модератор

• Забезпечує ефективне проведення оглядових нарад (якщо вони проводяться)
• Посередництво, якщо необхідно, між різними точками зору
• Часто є особою, від якої залежить успіх перевірки

Керівник (лідер) перевірки

• Бере на себе загальну відповідальність за перевірку
• Вирішує, хто буде залучений, і організовує час і місце проведення

Рецензенти

• Можуть бути експертами в галузі, особами, які працюють над проєктом, зацікавленими сторонами, які зацікавлені в робочому продукті, або особами з певним технічним чи бізнес-досвідом
• Визначають потенційні дефекти в робочому продукті, що перевіряється
• Можуть представляти різні точки зору (наприклад, тестувальник, розробник, користувач, оператор, бізнес-аналітик, експерт з зручності використання тощо)

Секретар

• Зіставляє потенційні дефекти, виявлені під час індивідуальної перевірки
• Записує нові потенційні дефекти, відкриті питання та рішення наради з перегляду (якщо вона проводиться)

У деяких типах рецензування одна особа може виконувати кілька ролей, і дії, пов’язані з кожною роллю, також можуть відрізнятися залежно від типу перевірки. Крім того, з появою інструментів для підтримки процесу перевірки, особливо реєстрації дефектів, відкритих питань і рішень, часто відпадає потреба в секретарі.

Типи перевірок документації

Хоча перевірки можна використовувати для різних цілей, одна з головних цілей – виявити дефекти. Усі типи перевірки можуть допомогти у виявленні дефектів, і вибраний тип перевірки має ґрунтуватися на потребах проєкту, наявних ресурсах, типі продукту та ризиках, бізнес-сфері та культурі компанії, серед інших критеріїв вибору.

Один робочий продукт може бути предметом кількох типів перевірки. Якщо використовується більше ніж один тип перевірки, порядок може відрізнятися. Наприклад, перед технічною перевіркою можна провести неформальну перевірку, щоб переконатися, що робочий продукт готовий до технічної перевірки.

Типи дефектів, виявлених під час перевірки, відрізняються, особливо залежно від робочого продукту, який перевіряється.

Найпоширеніші типи перевірки робочої документації: неформальна перевірка, наскрізне проходження, технічна перевірка, інспекція.

Неформальна перевірка (informal review, e.g., buddy check, pairing, pair review)

• Основне призначення: виявлення потенційних дефектів
• Можливі додаткові цілі: генерація нових ідей або рішень, швидке вирішення незначних проблем
• Не базується на офіційному (задокументованому) процесі
• Може не включати нараду з перевірки (review meeting)
• Може виконуватись колегою автора (buddy check) або кількома людьми
• Результати можуть бути задокументовані
• Корисність залежить від рецензентів
• Використання контрольних списків необов’язкове
• Дуже часто використовується в гнучкій розробці

Наскрізне проходження (Walkthrough)

• Основні цілі: виявлення дефектів, вдосконалення програмного продукту, розгляд альтернативних реалізацій, оцінка відповідності стандартам і специфікаціям
• Можливі додаткові цілі: обмін ідеями щодо технік чи варіацій стилю, навчання учасників, досягнення консенсусу
• Індивідуальна підготовка перед нарадою з перевірки (review meeting) необов’язкова
• Нараду з перевірки (review meeting) зазвичай проводить автор робочого продукту
• Секретар обов’язковий
• Використання контрольних списків необов’язкове
• Може мати форму сценаріїв, пробних прогонів або моделювання
• Створюються журнали потенційних дефектів і звіти про перевірку
• На практиці може варіюватися від досить неформального до дуже офіційного

Технічний огляд (Technical review)

• Основні цілі: досягнення консенсусу, виявлення потенційних дефектів
• Можливі додаткові цілі: оцінка якості та зміцнення довіри до робочого продукту, генерація нових ідей, мотивація та надання можливості авторам покращувати майбутні робочі продукти, розгляд альтернативних реалізацій
• Рецензенти мають бути технічними колегами автора та технічними експертами в тій самій чи інших дисциплінах
• Необхідна індивідуальна підготовка перед оглядовою зустріччю
• Нарада з перевірки (review meeting) є необов’язковою, в ідеалі її проводить навчений модератор (зазвичай не автор)
• Секретар обов’язковий, в ідеалі не автор
• Використання контрольних списків необов’язкове
• Створюються журнали потенційних дефектів і звіти про перевірку

Інспекція (Inspection)

• Основні цілі: виявлення потенційних дефектів, оцінка якості та формування довіри до робочого продукту, запобігання майбутнім подібним дефектам шляхом навчання автора та аналізу першопричини
• Можливі подальші цілі: мотивація та надання можливості авторам покращувати майбутні робочі продукти та процес розробки програмного забезпечення, досягнення консенсусу
• Дотримується визначеного процесу з офіційно задокументованими результатами на основі правил і контрольних списків
• Використовує чітко визначені ролі та може включати спеціального читача (який читає продукт роботи вголос, часто перефразовуючи, тобто описуючи його своїми словами, під час оглядової зустрічі)
• Необхідна індивідуальна підготовка перед оглядовою зустріччю
• Рецензенти є або колегами автора, або експертами в інших дисциплінах, які стосуються робочого продукту
• Використовуються визначені критерії входу та виходу
• Секретар обов’язковий
• Оглядову зустріч проводить навчений модератор (не автор)
• Автор не може виступати в ролі керівника перевірки, читача чи секретаря
• Створюються журнали потенційних дефектів і звіт про перевірку
• Показники збираються та використовуються для вдосконалення всього процесу розробки програмного забезпечення, включаючи процес перевірки

Техніки перевірок документації

lІснує ряд методів перевірки, які можна застосувати під час індивідуальної підготовки для виявлення дефектів. Ці методи можна використовувати в описаних вище типах перевірок. Ефективність методів може відрізнятися залежно від типу огляду, який використовується. Серед методів перевірок документації виділяють:

• Ad hoc
• На основі контрольного списку
• Сценарії та пробні прогони
• На основі переспективи (поглядів)
• На основі ролей (рольовий)

Ad hoc

Під час спеціального перегляду рецензентам надається мало або взагалі не надається вказівок щодо того, як слід виконувати це завдання. Рецензенти часто читають робочий продукт послідовно, виявляючи та документуючи проблеми, коли вони з ними стикаються. Спеціальне рецензування – це широко використовувана техніка, яка потребує невеликої підготовки. Ця техніка сильно залежить від навичок рецензента та може призвести до багатьох повторюваних проблем, про які повідомляють різні рецензенти.

Контрольний список

Огляд на основі контрольного списку – це систематичний метод, за допомогою якого рецензенти виявляють проблеми на основі контрольних списків, які розповсюджуються на початку перевірки (наприклад, модератором). Контрольний список перевірки складається з набору запитань, заснованих на потенційних дефектах, які можуть бути отримані з досвіду. Контрольні списки мають бути специфічними для типу робочого продукту, що перевіряється, і їх слід підтримувати регулярно, щоб охоплювати типи проблем, пропущені під час попередніх перевірок. Основна перевага методу, заснованого на контрольному списку, полягає в систематичному охопленні типових типів дефектів. Слід подбати про те, щоб не просто слідувати контрольному списку під час індивідуального перегляду, а й шукати дефекти поза контрольним списком.

Сценарії та пробні прогони

Під час рецензування на основі сценарію рецензентам надаються структуровані вказівки щодо того, як прочитати робочий продукт. Перевірка на основі сценаріїв підтримує рецензентів у виконанні «пробних прогонів» робочого продукту на основі очікуваного використання робочого продукту (якщо робочий продукт задокументовано у відповідному форматі, наприклад варіанти використання). Ці сценарії надають рецензентам кращі вказівки щодо визначення конкретних типів дефектів, ніж прості записи контрольного списку. Як і у випадку перевірки на основі контрольного списку, щоб не пропустити інші типи дефектів (наприклад, відсутні функції), рецензенти не повинні бути обмежені задокументованими сценаріями.

На основі перспективи

У перспективному читанні, подібному до рольового рецензування, рецензенти розглядають різні точки зору зацікавлених сторін під час індивідуального рецензування. Типові точки зору зацікавлених сторін включають кінцевого користувача, спеціаліста з маркетингу, дизайнера, тестувальника або оператора тощо. Використання різних точок зору зацікавлених сторін веде до більшої глибини індивідуального рецензування з меншим дублюванням проблем між рецензентами.

Крім того, читання, засноване на перспективі, також вимагає від рецензентів спроби використати робочий продукт, який перевіряється, для створення продукту, який вони б розробили на основі нього. Наприклад, тестувальник спробував би згенерувати проєкти приймальних випробувань, якщо зчитує специфікацію вимог на основі перспективи, щоб перевірити, чи включена вся необхідна інформація. Крім того, при читанні в перспективі очікується використання контрольних списків.

Емпіричні дослідження показали, що читання на основі перспективи є найефективнішою загальною технікою перегляду вимог і технічних робочих продуктів. Ключовим фактором успіху є включення та належне зважування точок зору різних зацікавлених сторін на основі ризиків.

Рольовий

Огляд на основі ролей — це техніка, за якої рецензенти оцінюють робочий продукт з точки зору окремих ролей зацікавлених сторін. Типові ролі включають конкретні типи кінцевих користувачів (досвідчені, недосвідчені, старші, діти тощо), а також конкретні ролі в організації (системний адміністратор, тестувальник продуктивності тощо). Застосовуються ті самі принципи, що й у читанні в перспективі, оскільки ролі подібні.

Фактори успіху перевірок

Для успішної перевірки необхідно розглянути відповідний тип огляду та використані методи. Крім того, існує низка інших факторів, які впливатимуть на результат перевірки.

Організаційні фактори успіху для оглядів включають:

• Кожна перевірка має чіткі цілі, визначені під час планування перевірки та використані як вимірювані критерії виходу
• Застосовуються типи перевірки, які підходять для досягнення цілей і відповідають типу та рівню робочих продуктів програмного забезпечення та учасників
• Будь-які використовувані методи перевірки, такі як перевірка на основі контрольного списку або на основі ролей, підходять для ефективного виявлення дефектів у робочому продукті, який перевіряється
• Будь-які використовувані контрольні списки стосуються основних ризиків і є актуальними
• lВеликі документи пишуться та переглядаються невеликими частинами, щоб контролювати якість шляхом надання авторам ранніх і частих відгуків про недоліки
• Учасники мають достатньо часу для підготовки
• Перевірки плануються з належним повідомленням
• Керівництво підтримує процес перевірки (наприклад, шляхом виділення достатнього часу для діяльності з перевірки в графіки проєкту) Перевірки інтегровані в політику якості або тестування компанії.

Пов’язані з людьми фактори успіху перевірок включають:

• Для досягнення цілей рецензування залучаються потрібні люди, наприклад, люди з різними навичками або перспективами
• Тестувальники вважаються цінними рецензентами, які роблять внесок у рецензування та дізнаються про робочий продукт, що дає їм змогу готувати більш ефективні тести та готувати ці тести раніше
• Учасники приділяють достатньо часу та уваги до деталей
• Огляди проводяться невеликими частинами, щоб рецензенти не втрачали концентрації під час індивідуального огляду або зустрічі з перевірки (якщо вона проводиться)
• Виявлені дефекти визнаються, оцінюються та розглядаються об’єктивно
• Зустріч добре організована
• Перевірка проводиться в атмосфері довіри; результат не використовуватиметься для оцінки учасників
• Учасники уникають мови тіла та поведінки, які можуть вказувати на нудьгу, роздратування або ворожість до інших учасників
• Забезпечується адекватне навчання, особливо для більш формальних видів перевірок
• Пропагується культура навчання та вдосконалення процесу

Статичний аналіз

Метою статичного аналізу є пошук дефектів у вихідному коді програмного забезпечення та моделях програмного забезпечення.

Потік керування (Control flow) — це послідовність подій (шляхів) після запуску компонента або системи на виконання.

Потік даних (Data flow) — це абстрактне представлення послідовності та можливих змін стану об’єктів даних: створення, використання або видалення.

Метрики коду

Під час виконання статичного аналізу коду обчислюється інформація про структурні атрибути коду, такі як:

• Частота коментарів
• Глибина вкладення
• Цикломатичне число
• Кількість рядків коду

Показники складності ідентифікують зони з високим ризиком і складність.

Досвідчені програмісти знають, що 20% коду викличуть 80% проблем, а аналіз складності допомагає знайти ці важливі 20%.

Цінність статичного аналізу

• Раннє виявлення дефектів до виконання тесту
• Раннє попередження про підозрілі аспекти коду або дизайну шляхом обчислення показників.
• Ідентифікація дефектів, які важко знайти під час динамічного тестування
• Виявлення залежностей і невідповідностей у моделях програмного забезпечення
• Покращено підтримку коду та дизайну
• Попередження дефектів

Типові дефекти

• Типові дефекти, виявлені інструментами статичного аналізу:
• Посилання на змінну з невизначеним значенням
• Непослідовні інтерфейси між модулями та компонентами
• Змінні, які не використовуються або оголошені неправильно
• Недосяжний (мертвий) код
• Відсутня та помилкова логіка (потенційно нескінченні цикли)
• Надто складні конструкції
• Порушення стандартів програмування
• Вразливі місця безпеки
• Порушення синтаксису коду та моделей програмного забезпечення

Інструменти статичного аналізу

Інструменти статичного аналізу зазвичай використовуються розробниками (перевірка на відповідність попередньо визначеним правилам або стандартам програмування) до та під час тестування компонентів та інтеграції, а також під час моделювання програмного забезпечення.

Інструменти статичного аналізу можуть створювати велику кількість попереджувальних повідомлень, які потрібно ретельно аналізувати, щоб забезпечити найбільш ефективне використання інструменту.

Компілятори можуть запропонувати певну підтримку для статичного аналізу, включаючи обчислення показників.

Інструменти статичного аналізу: CodeScene, Parasoft, Code Compare, Sourcemeter, Understand.

В цьому відео поговоримо про техніки статичного тестування:
00:06 Статичне тестування
00:46 Процес перевірки документації
08:30 Ролі у формальній перевірці
12:25 Типи перевірок документації
14:02 Неформальна перевірка
15:16 Наскрізне проходження
17:31 Технічна перевірка
20:03 Інспекція
23:44 Техніки перевірок документації
24:39 Ad hoc
26:06 Контрольний список
27:59 Сценарії та пробні прогони
30:25 На основі перспективи
33:52 Рольовий
36:11 Фактори успіху перевірок
40:09 Статичний аналіз
41:06 Метрики коду
42:01 Цінність статичного аналізу
42:39 Типові дефекти, які виявляються статичним аналізом
43:45 Інструменти статичного аналізу