Список використаних джерел. Пояснювальна записка
Пояснювальна записка
В структурі дисципліни „Тестування програмних систем і комплексів” передбачено 7 практичних робіт – 3 в першому семестрі та 4 в другому. Практичні роботи призначені для закріплення отриманих на лекціях знань, а також для набуття студентами практичних навиків процесу тестування.
Тематика практичних занять
| № заняття | Назва | Кількість годин |
| Тестування галужень та операторів відношень | ||
| Тестування циклів | ||
| Функціональне тестування | ||
| Тестування об’єктно-орієнтованої програмної системи | ||
| Проектування об’єктно-орієнтованих тестових варіантів | ||
| Планування тестування | ||
| Використання тестового пакету Everest | ||
| Всього |
Після виконання практичної роботи та відповіді на контрольні запитання, студент допускається до захисту роботи та отримує оцінку.
Критерії оцінювання виконання практичних робіт
1. «Відмінно»заслуговує студент, який виконав практичну роботу в повному обсязі, при цьому:
- робота охоплює всі істотні аспекти завдання і контрольних питань;
- завдання роботи виконане студентом самостійно і на високому рівні;
- при виконанні роботи дотримані загальні зауваження і поради викладача;
- звіт практичної роботи оформлений акуратно, грамотно структурований, не містить довільних скорочень і інформації, що не стосується теми роботи;
- робота виконана і захищена своєчасно.
2. «Добре» заслуговує студент, який виконав практичну роботу в повному обсязі, при цьому:
- студент правильно розуміє завдання та контрольні питання;
- завдання роботи виконане студентом самостійно, допущені незначні помилки, які були виправлені самостійно за порадами викладача;
- звіт практичної роботи оформлений в цілому акуратно, але містить численні виправлення; містить досить детальний опис предмету завдання та відповіді на контрольні питання, в ньому приведені та розкриті в тезовій формі основні поняття, відсутні помилкові положення;
- робота виконана та захищена своєчасно.
3. «Задовільно» заслуговує студент, який виконав практичну роботу в повному обсязі, при цьому:
- студент допустив неповне або неточне виконання завдання та помилки у відповідях на контрольні питання, а також окремих основних понять, що стосуються практичної роботи;
- робота містить окремі помилкові положення, які не мають визначального впливу на виконання завдання;
- звіт оформлено неакуратно, він містить виправлення об’ємних структурних частин і значну кількість нечітких формулювань.
4. «Незадовільно» отримують студенти, які:
- не змогли показати необхідний рівень знань для виконання практичного завдання;
- припустилися значних помилок: підхід до виконання завдання практичної роботи є неправильним у цілому і містить, в основному, помилкові положення; не розкриті основні поняття, що відносяться до предмету завдання практичної роботи;
- зовсім не виконали практичну роботу.
Практична робота №1
Тема. Тестування галужень та операторів відношень
Мета: навчитися використовувати різні методи тестування галужень та операторів відношень; провести порівняльний аналіз способів тестування.
Хід заняття
1. Організаційна частина
а) готовність групи до заняття;
б) психоемоційний настрій;
в) перевірка присутніх;
2. Актуалізація опорних знань студентів:
а) повідомлення теми та мети;
б) повідомлення основних тем, по яким відбувається практична робота.
3. Закріплення вмінь та навичок студентів
Теоретичні відомості. Для тестування галужень та операторів відношень можна використовувати методи структурного тестування „білого ящика”, а саме: метод базового шляху, спосіб тестування умов, а також спосіб тестування гілок та операторів відношень.
Для використання методу базового шляху необхідно виконати наступні кроки:
1) на основі тексту програми сформувати потоковий граф;
2) визначити цикломатичну складність потокового графу (по кожній з 3-х формул);
3) визначити базову множину незалежних лінійних шляхів;
4) розробити тестові варіанти для виконання кожного шляху.
Способи тестування умов містяться в тестуванні кожної гілки логічних умов програми. Простий спосіб міститься в тестуванні кожної простої умови, що входить в склад, при цьому перевіряється кожна true – та false – гілки. Інша методика тестування - тестування області визначення. При використанні даного методу необхідно виконати наступні кроки:
- побудувати обмеження умов;
- виявити обмеження результату по кожній простій умові;
- використовуючи константні формули ОМ& або OMOR будуємо обмежуючу множину (ОМ);
- для кожного елемента ОМ розробляється тестовий варіант.
4. Основна частина заняття:
Завдання. Використовуючи способи тестування, що наведені в теоретичних відомостях, виконати тестування частини програми за варіантом:
| Варіант 1. ……… var a, b, c, m:real; ………… if (a>b) then m:=(a-b)*c else begin if (a=c) then m:=(a+b)*c else writeln (“Vvedite drugie chisla!”); end; | Варіант 2. ……… var s, k, r, p:real; ………… if (s=k) then p:=(sqr(r)) else begin if (s>r)or(s>k) then p:=(s+k)*r else writeln(“p=0”); end; |
Приклад виконання роботи.
Для прикладу розглянемо тестування наступного коду:
………
var a, b, c, s:real;
…………
if (a<b) then s:=(a+b)*c
else begin
if (a>b) and(a<c)then s:=a/(b+c)
else s:=a+b+c;
end;
Тестуємо наведений код програми методом базового шляху:
1) 
Перетворюємо код в вершини та будуємо потоковий граф:
1: введення даних
2:якщо (a<b)
3: то s:=(a+b)
4:інакше якщо
5: (a>b) та (a<c)
6:то s:=a/(b+c)
7:інакше s:=a+b+c
8: кінець інакше
8: кінець програми
2) Розраховуємо цикломатичну складність 3-ма способами:
ЦС(1): V(G) = 9-8+2=3
ЦС(2): V(G) = 2пр.вуз.+1=3
ЦС(3): V(G) = 3 регіони
3) Базова множина незалежних лінійних шляхів:
Шлях 1: 1-2-3-8
Шлях 2: 1-2-4-7-8
Шлях 3:1-2-4-5-6-8
4) Тестові варіанти
| ТВ1: ПД: а=2, в=3, с=2 Оч.рез. : s=(2+3)*2=10 | ТВ2: ПД: а=5, в=2, с=7 Оч.рез. : s=5/(2+7)=5/9 |
| ТВ3: ПД: а=5, в=2, с=2 Оч.рез. : s=5+2+2=9 |
Тестуємо наведений код методом тестування галужень та операторів відношень.
1) будуємо обмеження умов:
С1=(a<b)
C2=(a>b)and(a<c)
1.1 ОУС1=(>,<,=)
OMC1={true, false,false}
ТВ1: ПД: а=5, в=7 Оч.рез. : (a<b)=true
ТВ2: ПД: а=5, в=2 Оч.рез. : (a>b)=false
ТВ3: ПД: а=2, в=2 Оч.рез. : (a=b)=false
1.2.1 ОУС2=(d1, d2,d3)
d1=(>,<,=)=(true,false,false)
d2=(true,false)
d3=(>,<,=)=(false, true, false)
1.2.2 будуємо таблицю істинності:
| & | a<b | a=b | a>b |
| a<c | false | false | true |
| a=c | false | false | false |
| a>c | false | false | false |
1.2.3 Використовуючи правила мінімізації скорочуємо кількість тестових варіантів та будуємо обмежуючу множину:
OMC2 = {(true, false,false), (false,false,false)}
1.2.4 Складаємо тестові варіанти:
ТВ1: ПД: а=2, в=1, c=3 Оч.рез. : true
ТВ2: ПД: а=2, в=2, c=4 Оч.рез. : false
ТВ3: ПД: а=2, в=5, c=4 Оч.рез. : false
ТВ4: ПД: а=2, в=5, c=2 Оч.рез. : false
ТВ5: ПД: а=2, в=2, c=2 Оч.рез. : false
ТВ6: ПД: а=2, в=5, c=4 Оч.рез. : false
Висновок: аналізуючи використані методики тестування, можна зробити висновок, що метод базового шляху є легким, але він не враховує особливостей тестування складених операторів галуження, тому для операторів галуження варто застосовувати метод тестування галужень та операторів відношень.
5. Контрольні запитання
5.1 Які особливості має потоковий граф?
5.2 Поясніть поняття цикломатичної складності.
5.3 Поясніть переваги та недоліки способу тестування галужень та операторів відношень.
6. Узагальнення та систематизація вмінь і навичок.
7. Підведення підсумків заняття.
8. Самостійна робота:за розглянутим прикладом самостійно виконати завдання та відповісти на контрольні запитання.
Практична робота № 2
Тема: Тестування циклів.
Мета: розглянути на практиці способи тестування циклів, порівняти вивчені способи, навчитися використовувати вивчені засоби тестування.
Хід заняття
1. Організаційна частина
а) готовність групи до заняття;
б) психоемоційний настрій;
в) перевірка присутніх;
2. Актуалізація опорних знань студентів:
а) повідомлення теми та мети;
б) повідомлення основних тем, по яким відбувається практична робота.
3. Закріплення вмінь та навичок студентів
Теоретичні відомості. Прості цикли
Для перевірки простих циклів з кількістю повторень n може використатися один з наступних наборів тестів:
1) прогін усього циклу;
2) тільки один прохід циклу;
3) два проходи циклу;
4) m проходів циклу, де m<n;
5) n - 1, n, n + 1 проходів циклу.
4. Основна частина заняття:
Завдання. Використовуючи способи тестування, що наведені в теоретичних відомостях, виконати тестування циклів за варіантом:
| Варіант 1. ………………… const n=10; var A:array[1..n] of real; i:integer; s:real; begin for (i:=1 to n do) A[i]:=sin(i/2); s:=0; for (i:=1 to n do) s:=s+A[i]; writeln (‘Summa elementov =’, s:5:2); end; | Варіант 2. ………………… const n=15; var B:array[1..n] of real; i:integer; p:real; begin for (i:=1 to n do) B[i]:=cos(i/2); p:=1; for (i:=1 to n do) p:=p*B[i]; writeln (‘Dobutok elementov =’, s:5:2); end; |
Приклад виконання роботи
Для прикладу розглянемо тестування наступного коду:
const n=5;
var C:array[1..n] of real; i:integer; S:real;
begin
for (i:=1 to n do)
C[i]:= i+1/i;
S:=0;
for (i:=1 to n do)
S:=S+C[i];
writeln (‘Summa elementov =’, S:5:2);
end;
1.1 Застосує перший спосіб тестування - прогін усього циклу.
Складаємо тестові варіанти:
| ТВ1: ПД.: і=1; Оч.Рез.: С[i] =2; S=2 | ТВ2: ПД.: і=2; Оч.Рез.: С[i] =1.5; S=3.5 |
| ТВ3: ПД.: і=3; Оч.Рез.: С[i] =1.33; S=4.83 | ТВ4: ПД.: і=4; Оч.Рез.: С[i] =1.25; S=6.08 |
| ТВ5: ПД.: і=5; Оч.Рез.: С[i] =1.2; S=7.28 | ТВ6: ПД.: і=6; Оч.Рез.: „Помилка вводу даних” |
1.2 Виконаємо один прохід циклу
ТВ1: ПД.: і=4;
Оч.Рез.: С[i] =1.25; S=?
1.3 Виконаємо 2 проходи циклу – перший та останній
ТВ1: ПД.: і=1;
Оч.Рез.: С[i] =2; S=2
ТВ2: ПД.: і=5;
Оч.Рез.: С[i] =1.2; S=7.28
Підсумок:розглянувши методики тестування циклів, можна зробити висновок, що найбільш інформативним для циклів з малою кількістю повторів буде методика, що позволяє виконати n - 1, n, n + 1 проходів циклу, т.я. в цьому випадку перевіряються не тільки значення в середині циклу, а й граничні значення, що перевищують кількість значень повторів циклу.
5. Контрольні запитання
5.1 Які особливості має тестування вкладених циклів?
5.2 Чи буде успішним застосування до циклів методу базового шляху?
6. Узагальнення та систематизація вмінь і навичок.
7. Підведення підсумків заняття.
8. Самостійна робота:за розглянутим прикладом самостійно виконати завдання та відповісти на контрольні запитання.
Практична робота № 3
Тема: Функціональне тестування
Мета: вивчити методи функціонального тестування на практиці.
Хід роботи
1. Організаційна частина
а) готовність групи до заняття;
б) психоемоційний настрій;
в) перевірка присутніх;
2. Актуалізація опорних знань студентів:
а) повідомлення теми та мети;
б) повідомлення основних тем, по яким відбувається практична робота.
3. Закріплення вмінь та навичок студентів
Теоретичні відомості. До вивчених способів функціонального тестування належать: спосіб розбиття по еквівалентності, спосіб аналізу граничних значень та спосіб причинно-наслідкових діаграм.
Для тестування програми за допомогою способу розбиття по еквівалентності необхідно виконати наступні кроки:
- сформувати класи еквівалентності;
- визначити післяумови та передумови;
- розробити тестові варіанти.
Для тестування способом аналізу граничних значень необхідно:
- визначити граничні значення;
- сформувати тестові варіанти для тестування граничних значень.
Тестування способом діаграм причин-наслідків відбувається у наступному порядку:
- для кожного модуля перераховуються причини (умови уведення або класи еквівалентності умов уведення) і наслідки (дії або умови виводу). Кожній причині й наслідку привласнюється свій ідентифікатор;
- розробляється граф причинно-наслідкових зв'язків;
- граф перетвориться в таблицю рішень;
- стовпці таблиці рішень перетворяться в тестові варіанти.
4. Основна частина заняття:
Завдання. Використовуючи способи тестування, що наведені в теоретичних відомостях, виконати тестування програми, специфікація якої вказана нижче:
| Дана програма, що виконує пошук студента по середнього балу успішності та виводить тих, у кого середній бал 4 та вище. Оцінки зберігаються в масиві. Оцінок в масиві має бути 5. Оцінки можуть бути від 2 до 5. Шостим елементом масиву є середній бал. Якщо студент має середній бал більше 4 – дані про нього виводяться на екран, інакше – записуються в файл. |
Приклад виконання роботи
1. Розглянемо застосування способів розбиття по еквівалентності та аналізу граничних значень на наступному прикладі. Необхідно протестувати програму бінарного пошуку. Є специфікація програми: пошук виконується в масиві елементів М, повертається індекс І елементу масиву, значення якого відповідає ключу пошуку Key.
Передумови:
1) масив має бути впорядкований;
2) масив повинен мати не менше одного елементу;
3) нижня межа масиву (індекс) повинна бути меншою або дорівнювати його верхній межі.
Постумови:
1) якщо елемент знайдений, то прапорець Result=True, значення І – номер елемента;
2) якщо елемент не знайдений, то прапорець Result=False, значення І – не визначене.
Для формування класів еквівалентності та їх ребер потрібно виконати розбиття області початкових даних – побудувати дерево розбиття. Листя дерева розбиття дадуть нам класи еквівалентності, як ми шукаємо. Визначимо стратегію розбиття. На першому рівні будемо аналізувати виконуваність передумов, на другому – виконуваність постумов. На третьому рівні можна аналізувати спеціальні вимоги, отримані з практики розробника. В нашому прикладі ми знаємо, що вхідний масив має бути впорядкований. Обробка впорядкованих наборів з парного та непарного набору елементів може виконуватися по різному. Крім того, прийнято виділяти спеціальний випадок одноелементного масиву. Отже, на рівні спеціальних вимог можливі наступні еквівалентні розбиття:
- масив з одного елементу;
- масив з парної кількості елементів;
- масив з непарної кількості елементів, який більший одиниці.
Нарешті, на останньому, 4-му рівні критерієм розбиття може бути аналіз ребер класів еквівалентності. Очевидно, можливі наступні варіантия:
1) робота з першим елементом масиву;
2) робота з останнім елементом масиву;
3) робота з проміжним елементом масиву.
Структура дерева розбиття представлена на малюнку 1.
Мал.. 1Дерево розбиття області початкових даних бінарного пошуку
Це дерево має 11 листків. Кожен листок задає окремий тестовий варіант. Розробимо тестові варіанти, що засновані на проведених розбиттях.
| ТВ1(одиничний масив, елемент знайдено): ПД.: М=15, Кеу=15. Оч. Рез.: Result=True; I=1. | ТВ2(парний масив, знайдено перший елемент): ПД.: М=15,20, 25, 30, 35, 40; Кеу=15. Оч. Рез.: Result=True; I=1. |
| ТВ3(парний масив, знайдено останній елемент): ПД.: М=15,20, 25, 30, 35, 40; Кеу=40. Оч. Рез.: Result=True; I=6. | ТВ4(парний масив, знайдено проміжний елемент): ПД.: М=15,20, 25, 30, 35, 40; Кеу=25. Оч. Рез.: Result=True; I=3. |
| ТВ5(непарний масив, знайдено перший елемент): ПД.: М=15,20, 25, 30, 35, 40, 45; Кеу=15. Оч. Рез.: Result=True; I=1. | ТВ6(непарний масив, знайдено останній елемент): ПД.: М=15,20, 25, 30, 35, 40, 45; Кеу=45. Оч. Рез.: Result=True; I=7. |
| ТВ7(непарний масив, знайдено проміжковий елемент): ПД.: М=15,20, 25, 30, 35, 40, 45; Кеу=30. Оч. Рез.: Result=True; I=4. | ТВ8(парний масив, не знайдено елементу): ПД.: М=15,20, 25, 30, 35, 40; Кеу=23. Оч. Рез.: Result=False; I=? |
| ТВ9(непарний масив, не знайдено елементу): ПД.: М=15,20, 25, 30, 35, 40, 45; Кеу=24. Оч. Рез.: Result=False; I=? | ТВ10(одиничний масив, не знайдено елементу): ПД.: М=15; Кеу=0. Оч. Рез.: Result=False; I=? |
| ТВ11(порушено передумови): ПД.: М=15,10, 5, 25, 20, 40, 35; Кеу=35. Оч. Рез.: Аварійне донесення: Масив не впорядкований. |
2. Для ілюстрації використання способу діаграм причин – наслідків (функціональних діаграм), розглянемо приклад, коли програма виконує розрахунок сплати за електроенергію по середньому та змінному тарифові. При розрахунку по середньому тарифові:
- при місячному споживанні енергії меншому, ніж 100кВт/год, виставляється фіксована сума;
- при споживанні енергії, що більше або рівне 100 кВт/год застосовується процедура А планування розрахунку.
При розрахунку за змінним тарифом:
- при місячному споживанні енергії меншому, ніж 100кВт/год, застосовується процедура А планування розрахунку;
- при споживанні енергії більшому або рівному 100кВт/год застосовується процедура В планування розрахунку.
Крок 1. Причинами є:
1) розрахунок по середньому тарифу;
2) розрахунок по змінному тарифу;
3) місячне споживання електроенергії менше, ніж 100кВт/год;
4) місячне споживання електроенергії більше або рівне 100кВт/год.
На основі різних комбінацій причин можна перерахувати наступні наслідки:
- 101 – мінімальна місячна вартість;
- 102 – процедура А планування розрахунків;
- 103 – процедура В планування розрахунків.
Крок 2. Розробка графу причинно-наслідкових зв’язків (мал.. 2).
Вузли причин розташовані вертикально по лівому краю малюнка, а вузли наслідків – по правому краю. Для наслідку 102 виникає необхідність вводу вторинних причин – 11 та 12, їх розміщаємо в центрі малюнку.
Мал. 2Граф причинно-наслідкових зв’язків
Крок 3. Генерація таблиці рішень. При генерації причини розглядаються як умови, а наслідки – як дії.
Порядок генерації.
1. Обираємо деякий наслідок, який має бути в стані „1”.
2. Знаходимо всі комбінації причин ( з врахуванням обмежень), які встановлюють цей наслідок в стан „1” . Для цього з наслідку прокладається зворотна траса через граф.
3. Для кожної комбінації причин, що приводять наслідок в стан „1”, будуємо один стовпець.
4. Для кожної комбінації причин до визначаємо стани всіх інших наслідків. Вони поміщаються в той самий стовпчик таблиці рішень.
5. Дії 1-4 повторюються для всіх наслідків графу.
Таблиця 1.1 Таблиця рішень для програми розрахунку сплати за електроенергію
| Номери стовпців | ||||||
| Умови | Причини | |||||
| Вторинні причини | ||||||
| Дії | Наслідки | |||||
Крок 4. Перетворюємо кожен стовпець таблиці в тестовий варіант. В нашому прикладі таких варіантів 4.
ТВ1(стовпець 1):
ПД.: розрахунок по середньому тарифу; місячне споживання електроенергії 75 кВт/год.
Оч.рез: мінімальна місячна вартість.
ТВ2(стовпець 2):
ПД.: розрахунок по змінному тарифу; місячне споживання електроенергії 90 кВт/год.
Оч.рез: процедура А планування розрахунку.
ТВ3(стовпець 3):
ПД.: розрахунок по середньому тарифу; місячне споживання електроенергії 100 кВт/год.
Оч.рез: процедура А планування розрахунку.
ТВ4(стовпець 4):
ПД.: розрахунок по змінному тарифу; місячне споживання електроенергії 100 кВт/год.
Оч.рез: процедура В планування розрахунку.
Підсумок:розглянувши методики функціонального тестування, можна зробити висновок, що застосування цих методик в комплексі дає найкращий результат функціонального тестування програм та комплексів.
5. Контрольні запитання
5.1 У яких випадках застосовуються методики тестування розбиття по еквівалентності та граничних значень?
5.2 Для визначення яких типів помилок застосовується метод функціональних діаграм (діаграм причин - наслідків)?
6. Узагальнення та систематизація вмінь і навичок.
7. Підведення підсумків заняття.
8. Самостійна робота:за розглянутим прикладом самостійно виконати завдання та відповісти на контрольні запитання.
Практична робота №4
Тема: Тестування об’єктно-орієнтованих програмних систем.
Мета:вивчити застосування методів тестування до тестування класів.
Хід роботи
1. Організаційна частина
а) готовність групи до заняття;
б) психоемоційний настрій;
в) перевірка присутніх;
2. Актуалізація опорних знань студентів:
а) повідомлення теми та мети;
б) повідомлення основних тем, по яким відбувається практична робота.
3. Закріплення вмінь та навичок студентів
Теоретичні відомості. Тестування класів аналогічне тестуванню модулів. Основним елементом ООП є клас, повне тестування ООПС – тестування кожного класу та їх взаємодії. Тестування охоплює види діяльності, що асоційовані з перевіркою реалізації класу на точну відповідність специфікації. Якщо реалізація коректна, то кожен екземпляр класу веде себе потрібним чином.
Ефективність тестування досягається з допомогою ревью та тестових прогонів. Ревью – перегляд початкового коду ПЗ з метою знаходження помилок та дефектів. Тестовий прогон – виконується в процесі роботи системи: визначаються набори вхідних та еталонних даних, реалізується тестовий драйвер.
Виділяють два типи класів з точки зору взаємодії з іншими класами – примітивні (клас може породжувати екземпляри) та не примітивні (класи – предки, які служать для організації логічної структури програми).
4. Основна частина заняття:
Завдання. Дана модель реальної системи керування автоматизованим комплексом зберігання підшипників. Вона забезпечує прийом підшипників на склад, збереження характеристик виробів в БД, а при надходженні заявки на підшипники разом з параметрами осі – підбір підходящих виробів та їх видачу.
Комплекс розділено на 3 елементи: склад, термінал підшипників, термінал осі. Для кожного з них реалізована низькорівнева програмна реалізація в вигляді динамічно підключених бібліотек. Описати тестовий випадок для функції GetAxleParam (), яка повертає параметри осі, код якої введений. За специфікацією: код визначається двозначним десятковим числом; база даних зберігає параметри 50 осей у вигляді: сторона осі (права, ліва), посадковий діаметри передній, посадковий діаметр задній. Після розробки тестового випадку необхідно зробити висновок.
Класи, що існують в системі:
| Назва класу | Тип класу | Описання |
| TBearingParam | Примітивний | Задає параметри підшипників |
| TAxleParam | Примітивний | Задає параметри осей |
| TCommand | Примітивний | Визначає імена команд |
| TLog | Примітивний | Відповідає за журнал |
| TCommandQueue | Не примітивний | Командні запити |
| TStore | Не примітивний | Склад |
| TTerminalBearing | Не примітивний | Термінал підшипників |
| TTerminalAxle | Не примітивний | Термінал осей |
| TModel | Не примітивний | Відповідає за моделі |
| MainForm | Не примітивний | Головна форма |
Приклад виконання роботи
Розглянемо тестування класу TCommand. В ньому реалізована єдина операція - GetFullName(), яка повертає повну назву команди у вигляді рядка. Розробимо специфікацію тестового випадку для даної операції. На вхід функції подається команда у вигляді десяткового числа, на виході отримуємо повну назву команди, що відповідає введеному кодові або відповідне повідомлення, якщо команду не знайдено.
В тесті подаються наступні коди: -1, 1, 2, 4, 6, 20.
- (- 1) – відповідає текст повідомлення „ПОМИЛКА: невірний код команди”.
- 1 – „Отримати з вхідної комірки”
- 2 – „Відправити з комірки в вихідну комірку”
- 4 – „Покласти в резерв”
- 6 – „Виконати обнуління”
- 20 – „Завершення команд видачі”.
На основі специфікації створюється тестовий драйвер, в якому перебираються всі вхідні значення та відстежується реакції на них. Відповідні пари зносяться до Log – файлу.
Підсумок:такимчином, длятестування класу необхідно виконати наступне для кожного його методу:
a. визначити, яка частин методу тестується, тобто при яких умовах він викликається;
b. створити тестове оточення забезпечення умови (тестовий драйвер);
c. запустити тестове оточення на виконання;
d. забезпечити збереження результатів в Log – файлі;
e. порівняти очікувані результати з результатами, представленими в Log – файлі.
5. Контрольні запитання:
1. Поясніть поняття примітивних та не примітивних класів
2. Дайте визначення тестового драйвера.
6. Узагальнення та систематизація вмінь і навичок.
7. Підведення підсумків заняття.
8. Самостійна робота:за розглянутим прикладом самостійно виконати завдання та відповісти на контрольні запитання.
Практична робота № 5
Тема: Проектування об’єктно-орієнтованих тестових варіантів
Мета:розглянути застосування методик системного тестування до тестування об’єктно-орієнтованих програмних систем.
Хід роботи
1. Організаційна частина
а) готовність групи до заняття;
б) психоемоційний настрій;
в) перевірка присутніх;
2. Актуалізація опорних знань студентів:
а) повідомлення теми та мети;
б) повідомлення основних тем, по яким відбувається практична робота.
3. Закріплення вмінь та навичок студентів
Теоретичні відомості. Системне тестування якісно відрізняється від інтеграційного та модульного рівнів. Воно розглядає систему в цілому та застосовується на рівні користувацьких інтерфейсів. Основним завданням системного тестування є виявлення дефектів, що пов’язані з роботою системи в цілому, таких як неправильне використання ресурсів системи, непередбачувані комбінації даних користувацького рівня, несумісність з оточенням, непередбачені сценарії використання, відсутня або неправильна функціональність, незручність в використанні та ін.. В даному випадку побудова спеціальної тестової системи не обов’язкова, проте обсяги даних на цьому рівні такі, що зазвичай більш ефективним підходом є повна або часткова автоматизація тестування. Існує два принципово різних підходи до системного тестування. В першому для побудови тестів використовують вимоги до системи: для кожної вимоги будується тест, який її перевіряє. Тестувальник тільки перевіряє відповідність системи вимогам. В другому підході основою для побудови тестів є уявлення про способи використання продукту та про задачі, які він вирішує. На основі більш-менш формальної моделі користувача створюються випадки використання системи, по яким будуються тестові варіанти.
Вхідні дані для кожного сценарію необхідно обирати наступним чином:
- ідентифікувати всі значення (вхідні дані), які можуть задавати суб’єкти для випадків використання;
- визначити класи еквівалентності для кожного типу вхідних даних;
- побудувати таблицю зі списком значень з різних класів еквівалентності;
- побудувати тестові випадки на базі таблиці з врахуванням зовнішніх обмежень.
4. Основна частина заняття:
В практичні роботі при побудові тестових варіантів використати обидва підходи, описані в теоретичних відомостях, та діяти наступним чином:
- на основі вимог визначити випадки використання (use case);
- на основі кожного випадку використання (use case) побудувати сценарії;
- для кожного сценарію розробити тестові випадки (набори тестів).
Завдання: виконати проектування тестового випадку для модулю, специфікація якого приведена нижче.
Використаємо модуль „Прийом підшипника на склад”. Послідовно приходять 3 підшипники. Система запитує їх з вхідної комірки, приймає параметри підшипника, що надійшов, та зберігає їх до бази даних. При надходженні підшипника (статус складу - 32) система запитує термінал підшипника, формує та посилає команду Складу – „Прийняти підшипник” та отримує відповідь зі Складу про результати виконання команди.
Приклад виконання роботи
Розглянемо приклад. Дано описання випадку використання (use case) модулю „Підбір підшипників для осі”. Послідовно приходять два підшипники, надходить запит від осі. При надходженні запиту від осі система підбирає два підшипники з тих, що є на складі та видає їх в вихідну комірку.
Згідно специфікації, система постійно запитує Склад та Термінал Осі. При надходженні підшипника (статус складу - 32) система запитує термінал підшипника, формує та посилає команду Складу – „Прийняти підшипник” та отримує відповідь зі Складу про результати виконання команди. При надходженні осі (надходженні параметрів осі при опитуванні терміналу осі) система повинна підібрати підшипники з тих, що є на складі, сформувати команди для їх видачі, надіслати їх складові та отримати відповідь про результати виконання команди.
Покрокове описання тестового випадку приведене на малюнку 3.
В покроковому описанні тестового випадку не враховуються можливі альтернативні шляхи поведінки системи.
Специфікація тестового випадку № 1.
Стан оточення (вхідні дані):
Статус складу (StoreStat=32). Надійшов підшипник.
Статус обміну з терміналом підшипника (0 – підшипник є) та його параметри (RollerPar="0 NewUser Depot1 123456 1 12 1 1").
Статус обміну з терміналом осі (1 – осі немає) та її параметри (AxlePar="1 NewUser Depot1 123456 1 0 12 12").
Статус команди (CommandStatus=0). Команда успішно прийнята.
Повідомлення від складу (StoreMessage=1). Команда успішно виконана.
Очікувана послідовність подій (вихідні дані):
- система запитує статус складу (виклик функції GetStoreStat) та отримує 0 NewUser Depot1 123456 1 12 1 1;
- система запитує параметри підшипника (виклик функції GetRollerPar ) та отримує NewUser Depot1 123456 1 12 1 1;
- система запитує параметри осі (виклик функції GetAxlePar) та отримує 1 NewUser Depot1 123456 1 0 12 12;
- система додає в чергу команд складу на останнє місце команду SendR (отримати з приймальника в комірку, виклик функції SendStoreCom ) та отримує повідомлення про те, що команда успішно прийнята – 0;
- система запитує склад про результати виконання команди (виклик функції GetStoreMessage) та отримує повідомлення про те, що команда успішно виконана – 1;
- система запитує статус складу (виклик функції GetStoreStat) та отримує 32;
- система запитує параметри підшипника (виклик функції GetRollerPar ) та отримує 0 NewUser Depot1 123456 1 12 1 1;
- система запитує параметри осі (виклик функції GetAxlePar) та отримує 1 NewUser Depot1 123456 1 0 12 12;
- система додає в чергу команд складу на перше місце команду GetR (отримати з приймальника до комірки, виклик функції SendStoreCom) та отримує повідомлення про те, що команда успішно прийнята – 0;
- система запитує склад про результати виконання команди (виклик функції GetStoreMessage) та отримує повідомлення про те, що команда успішно виконана – 1.
Описання процесу системного тестування:
1. Аналіз. Система, що тестується, аналізується (перевіряється) на наявність деяких властивостей, яким необхідно приділити особливу увагу, та визначаються відповідні тестові випадки.
2. Побудова. Вибрані на стадії аналізу тестові випадки переводяться на мову програмування.
3. Виконання та аналіз результатів. Відбувається виконання тестових випадків. Отримані результати аналізуються, для того, щоб визначити, чи успішно пройшла система випробувань на тестовому наборі. Процес запуску тестових випадків та аналізу отриманих результатів повинен бути детально описаний в тестових випадках.
Підсумок:таким чином, побудова об’єктно-орієнтованих тестових варіантів є основною для розробки тестів системного тестування. Для побудови тестових варіанті необхідно використовувати специфікацію програмної системи.
5. Контрольні запитання:
1. Дайте визначення системного тестування.
2. Які обмеження накладає використання об’єктно-орієнтованого програмування?
6. Узагальнення та систематизація вмінь і навичок.
7. Підведення підсумків заняття.
8. Самостійна робота:за розглянутим прикладом самостійно виконати завдання та відповісти на контрольні запитання.
Практична робота № 6
Тема: Планування тестування
Мета: навчитися будувати план тестування та розглянути всі етапи створення плану тестування.
Хід роботи
1. Організаційна частина
а) готовність групи до заняття;
б) психоемоційний настрій;
в) перевірка присутніх;
2. Актуалізація опорних знань студентів:
а) повідомлення теми та мети;
б) повідомлення основних тем, по яким відбувається практична робота.
3. Закріплення вмінь та навичок студентів
Теоретичні відомості. Процес тестування тісно пов’язаний з процесом розробки, відповідно, планування тестування також залежить від моделі розробки. При плануванні необхідно відповісти на питання:
1. Хто буде тестувати та на яких етапах? Розробники, тестувальники чи разом?
2. Які компоненти потрібно тестувати? Чи будуть піддаватися тестуванню всі компоненти програмного продукту або тільки компоненти, що можуть призвести до найбільших втрат для всього проекту?
3. Коли потрібно тестувати? Чи буде це неперервний процес, вид діяльності, що виконується в спеціальних контрольних точках, або вид діяльності, що виконується на завершальній стадії розробки?
4. Як потрібно тестувати? Чи буде тестування зосереджене тільки на перевірці того, що даний продукт повинен виконувати, або також на тому, як це реалізовано?
5. В якому обсязі потрібно тестувати? Як визначити, чи в достатньому обсязі виконане тестування, або як розподілити обмежені ресурси, що виділені під тестування?
Відповіді на поставлені запитання та, можливо, на багато інших запитань, оформлюються у вигляді документів, що прийняті в компанії. Приклад тестового плану розглянемо нижче.
4. Основна частина заняття:
Завдання: створити тестовий план, використовуючи приклад, розглянутий нижче. Для тестування пропонується система, призначена для автоматизації роботи аптеки. За специфікацією вона повинна використовуватися в аптеці, аптекарем та мати наступні функції: додавати, видаляти та зберігати дані про лікарські препарати. Мати функцію пошуку препаратів по різним критеріям. У випадку відсутності лікарського засобу – пропонувати заміну по способу дії, або видавати повідомлення про відсутність.
Приклад виконання роботи
Складемо тестовий план для тестування автоматизованої системи прийому підшипників на склад. Тестовий план буде містити:
1. Перелік тестових ресурсів: тестувальники – 3 чоловіки (система має 3 модулі); апаратні засоби – 3 ПК; програмні засоби – драйвери тестування.
2. Перелік функцій та підсистем, що підлягають тестуванню: підсистеми – Склад, Підшипники, Осі; функції: прийом вхідних даних, пошук та порівняння даних; коректне завершення роботи.
3. Вибір стратегії тестування:
3.1 Протестувати функції вводу, пошуку, виводу з допомогою методів структурного тестування (методом базового шляху).
3.2 Протестувати підсистеми з допомогою функціональних методів (розбиття по еквівалентності, методом граничних значень).
3.3 Підсистему „Ось” протестувати додатково методом функціональних діаграм (причин - наслідків).
3.4 Протестувати зборку системи одним з методів інтеграційного тестування (низхідним, висхідним).
3.5 Виконати контрольне системне тестування для перевірки взаємодії модулів.
4. Визначення стратегії вибору вхідних даних для тестування: дані обирати керуючись принципами розбиття на класи еквівалентності (тобто, таким чином, щоб вини покривали як найбільше тестових випадків).
5. Визначення потреби автоматизації процесу тестування ( при цьому рішення про використання вже існуючої, або про створення нової автоматизованої системи тестування має бути обґрунтоване, а також продемонстрована оцінка витрат на створення нової системи, або на впровадження вже існуючої): для автоматизації тестування використовувати вже існуючу систему, після деякої її адаптації. Розробка нової системи є занадто витратною, а тестування вручну – занадто довге.
6. Графік (розклад) тестових циклів:
6.1 Перший етап тестування проводити після створення коду відповідних модулів.
6.2 Другий етап проводити паралельно з проведенням зборки модулів.
6.3 Третій та четвертий етапи провести після зборки модулів в одне ціле.
7. Надання конкретних параметрів апаратури та програмного оточення: тестування слід проводити на ПК, що володіють такими мінімальними апаратними та програмними характеристиками: ОЗУ – 1Гб, жорсткий диск – 250 Гб, процесор – 2.2ГГц; ОС – Windows XP.
8. Визначення тестових метрик, які необхідно збирати та аналізувати (наприклад, покриття набору тестів, покриття коду, кількість та рівень серйозності дефектів, обсяг тестового коду і т.п.): для аналізу використовувати рівень виявлених дефектів, щоб визначити якість програмного продукту в цілому.
Підсумок:створення тестового плану дозволяє систематизувати процес тестування, врахувати досвід попередніх розробників та тестувальників шляхом аналізу їх тестових планів, визначати та своєчасно проводити тестові цикли та процедури. Ці заходи дозволяють досягнути поставленої мети – розробки якісного та працездатного програмного забезпечення.
5. Контрольні запитання:
1. Що розуміють під тестовим планом?
2. Дайте визначення тестового циклу.
6. Узагальнення та систематизація вмінь і навичок.
7. Підведення підсумків заняття.
8. Самостійна робота:за розглянутим прикладом самостійно виконати завдання та відповісти на контрольні запитання.
Практична робота № 7
Тема: Використання тестового пакету Everest
Мета: навчитись використовувати тестовий пакет Everest для тестування працездатності апаратного та програмного забезпечення персонального комп’ютера.
Хід роботи
1. Організаційна частина
а) готовність групи до заняття;
б) психоемоційний настрій;
в) перевірка присутніх;
2. Актуалізація опорних знань студентів:
а) повідомлення теми та мети;
б) повідомлення основних тем, по яким відбувається практична робота.
3. Закріплення вмінь та навичок студентів
Теоретичні відомості. Everest – це програма для діагности та тестування комп’ютера. З її допомогою можна отримати відомості про все встановлене апаратне та програмне забезпечення, провести тести різних модулів ПК, оптимізувати роботу комп’ютера, отримати звіти в HTML, TXT та інших форматах. Проте використання цього пакету вимагає від користувачів глибоких знань в області програмного та апаратного забезпечення. Всього програма тестує 13 основних категорій, по яким виконується аналіз. В кожній категорії є підрозділи, наприклад, в категорії Комп’ютер таких підрозділів 5 (сумарна інформація, DMI, Overclock, Датчик, Електроживлення). Виконується аналіз більш ніж 60-ти системних параметрів (залежно від конфігурації комп’ютера кількість параметрів може змінюватися). Наприклад, версія EVEREST Corporate Edition 4.20 підтримує віддалене діагностування комп’ютерів.
4. Основна частина заняття:для демонстрації можливостей тестового пакету Everest виконаємо діагностику типового домашнього персонального комп’ютера, використавши його для вирішення наступних ситуацій:
4.1 виявити проблему з безпровідною мишею A4Tech, яка дає збій в роботі з деякими програмами;
4.2 оптимізувати роботу системи в цілому;
4.3 відкалібрувати застарілий монітор;
4.4 виконати тестування модулю пам’яті.
Після проведення тестів створити, роздрукувати та додати до звіту тестовий звіт, який формує програма Everest.
Приклад виконання роботи
Для виконання поставлених завдань можна скористатися наступним алгоритмом:
1) Почнемо з проблем з мишею: в розділі програми „Пристрої - Введення” дивимося данні про маніпулятори. Якщо не виводиться інформація про драйвери, її необхідно перевірити засобами операційної системи. Якщо драйвер відповідає, але просто застарий – потрібно його оновити. Це можна зробити з допомогою Everest: готове посилання на сторінку скачування драйверів на сайті виробника є на закладці програми з властивостями миші.
2) Оптимізацію роботи системи рекомендується починати з перегляду процесів та автозавантаження. Процеси в вікні Everest відображаються з іконками програм, що дозволяє швидко знайти будь-який процес. Проте, процес неможливо закрити з тестуючої програми – для цієї мети варто використати „Диспетчер задач”. Робота з додатками в автозавантаженні: в програмі можна видалити програму з автозавантаження, але додати – ні. На вкладці „Мережа – Браузер” є список всіх сайтів, які користувач відвідував останнім часом. В закладці „Ліцензії” відображаються додатки, які Everest вважає легальними, тобто ліцензійними. Інші процеси – потенційно небезпечні та можуть містити віруси. На вкладці „Системна плата – Пам’ять” відображається файл підкачки. Якщо він буде замалим, Everest виведе пораду збільшити файл, для того, щоб підвищити швидкодію роботи програм. На наступному етапі оптимізації можна перевірити ступінь захисту комп’ютера від зовнішніх погроз. Everest надає для цього особливі можливості: розділ „Безпека” видає повні відомості про захисні програми, що встановлені на ПК.
3) Для діагности монітору можна скористатися спеціальною підпрограмою, яка викликається командою „Файл - Діагностика монітору”. Для проведення діагности потрібно на вкладці вибрати необхідні тести та натиснути на Run. Можливості тестової програми дуже широкі: калібровка екрану на різкість, яскравість, контраст, кольорову гамму, тести на сітку з різними фонами та на читаємість тексту.
Підсумок: в цілому програма Everest достатньо вдала та корисна. Особливо для тих, кому по роботі доводиться стикатися з комп’ютерами, для яких немає сертифікатів на апаратне та програмне забезпечення.
5. Контрольні запитання:
1. Чи можна протестувати з допомогою пакету Everest програмне забезпечення?
2. Які версії тестового пакету Everest ви знаєте та в чому їх особливості?
6. Узагальнення та систематизація вмінь і навичок.
7. Підведення підсумків заняття.
8. Самостійна робота:за розглянутим прикладом самостійно виконати завдання та відповісти на контрольні запитання.
Правила оформлення звітів з практичних робіт
1. Звіт оформлюється в зошиті.
2. Звіт має містити тему, мету та завдання на практичну роботу.
3. Завдання до практичної роботи має бути виконане охайно.
4. Кожний звіт повинен мати висновок та відповіді на контрольні запитання.
5. Завдання до практичної роботи має бути виконане та описане за прикладом, приведеним в методичних вказівках.
Список використаних джерел
1. Котляров В.П. „Основи тестування програмного забезпечення ” Інтернет – університет інформаційних технологій – ІНТУІТ.ру, 2006
2. Орлов С. А., „Технології розробки програмного забезпечення: Підручник для вузів ”. – Спб.: Пітер, 2004р.
3. В.В. Кулямін, А.К. Петренко, А.С. Косачев, И.Б. Бурдонов. Підхід UniTesK до розробки тестів. Програмування, 29(6): 25-43, 2003.
4. В. П. Іванников, А.С. Камкін, В.В. Куля мін, А.К. Петренко „Застосування технології UniTesK для функціонального тестування моделей апаратного забезпечення ”, 29(6): 16, 2004
5. Основи програмної інженерії (по SWEBOK) Російський переклад SWEBOK 2004 з примітками та коментарями підготований Сергієм Орликом при участі Юрія Булуя. Додаткові розділи написані Сергієм Орликом
6. http://www.upspecial.ru/testovyj-paket-everest-ultimate-edition.html