10. Програми-інструменти

Відладчики

Відладчики можуть бути корисні для внутрішнього і зовнішнього тестування. Методом тестування вважається метод прозорого ящика.

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

Відбувається управління початковим кодом і, можливо, виправлення помилок.

Щоденник тестування, що дозволяє робити повторне тестування, зберігається.

Аналізатори покриття

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

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

Компаратор

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

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

11. Статичні тести

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

Перевірки коректності непрактичні для реальних програм і, більшою мірою, виведені вченими в комп'ютерній техніці. Їх застосування до сучасних великих програм не має сенсу, хоч Academia все ще наполягає на розробці цих методів.

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

Неформальні тести недооцінюють, хоча вони можуть бути дуже ефективними.

Типові помилки, виявлені статичними тестами

Типовими помилками, які виявляються статичними тестами, є:

• неініціалізовані змінні,

• порівняння змінних з плаваючою крапкою,

• адреси, що перевищують межі,

• помилки з вказівниками,

• помилки в умовних командах,

• нескінченні цикли,

• помилки в межах (наприклад > чим =),

• неправильне використання круглих дужок,

• неправильне використання даних.

Стратегія неформальних тестів:

Неформальні статичні тести зазвичай проводяться програмістом, який написав модуль. Програміст аналізує код. Якщо все гаразд, його аналізує досвідчений програміст. Якщо той знайде помилки - програма повертається програмістові. Якщо модуль складний - його перевіряє декілька досвідчених програмістів.

12. Підрахунок кількості помилок

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

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

Метод сіяння помилок

Метод полягає у введенні в програму помилок, схожих з тими, що вже існують. Виявлення проводить інша група програмістів.

Нехай: N – кількість посіяних помилок, M - загальна кількість виявлених помилок, X - кількість виявлених помилок з числа посіяних.

Ми можемо підрахувати очікуване число помилок перед тестуванням:

(M-X)*N/X

Очікуване число помилок після їх виправлення буде таким:

(M-X)*(N/X-1)

Оцінка може бути помилковою якщо посіяні помилки сильно відрізнятимуться від справжніх. Метод також дозволяє тестувати самого себе. Дуже мале значення X/N означає необхідність виправлення методу.

Тестування системі

Тестування всієї системи може відбуватися двома способами: згори вниз і знизу вгору.

Тестування знизу вгору відбувається шляхом тестування, в першу чергу, конкретних модулів, після чого відбувається їх злиття і тестування великих модулів, аж до найвищого рівня. Застосування підходу не завжди можливо через взаємозв'язки модулів. Можуть використовуватися модулі-заглушки.

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

Стресове тестування

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

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

Безпека ПЗ

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

Слід зазначити, що безпека і надійність - не одне і те ж. Ненадійна система може бути безпечна, якщо наслідки помилок не небезпечні.

Системні вимоги можуть бути неповними і не описувати всіх випадків. Це відноситься до вхідних даних. Для системи важливо працювати правильно навіть у разі введення невірних даних.

До помилок ПЗ потрібно відносити і помилки апаратури. Безпека повинна враховувати обидва аспекти.

Безпека ПЗ повинна враховуватися, в першу чергу, з точки зору таких загроз, як смерть, втрата здоров'я, фінансові втрати, невідповідність юридичним нормам і т.д.

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

• неправильний підрахунок податку,

• нестача податкових декларацій,

• податкові декларації, що повторюються.

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

Дерево несправностей

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

Приклад дерева несправностей зображений на малюнку 11.13.1.

Рисунок 11.13.1. Приклад дерева несправностей.

Методи зменшення наслідків загрози

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

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