Визначення та сутність тестування

1.2.1. Важливі допоміжні поняття

Розкриття змісту тестування розпочнемо, визначивши базові поняття, які утворюють контекст його виконання, на підставі [1-3].

Програмна система ( Software system, ПС ) – група інтегрованих програмних засобів, що підтримують певний діловий процес Споживача і можуть використовувати спільні сховища даних.

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

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

Програмне забезпечення ( ПЗ) – сукупність програмних засобів, що придбаваються або розробляються для експлуатації у складі ПС. Будемо говорити «програмне забезпечення системи», якщо потрібно підкреслити його приналежність до ПС (яка включає також технічне, організаційне та інші види забезпечення). Отже, програмне забезпечення - це не тільки програми, але й уся документація щодо них.

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

Організаційною формою створення ПС є

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

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

Процес програмної інженерії, або конструювання,ПС( Software Engineering ) – система логічно взаємопов'язаних видів діяльності з визначення, проектування та побудови ПС.

Життєвий цикл розроблення (ЖЦ) ПС – період її існування від початку розроблення до впровадження/продажу. ЖЦ являє собою набір впорядкованих стадій (аналіз вимог, проектування, реалізація, тестування).

Робочий продукт ПС – подання знань розробників щодо неї на певній стадії її розроблення (вимоги та документи їх специфікації, опис архітектури, код, тести тощо).

Вимоги – сукупність тверджень щодо конкретних властивостей і характеристик, які повинна мати ПС, щоб нею можна було користуватися для вирішення тих задач, для яких вона призначена. Таким чином, вимоги визначають, яка поведінка ПС є правильною і бажаною (“якісною”), а яка має розглядатися як некоректна. Тому вимоги відіграють провідну роль під час тестування – саме вони мають перевірятися за його допомогою.

Вимоги зазвичай вилучаються за допомогою спеціальних процесів ЖЦ ПС і фіксуються в документі специфікації вимог (requirements specification).

Щоб вимоги до ПС можна було впевнено використовувати під час її розроблення й тестування, вони повинні мати низку характеристик, зафіксова-них у стандартах з розроблення ПС. Два таких стандарти – IEEE 830 [4] і IEEE 1233 [5] визначають необхідні характеристики правильно складених вимог:

1) адекватність – відповідність реальним потребам користувачів ПС;

2) однозначність, тобто відсутність можливості різного тлумачення;

3) повнота, тобто відображення у вимогах всіх істотних потреб і всіх ситуацій, за яких ПС має функціонувати;

4) несуперечність,або узгодженість, між різними елементами вимог;

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

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

7) придатність до перевірки, тобто можливість для кожної вимоги однозначно встановити за допомогою певного аналізу ПС, виконана вона чи ні;

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

Придатність і зручність програмного забезпечення для вирішення тих задач, для яких воно розроблялося, відображені в понятті його якості. За визначенням стандартів ДСТУ 2844-94 [2], ISO/IEC 9126: 2001 [3],

Якість ПС (Software Quality) –сукупність властивостей програмного забезпечення ПС, що забезпечують її здатність задовольняти встановлені, передбачувані або очікувані потреби відповідно до призначення.

Залежно від ситуації використання поняття якості в ЖЦ ПС, розрізняють внутрішню, зовнішню та експлуатаційну якість. Їх сутність та взаємозв’язки подано на рис. 1.2.

Згідно з рисунком, при визначенні вимог до якості, насамперед аналізу-ються характеристики експлуатаційної якості. На підставі аналізу вибираються певні характеристики зовнішньої якості, що якраз і відображають вимоги до ПС, функціонуючої в операційному середовищі під час тестування або експлуатації. Після визначення вимог в термінах характеристик зовнішньої якості специфікуються характеристики внутрішньоїі якості. Вони використовуються для планування дій з досягнення прийнятих значень зовнішніх характеристик якості ПС та їх втілення (“вбудовування”) в ПС впродовж розробки. На відміну від зовнішньої якості, поняття внутрішньої якості має сенс тільки для робочих продуктів ПС, не призначених для виконання на комп'ютері і створюваних на стадіях розробки до тестування (тобто визначення вимог, проектування, кодування).

Кольори на рис. 1.2 підкреслюють, що найбільш негативні наслідки у процесі розроблення ПС має неадекватне встановлення/недотримання характеристик саме внутрішньої якості (позначеної червоним кольором).

Рис 1.2– Використання градацій якості у ЖЦ ПС

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

Для вибору зовнішніх і внутрішніх характеристик якості використовуються різноманітні моделі якості ПС [1].

Модель якості – це множина взаємозв'язаних характеристик, які утворюють базис для специфікації вимог до якості та оцінювання якості ПС [3].

Наразі найбільш широко використовується еталонна, або рамкова (reference) модель якості ПО, зафіксована в наборі стандартів ISO 9126 [1]. Ця модель визначає шість основних характеристик зовнішньої та внутрішньої якості ПС та чотири характеристики експлуатаційної якості. Кожна характеристика уточнюється за допомогою спеціального набору підхаракте-ристик та метрик – кількісно вимірних властивостей підхарактеристик.

1.2.2. Основні трактування тестування

Розвиток програмної інженерії обумовив еволюцію поглядів на цілі й задачі тестування у процесі розроблення ПС. Вона мала такі основні етапи [6]:

1) до 1956 року –- орієнтація на відлагодження;

2) 1957-1978 рр. – орієнтація на встановлення відповідності ПС початковим вимогам;

3) 1979-1982 рр. – орієнтація на виявлення дефектів, що залишилися після реалізації;

4) 1983-1987 рр. – орієнтація на аналіз, перевірку і тестування з метою оцінки якості ПС на всіх стадіях розробки;

5) 1988-1995 рр. – інтеграція дій з перевірки і тестування в ЖЦ ПС з метою якомога раннього виявлення дефектів і попередження їх появи на всіх стадіях розробки.

Значну різноманітність сучасних трактувань тестування в залежності від ситуації його використання в ЖЦ ПС ілюструють три показові визначення, впорядковані за зростанням рівня їх загальності:

– процес виконання програми (або її частини) з метою виявлення помилок (Г. Майерс, 1982);

– динамічна перевірка поведінки програми на скінченому наборі тестових випадків, належним чином вибраних з нескінченного вхідного простору, на відповідність очікуваній поведінці (SWEBOK [7], 2004);

– процес аналізу елемента ПЗ для виявлення розбіжностей між існуючими і потрібними умовами та оцінки характеристик елемента ПЗ (IEEE Std. 610.12-1990).

Аналіз і узагальнення відомих визначень з використанням запроваджених вище понять дозволяє виділити чотири рольові погляди на тестування:

1) погляд тестувальника і програміста:

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

2) погляд менеджера програмного проекту:

система взаємопов’язаних робіт проекту, спрямованих на зниження витрат на ПС шляхом якомога раннього виявлення дефектів;

3) погляд аналітика, архітектора, супроводжувача ПС:

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

4) погляд члена групи якості:

– система взаємопов’язаних дій в основних процесах (Тестування ПЗ, Системна інтеграція, Системне тестування) і низці підтримуючих та організаційних процесів ЖЦ ПС, що надає індані для оцінювання якості ПС і її робочих продуктів;

– окрема область знань в ISO/IEC TR 19759:2005 (SWEBOK [7] ).

Якщо поточним поданням ПС є її виконувана реалізація в програмному коді, з визначення 1) випливає визначення динамічного тестування, або тестування коду.

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

Якщо ж поточним поданням ПС є її робочий продукт, формулювання 1) визначає статичне тестування.

Статичне тестування – оцінка проміжних продуктів у процесі розроблення ПС.

Чотири виділені словосполучення позначають визначальні аспекти динамічного тестування як окремого виду діяльності в ЖЦ ПС.

1. “ Перевірка відповідності вимогам підкреслює, що тестування можливе тільки за наявності вимог до ПС (програми). Тестування дозволяє проконтролювати якість ПС рівно настільки, наскільки повно, чітко і недвозначно (в розумінні стандартів [4], [5]) визначені вимоги до неї. Якщо вимоги явно не сформульовані, тестування можна виконувати, тільки ґрунтуючись на певних бажаних властивостях ПС, що неявно маються на увазі, наприклад, відсутності збоїв в її роботі. Перевірка відповідності вимогам ставить також так звану проблему оракула (еталона): потрібно вміти визначати, чи дійсно результати виконання коду відповідає вимогам.

2. “ Результати реальної роботи ” вказують на те, що перевірюваний код має виконуватися, щоб таку перевірку можна було вважати динамічним тестуванням. Цим динамічне тестування відрізняється від методів статичного тестування, базованих на аналізі проектних документів, без виконання самої програми (наприклад, статичного аналізу коректності коду) та методів контролю якості ПО (аналітичної верифікації)за допомогою доказу потрібних властивостей програми. Тестування відрізняється і від методів, що використовують функціонування деяких моделей програми, а не її самої, наприклад, від перевірки моделей (model checking), коли перевіряється, що певна модель програми має деяку властивість, і окремо робляться висновки щодо можливості перенесення цієї властивості на саму програму. Використання реального виконання тестованої ПС дозволяє застосовувати тестування для перевірки коректності її поведінки в робочому оточенні, на місці експлуатації, що неможливо зробити за допомогою інших методів контролю якості ПО.

3. “ Спеціально створені ситуації ”фіксуютьпринципову відмінність тестування як від пасивного спостереження за поведінкою ПС, так і від верифікації під час виконання (runtime verification), коли результати оперування ПС збираються і перевіряються, але це оперування не керується, не спрямовується на виникнення певних ситуацій. Такі ситуації звуться тестовими ситуаціями, а процедура або програма, при виконанні якої вони створюються і перевіряється правильність поведінки ПС у них, зветься тестом. Підготовка до проведення тестування завжди включає підготовку або розробку тестів.

4. “ Скінчений набір ситуацій ” нагадує, що можлива кількість ситуацій, які виникають під час тестування, обмежується практичними міркуваннями досягнення прийнятного компромісу між витратами часу і ресурсів проекту на розробку тестів і тестування та користю від нього – кількістю виявлених помилок, повнотою і адекватністю отриманої оцінки якості тестованої ПС. Через складність сучасних ПС повне тестування, хоча й можливе теоретично (внаслідок скінченності будь-якої обчислювальної системи), практично абсолютно нездійсненне. З одного боку, це означає, що проведення тестування ніколи не дає повної гарантії відсутності в тестованій ПС помилок. З іншого боку, ця обставина робить надзвичайно важливою проблему вибору тестів для виконання. Критичним для її вирішення є адекватний, відповідний реальній ситуації критерій повноти тестування.

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

– на відміну від аналітичної верифікації, тестування не може гарантувати повної відсутності помилок в коді ПС, але зате може перевірити коректність її роботи на місці експлуатації, під час взаємодії з іншими ПС;

– тестування завжди обмежене за ресурсами, але й надає гнучкі можливості управління повнотою і обсягом перевірок за рахунок різноманітних технік розробки і вибору тестів.

З тестуванням тісно пов’язані два спеціальні види діяльності в ЖЦ ПС.

Відлагодження (debug, debugging) – процесс пошуку, локалізації та виправлення помилок у програмі (IEEE Std. 610-12.1990)

Випробування ПС (software test) – технічна операція, що полягає в експериментальному встановленні однієї або кількох якісних і(або) кількісних характеристик програмного засобу згідно із встановленою процедурою (ДСТУ 2844-94)

Відмова (failure) – спостережуване порушення вимог до ПС, що виявляється при деякому сценарії її роботи.

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

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

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

Помилка розробника (error, mistake) – неправильне розуміння певної вимоги або обмеження, відсутність необхідних або наявність зайвих вимог.

Недолік розроблення (flaw) – некоректний опис деяких процесів ЖЦ ПС.

Як зазначено у SWEBOK, “тестування виявляє відмови, однак усувати можна і треба дефекти ” (див. рис. 1.3).

Основними джерелами дефектів (а отже, і відмов) У ЖЦ ПС є:

1) неправильне розуміння задач розробниками ПЗ або й самими користувачами та замовниками;

Рис. 1.3 – Взаємозв’язок аномалій у програмних проектах

2) неправильне розв’язання задач –обрані рішення можуть забезпечувати

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

3) неправильне перенесення рішень в код через особисті якості програміста або неадекватність засобів програмування.

1.2.3. Цілі та задачі тестування в ЖЦ ПС

Економічно виправдана місія тестування у процесі розроблення ПС – зниження вартості розроблення шляхом раннього виявлення дефектів

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

Як зазначає відомий практик тестування М.Болтон, “тестувальники – це додаткові очі, вуха, кінчики пальців, носи і органи смаку для програмістів і менеджерів. Ми – розширення їх органів чуття. В якнайкращому варіанті ми відіграємо роль надчутливих добре відкаліброваних приладів. Роль детекторів вибухових речовин. Ми допомагаємо програмістам і менеджерам побачити, почути і відчути те, що не завжди можливо відчути в межах типу мислення, який їм потрібен для роботи” (http://www.developsense.com).

Для реалізації своєї місії тестування в ЖЦ ПС переслідує чотири цілі.

1. Найбільш очевидна – п ошук відмов і дефектів, тобто розбіжностей між спостережуваною поведінкою ПС і вимогами до неї. Першочерговість цієї задачі зафіксована класичною фразою Е.Дейкстри «тестування може використовуватися для демонстрації наявності помилок в програмі, але не може використовуватися для демонстрації їх відсутності». Однак виявлені відмови – аж ніяк не єдина користь від тестування.

2. З агальна некількісна оцінка якості ПС та н адання вичерпних даних для її кількісних оцінок. Некількісна оцінка має, по-перше, включати інформацію про те, де, швидше за все, знаходяться ще не знайдені помилки, наскільки вони можуть бути серйозні, наскільки система, що тестується, надійно і коректно працює в цілому, наскільки коректні і стабільні її окремі функції і компоненти. Результатом таких перевірок є цінна інформація щодо властивостей ПС, недоступна з інших джерел. Таке тестування, якщо воно дійсно акуратне й систематичне, свідчить, що тестована ПС має прийнятну якість. Навіть якщо в ній і є помилки (їх відсутність довести за допомогою тестування неможливо), вони достатньо рідкі і трапляються в дуже специфічних ситуаціях. По-друге, саме така оцінка має надавати раціональні аргументи для визначення моменту припинення тестування.

3. Забезпечення стабільного розвитку ПС, надання засобів для відстеження змін в ній і прогнозу пов’язаних з ними проблем. Ефективні набори тестів на практиці стають не тільки засобом оцінки якості тестованої ПС і сертифікації її придатності для певних задач, але й інструментом відстеження важливих змін під час розвитку ПС та вимірювання її загальної стійкості й надійності. Однак для цього необхідно підтримувати набір тестів у працездатному стані, відповідному поточним вимогам до ПС.

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

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

1. Перевірка виконання вимог. Основна складність–необхідністьуточнювати вимоги до тестованої ПС і доопрацьовувати документи з їх поданням, роблячи їх більш ясними і повними та усуваючи наявні суперечності згідно вимог вищезгаданих стандартів [4], [5]. Для побудови систематичних і коректних тестів потрібне розуміння того, що може і має бути перевірено для кожної вимоги в кожній конкретній тестовій ситуації. При цьому в результаті аналізу вимог формується деяка модель вимог — цілісний, повний, несуперечливий і точний опис того, що повинна робити ПС. Вона вказує, як перевіряти правильність роботи ПС і дозволяє розмежувати формулювання перевіюваних вимог та проектування ситуацій для їх перевірки на два окремі види діяльності, підвищуючи якість обох.

2. Визначення критеріїв повноти тестування.