Міністерство освіти і науки, молоді та спорту України
Національний університет «Львівська політехніка»
Кафедра АСУ
Лабораторна робота №4
з дисципліни: «Управління ІТ-проектами»
на тему: «Тестування програмного забезпечення»
Мета роботи: Навчитися створювати тест-плани, тест-кейси, фази тестувать програмного забезпечення і стратегію тестувань; набути навики створювати і запускати модульні тести; навчитись оцінювати тестове покриття; практично оволодіти використанням mock –об’єктів.
1. ТЕОРЕТИЧНІ ВІДОМОСТІ
1.1. Зміст тест-плану
Таблиця 1. Базовий приклад змісту тест плану
1. Introduction
1.1 References
1.2 Test Plan Objective
1.3 Test Structure
1.3.1 In Scope
1.3.2 Out of Scope
1.4 Responsibilities
1.5 Definitions
1.5.1 Bugs
1.5.2 Enhancement
1.5.3 Acronyms
2. Test Approach
2.1 Testing Levels
2.1.1 Unit Testing
2.1.3 Integration Testing
2.1.4 System Testing
2.1.5 User Acceptance Testing
2.2 Testing Types
2.2.1 GUI Testing
2.2.2 Functional Testing
2.2.3 Load Testing
2.2.4 Stress Testing
2.2.4 Configuration testing
2.2.5 Installation Testing
2.2.6 Regression Testing
2.2.7 UI Automation and UI Automation components
3. Release Tests
4. Test Deliverables
4.1 Test Case Document
4.2 Test Execution Report
4.3 Bug Reporting
5. Resource & Environment Needs
5.1 Test Environment for Pre Beta Release
5.2 Test Environment for Beta Release
1.2. Приклад тест-кейсів
Створення документу тест-кейсів розпочинається з нумерації всіх модулів (сторінок, діалогів, закладки…) аплікації:
Таблиця 2. Перелік модулів аплікаці
A
Display PopUp
B
Setup Wizard
…
…
I
Language page
…
…
Z
Configuration page
Після чого виписуються всі кейси (cases):
Таблиця 3. Приклад документу тест-кейсів
Module No.
Module name/
screen
Test Case ID
Test Precondition
Test Condition
Expected Result
Pass/Fail
Remarks
A
Program start
A1
The application should be installed on your computer
Invoke application icon
The Boot Screen is displayed
Pass
A2
Power failures in an electricity network
Click on 'Dismiss' button
On Power Loss Recovery Screen: 'The system has recovered from a power loss. Message will be displayed
Pass
A3
The system is working properly
If it is not Power Loss
“Settings” Tab will be displayed
Fail
…
…
...
…
…
…
…
…
I
Settings: Setup Wizard
I1
Load language
Please select your preferred language by clicking on RadioButton
English language will be selected
Pass
…
…
…
…
…
…
…
…
1.3. Зміст документу “Test Report”
Таблиця 4. Базовий приклад змісту документу
1. Summary of Testing
2. Equipment Used
2.1 Hardware
2.2 Software/Firmware Versions
3. Test Results
4. Deviations to Protocol
5. Objective Evidence
1.4. Модульне тестування (юніт-тестування)
Модульне тестування, або юніт-тестування (англ. unit testing) – процес в програмуванні, що дозволяє перевірити на коректність окремі модулі вихідного коду програми.
Ідея полягає в тому, щоб писати тести для кожної нетривіальної функції або методу. Це дозволяє достатньо швидко перевірити чи не призвела чергова зміна коду до регресії, тобто до появлення помилок у відтестованих місцях програми, а також полегшує виявлення та усунення таких помилок.
Для більшості мов програмування високого рівня існують інструменти і бібліотеки модульного тестування. Деякі з них:
Для Java : JUnit, JavaTESK, Spock;
Для С: CUnit, cfix, Unity;
Для Objective-C: OCUnit;
Для .NET: Nunit, XUnit, MbUnit;
Для PHP: SimpleTest, PHPUnit;
Для ActionScript: FlexUnit, AsUnit;
Для JavaScript: Chai, Sinon.JS, JsUnit, QUnit.
План Тестування (Test Plan) — це документ, що описує весь обсяг робіт з тестування, починаючи з опису об'єкта, стратегії, розкладу, критеріїв початку і закінчення тестування, до необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення.
Тест дизайн (Test Design) — це етап процесу тестування програмного забезпечення, на якому проектуються і створюються тестові випадки (тест кейси), відповідно до визначених раніше критеріями якості та цілями тестування.
Тестовий випадок (Test Case) — це документ, що описує сукупність кроків, конкретних умов і параметрів, необхідних для перевірки реалізації тестованої функції або її частини.
Баг/Дефект Репорт (Bug Report) — це документ, що описує ситуацію або послідовність дій (Steps), що призвела до некоректної роботи об'єкта тестування (Misbehavior), із зазначенням причин та очікуваного результату (Expected Result).
Тестове Покриття (Test Coverage) — це одна з метрик оцінки якості тестування, що представляє із себе щільність покриття тестами вимог або коду, що виконується.
Деталізація Тест Кейсів (Test Case Specification) — це рівень деталізації опису тестових кроків і необхідного результату, при якому забезпечується розумне співвідношення часу проходження до тестового покриття.
Час Проходження Тест Кейса (Test Case Pass Time) — це час від початку проходження кроків тест кейса до отримання результату тесту.
Виконання роботи
Bug Reports
Summary
Відсутність перевірки валідації емейла
Bug ID
1.001
Built Number
Ver.1.001
Severity
C3, Minor
Priority
1
Assigned to
Igor Stebliy
Reported By
Maria Zhuk
Reported On
05.03.2015
Description
Відбувається реєстрація користувача з невалідним емейлом
Steps To Reproduce
Натискаєм кнопку вхід
«Реєстрація»
В полі email вводимо невалідний емейл FFF&<.@gmal...com
Expected result
Реєстрація не відбувається, поле емейл виділяється червоним, виводиться повідомлення про помилку
Summary
При перевірці коректності роботи на Iphone (Safari)
При реєстрації користувача, поля для заповнення необхідних даних завеликі у розмірі
Bug ID
1.002
Built Number
Ver.1.001
Severity
С4, cosmetic
Priority
3
Assigned to
Igor Stebliy
Reported By
Maria Zhuk
Reported On
05.03.2015
Description
Відкриття сторінки з полями необхідними для реєстрації – проте поля завеликі у розмірі
Steps To Reproduce
Натискаєм кнопку вхід
«Реєстрація»
Expected result
Відкриття сторінки з полями необхідними для реєстрації
Atachment
Summary
Не працює функція Forgot Password
Bug ID
1.003
Built Number
Ver.1.001
Severity
С2, major
Priority
1
Assigned to
Igor Stebliy
Reported By
Maria Zhuk
Reported On
05.03.2015
Description
При вході в систему та натисканні кнопки «Forgot Password» , виводиться поле для введення емейлу, і після введення емейлу та дані про аккаунт та зміни паролю не приходять на вказаний емайл
Steps To Reproduce
Заповнюємо поля входу в систему, не заповнюючи поле Password
Натискаємо кнопку «Forgot Password»
В поле «Email» вводимо діючий емейл
Expected result
Дані про аккаунт і зміну паролю приходять на вказаний емейл
Summary
Збій при здійсненні оплати послуги за допомогою MastrCard
Bug ID
1.004
Built Number
Ver.1.001
Severity
С2, major
Priority
1
Assigned to
Igor Stebliy
Reported By
Maria Zhuk
Reported On
15.03.2015
Description
При спробі олатити постугу за допомогою MastrCard, система зависає і не дає результату
Steps To Reproduce
Ввійти в систему
Вибрати і замовити послугу
Заповнити поля для замовлення
Вибрати спосіб оплати MastrCard
Expected result
Система успішно здійснює оплату послуги
Summary
При додаванні новини чи інформації на сайт зображення не відображається
Bug ID
1.005
Built Number
Ver.1.001
Severity
С4
Priority
1
Assigned to
Igor Stebliy
Reported By
Maria Zhuk
Reported On
05.03.2015
Description
При додаванні новини на головну сторінку сайту, зображення приріпленні до новини не відображаються на сайті
Steps To Reproduce
Увійти в систему (адміністратор)
Натиснути «додати інформацію»
Заповнити всі поля і додати зображення
Натиснути «оновити»
Expected result
Додавши новину зображення відображаються на сайті
Summary
Збій при додаванні файлу до питання
Bug ID
1.003
Built Number
Ver.1.006
Severity
С2, major
Priority
1
Assigned to
Igor Stebliy
Reported By
Maria Zhuk
Reported On
05.03.2015
Description
При спробі додати файл до питання – не працює кнопка додати
Steps To Reproduce
Увійти в систему
В полі для питання ввести питання та натиснути кнопку «прикіпити»
Вибрати файл .png/.jpg/.jpeg/.zip/.txt/.doc
Натиснути кнопку «додати»
Expected result
Файл додається до питання і питання надсилається адміну
Summary
При перевірці сайту на дотримання веб-стандартів за допомогою http://validator.w3.org. Виявлено 9 помилок на кожній сторінці
Bug ID
1.003
Built Number
Ver.1.007
Severity
С4
Priority
4
Assigned to
Igor Stebliy
Reported By
Maria Zhuk
Reported On
5.03.2015
Description
Виявлено на відповідність веб-стандартам
Steps To Reproduce
Перехомо за ссилкою http://validator.w3.org.
Вводимо URL кожної сторік
Отримуємо результат
Atachment
Висновок
Виконуючи дану лабораторну роботу, я навчилась створювати тест-плани, тест-кейси, фази тестувань програмного забезпечення і стратегію тестувань; набула навиків створювати і запускати модульні тести; навчилась оцінювати тестове покриття; практично оволоділа використанням mock-об’єктів.