Міністерство освіти і науки, молоді та спорту України

 

Харківський  національний університет  радіоелектроніки

 

 

 

 

 

 

 

МЕТОДИЧНІ ВКАЗІВКИ

ДО ЛАБОРАТОРНИХ РОБІТ З ДИСЦИПЛІНИ

«Якість та ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ»

для студентів усіх форм навчання напряму

7.05010302 – «Інженерія програмного забезпечення»

 

 

 

 

 

ЗАТВЕРДЖЕНО

кафедрою ПЗ ЕОМ

Протокол №1 від 31.08.2010

 

 

 

 

 

 

 

 

 

 

 

 

Харків 2011

 

Методичні вказівки до лабораторних робіт з дисципліни «Якість та тестування програмного забезпечення» для студентів усіх форм навчання напряму  7.05010302 – «Інженерія програмного забезпечення» (ІПЗ) /Упоряд. І.А. Ревенчук, Т.С. Ткачова - Харків: ХНУРЕ, 2010. - 41 с.

 

 

 

Упорядники:       І.А. Ревенчук

                            Т.С. Ткачова

 

 

 

Рецензент:         С.П. Новоселов

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Зміст

 

Зміст  5

Вступ   7

1    Створення тест плану для тестування програм    8

1.1   Мета роботи  8

1.2   Методичні рекомендації до самостійної роботи студентів  8

1.3   Порядок виконання роботи  12

1.4   Висновки  12

1.5   Контрольні запитання та завдання  13

2    Розробка тестових випадків (test case) 13

2.1   Мета роботи  13

2.2   Методичні рекомендації до самостійної роботи студентів  13

2.3   Порядок виконання роботи  16

2.4   Висновки  16

2.5   Контрольні запитання та завдання  16

3    техніка тест дизайну при розробці тестових випадків (Test Cases тест кейсів ) 16

3.1   Мета роботи  16

3.2   Методичні рекомендації до самостійної роботи студентів  16

3.3   Порядок виконання роботи  22

3.4   Висновки  22

3.5   Контрольні запитання та завдання  22

4    Розробка звітів про помилки/ дефекти (bug report) 23

4.1   Мета роботи  23

4.2   Методичні рекомендації до самостійної роботи студентів  23

4.3   Порядок виконання роботи  25

4.4   Висновки  25

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

ПЕРЕЛІК ПОСИЛАНЬ  26

Додаток А  Форма тест плану  27

Тестовий план (Test Plan) 30

1 Вступ (Introduction) 30

1.1 Мета (Purpose) 30

1.2 Довідкова інформація (Background) 30

1.3 Галузь застосування (Scope) 30

1.4 Визначення проекту (Project Identification) 30

2 Вимоги до тестування (Requirements for Test) 30

3 Стратегія тестування (Test Strategy) 30

3.1 Типи тестування (Testing Types ) 31

3.1.1 Дані і БД Інтеграційне тестування (Data and Database Integrity Testing) 31

3.1.2 Функціональне тестування (Function Testing) 31

3.1.3 Бізнес-цикл тестування (Business Cycle Testing) 31

3.1.4 Тестування інтерфейсу користувача (User Interface Testing) 32

3.1.5 Тестування продуктивності (Performance Profiling ) 32

3.1.6 Завантажувальне тестування (Load Testing) 33

3.1.7 Стресове тестування (Stress Testing) 33

3.1.8 Навантажувальне тестування (Volume Testing) 34

3.1.9 Тестування безпеки і контролю доступу (Security and Access Control Testing) 34

3.1.10 Тестування відмовостійкості та відновлення (Failover and Recovery Testing) 34

3.1.11 Тестування конфігурації (Configuration Testing) 35

3.1.12 Тестування інсталяції (Installation Testing) 36

3.2 Інструменти (Tools) 36

4 Ресурси (Resources) 36

4.1 Ролі (Roles) 36

4.2 Система (System) 37

5 Етапи проекту (Project Milestones) 38

6 Кінцевий продукт (Deliverables) 38

6.1 Тестова модель (Test Model) 38

6.2 Тестовий журнал (Test Logs) 38

6.3 Звіти з дефектів (Defect Reports) 38

7 Додаток А Задачі проекту (Appendix A Project Tasks) 38

Додаток Б  Приклад оформлення титульного листа звіту з лабораторних робіт  39

Додаток В  Шаблони і приклади заповнення тестового випадку(Test Case) 40

В.1 Шаблон №1 тестового випадку  40

В.2 Шаблон №2 тестового випадку  41

Додаток Г  Шаблони і приклади звіту про помилки/дефекти (Bug Report) 42

Г.1 Шаблон звіту про помилку/дефект (Bug Report) 42

Г.2 Приклад створення звіту про помилку/дефект (Bug Report) 43

 

Вступ

 

 

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

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

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

Тестування - це одна з технік контролю якості, що включає в себе діяльність з планування робіт (Test Management), проектуванню тестів (Test Design), виконанню тестування (Test Execution) і аналізу отриманих результатів (Test Analysis).

Необхідними умовами для тестування є наявність :

­   об'єкта тестування, доступного для проведення іспитів;

­   виконавця(ів) (залежно від виду проведених іспитів їм може бути як людина, так і машина або комбінація людина + машина).

Достатніми умовами для тестування є наявність:

­   об'єкта тестування, доступного для проведення іспитів;

­   виконавця(ів) (залежно від виду діяльності на різних фазах їм може бути як людина, так і машина або комбінація людина + машина);

­   плану тестування;

­   тест кейсів / тестів;

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

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

-         тест план (тест план IEEE 829, тест план RUP, план приймально – здавальних випробувань RUP, план проведення навантажувального тестування);

-         тест дизайн специфікації (тест дизайн специфікація MSF, тест дизайн специфікація IEEE 829-1998);

-         тестовий випадок (test case);

-         звіт про помилку (bug report).

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

1        Створення тест плану для тестування програм

 

1.1      Мета роботи

Отримання студентами навичок зі створення тест плану.

1.2      Методичні рекомендації до самостійної роботи студентів

1.2.1 Підготовка до роботи

В процесі підготовки необхідно проробити теоретичний материал з конспекту лекцій, а також літературні джерела [1, с.50-90, 284-339; 2, с.35-56], в яких викладені правила складання тест плану.

1.2.2 Сутність роботи

Тестування програмного забезпечення (Software Testing) – це перевірка відповідності між реальною і очікуваною поведінкою програми, що здійснюється на кінцевому наборі тестів, обраних певним чином. (IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004) У більш широкому змісті, тестування - це одна з технік контролю якості, що включає в себе діяльність з планування робіт (Test Management), проектуванню тестів (Test Design), виконанню тестування (Test Execution) і аналізу отриманих результатів (Test Analysis).

Верифікація (verification) програми і її компонентів з метою визначення чи задовольняють результати поточного етапу розробки умовам, сформованим на початку цього етапу (IEEE). Тобто чи виконуються цілі, терміни, задачі з розробки проекту, визначені на початку поточної фази.

Валідація (validation) - це визначення відповідності розроблювального ПЗ очікуванням і потребам користувача, вимогам до системи (BS7925-1).

План тестування (Test Plan) - це документ, що описує обсяг робіт з по тестування, починаючи з опису об'єкта, стратегії, розкладу, критеріїв початку і закінчення тестування, до необхідного в процесі роботи устаткування, спеціальних знань, а також оцінки ризиків з варіантами їхнього рішення.

Тест дизайн (Test Design) - це етап процесу тестування ПЗ, на якому проектуються і створюються тестові випадки (тест кейси), відповідно до визначених раніше критерій якості і цілей тестування.

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

Звіт про помилку/Дефект Репорт (Bug Report) - це документ, що описує ситуацію або послідовність дій, що призвели до некоректної роботи об'єкта тестування, із вказівкою причин і очікуваного результату.

Тестове Покриття (Test Coverage) - це одна з метрик оцінки якості тестування, що представляє із себе щільність покриття тестами вимог або коду, що виконується.

Деталізація Тест Кейсів (Test Case Detalization) - це рівень деталізації опису тестових кроків і необхідного результату, при якому забезпечується розумне співвідношення часу проходження до тестового покриття.

Час Проходження Тест Кейса (Test Case Pass Time) - це час від початку проходження кроків тест кейса до одержання результату тесту.

Залежно від переслідуваних цілей види тестування можна умовно розділити на наступні типи: функціональне, не функціональне, пов'язані зі змінами.

 

Таблиця 1.1 – Класифікація видів тестування ПЗ

А Функціональне	Б Нефункціональне	В Пов'язані зі змінами
Функціональні тести базуються на функціях і особливостях, а також взаємодії з іншими системами, і можуть бути представлені на всіх рівнях тестування: компонентному або модульному (Component/Unit testing), інтеграційному (Integration testing), системному (System testing) і приймальному (Acceptance testing). Функціональні види тестування розглядають зовнішнє поводження системи. Далі перераховані одні з найпоширеніших видів функціональних тестів:	Нефункціональне тестування описує тести, необхідні для визначення характеристик програмного забезпечення, що можуть бути вимірювані різними величинами. У цілому, це тестування того, "Як" система працює. Основні види нефункціональних тестів:	Після проведення необхідних змін, таких як виправлення помилки - бага/дефекту, ПЗ має бути знов протестоване для підтвердження того факту, що проблема була дійсно вирішена. Нижче перераховані види тестування, які необхідно проводити після установки ПЗ, для підтвердження працездатності додатка або вірності здійсненого виправлення дефекту:
А.1Функціональне тестування (Functional testing)	Б.1 Види тестування продуктивності: Б.1.1 Навантажувальне тестування (Performance and Load Testing) Б.1.2 Стресове тестування (Stress Testing) Б.1.3 Тестування стабільності або надійності (Stability / Reliability Testing) Б.1.4 Об'ємне тестування (Volume Testing)	В.1 Димове тестування (Smoke Testing)
А.2 Тестування безпеки (Security and Access Control Testing)	Б.2. Тестування установки (Installation testing	В.2 Регресійне тестування (Regression Testing)
А.3 Тестування взаємодії (Interoperability Testing): А.3.1 Тестування сумісності (compatibility testing); А.3.2 Інтеграційне тестування (integration testing).	Б.3 Тестування зручності користування (Usability Testing)	В.3 Тестування зборки (Build Verification Test)
	Б.4 Тестування на відмовлення і відновлення (Failover and Recovery Testing)	В.4 Санітарне тестування або перевірка погодженості/ справності (Sanity Testing)
	Б.5 Конфігураційне тестування (Configuration Testing)

 

 

А.1 Функціональне тестування (Functional Testing) розглядає заздалегідь зазначену поведінку і ґрунтується на аналізі специфікацій функціональності компонента або системи в цілому.

Функціональні тести ґрунтуються на функціях, виконуваних системою, і можуть проводитися на всіх рівнях тестування (компонентному, інтеграційному, системному, приймальному). Як правило, ці функції описуються у вимогах, функціональних специфікаціях або у виді випадків використання системи (use cases).

Тестування функціональності може проводиться в двох аспектах:

-         вимоги;

-         бізнеси-процеси.

Тестування в перспективі «вимоги» використовує специфікацію функціональних вимог до системи як основу для дизайну тестових випадків (Test Cases). У цьому випадку необхідно зробити перелік того, що буде тестуватися, а що ні, визначають пріоритетність вимог на основі ризиків (якщо це не зроблено в документі з вимогами), а на основі цього переліку пріоритетів формуються тестові сценарії (test cases). Це дозволяє сфокусуватися при тестуванні на важливішому функціоналі.

Тестування в перспективі «бізнеси-процеси» використовує знання цих самих бізнесів-процесів, що описують сценарії щоденного використання системи. У цій перспективі тестові сценарії (test scripts), як правило, ґрунтуються на випадках використання системи (use cases).

А.2 Тестування безпеки (Security and Access Control Testing) – це перевірка безпеки системи, а також аналіз ризиків, пов'язаних із забезпеченням цілісного підходу до захисту додатка, атак хакерів, вірусів, несанкціонованого доступу до конфіденційних даних. Тестування безпеки може виконуватися як автоматизовано так і в ручну, включаючи перевірку як позитивних, так і негативних тестових випадків. Ґрунтується на трьох основних принципах - це конфіденційність, цілісність і доступність(confidentiality, integrity, availability)

А.3 Тестування взаємодії (Interoperability Testing) – це функціональне тестування, що перевіряє здатність додатка взаємодіяти з одним і більш компонентами або системами,  що включає в себе тестування сумісності (compatibility testing) і інтеграційне тестування (integration testing).

Б.1 Види тестування продуктивності (Performance testing)

Задачею тестування продуктивності (Performance testing) є визначення масштабованості додатка під навантаженням, при цьому відбувається:

-         вимір часу виконання обраних операцій при визначених інтенсивностях виконання цих операцій;

-         визначення кількості користувачів, що одночасно працюють з додатком;

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

-         дослідження продуктивності на високих, граничних, стресових навантаженнях.

Б.1.1 Навантажувальне тестування (Load vs Performance Testing). В англомовній термінології ви можете так само знайти ще один вид тестування - Load Testing - тестування реакції системи на зміну навантаження (у межах припустимого). Load і Performance переслідують одну й теж саму мету: перевірка продуктивності (часів відгуку) на різних навантаженнях. Власне тому їх не розділяють.

Б.1.2 Стресове тестування (Stress Testing) дозволяє перевірити наскільки додаток і система в цілому працездатні в умовах стресу і також оцінити здатність системи до регенерації, тобто до повернення до нормального стану після припинення впливу стресу. Стресом у даному контексті може бути підвищення інтенсивності виконання операцій до дуже високих значень або аварійна зміна конфігурації сервера. Також однієї з задач при стресовому тестуванні може бути оцінка деградації продуктивності, у такий спосіб мети стресового тестування можуть перетинатися з цілями тестування продуктивності.

Б.1.3 Тестування стабільності або надійності (Stability / Reliability Testing) – це перевірка працездатності додатка при тривалому (багатогодинному) тестуванні із середнім рівнем навантаження. Часи виконання операцій можуть грати в даному виді тестування другорядну роль. При цьому на перше місце виходить відсутність витоків пам'яті, перезапусків серверів під навантаженням і інші аспекти, що впливають саме на стабільність роботи.

Б.1.4 Об'ємне тестування (Volume Testing) -це одержання оцінки продуктивності при збільшенні обсягів даних у базі дані додатки, при цьому відбувається:

-         вимір часу виконання обраних операцій при визначених інтенсивностях виконання цих операцій;

-         може вироблятися визначення кількості користувачів, що одночасно працюють з додатком

Б.2 Тестування установки (Installation Testing) направлено на перевірку успішної інсталяції і настроювання, а також відновлення або видалення ПЗ. Інсталяція відбувається автоматично вручну та за допомогою візардів.

Б.3 Тестування зручності користування (Usability Testing) - це метод тестування, спрямований на встановлення ступеня зручності використання, навчання, зрозумілості і привабливості для користувачів розроблювального продукту в контексті заданих умов.

В. Тестування, що пов'язане зі змінами

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

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

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

Сам по собі термін "Регресійне тестування", залежно від контексту використання може мати різний сенс.

3 основних типи регресійного тестування:

-         регресія помилок - багів (Bug regression) - спроба довести, що виправлена помилка насправді не виправлена

-         регресія старих помилок - багів (Old bugs regression) - спроба довести, що недавня зміна коду або даних зламало виправлення старих помилок, тобто старі помилки - баги стали знову відтворюватися.

-         регресія побічного ефекту (Side effect regression) - спроба довести, що недавня зміна коду або даних зламало інші частини розроблювального додатка

В.3 Тестування зборки (Build Verification Test)

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

В.4 Санітарне тестування або перевірка погодженості/справності (Sanity Testing). Вузькоспеціалізоване тестування достатнє для доказу того, що конкретна функція працює згідно заявленим у специфікації вимогам. Є підмножиною регресійного тестування. Використовується для визначення працездатності визначеної частини додатка після змін зроблених у ньому або навколишньому середовищу. Звичайно виконується вручну.

1.3      Порядок виконання роботи

1. Обрати за допомогою викладача або самостійно ПЗ для тестування.

2. Обгрунтувати вибір видів тестування для відповідного ПЗ.

3. Розробити тест план для тестування обраної програми за допомогою MSOffice.

4. Заповнити документ тест плану на відповідне ПЗ, форма тест плану наведена у додатку А.

5. Оформити звіт з лабораторної роботи згідно додатку Б і включити в звіт створений тест план.

1.4      Висновки

У даній лабораторній роботі: було обране відповідно ПЗ і створений тест план і представлений у звіті з даної лабораторної роботи.

.

1.5      Контрольні запитання та завдання

1. В чому полягає різниця між функціональним і не функціональним тестуванням?
2. Дайте характеристику тестуванню навантаження?
3. Що входить до тестування, що пов'язане зі змінами?
4. В чому відмінність димового та санітарного тестування?
5. В чому особливості тестування установки?
6. В чому особливості регресійного тестування?

 

2       Розробка тестових випадків (test case)

 

2.1      Мета роботи

Згідно тест плану розробити тестові випадки для відповідного ПЗ.

2.2      Методичні рекомендації до самостійної роботи студентів

2.2.1 Підготовка до роботи

В процесі підготовки необхідно проробити теоретичний матеріал з конспекту лекцій, а також літературні джерела [1, с.93-178; 2, с.56-98], в яких викладені правила складання тестових випадків.

2.2.2 Сутність роботи

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

Рівні тестування:

-         компонентне або модульне тестування (Component Testing or Unit Testing)

-         інтеграційне тестування (Integration Testing)

-         системне тестування (System Testing)

-         приймальне тестування (Acceptance Testing)

Компонентне (модульне) тестування (Component or Unit Testing) перевіряє функціональність і шукає дефекти в частинах додатка, які доступні і можуть бути протестовані окремо (модулі програм, об'єкти, класи, функції тощо). Звичайно компонентне (модульне) тестування проводиться викликаючи код, який необхідно перевірити і за підтримкою середовищ розробки, таких як фреймворки (frameworks - каркаси) для модульного тестування або інструменти для налагодження. Усі знайдені дефекти, як правило виправляються в коді без формального їхнього опису в системі менеджменту помилок/дефектів - багів (Bug Tracking System).

Один з найбільш ефективних підходів до компонентного (модульного) тестування - це підготовка автоматизованих тестів до початку основного кодування (розробки) програмного забезпечення. Це називається «розробка від тестування» (test-driven development) або «підхід тестування спочатку» (test first approach). При цьому підході створюються й інтегруються невеликі частини коду, напроти яких запускаються тести, написані до початку кодування. Розробка ведеться доти поки всі тести не будуть успішними.

Інтеграційне тестування (Integration Testing) призначене для перевірки зв'язку між компонентами, а також взаємодії з різними частинами системи (операційною системою, устаткуванням або зв'язком між різними системами).

Рівні інтеграційного тестування:

­   компонентний інтеграційний рівень (Component Integration testing). Перевіряється взаємодія між компонентами системи після проведення компонентного тестування;

­   системний інтеграційний рівень (System Integration Testing). Перевіряється взаємодія між різними системами після проведення системного тестування.

Підходи до інтеграційного тестування:

­   знизу нагору (Bottom Up Integration). Усі низькорівневі модулі, процедури або функції збираються разом і потім тестуються. Після чого збирається наступний рівень модулів для проведення інтеграційного тестування. Даний підхід вважається корисним, якщо всі або практично всі модулі, рівня, що розробляється готові. Також даний підхід допомагає визначити за результатами тестування рівень готовності додатка;

­   зверху вниз (Top Down Integration). Спочатку тестуються усі високорівневі модулі, і поступово один за іншим додаються низькорівневі. Усі модулі більш низького рівня симулюються заглушками з аналогічною функціональністю, потім в міру готовності вони заміняються реальними активними компонентами;

­   великий вибух ("Big Bang" Integration). Всі або практично всі розроблені модулі збираються разом у вигляді закінченої системи або її основної частини, і потім проводиться інтеграційне тестування. Такий підхід дуже гарний для збереження часу. Однак якщо тест кейси і їхні результати записані не вірно, то сам процес інтеграції сильно ускладниться, що стане перешкодою для команди тестування при досягненні основної мети інтеграційного тестування.

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

Можна виділити два підходи до системного тестування:

­   на базі вимог (requirements based).Для кожної вимоги пишуться тестові випадки (test cases), що перевіряють виконання даної вимоги;

­   на базі випадків використання (use case based). На основі представлення про способи використання продукту створюються випадки використання системи (Use Cases). По конкретному випадку використання можна визначити один або більш сценаріїв. На перевірку кожного сценарію пишуться тест кейси (test cases), які мають бути протестовані.

Формальний процес приймального тестування, що перевіряє відповідність системи вимогам і проводиться з метою:

­   визначення чи задовольняє система приймальним критеріям;

­   винесення рішення замовником або іншою уповноваженою особою приймається додаток чи ні.

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

Рішення про проведення приймального тестування приймається, коли:

­   продукт досяг необхідного рівня якості;

­   замовник ознайомлений із планом приймальних робіт (Product Acceptance Plan) або іншим документом, де описаний набір дій, пов'язаних із проведенням приймального тестування, дата проведення, відповідальні особи тощо.

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

Тестовий випадок (test case) - сукупність вхідних даних тесту, умови виконання і очікуваних результатів, які розроблені для конкретної мети. Тестовий випадок - це найменша одиниця тестування, яку можна самостійно виконати від початку до кінця. Шаблони тестового випадку і зразок їх заповнення представлені у додатку В.

Розглянемо особливості заповнення полів шаблону тестування.

Ідентифікатор тестового випадку -  включає номер версії тесту.

Власник тесту – ПІБ особи, що експлуатує тест (воно може не співпадати з  ПІБ автора тесту).

Дата останнього перегляду – ця інформація визначає актуальність тесту.

Назва тесту - опис назви тесту, що дозволяє його легко знайти і зрозуміти його призначення. Не рекомендується вживати назви, що не несуть ніякого сенсового навантаження, наприклад, "xxxLLL0123.tst".

Місцезнаходження тесту – повна назва шляху, розташування на диску ЕОМ.

Технічна вимога, що тестується - унікальний ідентифікатор, який відображається в документах технічних вимог.

Мета тестування - формулювання того, що має досягти тест.

Конфігурація засобів тестування - специфікація вводу / виводу, умови випробувань.

Налаштування на прогін тесту - процедура подібна методиці тестування. Вона передбачає опис дій тестувальника і очікуваних результатів. Якщо настроювання автоматизовані, це виглядає так: run setupSC03.pl.

Методика тестування - опис дій тестувальника і очікуваних результатів.

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

Очистка тесту – якщо система була переведена в нестійкий стан або дані були зруйнованими, очистка дозволяє усунути подібні ситуації.

2.3      Порядок виконання роботи

1. Провести види тестування, згідно плану тестування.

2. Обрати рівні тестування

3. Розробити тестові випадки (Test Case) згідно шаблонів і прикладів додатку В.

4. Оформити звіт в якому представити всі тестові випадки для відповідного ПЗ.

2.4      Висновки

У лабораторній роботі було проведено тестування згідно тест плану і розроблені тестові випадки. Тестові випадки оформленні згідно шаблону і представлені у звіті з даної лабораторної роботи.

2.5      Контрольні запитання та завдання

1. Назвіть рівні тестування і їх основні характеристики.
2. В чому різниця між компонентним і системним тестуванням?
3. Які підходи до системного тестування, ви знаєте?
4. Які підходи до інтеграційного тестування, ви знаєте?
5. Назвіть вимоги створення тестових випадків.

 

3       техніка тест дизайну при розробці тестових випадків (Test Cases тест кейсів )

 

3.1      Мета роботи

Згідно тест плану за допомогою техніки тест дизайну створити план розробки тестових випадків (Test Cases - тест кейсів) для відповідного ПЗ.

3.2      Методичні рекомендації до самостійної роботи студентів

3.2.1 Підготовка до роботи

В процесі підготовки необхідно проробити теоретичний матеріал з конспекту лекцій, а також літературні джерела [1, с.93-178, 248-262; 2, с.98-183], в яких викладені правила з техніки тест дизайну для розробці тестових випадків.

3.2.2 Сутність роботи

Тест дизайн – це етап процесу тестування ПЗ, на якому проектуються і створюються тестові випадки (тест кейси), відповідно до визначених раніше критеріїв якості і цілей тестування.

План роботи над тест дизайном:

­   аналіз існуючих проектних артефактів: документація (специфікації, вимоги, плани), моделі, що виконується код, тощо;

­   написання специфікації з тест дизайну (Test Design Specification);

­   проектування і створення тестових випадків (Test Cases);

Техніки тест дизайну:

­   Еквівалентний поділ (Equivalence Partitioning - EP). Як приклад, у вас є діапазон припустимих значень від 1 до 10, ви повинні вибрати одне вірне значення усередині інтервалу, скажемо, 5, і одне невірне значення поза інтервалом - 0.

­   Аналіз граничних значень (Boundary Value Analysis - BVA).Якщо взяти приклад вище, як значення для позитивного тестування виберемо мінімальну і максимальну границі (1 і 10), і значення більше і менше границь (0 і 11). Аналіз Граничних значень може бути застосований до полів, записів, файлів, або до будь-якого роду сутностей, що мають обмеження.

­   Причина / Наслідок (Cause/Effect - CE). Це, як правило, уведення комбінацій умов (причин), для одержання відповіді від системи (Наслідок). Наприклад, ви перевіряєте можливість додавати клієнта, використовуючи визначену екранну форму. Для цього вам необхідно буде ввести кілька полів, таких як "Ім'я", "Адреса", "Номер Телефону" а потім, натиснути кнопку "Додати" - ця "Причина". Після натискання кнопки "Додати", система додає клієнта в базу даних і показує його номер на екрані - це "Наслідок".

­   Передбачення помилки (Error Guessing - EG). Це коли тест аналітик використовує свої знання системи і здатність до інтерпретації специфікації на предмет того, щоб "вгадати" при яких вхідних умовах система може видати помилку. Наприклад, специфікація говорить: "користувач має увести код". Тест аналітик, буде думати: "Що, якщо я не введу код?", "Що, якщо я введу неправильний код? ", і так далі. Це і є здогадування помилки.

­   Вичерпне тестування (Exhaustive Testing - ET) - це крайній випадок. У межах цієї техніки ви повинні перевірити всі можливі комбінації вхідних значень, і в принципі, це повинно знайти всі проблеми. На практиці застосування цього методу не представляється можливим, через величезну кількість вхідних значень.

План розробки тест випадків - кейсів містить.

1. Аналіз вимог.

2. Визначення набору тестових даних на підставі EP, BVA, EG.

3. Розробка шаблона тесту на підставі CE.

4. Написання тест кейсів на підставі первинних, тестових даних і кроків тесту.

Далі на прикладі, розглянемо запропонований підхід.

 

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

 

Прийом заяв через форму графічно можна представити так:

 

 

 

 

Рисунок 3.1 – Графічне зображення подання заяв через відповідну форму

 

Таблиця 3.1 – Вимоги до тестування функціональності форми прийому заявок

Елемент	Тип елемента	Вимоги
Тип звертання	combobox	Набір даних: Консультація Проведення тестування Розміщення реклами Помилка на сайте * - на процес виконання операції прийому заявок не впливає
Контактна особа	editbox	1. Обов'язкове для заповнення 2. Максимально 25 символів 3. Використання цифр і спец символів не допускається
Контактний телефон	editbox	Обов'язкове для заповнення Припустимі символи "+" і цифри "+" можна використовувати тільки на початку номера Припустимі формати: -         починається з плюса - 11-15 цифр    +31612361264   +375291438884 без плюса - 5-10 цифр, наприклад: 0613261264 або  2925167
Повідомлення	text area	1. Обов'язкове для заповнення 2. Максимальна довжина 1024 символу
Відправити	button	Стан: 1. За замовчуванням - не активна (Disabled) 2. Після заповнення обов'язкових полів стає активна (Enabled) Дії після натискання 1. Якщо введені дані коректні - відправлення повідомлення 2. Якщо введені дані НЕ коректні - валідаційне повідомлення

План розробки тест випадків - кейсів:

1. Аналіз вимог.

Читаємо, аналізуємо вимоги і виділяємо для себе наступні нюанси:

-         які з полів обов'язкові для заповнення?

-         чи мають поля обмеження по довжині або по розмірності (границі)?

-         які з полів мають спеціальні формати?

2. Визначення набору тестових даних.

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

-         залежно від рівня обов'язковості поля, визначимо які поля необхідно перевірити на порожнє значення, тому що воно може викликати помилку (У результуючій таблиці +);

-         необхідно визначити мінімальний набір даних, тому що вичерпне тестування не можливо через велику кількість всіляких комбінацій значень. Це можна зробити використовуючи такі техніки, як EP і BVA. (У результуючій таблиці **)

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

-         по завершенню генерації даних використовуючи стандартні техніки, можна додати деяку кількість значень на підставі особистого досвіду (техніка EG) - це буде використання спеціальних символів, дуже довгих рядків, різних форматів даних, регістрів у рядках (Upper, Lowwer, Mixed cases), негативні і нульові значення, кейворды Null - Na – Infinity, тощо. Сюди можна включити все, що на гадку тестувальника, може вивести додаток з ладу (У результуючій таблиці ^)

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

2.1 Вибір тестових даних для кожного окремо узятого поля

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

Поле Контактна особа. Це обов'язкове поле розміром від 1 до 25 символів (включаючи границі). Перевірка на обов'язковість додає до тестових даних порожнє значення. Проведемо аналіз граничних умов (BVA), одержимо набір: 0, 1, 2, 24, 25 і 26 символів. Порожнє значення (0 символів) уже було додано при аналізі обов'язковості поля для введення, тому при BVA ми не будемо додавати його ще раз. (Якщо його додати другий раз, відбудеться дублювання тестових даних, що не приведе до дублювання нових дефектів, а значить повторне додавання в домен не має сенсу). У зв'язку з тим, що значення 2 і 24 символи є, на наш погляд, некритичними, їх можна не додавати. У підсумку одержуємо, що мінімальний набір даних для тестування поля - це рядки 1 і 25 - ОК, і 0 (порожнє значення), 26 символів - NOK.

Поле Контактний телефон складається з декількох частин: код країни, код оператора, номер телефону (який може бути складеними і розділений дефісами). Для визначення правильного набору тестових даних необхідно розглядати кожну складову частину окремо. Застосовуючи BVA і EP, одержимо:

 

 

для номерів з плюсом

для номерів без плюса

По BVA одержимо номера з 10, 11, 12 і 14, 15, 16 цифрами, де 10 і 16 - NOK, а 11, 12, 14, 15 – OK Розглядаючи отримані дані з позиції EP виділимо, що 11, 12, 14, 15 входять в один клас еквівалентності. Тому при тестуванні ми можемо використовувати кожне з них, але тому що 11 і 15 - це границі інтервалу, то на наш погляд їх пропускати не можна. Отже ми можемо зменшити набір значень до двох, виключивши 12 і 14, а залишивши 11 і 15 для перевірки граничних умов. Разом маємо: 11 і 15 цифр - OK, (+12345678901, +123456789012345) 10 і 16 цифр - NOK; (+1234567890, +1234567890123456);

По BVA одержимо номера з 4, 5, 6 і 9, 10, 11 цифрами. Діючи аналогічно прикладу для номерів телефонів з плюсом, виключимо значення 6 і 9, залишивши 5 і 10. Разом маємо: 5 і 10 цифр - OK, (12345, 1234567890)     4 і 11 цифр-NOK;(1234, 12345678901).

Поле Повідомлення. Підбор даних проводимо за аналогією з полем Контактна особа. На виході одержуємо значення: рядка 1 і 1024 - ОК, і 1025 символів - NOK.

 

Таблиця 3.2 - Результуюча таблиця даних, для використання при наступному складанні тест кейсів

Поле	OK/NOK	Значення	Коментар
Тип звертання	OK	Консультація	перший у списку**
		Помилка на сайті	останній у списку**
	NOK
Контактна особа	OK	Йцукенгшщзйцукенгшщзйцуке	25 символів нижній регістр**
		а	1 символ**
		ЙЦУКЕНГШЩЗФЫВАПРОЛДЖЯЧСМИ	25 символів ВЕРХНІЙ регістр**
		ЙЦУКЕНГШЩЗфывапролджЯЧСМИ	25 символів Змішаний регістр**
	NOK		порожнє значення +
		Йцукенгшщзйцукенгшщзйцукей	довжина більш максимальної (26 симв.**
		@#$%^&;.?,>|\/№"!()_{}[<~	спец. символи (ASCII)^
		1234567890123456789012345	тільки цифри ^
		adsadasdasdas dasdasd asasdsads(...)sas	дуже довгий рядок (~1Mb)^
Контактний телефон	OK	+12345678901	з плюсом - мінімальна довжина
		+123456789012345	з плюсом – максимальна довжина
		12345	без плюса - мінімальна довжина
		1234567890	без плюса - максимальна довжина
	NOK		порожнє значення +
		+1234567890	з плюсом - < мінімальної довжини
		+1234567890123456	з плюсом - > максимальної довжини
		1234	без плюса - < мінімальної довжини
		12345678901	без плюса - > максимальної довжини
		+YYYXXXyyyxxzz	с плюсом - букви замість цифр
		yyyxxxxzz	без плюса - букви замість цифр
		+###-$$$-%^-&^-&!	спец. символи (ASCII) ^
		1232312323123213231232(...)99	дуже довгий рядок (~1Mb) ^
Повідомлення	OK	йццуйцуйц(...)йцу	Максимальна довжина (1024 симв.)**
	NOK	*	порожнє значення +
		йццуйцуйц(...)йцуц	Довжина більше максимальної (1025 симв.)**
		adsadasdasdas dasdasd asasdsads(...)sas	очень довгий рядок (~1Mb)
		@##$$$%^&^&	тільки спец. символи (ASCII)

3. Розробляємо шаблон тесту

На підставі техніки CE і варіантів використання (Use case)(якщо є) створимо шаблон планованого тесту. Даний документ містить кроки й очікувані результати тесту, але без конкретних даних, що заповнюються на наступному етапі розробки тест кейсів.

 

Таблиця 3.3 – Приклад шаблона тест кейса

Дія	Очікуваний результат
1. Відкриваємо форму відправлення повідомлення	-          Форма відкрита -          Усі поля за замовчуванням порожні -          Обов'язкові поля позначені - * -          Кнопка «Відправити» не активна
2. Заповнюємо поля форми: -          Тип звертання -          Контактна особа -          Контактний телефон -          Повідомлення	-          Поля заповнені -          Кнопка «Відправити» - активна (Enabled)
3. Натискаємо кнопку «Відправити»	Якщо введені дані коректні: ­   Повідомлення «Заявка відправлена» виведене на екран. ­   Нова заявка з'явилася в списку на сторінці «Заявки». Якщо введені дані НЕ коректні: ­   Валідаційне повідомлення з усіма помилками виведено на екран. ­   Заявка НЕ з'явилася в списку на сторінці «Заявки».

 

4. Написання тест кейсів на підставі первісних вимог, тестових даних і шаблона тесту

Після того, як тестові дані і кроки тесту готові приступаємо безпосередньо до розробки тест кейсів. Тут нам допоможуть такі методи комбінування як:

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

­   попарний перебір (Pairwise Testing).Найчастіше, збої викликають не складна комбінація всіх параметрів, а комбінація лише пари параметрів. Техніка попарного перебору, дозволяє створити тестові набори, що комбінують дані з двох полів. Завдяки цьому, кількість отриманих на виході тест кейсів у рази менше, ніж при комбінуванні того ж самого набору даних при послідовному переборі. Відзначимо також, що в даний момент існує кілька алгоритмів генерації комбінацій для попарного тестування: Orthogonal Arrays Testing, All pairs, IPO (In-Parameter Order). Так наприклад, при використанні техніки All Pairs у нашому конкретному випадку ми одержимо 118 тест кейса.

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

Примітка: Тест кейси розділяються по очікуваному результаті на позитивні й негативні тест кейси. У позитивному тест кейсі усі поля OK:

 

Таблиця 3.4 – Приклад позитивного і негативного тест кейсу

Позитивний тест кейс			Негативний тест кейс (поле Контактна особа - NOK):
Дія	Очікуваний результат		Дія	Очікуваний результат
1. Відкриваємо форму відправлення повідомлення	-          Форма відкрита -          Усі поля за замовчуванням порожні -          Обов'язкові поля позначені - * -          Кнопка «Відправити» не активна		1. Відкриваємо форму відправлення повідомлення	-          Форма відкрита -          Усі поля за замовчуванням порожні -          Обов'язкові поля позначені - * -          Кнопка «Відправити» не активна
2. Заповнюємо поля форми: -      Тип звертання Консультація -      Контактна особа йцукенгшщзйцукенгшщзйцуке -      Контактний телефон +7-916-111-11-11 -      Повідомлення	-          Поля заповнені -          Кнопка «Відправити» - активна (Enabled)		2. Заповнюємо поля форми: -      Тип звертання Консультація -      Контактна особа @#$%^&;.?,>|\/№"!()_{}[<~ -      Контактний телефон (916)333-33-33 -      Повідомлення йццуйцуйц(...)йцу - 1024 символу	-          Поля заповнені -          Кнопка «Відправити» - активна (Enabled)
3. Натискаємо кнопку «Відправити»	Якщо введені дані коректні: ­    Повідомлення «Заявка відправлена» виведене на екран. ­    Нова заявка з'явилася в списку на сторінці «Заявки».		3. Натискаємо кнопку «Відправити»	­  Валідаційне повідомлення з усіма помилками виведено на екран: «У поле Контактна особа заборонене використання цифр і спец. символів.» ­  Заявка НЕ з'явилася в списку на сторінці «Заявки».

3.3      Порядок виконання роботи

1. Згідно тест плану за допомогою техніки тест дизайну створити план розробки тестових випадків (Test Cases - тест кейсів) для відповідного ПЗ.

2. Заповнити для обраного ПЗ таблиці аналогічні таблицям 3.1-3.4.

3. Оформити звіт в якому представити план розробки тестових випадків (Test Cases - тест кейсів) відповідного ПЗ.

3.4      Висновки

У лабораторній роботі було створено план розробки тестових випадків (Test Cases - тест кейсів) за допомогою техніки тест дизайну. План розробки тестових випадків представлений у звіті з даної лабораторної роботи.

3.5      Контрольні запитання та завдання

1. Що таке тест дизайн?
2. Назвіть техніки тест дизайну і їх основні характеристики.
3. Які основні розділи включає план розробки тестових випадків?

 

4       Розробка звітів про помилки/ дефекти (bug report)

 

4.1      Мета роботи

Згідно тест плану, тестових випадків для відповідного ПЗ, що закінчилися невдало розробити звіт про помилки/дефекти (Bug Report).

4.2      Методичні рекомендації до самостійної роботи студентів

4.2.1 Підготовка до роботи

В процесі підготовки необхідно проробити теоретичний материал з конспекту лекцій, а також літературні джерела [1, с.248-262; 2, с.293-368], в яких викладені правила складання звіту про помилки/дефекти (Bug Report). Приклад звіту про помилки/дефекти наведено у додатку Г.

4.2.2 Сутність роботи

Звіт про помилки/дефекти (Bug Report, Баг репорт) - це технічний документ і мова опису має бути технічною. Повинна використовуватися правильна термінологія при використанні назв елементів інтерфейсу користувача (editbox, listbox, combobox, link, text area, button, menu, popup menu, title bar, system tray, тощо.), дій користувача (click link, press the button, select menu item,тощо) і отриманих результатах (window is opened, error message is displayed, system crashed, тощо).

Обов'язковими полями баг репорту є: короткий опис (Bug Summary), серйозність (Severity), кроки до відтворення (Steps to reproduce), результат (Actual Result), очікуваний результат (Expected Result). Нижче приведені вимоги і приклади по заповненню цих полів.

Короткий опис. Зміст усього баг репорту. Наприклад:

1. Додаток зависає, при спробі збереження текстового файлу розміром більше 50Мб.

2. Дані на формі «Профайл» не зберігаються після натискання кнопки «Зберегти».

 

При написанні баг репорту використовується принцип "Де? Що? Коли?":

Де?: У якому місці інтерфейсу користувача або архітектури програмного продукту знаходиться проблема. Причому, починайте пропозицію з іменника, а не з прийменника (предлог).

Що?: Що відбувається або не відбувається відповідно до специфікації або вашій уяві про нормальну роботу програмного продукту. При цьому вказуйте на наявність або відсутність об'єкта проблеми, а не на його зміст (його вказують в описі). Якщо зміст проблеми варіюється, усі відомі варіанти вказуються в описі.

Коли?: У який момент роботи програмного продукту, або при якій події або при яких умовах проблема виявляється.

Серйозність.Якщо проблема знайдена в ключовій функціональності додатку і після її виникнення додаток стає цілком недоступний, і подальша робота з ним неможлива, то вона є помилкою, що блокує. Звичайно всі проблеми, що блокують, знаходяться під час первинної перевірки нової версії продукту (Build Verification Test, Smoke Test), тому що їхня наявність не дозволяє повноцінно проводити тестування. Якщо ж тестування може бути продовжено, то серйозність даного дефекту буде критична.

Кроки до відтворення / Результат / Очікуваний результат.Дуже важливо чітко описати всі кроки, зі згадуємо усіх вводи даних (імені користувача, даних для заповнення форми) і проміжних результатів.

Наприклад:

Кроки до відтворення

1. Увійдіть у систему: Користувач Тестер1, пароль xxxXXX > Вхід у систему здійснений.

2. Кликніть линк Профайл > Сторінка Профайл відкрилася.

3. Уведіть Нове ім'я користувача: Тестер2.

4. Натисніть кнопку Зберегти.

Результат.

На екрані з'явилася помилка. Нове ім'я користувача не був збережено.

Очікуваний результат.

Сторінка профайл перевантажилася. Нове значення імені користувача збережено.

 

Серйозність і пріоритет дефекту.

Серйозність (Severity) - це атрибут, що характеризує вплив дефекту на працездатність додатка.

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

Градація серйозності дефекту (Severity)

­   S1 Що Блокує (Blocker) – цяпомилка, приводить додаток у неробочий стан, у результаті якого подальша робота з системою, що тестується або її ключовими функціями стає неможлива. Рішення проблеми необхідно для подальшого функціонування системи.

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

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

­   S4 Незначна (Minor) - не порушує бізнес логіку частини додатка, що тестується, очевидна проблема інтерфейсу користувача.

­   S5 Тривіальна (Trivial) - не стосується бізнес логіки додатка, погано відтворена проблема, малопомітна по засобах інтерфейсу користувача, проблема сторонніх бібліотек або сервісів, проблема, що не робить ніякого впливу на загальну якість продукту.

Градація пріоритету дефекту (Priority).

­   P1 Високий (High). Помилка повинна бути виправлена якнайшвидше, тому що її наявність є критичною для проекту.

­   P2 Середній (Medium). Помилка повинна бути виправлена, її наявність не є критичної, але вимагає обов'язкового рішення.

­   P3 Низький (Low). Помилка повинна бути виправлена, її наявність не є критичної, і не вимагає термінового рішення.

Порядок виправлення помилок за пріоритетами: High > Medium > Low

Наявність відкритих дефектів P1, P2 і S1, S2, вважається неприйнятним для проекту. Усі подібні ситуації вимагають термінового рішення і йдуть під контроль до менеджерів проекту.

Наявність строго обмеженої кількості відкритих помилок P3 і S3, S4, S5 не є критичним для проекту і допускається у додатку. Кількість же відкритих помилок залежить від розміру проекту і встановлених критеріїв якості.

Шаблон звіту про помилки/дефекту поданий у додатку Г.

4.3      Порядок виконання роботи

1. Проаналізувати тестові випадки

2. Обрати тестові випадки, коли результат тесту мав такі результати: ПРОВАЛЕНО (Fail), або ЗАБЛОКОВАНО (Blocked).

3. Розробити для таких тестових випадків (Test Case) звіт про помилки/дефекти, які призвели до означених результатів тестування.

4. Оформити звіт в якому представити всі тестові помилки/дефекти відповідно до тестових випадків, тест плану відповідного ПЗ і прикладу додатка Г.

4.4      Висновки

У лабораторній роботі був складений звіт з помилок/дефектів. Звіт з помилок/дефектів оформленні згідно прикладу і представлений у звіті з даної лабораторної роботи.

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

1       Назвіть причини створення звіту про помилки/дефекти (Bug Report).

2       Назвіть особливості створення звіту про помилки/дефекти.

3       Назвіть градацію серйозності дефекту.

4       Назвіть градацію пріоритету дефекту.

ПЕРЕЛІК ПОСИЛАНЬ

 

1. Канер, Кем, Тестування програмного забезпечення. Фундаментальные концепции менеджменту бизнес-приложений [Текст]: учеб. / Д. Фолк, Енг Кек Нгуєн - К.: ДиаСофт, 2001. - 544 с.
2. Калбертсон, Роберт Быстрое тестирование [Текст]: учеб. / К. Браун, Г. Кобб. - М.: «Вильямс», 2002. - 374 с.

 

Додаток А

Форма тест плану

 

 

 

 

Назва проекту

(Project Name)

 

План випробувань і тестування

(Test Plan)

 

 

 

Версія 1.0

(Version 1.0)

Історія змін (Revision History)

 

Дата (Date dd/mmm/yy)	Версія (Version x.x)	Детальний опис (Description details)	ПІБ Автора (Author name)

Зміст (Table of Contents)

 

 

1.   Вступ (Introduction)

1.1   Мета (Purpose)

1.2   Довідкова інформація (Background)

1.3   Галузь застосування (Scope)

1.4   Визначення проекту (Project Identification)

2.   Вимоги до тестування (Requirements for Test)

3.   Стратегія тестування (Test Strategy)

3.1   Типи тестування (Testing Types ) 29

3.1.1  Дані і БД Інтеграційне тестування (Data and Database Integrity Testing)

3.1.2  Функціоанльне тестування (Function Testing)

3.1.3  Бізнес-цикл тестування (Business Cycle Testing)

3.1.4  Тестування інтерфейсу користувача (User Interface Testing)

3.1.5  Тестування продуктивності (Performance Profiling )

3.1.6  Завантажувальне тестування (Load Testing)

3.1.7  Стресове тестування (Stress Testing)

3.1.8  Навантажувальне тестування (Volume Testing)

3.1.9  Тестування безпеки і контролю доступу (Security and Access Control Testing)

3.1.10   Тестування відмовостійкості та відновлення (Failover and Recovery Testing)

3.1.11   Тестування конфігурації (Configuration Testing)

3.1.12   Тестування інсталяції (Installation Testing)

3.2   Інструменти (Tools)

4.   Ресурси (Resources)

4.1   Ролі (Roles)

4.2   Система (System)

5.   Етапи проекту (Project Milestones)

6.   Кінцевий продукт (Deliverables)

6.1   Тестова модель (Test Model)

6.2   Тестовий журнал (Test Logs)

6.3   Звіти з дефектів (Defect Reports)

7.   Додаток А Задачі проекту (Appendix A Project Tasks)

 

Тестовий план (Test Plan)

1 Вступ (Introduction)

1.1 Мета (Purpose)

-          Виявлення існуючих проектів і програмних компонентів, які необхідно перевірити.

-          Перелік вимог для проведення випробування.

-          Рекомендації щодо опису стратегії тестування.

-          Визначення необхідних ресурсів і забезпечення оцінки випробувань.

-          Перелік тестових елементів проекту.

1.2 Довідкова інформація (Background)

Опис елементів тестування (компоненти, додатки, системи тощо). Інформація, щодо основних функцій і можливостей, архітектури, короткої історії проекту. Цей розділ містить від 3 до 5 пунктів.

1.3 Галузь застосування (Scope)

Описують:

-          Типи, наприклад, групи, інтеграцію, систему, етапи тестування (функціональність і продуктивність).

-          Перелік особливостей функцій, що будуть протестовані.

-          Перелік пропозицій, що можуть вплинути на проектування, розробку тестування.

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

-          Перелік обмежень, які можуть вплинути на проектування, розробку тестування.

1.4 Визначення проекту (Project Identification)

Примітка: видаляти або додавати елементи таблиці можна за необхідністю.

Документ і версія / дата) (Document and version / date)	Створено або Доступно (Created or Available)	Поступило або Відзив (Received or Reviewed)	Автор або ресурс (Author or Resource)	Примітка (Notes)
Специфікація вимог (Requirements Specification)	o Так  o Ні o Так  o Ні
Функціональна специфікація (Functional Specification)	o Так  o Ні o Так  o Ні
Звіти використання - випадок (Use-Case Reports)	o Так  o Ні o Так  o Ні
План проекту (Project Plan)	o Так  o Ні o Так  o Ні
Специфікація дизайну (Design Specifications)	o Так  o Ні o Так  o Ні
Прототип (Prototype)	o Так  o Ні o Так  o Ні
Керівництво користувача  (User’s Manuals)	o Так  o Ні o Так  o Ні
Бізнес модель (Business Model or Flow)	o Так  o Ні o Так  o Ні
Модель даних (Data Model or Flow)	o Так  o Ні o Так  o Ні
Бізнес-функції (Business Functions and Rules)	o Так  o Ні o Так  o Ні
Оцінка ризиків (Project or Business Risk Assessment)	o Так  o Ні o Так  o Ні

2 Вимоги до тестування (Requirements for Test)

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

3 Стратегія тестування (Test Strategy)

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

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

Якщо тип тесту не буде реалізований і виконаний, необхідно обґрунтовано вказати причину його не виконання. Наприклад, "Цей тест не буде виконуватися, тому що він не підходе для випробування системи”, тощо.

Основними вимогами для випробування стратегії є методи, які використовуються і критерії тестування.

Тестування має бути виконане тільки з використанням відомих, контролюючих БД в захищених середовищах.

3.1 Типи тестування (Testing Types )

3.1.1 Дані і БД Інтеграційне тестування (Data and Database Integrity Testing)

БД і БД процесів мають бути перевірені в якості підсистеми в межах проекту. Ці підсистеми мають бути перевірені як інтерфейс з даними без тестування Інтерфейсу Користувача

Додаткові дослідження в СУБД мають бути виконані із зазначенням інструментів і методів, які можуть існувати для підтримки тестування, див. табл. нижче.

Мета випробування (Test Objective)	Забезпечення методів доступу до БД і функціональних процесів без пошкодження даних .
Технічний прийом (Technique)	-          Виклик кожного метода доступу до БД і функціональних процесів, відбір дійсних та недійсних даних або запитів. -          Перевірка БД для забезпечення: цілісності та несуперчних даних, а також всіх запитів, що пов’язані з роботою БД.
Критерії завершення (Completion Criteria)	Виконання всіх методів доступу до БД і функціональних процесів без пошкодження даних.
Спеціальні рекомендації (Special Considerations)	-          Тестування середовища СУБД може вимагати розвитку або драйверів для вводу або зміни даних безпосередньо в базах даних. -          Процеси повинні бути викликані вручну. Малий або мінімальний розмір БД (обмежена кількість записів) має бути використаний для підвищення видимості будь-якої неприйнятої події.

3.1.2 Функціональне тестування (Function Testing)

Функція тестування повинна зосередитися на будь-яких вимогах для випробувань, які можуть бути простежені, безпосередньо використовуватимуть випадки або бізнес-функції і бізнес-правила. Мета цих тестів - перевірка правильності прийняття даних, обробки і пошуку, а також належного виконання бізнес-правил. Цей тип тестування заснований на методі тестування «чорної скрині», тобто перевірки додатка і його внутрішніх процесів, взаємодіючи з додатком через графічний інтерфейс користувача (GUI) й аналізу продукції або результатів. Зазначений нижче план тестування рекомендується для кожного додатка.

Мета випробування (Test Objective)	Забезпечити належне тестування функціональності, в тому числі навігації, введення даних, обробки і пошуку.
Технічний прийом (Technique)	Виконати перевірку кожного випадку потоку, або функції, з використанням дійсних і недійсних даних, щоб перевірити: -          Очікувані результати, що виникають при достовірних даних. -          Відповідні помилки або попередження, що виникають при введенні невірних даних. -          Правильність застосування кожного бізнес-правила.
Критерії завершення (Completion Criteria)	-          Всі заплановані випробування було проведено. -          Усі виявлені дефекти були розглянуті.
Спеціальні рекомендації (Special Considerations)	Визначити або описати ті пункти або питання, які впливають на здійснення та виконання основної функції.

3.1.3 Бізнес-цикл тестування (Business Cycle Testing)

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

Мета випробування (Test Objective)	Забезпечити належне тестування і фонові функціональні процеси відповідно до необхідної бізнес-моделей та графіків.
Технічний прийом (Technique)	Тестування буде імітувати кілька циклів ділової активності, а саме: -          тести, що використовуються для тестування цільової функції, яка може бути змінена або розширена, для збільшення числа. Кожна функція виконується для імітації різних користувачів протягом певного періоду часу. -          Весь час або тестування функцій буде виконуватися з використанням дійсних і недійсних дат або періодів часу. -          Всі функції, які відбуваються згідно за графіком періодично будуть виконані і розпочаті у відповідний час. -          Тестування буде включати в себе використання дійсних та недійсних даних для перевірки: використовуються очікувані результати виникають при достовірних даних; використовуються відповідні помилки або попередження відображаються при введенні невірних даних; правильно застосовувати бізнес-правила.
Критерії завершення (Completion Criteria)	Всі заплановані випробування були проведені. Усі виявлені дефекти були розглянуті.
Спеціальні рекомендації (Special Considerations)	Система дати і подій можуть вимагати спеціальної підтримки діяльності бізнес-моделі, необхідної для визначення відповідних вимог до випробувань та процедур

3.1.4 Тестування інтерфейсу користувача (User Interface Testing)

Тестування інтерфейсу користувача (UI) – це перевірка взаємодії користувача з програмним забезпеченням. Мета тестування інтерфейсу користувача полягає в зручності надання користувачеві, з відповідним рівнем доступу, навігації цільових функцій. Крім того, тестування інтерфейсу користувача гарантує відповідність об'єктів функцій UI, очікуваним і/або корпоративним або галузевим стандартам.

Мета випробування (Test Objective)	Перевірте наступне: -          Навігація через механізм тестування програми з правильним відображенням бізнес-функцій та вимог, у тому числі вікна до вікна, поля для поля, і використання методів доступу (закладка клавіш, рух миші, поєднання клавіш). -          Вікно об'єктів і характеристик, таких як меню, розмір, положення, стан, має відповідати нормам.
Технічний прийом (Technique)	Створення та редагування випробувань для кожного вікна, щоб перевірити правильність навігації і станів об'єкта для кожного вікна програми і об'єктів.
Критерії завершення (Completion Criteria)	Кожне вікно послідовно успішно перевірене у тестовій версії або протягом прийнятного рівня.
Спеціальні рекомендації (Special Considerations)	Не всі властивості для користувача об'єктів і третього учасника можуть бути доступні.

3.1.5 Тестування продуктивності (Performance Profiling )

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

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

Мета випробування (Test Objective)	-          Перевірка продуктивності поведінки для призначених операцій або бізнес-функцій при дотриманні наступних умов: Нормальний очікуваний обсяг. Очікується гірший випадок навантаження.
Технічний прийом (Technique)	-          Використання випробувань і тестування функцій. -          Зміна файлів даних зі збільшенням числа транзакцій або скриптів для збільшення числа ітерацій кожної транзакції. -          Сценарії повинні бути запущені на одній машині (кращий випадок для порівняння одного користувача, однієї транзакції) і повторюватися з декількома клієнтами (віртуальним або фактичним див. Спеціальні рекомендації нижче).
Критерії завершення (Completion Criteria)	-          Одна операції або один користувач: Успішне завершення тестових скриптів без будь-яких збоїв і в межах очікування або в межах виділеного часу на транзакцію. -          Кілька угод або кілька користувачів: Успішне завершення тестових скриптів без будь-яких збоїв і в межах прийнятного розподілу часу.
Спеціальні рекомендації (Special Considerations)	Охоплююче тестування включає наявність фону навантаження на сервер. Є кілька методів, які можуть бути використані для виконання цього, в тому числі: -          "Драйв операцій" безпосередньо на сервері, як правило, у вигляді мови структурованих запитів (SQL) звернень. -          Створення "віртуальних" користувачів навантаження з метою імітації чисельних клієнтів, як правило, кілька сотень. Віддалений термінал емуляції - інструменти використовуються для досягнення цього навантаження. Цей метод може також бути використаний для завантаження мережі з трафіком. -          Використання декілька фізичних клієнтів, кожний з яких виконує сценарії випробувань на місці навантаження на систему. Тестування має проводитися на виділеному комп'ютері або в означений час. Це дозволяє повністю контролювати і точніше проводити вимірювання. Бази даних, що використовуються для тестування продуктивності повинні бути або фактичного розміру або однакового масштабу.

3.1.6 Завантажувальне тестування (Load Testing)

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

Примітка: Операції нижче, відносяться до „логічних”. Ці операції визначаються як специфічні функції, які кінцевий користувач системи повинен виконувати за допомогою програми

Мета випробування (Test Objective)	Перевірка роботи в часі для призначених операцій або бізнес-кейсів при різних умовах навантаження.
Технічний прийом (Technique)	Використовуйте тести, розроблені для функцій або для тестування бізнес-циклів. Змінити файли даних для збільшення числа операцій, щоб збільшити кількість звернень.
Критерії завершення (Completion Criteria)	Декілька транзакцій або декількох користувачів. Успішне завершення випробувань без будь-яких збоїв і в рамках прийнятного розподілу часу.
Спеціальні рекомендації (Special Considerations)	Завантажувальне тестування має проводитися на виділеному комп'ютері або у відведений час. Це дозволяє повністю контролювати і точно вимірювати. Бази даних, що використовуються для завантажувального тестування повинні бути або фактичного розміру або однакового масштабу.

3.1.7 Стресове тестування (Stress Testing)

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

Мета випробування (Test Objective)	Тестування при таких умовах стресу: -          мала або взагалі відсутня пам'ять, що доступна на сервері (RAM і DASD). -          фактична або фізична максимальна кількість клієнтів, підключених або змодельованих. -          велика кілька користувачів, що виконують однакові операції, або одночасні транзакції.
Технічний прийом (Technique)	Використовуйте тести, розроблені для профілювання продуктивності або навантажувального тестування. Для перевірки обмеженості ресурсів, тести повинні бути запущені на одній машині, і обсяг оперативної пам'яті і DASD на сервері повинен бути зменшений або обмежений. Для інших стрес-тестів, необхідно достатньо користувачів.
Критерії завершення (Completion Criteria)	Всі заплановані тести виконуються у зазначених межах системи.
Спеціальні рекомендації (Special Considerations)	Стрес мережі може вимагати мережевих інструментів для завантаження мережі з повідомленнями або пакетів. DASD, використовувані в системі повинно бути тимчасово зменшено або обмежений вільний простір для БД Синхронізація одночасних клієнтів, які звертаються до однієї і тієї ж записи або до даних розрахунків.

3.1.8 Навантажувальне тестування (Volume Testing)

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

Мета випробування (Test Objective)	тест успішно працює в наступних сценаріях: -          Максимальна (фактична або фізична) кількість клієнтів, підключених, або змодельованих, виконують бізнес-функції протягом тривалого часу. -          Максимальний розмір бази даних було досягнуто (фактичний або збільшений) і одночасно виконуються декілька запитів або транзакцій операцій.
Технічний прийом (Technique)	Використовуйте тести, розроблені для профілювання продуктивності або навантажувального тестування.
Критерії завершення (Completion Criteria)	Всі заплановані тести виконуються і зазначені межі системи.
Спеціальні рекомендації (Special Considerations)	Який період часу необхідно розглядати для тестування.

3.1.9 Тестування безпеки і контролю доступу (Security and Access Control Testing)

Тестування безпеки і контролю доступу має зосередити увагу на:

-          застосуванні рівня безпеки, включаючи доступ до даних або бізнес-функцій,

-          рівнях системи безпеки, в тому числі при віддаленому доступу до системи.

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

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

Мета випробування (Test Objective)	Застосування рівня безпеки. Переконайтеся, що актор може отримати доступ тільки до тих функцій або даних, до яких їх тип користувача має дозвіл. Система безпеки на рівні: Переконайтеся, що тільки ті суб'єкти, що мають доступ до системи і додатків мають доступ до них.
Технічний прийом (Technique)	Застосування рівня безпеки: Визначення та перелік кожного типу користувачів з відповідним дозволом до відповідних функцій. Створювати тести для кожного типу користувача і перевірки кожного рішення шляхом створення специфічної операції для кожного типу користувача. Для тих же користувачів змінити тип користувача для повторних випробувань. У кожному разі, необхідно перевірити ці додаткові функції або дані, які доступні або заборонені.
Критерії завершення (Completion Criteria)	Запустити у попередній заявці функціональний тест для кожного відомого типу акторів, відповідної функції або даних. І порівняти результати з очікуваними.
Спеціальні рекомендації (Special Considerations)	Доступ до системи має бути переглянутим або обговорюватися з відповідними системними адміністраторами мережі. Це тестування не може вимагатися, як функція адміністрації мережі або системи.

3.1.10 Тестування відмовостійкості та відновлення (Failover and Recovery Testing)

Цей вид тестування гарантує працездатність ПЗ, мережі або збереження даних.

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

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

Мета випробування (Test Objective)	Переконайтеся, що процеси відновлення (ручний або автоматичний) правильно відновлюють БД, додатки і систему. Наступні типи умов мають бути включені в тестування: -          відключення живлення клієнта -          відключення живлення сервера -          переривання зв'язку через мережу серверів -          перерви зв'язку, а також втрата потужності на DASD або контролерах. -          неповні цикли (дані фільтра процесів переривається, дані процесу синхронізації перервана). -          неприпустимий покажчик БД або ключів. -          недійсний або пошкоджений елемент даних в БД.
Технічний прийом (Technique)	Тести створюються для функцій і бізнес-циклів. Як тільки необхідна початкова тестова точка досягнута, наступні дії повинні бути виконані, або змодельовані, індивідуально: -          відключення живлення клієнта: потужність ПК падає. -          відключення живлення сервера: імітувати або ініціювати виключення процедур сервера. -          переривання через мережу серверів: імітувати або ініціювати втрати зв'язку з мережею (фізично відключити дроти зв'язку або відключення живлення мережі серверів або маршрутизаторів. Переривання зв'язку, або втрата потужності на DASD і DASD контролери: імітувати або фізично ліквідувати зв'язок з одним або кількома контролерами DASD або пристроїв. Після цих штучно створених умов досягаються додаткові операції. Тестування вимагає, щоб деякі поля БД, покажчики, і ключі були пошкоджені вручну і безпосередньо в БД (за допомогою інструментів для БД). Додаткові операції тестуються із застосуванням функцій і бізнес-циклів тестування і повних циклів.
Критерії завершення (Completion Criteria)	Всі випадки тестування, що були зроблені вище, включають додатки, БД та системи, які мають по завершенні процедури відновлення, повернення до відомого стану, крім того включає в себе дані, пошкоджені поля, покажчики або ключі, а також повідомлення про те, процеси або операції, які не були завершені через перерву.
Спеціальні рекомендації (Special Considerations)	-          Процедура відключення кабелів не бажана. Може знадобитися альтернативний метод - діагностичний інструмент програмного забезпечення. -          Ресурси системи (чи комп'ютерних операцій), бази даних та мережі групи не потрібні. -          Ці тести повинні бути запущені після години роботи або на ізольованій машині.

3.1.11 Тестування конфігурації (Configuration Testing)

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

Мета випробування (Test Objective)	Тестування проводиться належним чином на необхідному апаратному і програмному забезпеченні
Технічний прийом (Technique)	Використовувати функцію тестових сценаріїв. Відкриття та закриття різного відповідного ПЗ, що використовується як частина тестування або до початку випробування. Виконання зазначеної операції для імітації взаємодії актора з цільовим ПЗ. Повторення процесу при мінімальній конфігурації апаратного і ПЗ. Для кожної комбінації виконання тестів, всі операції мають бути успішно завершені без збоїв.
Критерії завершення (Completion Criteria)	Для кожної комбінації цільових і нецільових тестів, всі операції успішно завершені без збоїв.
Спеціальні рекомендації (Special Considerations)	Які нецільові програмні засоби, доступні, і є на робочому столі? Які програми зазвичай використовуються? В яких програмах, що працюють, відкрито великі таблиці, наприклад Excel або 100 - сторінковий документ Word? Необхідно задокументувати в рамках цього тесту системи, NetWare, мережеві сервери, бази даних тощо.

3.1.12 Тестування інсталяції (Installation Testing)

Тестування інсталяції має дві мети:

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

2. Перевірка після установки того, що ПЗ працює правильно. Це зазвичай означає функціональне тестування.

Мета випробування (Test Objective)	Правильна установка ПЗ на кожне машину з необхідною конфігурацією при дотриманні наступних умов: -          нові установки, нові машини, ніколи не встановлювалося ПЗ з означеного проекту, -          оновлення, на ЕОМ раніше встановлено ПЗ такоїж версії, -          оновлення, на ЕОМ раніше встановлено стара версія ПЗ.
Технічний прийом (Technique)	Ручна установка або автоматична з набором скриптів. Для встановлення ПЗ -¾перевірка стану цільової машині і наявності ПЗ і ПЗ , що ставиться. Було воно встановлено, чи ні, якщо ПЗ встановлено було, то необхідно дізнатися якої версії Використання зумовило суб-набір скриптів функціонального тесту.
Критерії завершення (Completion Criteria)	ПЗ виконано успішно без збоїв.
Спеціальні рекомендації (Special Considerations)	Операції повинні бути обрані для впевненості того, що тест був успішно виконаний і є достатня кількість основних компонентів ПЗ

3.2 Інструменти (Tools)

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

Примітка: видаляти або додавати елементи таблиці можна за необхідністю.

	Інструмент (Tool)	Постачальник (Vendor/In-house)	Версія (Version)
Управління тестами (Test Management)
Відслідковування дефектів (Defect Tracking)
ASQ інструмент для функціонального тестування (ASQ Tool for functional testing)
ASQ інструмент для тестування продуктивності (ASQ Tool for performance testing)
Тестовий монітор покриття або Profiler (Test Coverage Monitor or Profiler)
Управління проектами (Project Management)
СУБД інструменти (DBMS tools)

4 Ресурси (Resources)

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

4.1 Ролі (Roles)

Ця таблиця показує, кадрові забезпечення  для проекту.

Примітка: видаляти або додавати елементи таблиці можна за необхідністю.

Людський ресурс (Human Resources)
Працівник (Worker)	Рекомендований мінімальний обсяг осіб (повний робочий день). (Minimum Resources Recommended (number of full-time roles allocated))	Конкретні обов'язки або Коментарі (Specific Responsibilities or Comments)
Тест-менеджер, Менеджер з тестування (Test Manager, Test Project Manager)		Забезпечує управління наглядом. Обов'язки: -          технічна підтримка, -          придбання відповідних ресурсів, -          забезпечення управлінської звітності
Конструктор тестів (Test Designer)		Визначення, пріоритетів, і реалізація тестів. Обов'язки: -          створення плану тестування, -          генерація тестових моделей, -          оцінка ефективності тестових зусиль.
Тестувальник (Tester)		Виконання тестів. Обов'язки: -          виконання тестів, -          журнал результатів, -          відновлення в журналі реєстрації після помилок, -          документ зміни.
Тестовий системний адміністратор (Test System Administrator)		Забезпечує тестове середовище і управління активами. Обов'язки: -          адміністрування тестової системи управління, -          встановлення і управління доступом до тест-системи.
Адміністратор бази даних (Database Administrator, Database Manager)		Забезпечує управління і підтримку тестових даних (бази даних) навколишнє середовище та активи Обов'язки: -          адміністрування тестових даних (БД)
Дизайнер (Designer)		Виявляє і визначає операції, атрибути та асоціації тестів. Обов'язки: -          виявляє і визначає тестові класи -          ідентифікує і визначає з тестовими пакетами
Виконавець (Implementer)		Реалізує модульні тести і тестові класи Обов'язки: -          створює тестові класи і пакети, -          виконує тестові моделі

4.2 Система (System)

Нижче в таблиці представлені системні ресурси для тестування проекту.

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

Примітка: видаляти або додавати елементи таблиці можна за необхідністю.

Системні ресурси (System Resources)
Ресурси (Resource)	Назва (Name) / Тип (Type)
Сервер БД (Database Server)
- Мережі та підмережі (Network or Subnet)	підлягає подальшому уточненню (TBD)
- Ім’я серверу (Server Name)	підлягає подальшому уточненню (TBD)
- Ім’я БД (Database Name)	підлягає подальшому уточненню (TBD)
Клієнт випробувань ПК (Client Test PC's)
- Включає спеціальні вимоги до конфігурації (Include special configuration requirements)	підлягає подальшому уточненню (TBD)
Тестування репозиторія (Test Repository)
- Мережі та підмережі Network or Subnet	підлягає подальшому уточненню (TBD)
- Ім’я серверу Server Name	підлягає подальшому уточненню (TBD)
Тест розвитку ПК (Test Development PC's)	підлягає подальшому уточненню (TBD)

5 Етапи проекту (Project Milestones)

Тестування відповідного проетку повинно включати уільове випробування.

Цільове завдання (Milestone Task)	Обсяг робіт (Effort)	Дата початку (Start Date)	Дата закінчення (End Date)
План випробувань (Plan Test)
Тест – дизайн (Design Test)
Реалізація випробувань (Implement Test)
Виконання тесту (Execute Test)
Оцінка випробувань  (Evaluate Test)

6 Кінцевий продукт (Deliverables)

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

6.1 Тестова модель (Test Model)

В цьому розділі визначаються звіти, які будуть створені і поширені з тестування моделі. Ці артефакти у тестовій моделі мають бути створені або вказують посилання на інструменти ASQ (American Society Quality – Американська спільнота якості ).

6.2 Тестовий журнал (Test Logs)

Описують методи та інструменти, що використовувалися для запису і звітів тестових результатів і статусу тестування.

6.3 Звіти з дефектів (Defect Reports)

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

7 Додаток А Задачі проекту (Appendix A Project Tasks)

Нижче наводиться завдання тесту:

 

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

 

Додаток Б

Приклад оформлення титульного листа звіту з лабораторних робіт

 

 

Міністерство освіти і науки України

Харківський національний університет радіоелектроніки

 

 

 

 

 

 

 

 

 

ЗВІТ

з лабораторної роботи №____

з дисципліни „Тестування програмного забезпечення”

 

 

 

 

 

 

 

 

 

 

 

Виконав: Студент групи ________	Перевірив: Доцент каф. ПЗ ЕОМ
(П І.Б.)	Ревенчук І.А.

 

 

 

 

 

 

 

 

 

 

Харків, 2010

 

Додаток В

Шаблони і приклади заповнення тестового випадку(Test Case)

 

В.1 Шаблон №1 тестового випадку

 

Інформація про тестовий випадок
Ідентифікатор тестового випадку			SC03 ver3.0
Власник тесту			Іванов І.І
Місцезнаходження тесту (шлях)			TestServer:D:\TestProject\TestSuite\SC03.doc
Дата останнього перегляду			День/місяць/рік
Технічна вимога, що тестується			SC101
Конфігурація засобів тестування			ST02
Взаємозалежність тестових випадків			Виконати прогін тесту SC01 і його на лаштування перед прогіном даного тесту.
Мета тесту			Перевірити, що допустимі вхідні значення ваги вантажу, що відправляється, дають вірне значення вартості доставки, і що недопустимі вхідні значення призводять до повідомлення про помилку.
Методика тестування
Налаштування прогону теста	Не проводиться					N/A *
Крок	Дія			Очікуваний результат		Відмітка(V)*
1.	Клацнути на елементі „Стоимость доставки” в головному меню.			Відображається меню „Стоимость доставки”		(V)
2.	Ввести „101” в поле „Вес доставляемого груза”			Повідомлення про помилку „Неправильно указан вес доставляемого груза” (V)		(V)
3.	Ввести „0” в поле „Вес доставляемого груза”			Повідомлення про помилку "Неправильно указан вес доставляемого груза"		X
4.	Ввести „100” в поле „Вес доставляемого груза”			Вказана вага вантажу, що доставляється „100 грамм”		(V)
5.	Ввести „1” в поле „Вес доставляемого груза”			Вказана вага вантажу, що доставляється „1 грамм”		(V)
Очистка після прогону теста	Не проводиться					N/A *
Результати тесту
Тестувальник: Іванов І.І		Дата прогона теста: День/місяць/рік			Результат тесту (P/F/B)*: Провалено (F)
Примітка:  - Тест зазнав гавдачі на кроці 3. - При виникненні несправності видається код помилки BR1011.

*-N/A:Неприменимо (англ. not applicable) — в случае, когда 2-3 компонента, на которые указывает ячейка, не совместимы между собой, так что вносить данные в эту ячейку нет смысла. Нет данных (англ. not available).  Нет ответа (англ. no answer). Недоступен (англ. not available); (V) – Verification&Validation; P/F/B – Pass / Fail / Blocked. (пройдено/ провалено/заблоковано)

В.2 Шаблон №2 тестового випадку

 

Назва тесту:	Тест відправки коментарю
Функція:	Контакт-Питання
Дія		Очікуваний результат	Результат тесту: -          пройдено (P); -          провалено (F); -          заблоковано(B).
Передумова:
Відкрийте сайт ПроТестинг: http://www.protesting.ru		Сайт ПроТестинг відкритий і доступний	Пройдено
Перейдіть за посиланням "Задать вопрос" внизу сторінки		Сторінка „Вопросы, пожелания и заявки” відкрита і доступна	Пройдено
Кроки тесту:
Заповніть форму відправки коментаря: „Тип Обращения”: Коментар „Контактное лицо”: Ольга „E-mail”:  test@test.com „Сообщение”: Добрий день, коллектив "ПроТестинг"! Я ще жодного разу не бачила приклад баг-репорта і тест-кейсу. Підкажіть,где я могу з ними ознайомитися? Ольга.		Дані успішно введені	Пройдено
Клацніть кнопку „Отправить”		Сторінка „Ваш запрос успешно отправлен!” відкрита	Пройдено
Постумова:
Клацніть за посиланням "Перейти Назад на форму отправления заявок"		Сторінка „Вопросы, пожелания и заявки” відкрита	Пройдено
Результати тесту
Тестувальник: Іванов І.І		Дата прогона теста: День/місяць/рік	Результат теста (P/F/B): пройдено (P)
Примітка:

 

Додаток Г

Шаблони і приклади звіту про помилки/дефекти (Bug Report)

 

Г.1 Шаблон звіту про помилку/дефект (Bug Report)

 

Шапка
Короткий опис (Summary)	Короткий опис проблеми, що явно вказує на причину і тип помилкової ситуації.
Проект (Project)	Назва проекту, що тестується
Компонент додатка (Component)	Назва частини або функції продукту, що тестується
Номер версії (Version)	Версія на якій була знайдена помилка
Серйозність* (Severity)	Найбільш поширена п’ятирівнева система градації серйозності дефекту: S1 Що Блокує (Blocker) S2 Критичний (Critical) S3 Значний (Major) S4 Незначний (Minor) S5 Тривіальний (Trivial)
Пріоритет (Priority)**	Пріоритет дефекту: P1 Високий (High) P2 Середній (Medium) P3 Низький (Low)
Статус (Status)	Статус бага. Залежить від процедури і життєвого циклу бага, що використовується (bug workflow and life cycle)
Автор (Author)	Автор баг репорту
Призначений на (Assigned To)	Ім'я співробітника, призначеного для рішення проблеми, менеджером проекту.
Оточення
ОС / Сервіс Пак і т.д. / Браузера + версія / ...	Інформація про оточення, на якому був знайдений баг: операційна система, сервіс пак, для WEB тестування - ім'я і версія браузера тощо.
Опис
Кроки відтворення (Steps to Reproduce)	Кроки, по яких можна легко відтворити ситуацію, що призвела до помилки.
Фактичний Результат (Result)	Результат, отриманий після проходження кроків до відтворення
Очікуваний результат (Expected Result)	Очікуваний правильний результат
Доповнення
Прикріплений файл (Attachment)	Файл із логами, скріншот або будь-який інший документ, що може допомогти прояснити причину помилки або вказати на спосіб рішення проблеми

 

Г.2 Приклад створення звіту про помилку/дефект (Bug Report)

 

Короткий опис	Пошук на сайті «Сонник» на головній сторінці, з використанням російських слів працює невірно
Проект	http://www.ameno.ru/
Компонент додатку	Пошук на сайті «Сонник»
Номер версії	0.001
Важливість: S1 Блокуюча (Blocker) S2 Критична (Critical) S3 Значна (Major) S4 Незначна (Minor) S5 Тривіальна (Trivial)	S3 Значна (Major)
Пріоритет: P1 Високий (High) P2 Середній (Medium) P3 Низький (Low)	P1 Високий (High)
Статус	Нова
Автор	П І Б повністю
Призначений на	розробника
Кроки відтворення	1. Відкриваємо головну сторінку сайту: http://www.sonnik.ru/ .Внизу сторінки знаходимо розділ: „СОННИК” (см. копію екрану – виділено жовтою рамкою)   3. Введіть пошукове слово, наприклад „ночь” 4. Натисніть кнопку „Найти”"
Фактичний результат	Запит не пройшов валідацію (див. копію екрана).
Очікуваний результат	Пошук пройшов невдало, опис потрібного сну показано невірно.

 

 

Навчальне видання

 

Методичні вказівки до лабораторних робіт з дисципліни «Тестування програмного забезпечення» для студентів усіх форм навчання напряму 6.050103 – «Програмна інженерія»

 

 

 

 

 

Упорядники:                                   І.А. Ревенчук

                                                        Т.С. Ткачова

 

 

 

 

 

 

 

 

 

Відповідальний  випусковий    З.В. Дудар

 

Редактор      О.С. Бєлянінова

Комп’ютерна верстка    Г.М.Голоднікова

 

 

 

 

 

План 2011, поз.10

Підп. до друку 31.18.10    Формат 60х 84 1\16             Спосіб друку – ризографія

Умов. друк. арк. 2,6         Облік. вид. арк. 2,3              Тираж 25 прим.

Зам. №1-10                          Ціна договірна.  

 

 

Віддруковано в навчально-науковому

видавничо-поліграфічному центрі ХНУРЕ

61166 Харків, просп. Леніна, 14