2. Приклад реалізації етапу тестування

В якості прикладу, проведемо тестування проекту PayCheck. Розглянемо основні види тестування і виберемо найоптимальніші в нашому випадку.

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

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

• Автоматизоване тестування – цей вид, як підвид тестування методом прозорої скриньки, ми також використаємо для тестування проекту.

• Метод чорної скриньки – оберемо цей вид для демонстрування його відмінностей від методу прозорої скриньки.

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

• Метод сіяння помилок – не підходить для тестування даного проекту через обмеженість вхідних даних.

Використаємо три типи тестування: тестування методом чорної скриньки, методом білої скриньки і автоматичне тестування за допомого юніт тестів. Були обрані тільки ці методи, оскільки інші є менш ефективні у нашому випадку.

Метод чорної скриньки

Ц

Рис 2.1.

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

1. На головному вікні програми, додамо запис з таблиці товарів в таблицю чеку. В правому верхньому куті вікна значення суми мало змінитися на суму значень з таблиці чеку по полю "Сума". Як можна бачити на рисунку, сума залишилась старою. Ситуацію відображено на рис 2.1.

2. На головному вікні програми за допомогою клавіш Ctrl+PgDn встановлюємо значення знижки рівним 10%. Сума не змінилася. Це означає що система обрахування знижки працює некоректно.

3. За допомогою клавіші Tab переходимо в таблицю чеку та клавішею Enter вибираємо запис. Відкривається вікно з властивостями запису де в полі "кількість" має бути значення з поля "кількість" вибраного запису, але поле пусте.

4. Додаємо запис про товар з таблиці товарів в таблицю чеку. Після цієї дії, в головному меню мають бути заблоковані для виклику наступні пункти: "Формування чеку", "Інвентаризація", "Чек повернення", "Налаштування", "Параметри друку", "Реєстрація", "Змінити касира" та "Вихід". Натомість пункти меню доступні.

5. В основному меню вибираємо пункт "Налаштування". Має з’явитись вікно з налаштуваннями де необхідно змінити значення назви підрозділу та період оновлення бази товарів. Вікно не з’явилось.

М

Рис 2.2.

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

Метод білої скриньки

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

1

Рис 2.3.

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

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

3

Рис 2.4.

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

4.Функція, яка обраховує значення ПДВ для поточного запису вибирає з масиву значень ПДВ потрібне значення. В даному випадку поточний запис мав значення ПДВ, яке не входило до множини допустимих значень. Тобто помилка заклечається в тому що параметр index має значення яке виходить за межі масиву TAX_AppTaxRates.

5. В полі пошуку, при введенню значення штрих-коду, для пошуку відповідного запису, функція яка відповідає за пошук, формує спочатку спеціальний запис, який буде використовувати для пошуку. Цей запис є записаний з помилкою, та включає в себе команди без параметрів, наприклад команда cmd, для вибірки записів з таблиці Cheque, є неправильна.

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

Автоматизоване тестування

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

1

Рис 2.5.

. Помилка при спробі функції переключитись в сервісний режим. Помилка полягала неправильній передачі даних функції - першим параметром мав бути пароль а другим логін. Також помилка була виявлена в функції яка формує сервісний пароль. Сервісний пароль формується з значення номеру дня, місяця та року не відкидаючи нулів у номері місяцю і дня, тобто пароль мав би бути таким "29012009" (для 29 січня 2009 року), але функцією очікувався наступний пароль "2912009", тобто з відкинутими нулями.

2. При спробі системи увійти в папку C:\\users виникла помилка, по причині того що такої папки не існує. В такому випадку при спробі зчитати дані з папки користувачів, необхідно перевірити чи існує така папка і якщо не існує то створити її.

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

4

Рис 2.6.

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

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

Ю ніт тести допомагають виявити проблемні функціонали, які працюють не так як очікується. Сучасні середовища розробки ПЗ, включають в себе зручні для використання засоби для проведення тестування такого типу. В процесі розробки проекту, приведеного в якості прикладу, було використано середовище Microsoft Visual Studio. Воно дозволяє зручно організовувати тестування, і відслідковувати реакцію тестів на зміну функціоналу. На рисунку 2.7. відображена ситуація, в якій всі тести пройшли успішно. Не зважаючи на всі свої переваги, юніт тести не дають можливість визначити джерело помилки, оскільки показують тільки результати неправильної роботи функціоналу.

Звіт про проведене тестування

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

Одним з найважливіших пунктів звіту є пункт про відтворення помилки, який повинен допомогти розробнику відтворити помилку і виправити її.

Опис помилки повинен складатись з наступних пунктів

1. Ім’я того хто виявив помилку.

2. Номер помилки.

3. Тип помилки (косметична помилка, критична помилка, помилка з втратою даних, помилка без втрати даних, критична).

4. Пріоритет помилки (Високий, середній, низький. Помилки з більш високим пріоритетом виправляються першими).

5. Короткий опис помилки.

6. Шлях відтворення. (Покрокова інструкція користування програмою, виконання якої призводить до невдачі)

Приведемо приклад звіту, складеного на основі результатів тестування методом чорної скриньки.

1. Василь Петренко.

2. 101.

3. Без втрати даних.

4. Середній.

5. Не виводиться сума на головному вікні.

6. Ввести реєстраційні дані, активувати таблицю товарів, натиснути ENTER.

1. Василь Петренко.

2. 102.

3. З втратою даних.

4. Високий.

5. Не коректно працює система знижок – не з’являється напис "загальна знижка 10%", сума не міняється.

6. Ввести реєстраційні дані, активувати таблицю товарів, натиснути ENTER, ввести комбінацію Ctrl+PgDn, ввести значення знижки 10%, натиснути на кнопку "Добре".

1. Василь Петренко.

2. 103.

3. Косметична.

4. Низький.

5. Автоматично не додається кількість товару, у вікні властивостей товару.

6. Ввести реєстраційні дані, активувати таблицю товарів, натиснути ENTER, натиснути клавішу TAB, вибрати запис і викликати його властивості.

1. Василь Петренко.

2. 104.

3. Без втрати даних.

4. Середній.

5. Не блокуються пункти меню після додавання нового товару в базу.

6. Ввести реєстраційні дані, активувати таблицю товарів, натиснути ENTER, натиснути комбінацію клавіш ctrl+s або ctrl+f, викликати головне меню.

1. Василь Петренко.

2. 105.

3. Без втрати даних.

4. Високий.

5. Неможливо викликати пункт меню налаштування.

6. Ввести реєстраційні дані, активувати таблицю товарів, натиснути ENTER, викликати головне меню, вибрати пункт налаштування.

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