Розділ 5 принципи розробки програм для тестування

Тема 5.1 Особливості моделей апаратного забезпечення

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

 

Моделі апаратного забезпечення такими мовами як Verilog HDL і System являють собою системи з декількох взаємодіючих модулів. Як і в мовах програмування, модулі використаються для декомпозиції складної системи на безліч незалежних або слабко зв'язаних підсистем. Кожний модуль має інтерфейс - набір входів і виходів, через які здійснюється з'єднання модуля з оточенням, і реалізацію, що визначає спосіб обробки модулем вхідних сигналів: обчислення значень вихідних сигналів і зміна внутрішнього стану.

Обробка модулем вхідних сигналів ініціюється подіями з боку оточення. Під подіями в моделях апаратного забезпечення розуміють будь-які зміни рівнів сигналів. Оскільки звичайно розглядають двійкові сигнали, виділяють два основних види подій: фронт сигналу (posedge, positive edge) — зміна рівня сигналу з низького на високий і зріз сигналу (negedge, negative edge) — зміна рівня сигналу з високого на низький.

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

Важливою особливістю моделей апаратного забезпечення є наявність у них поняття часу: поводження таких моделей визначається не тільки послідовністю подій, але й тривалістю тимчасових інтервалів між ними. Час моделюється дискретною цілочисельною величиною, фізичний зміст одиниці часу можна задавати. Для опису причинно-наслідкових відносин між подіями, що відбуваються в одну одиницю модельного часу використається поняття дельта-затримки (delta delay). Події, між якими є дельта-затримка, виконуються послідовно одна за другою, але в ту саму одиницю модельного часу.

Для виконання моделей з метою аналізу їхнього поводження звичайно використають симуляцію по подіях (event-driven simulation). На відміну від симуляції по інтервалах часу (time-driven simulation), у якій значення сигналів і внутрішні стани модулів обчислюються через регулярні інтервали часу, у цьому способі модель розглядається тільки в ті моменти часу, коли наступають деякі події.

Робота подійного симулятора (event-driven simulator) здійснюється в такий спосіб. На початку симуляції модельний час установлюється в нуль. Далі в циклі, поки є активні процеси, вибирається один з них і виконується доти, поки цей процес не стане пасивним.

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

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

Моделі апаратного забезпечення й технологія UniTesК

Традиційна архітектура тестової системи для тестування моделей апаратного забезпечення виглядає в такий спосіб:

Мал. 5.1 Традиційна архітектура тестової системи.

Тестовий модуль (testbench) послідовно подає на модель, що тестується, тестові впливи й здійснює перевірку правильності реакцій на них. Результатом тесту є VCD4-файл, що створюється симулятором та містить зміни значень сигналів на входах і виходах моделі в часі. Отриманий файл звичайно використається для візуалізації хвильової діаграми тесту - традиційного засобу аналізу результатів тестування.

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

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

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

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

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

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

Тепер кілька слів про адаптацію тестової системи до виконання в симуляторі. Щоб тестова система могла бути виконана в симуляторі, вона повинна бути оформлена як окремий модельний процес. При цьому можливі дві різні ситуації: коли тестова система може прямо управляти виконанням цього модельного процесу (див. розділ «Тестування SystemC-моделей») і коли не може (див. розділ «Тестування Verilog-моделей»).

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

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

Приклад лічильника

Розглянемо приклад невеликого пристрою — лічильника, на Verilog- і SystemC-моделях якого ми будемо ілюструвати основні кроки розробки тестів. Інтерфейс лічильника складається із двох двійкових входів inc і rst і одного цілочисельного вихідного регістра cnt.

Мал. 5.2 Схема входів і виходів лічильника.

У відповідь на фронт сигналу inc, пристрій збільшує вміст регістра cnt на одиницю, на фронт rst — обнуляет регістр cnt. Зрізи сигналів не обробляються. Для спрощення специфікації й тестування будемо вважати, що поводження пристрою при одночасному виникненні фронтів сигналів на обох входах не визначено.

Розглянемо специфікацію лічильника мовою SeС. Специфікаційна модель даних містить у собі поточні значення вхідних сигналів inc і rst, а також вихідного регістра cnt:

// специфікаційна модель даних лічильника

typedef struct

{

bool inc; // поточне значення сигналу

// на вході inc

bool rst; // поточне значення сигналу

// на вході rst

int cnt; // поточне значення регістра cnt

} Model;

Специфікаційні функції описують поводження пристрою у відповідь на фронти й зрізи сигналів inc і rst. Нижче приводиться специфікаційна функція inc_posedge_spec, що описує реакцію на фронт сигналу на вході inc. Інші функції визначаються аналогічним чином.

// специфікація реакції на фронт сигналу на вході inc

specification void inc_posedge_spec(Model *model)

updates cnt = model->cnt,

inc = model->inc

{

pre { return model!= NULL && inc == false

&& cnt < INT_MAX; }

coverage C { return {single, "Single branch"}; }

post { return inc == true && cnt == @cnt + 1; }

}

Розглянемо сценарій тестування лічильника. Як стан кінцевого автомата для нашого приклада будемо просто використати стан специфікаційної моделі, тобто поточні значення вхідних сигналів inc і rst, а також вихідного регістра cnt. У цьому випадку функція обчислення стану кінцевого автомата буде виглядати як показане нижче.

static List* scenario_state()

{

List* list = create_List(&type_Integer);

append_List(list, create_Integer(model.inc));

append_List(list, create_Integer(model.rst));

append_List(list, create_Integer(model.cnt));

return list;

}

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

У початковому стані тесту встановлюємо низькі рівні сигналів inc і rst, а значенню регістра cnt привласнюємо нуль.

Нижче приводиться сценарна функція для фронту inc. Інші функції визначаються аналогічним образом.

scenario bool inc_posedge_scen()

{

if(model.cnt < 10)

{

if(pre_inc_posedge_spec(&model))

inc_posedge_spec(&model);

}

return true;}

 

Контрольні запитання:

1. Що представляють собою моделі апартного забезпечення мовами Verilog HDL та SystemC?
2. Як виконується обробка специфікаціних подій моделлю?
3. В чому особливість застосування технології UniTesK?
4. З чого складається традиційна архітектура тестової системи UniTesK?
5. Дайте визначення тестового модулю.
6. Як реалізовується тестовий модуль?
7. Приведіть приклад застосування технології UniTesK.

 

 

Тема 5.2 Тестування Verilog-моделей

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

 

Пропонована архітектура тестової системи показана на мал. 5.3

Тестова система складається із двох потоків:

• потоку симулятора Verilog - основного потоку;

• потоку тестової системи CTesК - підлеглого потоку.

На початку симуляції за допомогою виклику спеціальної функції із симулятора Verilog в окремому потоці запускається тестова система CTesК, що у циклі надає тестові впливи на Verilog-модель, що тестується, приймає реакції на них і оцінює правильність цих реакцій.

Мал. 5.3 Пропонована архітектура тестової системи.

Verilog-оточення містить екземпляр Verilog-моделі, що тестується. Воно здійснює ініціалізацію екземпляра моделі, запускає через VPI-модуль в окремому потоці тестову систему CTesК, від якої в циклі приймає тестові впливи і якої передає реакції моделі на них. Прийом тестових впливів і передача реакцій здійснюються через VPI-медіатор.

VPI-модуль зв'язує Verilog-оточення з тестовою системою CTesК. Він реалізує функцію запуску тестової системи CTesК і містить як складена частина VPI-медіатор.

VPI-медіатор зв'язує екземпляр Verilog-моделі, що тестується, з медіатором тестової системи CTesК. Він реалізує прийом тестових впливів від тестової системи CTesК і посилку реакцій моделі на них, а також здійснює синхронізацію станів екземпляра моделі й специфікаційної моделі даних тестової системи CTesК.

При виклику $startScenario з Verilog-оточення VPI-модуль запускає в окремому потоці тестову систему CTesК (генератор, оракул, медіатор). Далі в циклі здійснюються виклики $applyAction, для прийому чергового тестового впливу, і $checkAction, для передачі реакції на нього.

Примітка. VPI (Verilog Procedural Interface) або PLI (Programming Language Interface) 2.0 — стандартний інтерфейс, призначений для виклику з Verilog-модулів функцій, написаних мовою програмування C і інших мовах програмування.

Генератор через оракул передає медіатору черговий тестовий вплив Action, що перетворить його в посилку повідомлення ApplyAction VPI-модулю й переходить у стан очікування реакції на нього WaitForCheck.

VPI-модуль при виклику $applyAction переходить у стан очікування чергового тестового впливу WaitForAction і виходить із нього при одержанні повідомлення ApplyAction від медіатора тестової системи CTesК. Після цього він викликом SetSignals змінює потрібним образом вхідні сигнали екземпляра тестируемой Verilog-моделі й передає керування Verilog-оточенню, повертаючи статус OK.

При виклику $checkAction VPI-модуль, використовуючи GetSignals, одержує значення вихідних сигналів і синхронізує стану екземпляра Verilog-моделі й специфікації тестової системи CTes. Після цього він посилає повідомлення ApplyCheck медіатору.

При прийманні повідомлення ApplyCheck медіатор виходить зі стану WaitForCheck і передає керування оракулові, що перевіряє правильність реакції екземпляра Verilog-моделі, що тестується, на тестовий вплив.

Цикл завершується при одержанні VPI-модулем у стані очікування тестового впливу WaitForAction повідомлення Finish про завершення тесту від тестової системи CTesК.

Мал. 5.4 Послідовність взаємодії основних компонентів тестової системи.

Розробка тесту

Розглядається процес розробки тесту для Verilog-моделей апаратного забезпечення за допомогою інструмента CTesК. Для ілюстрації процесу будемо використати приклад лічильника (див. попередню тему).

Процес розробки тесту складається з наступних кроків:

1. Розробка специфікації пристрою.

2. Розробка модуля взаємодії потоків.

3. Розробка медіатора.

4. Розробка тестового сценарію.

5. Розробка Verilog-оточення.

6. Розробка VPI-модуля.

Розробка модуля взаємодії потоків

Модуль взаємодії потоків реалізує функції синхронізації потоку симулятора Verilog і потоку тестової системи CTesК. Ці функції використаються медіатором і VPI-модулем, тому модуль взаємодії потоків рекомендується розробляти перед розробкою медіатора або VPI-модуля.

Модуль взаємодії потоків повинен реалізовувати наступні функції:

• wait_for_check — функція очікування реакції на тестовий вплив. Викликається в медіаторі;

• wait_for_apply — функція очікування тестового впливу. Викликається в VPI-медіаторі, повертає ідентифікатор тестового впливу;

• apply_check — функція передачі реакції на тестовий вплив. Викликається в VPI-медіаторі;

• apply_finish — функція посилки повідомлення об завершення тесту. Викликається тестовою системою CTes;

• apply_<вплив> — функції посилки тестових впливів. Викликаються в медіаторі.

Також у модулі взаємодії потоків можна визначити функції:

• start_scenario — функція запуску тестової системи CTes. Викликається в VPI-медіаторі, створює необхідні для взаємодії потоків ресурси, установлює ім'я UniTesK-траси, запускає в окремому потоці тестову систему CTesК;

• end_scenario — функція завершення роботи тестової системи CTesК. Викликається в VPI-медіаторі при одержанні повідомлення про завершення тесту, звільняє створені ресурси.

Розробка медіатора

В інструменті CTesК медіатор реалізується c допомогою медіаторних функцій, кожна з яких зв'язує специфікаційну функцію із групою тестових впливів на цільову систему. Код медіаторної функції складається із блоку впливу (блоку call), у якому здійснюється тестовий вплив, і блоку синхронізації (блоку state), у якому здійснюється синхронізація стану специфікаційної моделі даних зі станом цільової системи.

Розробку медіатора для Verilog-моделі можна здійснити автоматично за наступною схемою:

• для кожної специфікаційної функції пишеться медіаторна функція наступного виду:

o блок call ≡ {apply_<вплив>(<параметри>);};

o блок state ≡ {wait_for_check();}.

 

Медіаторна функція для специфікаційної функції inc_posedge_spec буде виглядати в такий спосіб:

// медіаторна функція для inc_posedge_spec

mediator inc_posedge_media for

specification void inc_posedge_spec(Model *model)

updates cnt = model->cnt,

inc = model->inc

{

// посилаємо тестовий вплив

call { apply_inc_posedge(model); }

// очікуємо реакції

state { wait_for_check(); }

}

Розробка Verilog-оточення

Verilog-оточення являє собою модуль верхнього рівня мовою Verilog HDL і розробляється за наступною схемою:

• для кожного входу Verilog-моделі, що тестується, всередині Verilog-оточення визначається однотипний регістр;

• визначається екземпляр Verilog-моделі, що тестується, target, як аргументи якого виступають визначені раніше регістрами;

• визначається блок initial, всередині якого:

o встановлюється ім'я VCD-файлу й сигнали, що в нього трасуються;

o викликається системне завдання $startScenario, що запускає тестову систему CTesК;

o у циклі за допомогою системної функції $applyAction приймаються тестові впливи від тестової системи CTes і за допомогою системного завдання $checkAction посилають реакції на них.

Verilog-оточення використає системні завдання $startScenario, $checkAction і системну функцію $applyAction, які повинні бути реалізовані в VPI-модулі. Видно, що розробку Verilog-оточення можна повністю автоматизувати.

Розробка VPI-модуля

VPI-модуль розробляється мовою програмування C з використанням інтерфейсу VPI. Він повинен реалізовувати наступні системні функції й завдання:

• $startScenario — викликає функцію start_scenario модуля взаємодії потоків;

• $applyAction — викликає функцію wait_for_action модуля взаємодії потоків і залежно від значення, що повертає, робить необхідні зміни вхідних сигналів Verilog-моделі, що тестується;

• $checkAction — здійснює синхронізацію станів екземпляра Verilog-моделі й специфікації тестової системи CTes, після цього викликає функцію apply_check модуля взаємодії потоків;

 

Системна функція $applyAction і системне завдання $checkAction утворять VPI-медіатор. Розробку частини VPI-модуля, пов'язану із запуском тестової системи CTesК, можна повністю автоматизувати.

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

У таблиці показано, що розробку модуля взаємодії потоків, медіатора й Verilog-оточення можна автоматизувати повністю, розробку VPI-модуля - частково.

Тестування SystemC-моделей

Тестова система CTesК виконується в симуляторі System, вона подає на SystemC-модель, що тестується, тестові впливи, приймає реакції на них і оцінює правильність цих реакцій. Взаємодія тестової системи CTesК і SystemC-моделі, що тестується, здійснюється через C-медіатор.

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

Модуль запуску тестової системи призначений для запуску тестової системи CTesК в симуляторі System.

Розробка тесту

Розглянемо процес розробки тесту для SystemC-моделей апаратного забезпечення за допомогою інструмента CTesК. Для ілюстрації процесу будемо використати приклад лічильника.

Процес розробки тесту складається з наступних кроків:

1. Розробка C-медіатора.

2. Розробка специфікації системи.

3. Розробка медіатора.

4. Розробка тестового сценарію.

5. Розробка модуля запуску тестової системи.

Розробка C-медіатора

Оскільки інструмент CTesК призначений для розробки тестів для програмних інтерфейсів мовою програмування С, то з компонентів тестової системи CTesК не можна прямо звертатися до SystemC-моделі. Всі звертання до моделі, що тестується, повинні здійснюватися через спеціально розроблений С-медіатор, що надає інтерфейс для подачі тестових впливів і одержання реакцій моделі на них.

Нижче приводиться інтерфейс С-медіатора для SystemC-моделі лічильника.

#ifdef __cplusplus

extern "C" {

#endif // #ifdef __cplusplus

// интерфейсные функції, що здійснюють

// тестові впливи

// на екземпляр SystemC-моделі лічильника

void count_inc_posedge(void);

void count_rst_posedge(void);

void count_inc_negedge(void);

void count_rst_negedge(void);

// интерфейсные функції, що одержують інформацію

// про стан екземпляра SystemC-моделі лічильника

int count_inc(void);

int count_rst(void);

int count_cnt(void);

#ifdef __cplusplus

} #endif // #ifdef __cplusplus

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

Розробка медіатора

Після того, як створений C-медіатор, розробка медіатора здійснюється за наступною схемою:

• розробляється функція синхронізації станів map_state_up, що здійснює синхронізацію стану спецификационной моделі даних тестової системи CTesК зі станом екземпляра SystemC-моделі, що тестується;

• для кожної специфікаційної функції пишеться медіаторна функція наступного виду:

o у блоці call здійснюється виклик відповідної интерфейсной функції C-медіатора;

o у блоці state здійснюється виклик функції map_state_up.

Розробка модуля запуску тестової системи

Розробка модуля запуску тестової системи здійснюється за наступною схемою:

• розробляється функцію запуску тестової системи CTesК;

• розробляється SystemC-модуль для виклику тестової системи CTes в окремому модельному процесі.

Нижче приводиться функція count_start, що запускає тестовий сценарій count_scenario.

// функція запуску тестового сценарію

void count_start(const char *trace)

{

addTraceToFile(trace);

count_scenario(0, NULL);

}

Нижче приводиться SystemC-модуль для виклику тестової системи CTesК в окремому модельному процесі.

// модуль запуску тестової системи

SC_MODULE(count_testbench)

{ public:

// визначаємо окремий модельний процес

SC_CTOR(count_testbench) { SC_THREAD(main); }

// метод запуску тесту

void start(void) { sc_start(); }

// процес тестової системи CTes

void main(void)

{ count_start("simulation.unitrace"); } };

Видно, що розробку модуля запуску тестової системи можна повністю автоматизувати.

Можливість автоматизації кроків розробки

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

У таблиці показано, що розробку медіатора й модуля запуску тестової системи можна автоматизувати повністю.

Контрольні запитання:

1. З яких компонентів складається архітектура тестової системи?

2. Як відбувається взаємодія між компонентами архітектури тестової системи?

3. Як відбувається розробка тестів?

4. Як розробити модуль взаємодії потоків?

5. Дайте поняття розробки медіатора.

6. Розкажіть про розробку Verilog – оточення.

7. Які особливості розробки тестової системи для SystemC-моделей?

 

 

Тема 5.3 Тестування на етапі супроводу

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

 

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

Супровід

Значна частина засобів, які компанія затрачає на програмний продукт, іде вже після завершення його розробки. От які дані приводять у своєму підручнику Мартін і Мак-Клер (Martin & mcClure, 1984).

На супровід програмного забезпечення затрачається 67% його загальної вартості. Розподіляється ця сума так.

• 20% бюджету супроводу витрачається на виправлення помилок

• 25% іде на адаптацію продукту до нового апаратного забезпечення й нового програмного середовища

• 6% витрачається на виправлення документації

• 4% витрачається на підвищення продуктивності

• 42% витрачається на внесення змін і вдосконалень

• 3% на інші потреби

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

Адаптаційне тестування

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

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

• Клавіатура. Якщо в комп'ютера специфічна клавіатура, у роботі з нею можуть бути невеликі відхилення від стандарту. Тому потрібно обов'язково натиснути кожну клавішу, і до того ж у різних ситуаціях. Особливу увагу зазвичай звертають на керуючі клавіші - <Shift>, <Alt> і т.п.

• Термінал. Перевірте, як програма працює з новим терміналом. Як відображається графіка? Якщо програма працює в текстовому режимі, то чи всі символи відображаються правильно, немає чи проблем із кольором, підкресленням або підсвічуванням?

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

• Диски. Ємність і формат дисків можуть сильно відрізнятися. Переконайтеся, що програма правильно працює з файлами, розмір яких кратний 2. Якщо нова система підтримує розмір дисків, якого не підтримувала стара, спробуйте попрацювати з таким більшим диском.

• Обробка помилок операційною системою. Як діє операційна система в таких ситуаціях, як помилка доступу до диска? Чи дозволить вона прикладній програмі самої обробити цю ситуацію й видати коректне повідомлення або просто зупинить програму й повідомить про системну помилку? А як сам програмний продукт захищає користувача від помилок і примх операційної системи?

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

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

• Інтерфейс. У різних графічних середовищах (Windows, Mac, AmigaDOS, Motif і т.п.) діють різні угоди про користувальницький інтерфейс. Перейшовши в нове середовище, програма повинна виглядати в ній досить природно.

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

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

 

Контрольні питання:

1. Які роботи виконує тестувальник на етапі супроводу програмного продукту?
2. Дайте визначення адаптаційному тестуванню.
3. На які параметри програмного середовища необхідно звернути увагу при виконанні адаптаційного тестування?

Тема 5.4 Встановлення, наладка та використання пакету Everest

Завдання: виконати завдання, представлені в темі та законсппектувати хід виконання

до зошита.

 

 

Тема 5.5 Документування результатів роботи тестового пакету

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.