Дублювання логіки — єдиний спосіб верифікації

Привіт.

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

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

Введення
Розробляючи ми, по суті, займаємося формалізацією деякої предметної області, результатом якої є поява описує її моделі.

Перевірити точність реалізації моделі можна лише порівнявши її з зовнішніми по відношенню до моделі зразком:

  • оригінальної предметною областю — запустивши на експлуатацію;
  • іншою моделлю, розробленою для тієї ж предметної області.
Звичайно, при порівнянні моделей відбувається не стільки їх перевірка, скільки «синхронізація», так як при виявленні розходжень не можна безумовно сказати в якій з двох моделей помилка.

Чому дублювання логіки працює
Нехай:

  • при розробці моделі 1 ймовірність допустити помилку дорівнює p1;
  • при розробці моделі 2 ймовірність допустити ту ж помилку дорівнює p2;
Тоді:

  • ймовірність допустити цю помилку одночасно в двох моделях дорівнює p1*p2 (для скорочення тексту приймемо, що це незалежні події);
  • це, звичайно, значно менше вихідних ймовірностей.

Цей графік відображає зміну ймовірності появи однакової помилки в двох моделях і покликаний додати ваги статті.

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

У разі, коли тестова модель закриває лише частину функціональності оригінальної моделі, розумно розглядати її по компонентно: так, що тестова модель або закриває весь компонент або ні.

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

Для цього визначимо властивості, якими можуть відрізнятися методи:

  • спосіб реалізації — як реалізується дублююча модель;
  • спосіб верифікації — як здійснюється порівняння моделей;
Тести (автоматичні, напівавтоматичні, ручні)
спосіб реалізації: код (або алгоритм дій людини), що реалізує створення оточення і перевіряючий результат роботи цільової моделі;
спосіб верифікації: виклик коду програми тестами або ручна робота тестувальника;

Статичний аналіз
спосіб реалізації: модель задана правилами всередині перевіряючого софта, наприклад: компілятора, pylint, PVS-Studio. В окремих випадках може існувати додаткова специфікація, наприклад: опис типів розширена специфікація алгоритмів (приклад: habrahabr.ru/post/251751;
спосіб верифікації: виклик зовнішнього верифікатора для аналізу коду цільової моделі;

Парне програмування і рев'ю коду
спосіб реалізації: модель знаходиться в голові напарника;
спосіб верифікації: порівняння напарником своєї моделі з тим, що ви пишете;

Повне дублювання системи
спосіб реалізації: повний аналог цільової моделі, розроблений іншою командою;
спосіб верифікації: порівняння двох станів моделей і результатів їх функціонування;

Пара слів про типізації
На мій погляд, її не можна вважати окремим методом верифікації, а правильніше віднести до:

  • статичного аналізу, якщо вона статична;
  • до тестування, якщо вона динамічна.
Відповідно, типізація має всі особливості відповідних методів.

Як ці міркування можна використовувати?
Ми можемо зміцнити нашу аргументацію при організації процесу тестування і отримати кілька правдоподібних метрик «верифицированности» проекту.

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

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

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

Виходячи з цієї вимоги, ми направляємо всі ресурси відділу тестування на 100% перевірку UI, а для внутрішніх компонентів виділяємо розробника для написання unit-тестів.

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

Резюме
У цій статті, звичайно, немає претензій на якесь відкриття. Але є спроба додати більше формальності та обґрунтованості в процес організації розробки ПО.
Треба розробляти методику формальної оцінки верифицированности?

/>
/>


<input type=«radio» id=«vv67499»
class=«radio js-field-data»
name=«variant[]»
value=«67499» />
Обов'язково треба!
<input type=«radio» id=«vv67501»
class=«radio js-field-data»
name=«variant[]»
value=«67501» />
Не завадить
<input type=«radio» id=«vv67503»
class=«radio js-field-data»
name=«variant[]»
value=«67503» />
Без різниці
<input type=«radio» id=«vv67505»
class=«radio js-field-data»
name=«variant[]»
value=«67505» />
Це нікому не треба
<input type=«radio» id=«vv67507»
class=«radio js-field-data»
name=«variant[]»
value=«67507» />
Ні в якому разі!

Проголосувало 20 осіб. Утрималося 15 чоловік.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.