Professional Documents
Culture Documents
Курсова Робота Андрій Чирвон ТЗ-01
Курсова Робота Андрій Чирвон ТЗ-01
Курсова робота
Тестування програмного забезпечення
Version 0.0.3
Revision History
Date Version Description Author
11/03/2018 0.0.1 Створено шаблон Oleksii Ostapov
14/04/2019 0.0.2 Шаблон оновлено для нового Oleksii Ostapov
завдання
17/06/2022 0.0.3 Додання інформації до роботи Андрій Чирвон
Table of Contents
1. Вступ
1.1. Мета
1.2. Scope
1.3. Out of scope
1.4. Definitions, Acronyms, and Abbreviations
1.5. References
2. Загальний опис робіт
3. Частина 1 - Аналіз та планування
4. Частина 2 - Розробка тестів
1. Вступ
Дана курсова робота створена для перевірки знань та умінь студентів НТУУ КПІ з тестування
програмного забезпечення
Мета
Мета документу:
● Навчитись писати змістовні та корисні формальні документи
● Бути результатом самостійної роботи з тестування ПЗ
Scope
● Аналіз вимог
● Планування тестування
● Розробка тест кейсів
● Тестування ПЗ
● Написання багів
● Написання тестового звіту
References
# Name of the document Versio Link
n
[1] Завдання на курсову роботу 1.0 https://docs.google.com/
document/d/
1DWjICGdmOQesdSA8bqKV7lhXC3d
u9DFtUDMsjQXQND4
2 Circus Ticket App 2.0.4 https://docs.google.com/
Software Requirements Specification document/d/
1LLUCFyLZa23rUMO34bZA3VxNPTa
o-dpFhS_Q8quJWWk/edit
3. Атрибути якості
Атрибут Характеристика Приклад
-Користувач має змогу Користувач реєструє акаунт з
зареєструвати акаунт лоігном «bibika» та паролем
«bbk25»
Сумісність
Користувач може замовити
Сайт має коректно
квитки і без доступу до
відображатись і на смартфонах
комп'ютера
Ремонтопридатність
Якщо у користувача сталась
Сайт має можливість залишити
помилка він може описати її в
відгук
службу підтримки і
несправність буде усунуто
Висновок:
Якість це комплексна характеристика яка залежить від багатьох параметрів та показників.
Ми можемо визначити які з характеристик об’єкта зроблять його більш привабливішим
для користувача або замовника, або за допомогою яких він буде кращим ніж інші
продукти на ринку. Це можуть бути або особливі фічі, те чого бракує іншим програмам, те
що зробить продукт надійнішим, зручнішим, функціональнішим тощо. Якість це
відповідність продукта визначеним вимогам і дотримання цих вимог та задоволення всих
атрибутів якості зробить продукр якісним і кращим на ринку.
Пошук
1. Після входу користувачу відкривається сторінка пошуку яка є головною сторінкою.
2. Для пошуку квитків має бути реалізована функція пошуку по:
-діапазону цін за допомогою повзунка
-Ключовим словам в описі до вистави
-Даті на яку заплановано виставу.
3. Має підтримуватись функція покупки декількох квитків, максимальна кількість – 10 квитків
за одну покупку.
4. Користувач повинен мати можливість замовити квиток для домашньої тваринки. При
цьому не має бути конфлікту з списком тварин у виставі.
5. Функція повернення квитків не підтримується.
Програма лояльності
1. На сайті має бути реалізована система знижок
2. За вказання електронної пошти користувачу надається знижка 3%.
3. За введення промокоду на сторінці покупки квитка користувачу надається знижка 5%.
4. Знижка за введення пошти та за промокод не додаються. Перевага надається знижці за
промокодом.
5. Має бути реалізований лічильник покупок. На кожну десяту покупку користувач отримує
знижку 1% яка додається до одної з вищезгаданих.
Інші вказівки
1. Сайт повинен мати інтерфейс на англійській мові.
2. Сайт не повинен мати вікових обмежень.
3. На сайті не має бути системи відгуків.
Висновок:
Вимоги є необхідною складовою для реалізації і розробки продукту. Поки немає чітких вимог
неможливо зробити якісний продукт який не матиме внутрішніх помилок і в якому всі складові
будуть продумані. Потрібно розуміти для яких цілей робиться продукт, хто його
використовуватиме і з якою метою. Відповідно до цього потрібно зазначити всі критерії
відповідності продукту та встановити. Самі вимоги ж це набір властивостей, критеріїів та
характеристик які мають бути надані продукту щоб він працював коректно і був максимально
функціональним та зручним. Під час їх написання можна зрозуміти яким буде продукт та які
властивості в ньому будуть, чим він буде виділятись серед інших і т.п. Технічну документацію
згідно стандартів треба писати по тій причині, що це систематизована схема яка вибудовує скелет
майбутнього проекту.
5.Тест-кейси
Таблиця рішень для Тест Тест Тест Тест Тест Тест Тест Тест
знижок 1 2 3 4 5 6 7 8
Користувач ввів
електронну пошту (3%) + + + + - - - -
For public use ©Infopulse, 2019 Page 22
Тестування Програмного Забезпечення Version: 0.0.3
Висновок:
На мою думку продукт недороблений і його випускати не можна. Є велика кількість критчиних
багів, проблем з основними функціями і помилок які не відповідають вимогам. Реліз в такому
стані однозначно не повинен відбуватися, продукт або треба переробляти, або виправляти по
максимуму всі помилки.
6.Додаток
7.Висновок
Отже, після виконання курсової роботи я може зробити висновки щодо тестування таких
проектів. Оснвоні труднощі були пов’язані з доступом до сайту, оскільки тестуванням
займались дві групи, тестувальники експериментували з квитками, тому часто їх не можна
було знайти. Також певним чином заважало незнання коду та принципу роботи сайту, яка
структура всих даних і як це працює.
Системний підхід до тестування все таки дає свої плюси, адже за допомогою «чуйки»
неможливо виявити баги та помилки в тих місцях де їх просто не очікуєш. За допомогою
передчуття тестувальник може просто зрозуміти слабкі місця програми або об’єкту і вже
перевіряти саме їх, але це не дасть змоги виявити якісь системні похибки, або просто
накладання , як от використання однакових змінних на різних параметрах, або
неправильно прописаний клас. Від досвіду тестувальника також залежить багато чого, бо
якщо тестувальник стикався з подібними завданнями то він може знати їх слабкі місця і
що в першу чергу потрібно тестувати. НА мою думкеу потрібно використовувати ці три
підходи одночасно, бо без системного класифікування помилок дуже важко підтримувати
порядок у всій структурі.
Закінчувати тестування і віддавати цей продукт замовнику можна хіба у в випадку
виправлення всих основних функцій та їх коректної роботи. До цього проект не можна
випускати, бо від нього буде більше проблем ніж користі.
Щодо розробки мобільного додатку то я можу сказати лише те що потрібно довести до
ладу веб-версію. Коли в команди розробників вже буде розуміння що є проблемним в
цьому проекті тоді вони зможуть більш якісно та оперативно виконати роботу. Випустити
ще один продукт з такими ж самими помилками це , я вважаю, просто зайва трата часу та
ресурсів. Але якщо діло дійшло б до тестування додатка то я б в першу чергу перевірив
всі елементи інтерфейсу, їхню функціональність та чи не спричиняє їх використання
помилок в роботі. Другим етапом було б тестування функцій в межах одної сторінки та
перевірка їх функціональностей. Третім етапом я б перевіряв взаємозвязок всих сторінок,
баз даних та чи реалізовані в проекті задумані по ходу роботи «фічі» та особливості
програми. Тільки після проходження цього тестування можна було б видавати продукт
замовнику.
В цілому, під час виконання роботи я на практиці зрозумів суть такого підходу до
тестування