Успіх налагодження в значній мірі визначає раціональна організація тестування. При налагодженні відшукуються й усуваються, в основному, ті помилки, наявність яких у ПЗ установлюється при тестуванні. Як було вже відзначене, тестування не може довести правильність ПЗ, у найкращому разі воно може продемонструвати наявність у ньому помилки. Інакше кажучи, не можна гарантувати, що тестуванням ПЗ практично здійсненним набором тестів можна встановити наявність кожної наявної в ПЗ помилки. Тому виникає два завдання. Перша: підготувати такий набір тестів і застосувати до них ПЗ, щоб виявити в ньому по можливості більше число помилок. Однак чим довше триває процес тестування (і налагодження в цілому), тим більшої стає вартість ПЗ. Звідси друге завдання: визначити момент закінчення налагодження ПЗ (або окремого його компонента). Ознакою можливості закінчення налагодження є повнота охоплення пропущеними через ПЗ тестами (тобто тестами, до яких застосоване ПЗ) безлічі різних ситуацій, що виникають при виконанні програм ПЗ, і відносно рідкий прояв помилок у ПЗ на останньому відрізку процесу тестування. Останнє визначається відповідно до необхідного ступеня надійності ПЗ, зазначеної в специфікації його якості.
Для оптимізації набору тестів, тобто для підготовки такого набору тестів, що дозволяв би при заданому їхньому числі (або при заданому інтервалі часу, відведеному на тестування) виявляти більше число помилок, необхідно, по-перше, заздалегідь планувати цей набір і, по-друге, використовувати раціональну стратегію планування (проектування) тестів. Проектування тестів можна починати відразу ж після завершення етапу зовнішнього опису ПЗ. Можливі різні підходи до вироблення стратегії проектування тестів, які можна умовно графічно розмістити між наступними двома крайніми підходами. Лівий крайній підхід полягає в тім, що тести проектуються тільки на підставі вивчення специфікацій ПЗ (зовнішнього опису, опису архітектури й специфікації модулів). Будова модулів при цьому ніяк не враховується, тобто вони розглядаються як чорні ящики. Фактично такий підхід вимагає повного перебору всіх наборів вхідних даних, тому що при використанні як тести тільки частини цих наборів деякі ділянки програм ПЗ можуть не працювати ні на якому тесті й, виходить, що втримуються в них помилки не будуть проявлятися. Однак тестування ПЗ повною безліччю наборів вхідних даних практично нездійсненно. Правий крайній підхід полягає в тім, що тести проектуються на підставі вивчення текстів програм з метою протестувати всі шляхи виконання кожної програм ПЗ. Якщо взяти до уваги наявність у програмах циклів зі змінним числом повторень, то різних шляхів виконання програм ПЗ може виявитися також надзвичайно багато, так що їхнє тестування також буде практично нездійсненно.
Рис. Спектр підходів до проектування тестів.
Оптимальна стратегія проектування тестів розташована усередині інтервалу між цими крайніми підходами, але ближче до лівого краю. Вона включає проектування значної частини тестів по специфікаціях, виходячи із принципів: на кожну використовувану функцію або можливість - хоча б один тест, на кожну область і на кожну границю зміни якої-небудь вхідної величини - хоча б один тест, на кожний особливий випадок або на кожну виняткову ситуацію, зазначені в специфікаціях, - хоча б один тест. Але вона вимагає також проектування деяких тестів і по текстах програм, виходячи із принципу (як мінімум): кожна команда кожної програми ПЗ повинна проробити хоча б на одному тесті.
Оптимальну стратегію проектування тестів можна конкретизувати на підставі наступного принципу: для кожного програмного документа (включаючи тексти програм), що входить до складу ПЗ, повинні проектуватися свої тести з метою виявлення в ньому помилок. У всякому разі, цей принцип необхідно дотримувати відповідно до визначення ПЗ і змістом поняття технології програмування як технології розробки надійних ПЗ (див. лекцію 1). У зв'язку із цим Майерс навіть визначає різні види тестування залежно від виду програмного документа, на підставі якого будуються тести. У нашій країні розрізняються два основних види налагодження (включаючи тестування): автономне й комплексне налагодження. Автономне налагодження означає тестування тільки якоїсь частини програми, що входить у ПЗ, з пошуком і виправленням у ній фіксуємих при тестуванні помилок. Вона фактично включає налагодження кожного модуля й налагодження сполучення модулів. Комплексне налагодження означає тестування ПЗ у цілому з пошуком і виправленням фіксуємих при тестуванні помилок у всіх документах (включаючи тексти програм ПЗ), що ставляться до ПЗ у цілому. До таких документів ставляться визначення вимог до ПЗ, специфікація якості ПЗ, функціональна специфікація ПЗ, опис архітектури ПЗ і тексти програм ПЗ.
