Принципи і види відладки програмного засобу.

Основні поняття.

ТЕСТУВАННЯ І ВІДЛАДКА ПРОГРАМНОГО ЗАСОБУ

Лекція 10.

Основні поняття. Стратегія проектування тестів. Заповіді відладки. Автономна відладка і тестування програмного модуля. Комплексна відладка і тестування програмного засобу.

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

Відладка = Тестування + Пошук помилок + Редагування.

У зарубіжній літературі відладку часто розуміють [10.1-10.3] тільки як процес пошуку і виправлення помилок (без тестування), факт наявності яких встановлюється при тестуванні. Іноді тестування і відладку вважають синонімами [10.4,10.5]. У наший країні в поняття відладки зазвичай включають і тестування [10.6 -10.8], тому ми слідуватимемо традиції, що склалася. Втім, сумісний розгляд в даній лекції цих процесів робить вказане різночитання не таким істотним. Слідує, проте, відзначити, що тестування використовується і як частина процесу атестації ПС (див. лекцію 14).

Успіх відладки ПС в значній мірі зумовлює раціональна організація тестування. При відладці ПС відшукуються і усуваються, в основному, ті помилки, наявність яких в ПС встановлюється при тестуванні. Як було вже відмічено, тестування не може довести правильність ПС [10.9], в кращому разі воно може продемонструвати наявність в нім помилки. Іншими словами, не можна гарантувати, що тестуванням ПС практично здійснимим набором тестів можна встановити наявність кожною наявною в ПС помилки. Тому виникає два завдання. Перше завдання: підготувати такий набір тестів і застосувати до них ПС, щоб виявити в нім по можливості більше число помилок. Проте чим довше продовжується процес тестування (і відладки в цілому), тим більшою стає вартість ПС. Звідси друге завдання: визначити момент закінчення відладки ПС (або окремою його компоненти). Ознакою можливості закінчення відладки є повнота обхвату пропущеними через ПС тестами (тобто тестами, до яких застосоване ПС) безлічі різних ситуацій, що виникають при виконанні програм ПС, і відносний рідкісний прояв помилок в ПС на останньому відрізку процесу тестування. Останнє визначається відповідно до необхідного ступеня надійності ПС, вказаної в специфікації його якості.

Для оптимізації набору тестів, тобто для підготовки такого набору тестів, який дозволяв би при заданому їх числі (або при заданому інтервалі часі, відведеному на тестування) виявляти більше число помилок в ПС, необхідно, по-перше, заздалегідь планувати цей набір і, по-друге, використовувати раціональну стратегію планування (проектування [10.1]) тестів. Проектування тестів можна починати відразу ж після завершення етапу зовнішнього опису ПС. Можливі різні підходи до вироблення стратегії проектування тестів, які можна умовно графічно розмістити (див. мал. 9.1) між наступними двома крайніми підходами [10.1]. Лівий крайній підхід полягає в тому, що тести проектуються тільки на підставі вивчення специфікацій ПС (зовнішнього опису, опису архітектури і специфікації модулів). Будова модулів при цьому ніяк не враховується, тобто вони розглядаються як чорні ящики. Фактично такий підхід вимагає повного перебору всіх наборів вхідних даних, оскільки інакше деякі ділянки програм ПС можуть не працювати при пропуску будь-якого тесту, а це означає, що помилки, що містяться в них, не виявлятимуться. Проте тестування ПС повним безліччю наборів вхідних даних практично нездійсненно. Правий крайній підхід полягає в тому, що тести проектуються на підставі вивчення текстів програм з метою протестувати всі шляхи виконання кожній програм ПС. Якщо взяти до уваги наявність в програмах циклів із змінним числом повторень, то різних шляхів виконання програм ПС може опинитися також надзвичайно багато, так що їх тестування також буде практично нездійсненно.

Мал. 10.1. Спектр підходів до проектування тестів.

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

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

· на кожну область і на кожну межу зміни якої-небудь вхідної величини - хоч би один тест

· на кожну особливу (виняткову) ситуацію, вказану в специфікаціях, - хоч би один тест.

У другому випадку ця стратегія базується на принципі: кожна команда кожної програми ПС повинна пропрацювати хоч би на одному тесті.

Оптимальну стратегію проектування тестів можна конкретизувати на підставі наступного принципу: для кожного програмного документа (включаючи тексти програм), що входить до складу ПС, повинні проектуватися свої тести з метою виявлення в нім помилок. В усякому разі, цей принцип необхідно дотримувати відповідно до визначення ПС і змістом поняття технології програмування як технології розробки надійних ПС (див. лекцію 1). У зв'язку з цим Майерс навіть визначає різні види тестування [10.1] залежно від вигляду програмного документа, на підставі якого будуються тести. У наший країні розрізняються [10.8] два основні види відладки (включаючи тестування): автономну і комплексну відладку ПС. Автономна відладка ПС означає послідовне роздільне тестування різних частин програм, що входять в ПС, з пошуком і виправленням в них помилок, що фіксуються при тестуванні. Вона фактично включає відладку кожного програмного модуля і відладку сполучення модулів. Комплексна відладка означає тестування ПС в цілому з пошуком і виправленням помилок, що фіксуються при тестуванні, у всіх документах (включаючи тексти програм ПС), що відносяться до ПС в цілому. До таких документів відносяться визначення вимог до ПС, специфікація якості ПС, функціональна специфікація ПС, опис архітектури ПС і тексти програм ПС.