2.1. Введення. Поняття процесу програмування якісно ізменілісь.Проізводство програм набуло масового характеру, существенноувелічілісь їх обсяг і складність. Розробка програмних комплексом потребувала значних зусиль великих коллектівовспеціалістов. Програми перестали бути тільки вичіслітельниміі почали виконувати найважливіші функції з управління і обработкеінформаціі в різних галузях. Розвиток і застосування технологій проектування комплексовпрограмм призводить до необхідності вимірювання та порівняння їх ефективних перш за все за ступенем впливу на якість прог-раммного продукту. Забезпечення високої якості складних комплексів программсвязано зі значними витратами праці розробників. Затру-ти на створення програм швидко збільшуються при возрастаніітребованій, причому для складних комплексів вельми складно дос-тічь високої якості функціонування, і після обеспеченіяобщей працездатності можуть знадобиться роки праці для полу-чення необхідних показників якості. Тому вже сегоднятребуются методи і засоби, які дозволили б помітно по-висіть якість програм програм при відносно невисокіхзатратах праці. 2.2. Обгрунтування вибору технології тестування. Як відомо, під час створення типового програмного проектаоколо 50% загального часу і більше 50% загальної вартості витраті-ється на перевірку (тестування) розробляється програми ілісістеми. Крім того, частка вартості тестування в загальній стои-мости програм має тенденцію зростати при збільшенні складність ності комплексів програм і підвищення вимог до їх качест-ву. З огляду на це, при відпрацюванні технології тестування прог-Рамм слід чітко виділяти певний (по можливості неочень велика) число правил налагодження, що забезпечують високоекачество програмного продукту і знижують витрати на його ство-даніе. Тестування - це процес виконання програми з цельюобнаруженія помилок. Одним із способів вивчення поставленноговопроса є дослідження стратегії тестування, називає-мій стратегією чорного ящика, тестуванням з керуванням поданням, або тестуванням з управлінням по входу-виходу. Прііспользованіі цієї стратегії програма розглядається какчерний скриньку. Тестові дані використовуються тільки у відповідних вії зі специфікацією програми (тобто без урахування знань про еевнутренней структурі). При такому підході виявлення всіх помилок у програмі яв-ся критерієм вичерпного вхідного тестування. Послід-неї може бути досягнуто, якщо в якості тестових наборовіспользовать всі можливі набори вхідних даних. Слідчий-но, ми приходимо до висновку, що для вичерпного тестірованіяпрограмми потрібно нескінченне число тестів, а значить побудувати-ение вичерпного вхідного тесту неможливо. Це підтверджують ється двома аргументами: по-перше, не можна створити тест, гаран-тірующій відсутність помилок, по-друге, розробка таких тес-тов суперечить економічним вимогам. Оскільки ісчерпи-БЕЗПЕЧУЮТЬ тестування виключається, нашою метою має стати мак-сімізація результативності вкладення капіталовкладень в тести-вання (максимізація числа помилок, що виявляються одним тес-те). Для цього необхідно розглядати внутрішню структурупрограмми і робити деякі розумні, але, звичайно, не облад-ющіе повною гарантією вірогідності припущення. Стратегія білого ящика, чи стратегія тестування, управ-ляемого логікою програми, дозволяє досліджувати внутреннююструктуру програми. У цьому випадку тестує отримує тісто-ші дані шляхом аналізу логіки програми. Порівняємо спосіб побудови тестів при даній стратегії сісчерпивающім вхідним тестуванням стратегії чорного ящіка.Неверно припущення, що достатньо побудувати такий набортестов, в якому кожен оператор виконується хоча б одінраз. Вичерпного вхідного тестування може бути поставлене-но у відповідність вичерпне тестування маршрутів. Підрив-зумевается, що програма повністю перевірена, якщо з помощьютестов вдається здійснити виконання цієї програми з всемвозможним маршрутами її потоку (графа) передач управління. Останнє твердження має два слабкі пункти: по-перше, число не повторюють один одного маршрутів - астрономічне, по-друге, навіть якщо кожен маршрут може бути перевірений, самапрограмма може містити помилки (наприклад, деякі маршрутипропущени). У результаті всіх викладених вище зауважень можна зазначити, що ні вичерпне вхідне тестування ні вичерпують-ний тестування маршрутів не можуть стати корисними стратегія-ми, тому що обидва вони не реалізовуються. Тому реальним шляхом, який дозволить створити хорошу, але, звичайно не абсолютнуюстратегію, є поєднання тестування програми несколь-кими методами. 2.3. Розробка технологічного процесу тестування. Якщо відмовитися від тестування всіх шляхів, то можна поки-мовити, що критерієм покриття є виконання кожного опе-ратора програми принаймні один раз. Як приклад візьмемо тестування модуль Param.Предназначеніе модуля - розбирати командний рядок з парамет-рами на окремі параметри. Об'єктом тестування оберемо правило ParamStr об'ектаParameters. function Parameters.ParamStr (ParamNum: byte): string; begin if ParamNum = 0 then if Delux then ParamStr: =''else if Lo (DosVersion)> = 3 then ParamStr: = system.ParamStr (0) else ParamStr: = ' 'else ParamStr: = OptionStr (ParamNum); end; Схема алгоритму цієї функції: --------------------¬ | Початок | L -------- -T ---------- |// ні/ParamNum ----------------¬ = 0/|/---------- +---------¬/да | ParamStr = | | | OptionStr (ParamNum) |/L --------- T ---------- так/| -- = 3/| | |/| | |/да | | | -----------+---------¬ ---------+--- -----¬ | | | ParamStr = System. | | ParamStr =''| | | | ParamStr (0) | L -------- T --------- | | L ---------- T ---------- | | L ----------------> + = 3 буде оші-Бочна записано Lo (DosVersion)> 3. Під час тестування по данно-му критерію ця помилка не буде виявлена. Більш сильний критерій покриття логіки програми ізвестенкак покриття рішень, або покриття переходів. Згідно данно-му критерієм має бути записано достатню кількість тестів, та-дещо, що кожне рішення на цих тестах набуде значення істінаі брехня принаймні один раз. Можна показати, що покриття рішень звичайно удовлетворяеткрітерію покриття операторів. Оскільки кожен оператор лежітна деякому шляху, що виходить з оператора переходу, або ізточкі входу програми, при виконанні кожного напряму пе-рехода кожен оператор повинен бути виконаний. Отже, тести наведені вище підходять і для цього критерію. Однак існують винятки, наприклад, оператор case. Ветом операторі можливі не двозначні рішення. CASE умова OF m1: оператор1; m2: оператор2; m3: оператор3 ELSE m4: оператор4 END Критерієм для таких випадків є виконання каждоговозможного результату всіх рішень по крайней мере один раз. Кращим критерієм в порівнянні з попереднім є покриття-нення умов. У цьому випадку записують кількість тестів, достатній-не для того, щоб всі можливі результати кожного условіяв вирішенні виконувалися принаймні один раз. Розглянемо приклад на функції OptionStr. function Parameters.OptionStr (ParamNum: byte): string; var I, Len: Byte; begin Len: = 0; I: = OptPosition (ParamNum); if I 0 then while (I + | ParStr (I) в/| | OptDelim/| |/| |/ні | | ----------+---------¬ | | | Len = Len + 1; | | | | OptionStr (Len) = | | | | ParStr (I) | | | L --------- T ---------- | L ---------------- | ------------------------ ----------+---------¬ | Кінець | L -------------------- Рис 2.2. Функція містить три умови: I = 0, I0 в першу умови іISLen, (ParStr [i] in OptDelim) = true, ( ParStr [i] inOptDelim) = false в другому умови. Тести, що задовольняють критерію покриття умов піведенив таблиці 2.2. (нехай стоку параметрів має вигляд: MAIN.GRM/Q/P, SLen = 13, ParamNum = 1): Табл. 2.2. г === T ================== T =================== T ====== ==============¬| N | Вхідні дані | Очікуваний результат | Отриманий результат ||---+------------------ +-------------------+--------------------|| 1 | I = 0 | OptionStr (0) = 0 | OptionStr (0) = 0 | | | | | ||---+------------------+-------- -----------+--------------------|| 2 | I = 1 | OptionStr (0) = 0 | OptionStr (0 ) = 0 | | | (ParStr [i] in | | | | | OptDelim) = true | | ||---+------------------+-- -----------------+--------------------|| 3 | I = 1 | OptionStr (0) = 8 | OptionStr (0) = 8 | | | (ParStr [i] in | | | | | OptDelim) = false | | ||---+--------------- ---+-------------------+--------------------|| 4 | I = 11 | OptionStr (0) = 0 | OptionStr (0) = 0 | | | (ParStr [i] in | | | | | OptDelim) = true | | ||---+--------- ---------+-------------------+-------------------- | | 5 | I = 11 | OptionStr (0) = 0 | OptionStr (0) = 0 | | | (ParStr [i] in | | | | | OptDelim) = false | | | L ===|=== ===============|===================|============== ======- Хоча застосування критерію покриття умов на первийвзгляд задовольняє критерію покриття рішень, це не всегдатак. Якщо тестується рішення if A and B then ... то при критерії покриття умов потрібні були б два тести: A = true, B = false і A = false, B = true. Але в цьому случаене виконувалося б then-пропозиція оператора if. Існує ще один критерій, названий покриттям реше-ній/условій. Він вимагає такого достатнього набору тестів, щоб всі можливі результати кожної умови в рішенні виконуваних принаймні один раз, всі результати кожного ре-ня виконувалися принаймні один раз і кожній точці входити-да передавалося управління принаймні один раз. Недоліком критерію покриття рішень/умов є не-можливість його застосування для виконання всіх результатоввсех умов; часто таке виконання має місце в следст-умові того, що певні умови приховані іншими условіямі.Напрімер, якщо умова AND це неправда, то ніяке з подальші-щих умов у виразі не буде виконано. Аналогічно, есліусловіе OR є істина, то жодне з наступних умов небудет виконано. Отже, критерії покриття умов іпокритія рішень/умов недостатньо чутливі до ошібкамв логічних виразах. Критерієм, який вирішує ці та деякі інші пробле-ми, є комбінаторне покриття умов. Він вимагає ство-ня такого числа тестів, щоб всі можливі комбінації різу-льтатов умови в кожному рішенні і всі крапки входу виконуємо-лись принаймні один раз. Розглянемо правило CheckTreeNil в модулі TmObejct об'ектаMain. procedure Main.CheckTreeNil; var tn: boolean; begin tn: = (GetPtrOfClass (SCl) = nil) and (GetPtrOfClass (UCl) = nil) and (GetPtrOfClass (ACl) = nil); if tn then Error ( 'не знайдено жодного нетермінал'); end; Алгоритм процедури: --------- -----------¬ | Початок | L --------- T ---------- |//// G (SCl) = nil/і немає/G (UCl) = nil -----------¬ і/| G (ACl) = nil/|/|/|/да | | | ----------- ---------+------------------¬ | | Error ( 'не знайдено жодного нетермінал') | | L ------ ------------- T ------------------- | + nil | | | | 2 | GetPtrOfClass (UCl) = nil | tn = false | tn = false | | | GetPtrOfClass (ACl) = nil | | ||---+--------------------------- +------------+------------|| | GetPtrOfClass (SCl) = nil | | | | 3 | GetPtrOfClass (UCl) nil | tn = false | tn = false | | | GetPtrOfClass (ACl) = nil | | ||---+---------------------------+- -----------+------------|| | GetPtrOfClass (SCl) nil | | | | 4 | GetPtrOfClass (UCl) nil | tn = false | tn = false | | | GetPtrOfClass (ACl) = nil | | ||---+---------------------------+---- --------+------------|| | GetPtrOfClass (SCl) = nil | | | | 5 | GetPtrOfClass (UCl) = nil | tn = false | tn = false | | | GetPtrOfClass (ACl) nil | | ||---+---------------------------+------ ------+------------|| | GetPtrOfClass (SCl) nil | | | | 6 | GetPtrOfClass (UCl) = nil | tn = false | tn = false | | | GetPtrOfClass (ACl) nil | | ||---+---------------------------+--------- ---+------------|| | GetPtrOfClass (SCl) = nil | | | | 7 | GetPtrOfClass (UCl) nil | tn = false | tn = false | | | GetPtrOfClass (ACl ) nil | | ||---+---------------------------+------------ +------------|| | GetPtrOfClass (SCl) nil | | | | 8 | GetPtrOfClass (UCl) nil | tn = false | tn = false | | | GetPtrOfClass (ACl) nil | | | L ===|===========================|============|=== =========- У разі циклів кількість тестів для задоволення крітеріюкомбінаторного покриття умов зазвичай більше, ніж число пу-тей. Легко бачити, що набір тестів, що задовольняє крітеріюкомбінаторного покриття умов, задовольняє також і крите-ріям покриття рішень, покриття умов і покриття рішень/ус-ловій. Таким чином, для програм, що містять тільки одне усло-віє на кожне рішення, мінімальним є критерій, набортестов якого: - викликає виконання всіх результатів кожного рішення покрайней мере один раз; - передає управління кожній точці входу (наприклад, опера-тор CASE). Для програм, що містять рішення, кожне з яких імеетболее однієї умови, мінімальний критерій складається з наборатестов, що викликають всіх можливих комбінацій результатів усло-вий у кожному рішенні і передають управління кожній точці входити-да програми з принаймні один раз. У світлі всього вищевикладеного, можна зобразити алгорітмвибора мінімального критерію, за яким необхідно тестую-ти програму (див. рис. 2.4.). ------------------ - ¬ | Початок | L --------- T ---------- ----------------------- ---------->+ | ----------+---------¬ | | Вибір оператор | | | умовного переходу | | L ---- ----- T ---------- |/|/|/ні |/Це оператор ---------¬ | IF/| |/| |/| |/да | | | | |/| |/| | так/Умова немає | | ----------/ містить --------->+ | | більше одного/| | | комп - та/| | |/| | |/| | ----------------+---------------¬ ----- -----------+-------------¬ | | Набір тестів, що викликає все | | Набір тестів, що викликає | | | можливі комбінації резуль-в | | виконання всіх результатів | | | умов у кожному рішенні не | | кожного рішення не менш | | | менше одного разу. | | одного разу. | | L --------------- T --- ------------- L --------------- T -------------- | L ---- -----------> T