Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Розробка програмного продукту.
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
КН
Кафедра:
Кафедра автоматизованих систем управління
Інформація про роботу
Рік:
2011
Тип роботи:
Лабораторна робота
Предмет:
Розробка програмного продукту
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти України
Національний університет «Львівська політехніка»
Кафедра автоматизованих систем управління
/
Звіт
до лабораторної роботи №5
на тему:
Розробка програмного продукту.
Етап тестування
Львів 2011
Лабораторна робота №5
Тема: Розробка програмного продукту. Етап тестування
Мета: Ознайомлення з основними задачами, які необхідно розв’язати під час виконання етапу тестування
Теоретичні відомості:
Мета тестування полягає в тому, щоб виявити і виправити помилки. Цей процес допомагає розпізнавати алгоритмічні помилки і помилкове виконання системою своїх функцій. Під алгоритмічною помилкою ми розуміємо конструкцію, яка розроблена неправильно. Одна помилка може викликати безліч неправильних виконань програми. Також помилки можуть бути наслідком інших помилок, це потрібно враховувати при їх аналізі.
Тестування це:
Сертифікація - наприклад, перевірка відповідності системи вимогам клієнта;
Перевірка - наприклад, перевірка відповідності системи вимогам з етапу формування вимог.
Тести призначені для виявлення, і подальшого усунення, максимальної кількості помилок, розрахунку статистики помилок, а також - оцінки надійності всієї системи.
Тести поділяються на:
Динамічні - які порівнюють результати роботи програми з правильними результатами.
Статичні - засновані на аналізі коду.
Існують наступні фази тестування:
Тестування модулів виконується після їх реалізації і об’єднання.
Тестування системи виконується після її інтеграції. Воно охоплює тестування системи і всіх її модулів.
Приймальне випробування. Системи, які розроблені для клієнта, доставляються йому для перевірки. Такі тести називають альфа-тестами. Системи, які розроблені для ринку, доставляються деяким представницьким користувачам (бета-тестувальникам) і перевіряються ними. Такі тести називають бета-тестами.
Основні чинники успіху етапу тестування: визначення спеціальних вимог надійності частин системи і мотивація відповідальних за тестування людей. Оскільки тестуючий персонал найчастіше представляє нижчий рівень в ієрархії службовців, рекомендується призначити для тестування людей, які займаються програмуванням і проектуванням даної системи.
Основні результати етапу тестування:
Покращені код, проект, модель і, можливо, специфікація вимог.
Звіт про тести.
Оцінка надійності системи.
В процесі тестування розрізняють два поняття:
Перевірка – тестування відповідності ПЗ вимогам, описаним на етапі формулювання вимог.
Затвердження – оцінка того, чи є система або її компоненти відповідної якості. Затвердження проводиться під час або після розробки.
Види тестів
До тестування відносяться два поняття: помилка і невдача.
Помилка - це неправильна побудова програми, яка може призвести до помилок в ході її виконання.
Невдача - неправильне функціонування системи під час її роботи.
Помилка може призвести до багатьох невдач. Одна і та ж невдача може відбуватися з різних причин.
Отже: тестування - це процес визначення і усунення помилок, заснований на неправильних виконаннях та інших тестах.
Тести ПЗ можуть класифікуватися з точки зору головної мети або техніки тестування.
Класифікація з точки зору техніки тестування.
Існують наступні тести:
статичні тести, засновані тільки на аналізі коду. Вони здійснюються програмістами.
динамічні тести, які складаються з виконання різних частин коду і порівняння їх результатів з правильними.
Процес тестування
Різні частини ПЗ тестуються на різних етапах розробки. Типові елементи зображені в таблиці 1.1.
Тестований елемент
Опис тестування
Продуктивність
Тестується продуктивність програми і її функцій.
Інтерфейс
Тестуються інтерфейси на відповідність вимогам.
Властивості організації
Тестується: логіка, організація, зручність використання, складність вхідних інструкцій, вивід на екран, якість повідомлень, якість повідомлень про помилки, рівень якості допоміжних файлів.
Використання ресурсів
Тестуються використання одиниць пам'яті: оперативна пам'ять, місце, яке програма використовує на жорсткому диску.
Безпека
Тестується гнучкість, конфіденційність, цілісності даних, доступності. Тестуються паролі, доступ до файлів, захищеність від атак ззовні.
Переносимість
Тестується можливість роботи у різних середовищах, з різними бібліотеками, графічними режимами, на різних версіях Windows та Unix.
Надійність
Вимірюється середній час між помилками.
Підтримування
Вимірюється середній час відновлення програми після помилки, тобто проміжок часу, починаючи з виникнення помилки і закінчуючи відновленням робочого стану програми.
Безпечність ПЗ
Оптимізація наслідків збою, наприклад, втрати електроенергії.
Можливість модифікації
Аналіз можливого розширення ПЗ.
Навантаження на ПЗ
Тестується робота програми в екстремальних умовах: з максимальною кількістю користувачів, великими файлами, скриптами, базами даних. Тривалість тестування не є важливим. Найважливіше - можливість програми працювати в екстремальних умовах.
Масштабованість програми
Відповідність вимогам (серед інших - вимогам часу) зі збільшенням навантаження.
Повнота вимог
Тестуються формулювання вимог
Прийнятність програми
Тестування ступеню задоволення кінцевого користувача
Якість документації
Тестування якості документації.
Таблиця 1.1. Типові елементи ПЗ, які тестуються.
Виконання роботи:
Етап тестування
На цьому етапі було проведено тестування проекту «Прокат спорядження» згідно плану розробленого на етапі реалізації.
Було розглянуто основні види тестувань і з них обрано найоптимальніші для даної системи.
Статистичне тестування було опущено оскільки даний проект не передбачає складних операцій обробки даних, в яких можуть виникати помилки.
Метод прозорої скриньки був обраний, оскільки він дозволяє визначити джерело помилки безпосередньо в програмному коді.
Автоматизоване тестування як підвид тестування методом прозорої скриньки було відкинуто, оскільки таке тестування потребує додаткових витрат на написання тестуючого коду, що є недоцільним у випадку невеликих проектів, як наш.
Метод чорної скриньки також був обраний, оскільки він є базовим та простим, і не вимагає заглиблення у принципи функціонування системи.
Статичні тести проводились програмістами в процесі розробки системи. Такі тести базуються на аналізі коду, що є ефективним у випадку невеликих за об’ємом коду систем. Також такі тести є економічно вигідними оскільки виконуються безпосередньо програмістами без участі тестерів.
Метод сіяння помилок не використовувався для тестування даного проекту, оскільки даний проекти не є великим і має добре виражену просту структуру.
1. Спочатку тестувалися класи модулів: AdminModule, ExcModule. Для тестування цих класів використовувались такі методи тестування, як метод чорної скриньки та метод прозорої скриньки. Ті класи у яких було виявлено несправності при тестуванні методом чорної скриньки тестувалися методом прозорої скриньки для визначення джерела помилки.
Тестування методом чорної скриньки
Модуль AdminModule:
TUsers – клас що містить методи для роботи з користувацькими записами. Даний клас містить такі методи: LogIn, AddUser, DelUser, GetUsers, BlockUser, EditUser.
Процес тестування:
LogIn - метод для авторизації користувача.
Було проведено 3 тести для перевірки коректності роботи даного методу
Тест №1. Запускається програма, у поле «логін» вводимо («param») та в поле «пароль»,( «pampam»), які не відповідають жодному користувацькому запису в БД (Рис. 1):
/
Рис. 1
Після натиснення кнопки Вхід (Рис. 1) програма видає повідомлення про некоректні дані логування (Рис. 2):
/
Рис. 2
Тест №2. Запускається програма, у поле «логін» вводимо («direktor») та в поле «пароль», («mira»), які відповідають користувацькому запису директора (Рис. 3):
/
Рис. 3
Після натиснення кнопки Вхід (Рис. 3) відбувається вхід у систему в режимі користувача (Рис. 4):
/
Рис. 4
Тест №3. Запускається програма, у поле «логін» вводимо («rollerman») та в поле «пароль», («ololo»), які відповідають користувацькому запису користувача (Рис. 5):
/
Рис. 5
Після натиснення кнопки Вхід (Рис. 5) відбувається вхід у систему в режимі Клієнта (Рис. 6):
/
Рис. 6
Висновок: Метод працює коректно.
AddUser - метод для додавання нового користувача. Цей метод використовується при роботі з інтерфейсом адміністратора.
Було проведено тест для перевірки коректності роботи даного методу:
Тест. Спочатку потрібно натиснути кнопку «+» після цього вже вводити дані про нового користувача: Login: kitty; Parol: cat15; Prizvyshche: Vojtov; Imja: Anton; Po-batkovi: Volodumurovuch; Nomer_telefony: 064224950 (Рис. 7):
/
Рис. 7
Після введення даних натискаємо кнопку «Ок», але програма видасть помилку про те що зміни не збережені (Рис. 8):
/
Рис. 8
Висновок: Потребує тестування методом прозорої скриньки.
DelUser – метод для видалення користувача. Цей метод використовується при роботі з інтерфейсом адміністратора.
Було проведено тест для перевірки коректності роботи даного методу:
Тест. В списку користувацьких записів вибираємо запис який необхідно видалити і натискаємо кнопку «-» (Рис. 9):
/
Рис. 9
Після натискання кнопки «-» виводиться діалогове вікно (Рис. 10), натискаємо кнопку «ОК»:
/
Рис. 10
Після всіх операція програма видасть помилку про неможливість видалення даного запису (Рис. 11):
/
Рис. 11
Висновок: Потребує тестування методом прозорої скриньки.
EditUser - метод для редагування інформації про користувача. Метод використовується при роботі з інтерфейсом адміністратора.
Було проведено тест для перевірки коректності роботи даного методу:
Тест. В списку користувацьких записів вибираємо запис який необхідно змінити і натискаємо кнопку «▲» (Рис. 12):
/
Рис. 12
У записі «Moderator» змінюємо поле на нове «Muronovuch» і зберігаємо зміни натискаючи на кнопку «OK», але програма видає повідомлення про помилку (Рис. 13):
/
Рис. 13
Висновок: Потребує тестування методом прозорої скриньки.
Interedit – метод редагування інтерфейсу. Метод використовується при роботі з інтерфейсом адміністратора.
Було проведено тест для перевірки коректності роботи даного методу:
Тест. Спочатку потрібно вибрати члена персоналу запис якого потрібно заблокувати, потім натискаємо на одну з чоритрьох кнопок, наприклад на кнопку «Інтерфейс Директора» (Рис. 14):
/
Рис. 14
/
Рис. 16
Висновок: Потребує тестування методом прозорої скриньки.
GetUsers - метод для отримання списку користувачів. Метод використовується при роботі з двома інтерфейсами: працівника і адміністратора.
Вище описані тести продемонстрували коректну роботу цього методу оскільки на таблиці користувацьких записів були відтворені всі записи бази даних.
Висновок: Метод працює коректно.
TSystems – клас для редагування та перегляду системних файлів та зміни БД. Даний клас містить такі методи: AddSysF, DeleteSysF, ChangeSysF, GetSys, AddMenuItems, DelMenuItems, EditMenuItems, AddInstrument, DelInstrument, EditInstrument, EditNews.
Процес тестування:
Метод AddSysF. Пройшов тестування. Додавання файлу успішно відбулося.
Висновок: метод працює коректно.
Метод DeleteSysF. Пройшов тестування. Видалення файлу успішно відбулося.
Висновок: метод працює коректно.
Метод ChangeSysF. Пройшов тестування. Редагування файлу успішно відбулося.
Висновок: метод працює коректно.
Метод AddSysF. Пройшов тестування. Додавання файлу успішно відбулося.
Висновок: метод працює коректно.
Метод GetSys. Пройшов тестування. Виведення списку системних файлів успішно відбулося.
Висновок: метод працює коректно.
Метод EditMenuItems. Пройшов тестування. Редагування інформації у меню успішно відбулося.
Висновок: метод працює коректно.
Метод AddInstryment. Пройшов тестування. Додавання інструмента у БД успішно відбулося.
Висновок: метод працює коректно.
Метод DelInstryment. Пройшов тестування. Видалення інструмента із БД успішно відбулося.
Висновок: метод працює коректно.
Метод EditInstryment. Пройшов тестування. Редагування інформації про інструмент у БД успішно відбулося.
Висновок: метод працює коректно.
Метод EditNews. Пройшов тестування. Редагування інформації у БД успішно відбулося.
Висновок: метод працює коректно.
Всі методи пройшли тестування та результат був позитивним, тобто всі методи працюють коректно.
Модуль ExcModule:
TPrice – клас який містить методи, що використовуються при оформленні замовлення. Даний клас містить такі методи: AddItem, DeleteItem, ShowMenu.
Процес тестування:
AddItem – метод для додавання продукту в кошик замовлення. Метод призначений для роботи з інтерфейсами інтернет-користувача та продавця.
Було проведено тест для перевірки коректності роботи даного методу:
Тест. Запускаємо програму авторизуємось як інтернет користувач та робимо замовлення, вибираємо потрібний пункт меню, вибираємо кількість людей і натискаемо кнопку «Замовити» (Рис. 17):
/
Рис. 17
Після цього програма видає нам підтвердження про покупку та переносить його у кошик (Рис. 18):
/
Рис. 18
Висновок: Метод працює коректно.
DeleteItem – метод для видалення замовлення з кошика замовлень. Метод призначений для роботи з інтерфейсами інтернет-користувача та продавця.
Пройшов тестування. Видалення замовлення з кошика успішно відбулося.
Висновок: метод працює коректно.
ShowExc – метод для відображення списку екскурсій. Метод призначений для роботи з інтерфейсами інтернет-користувача та продавця.
Вище описані тести продемонстрували коректну роботу цього методу оскільки на таблиці меню були відтворені всі записи бази даних.
Висновок: Метод працює коректно.
Ttech – клас який містить методи, що використовуються при зв’язку з оператором. Даний клас містить такі методи: Ticketshow, Onlinecon, Enterticket.
Процес тестування:
TicketShow – Метод для відображення запитів від користувачів. Метод призначений для роботи з інтерфейсами інтернет-користувача та продавця.
Було проведено тест для перевірки коректності роботи даного методу:
Тест. Запускаємо програму та авторизуємось як оператор заходимо в закладку ‘Термінал тех.-підтримки’ нам відображає останню по даті заявку. Ми натискаємо «Попередня\Наступна» щоб переходити від одної заявки до наступної(Рис. 19):
/
Рис. 19
Після цих дій програма видає помилку (Рис. 20):
/
Рис. 20
Висновок: Потребує тестування методом прозорої скриньки.
OnlineСon - метод для онлайн підключення до клієнта. Метод призначений для роботи з інтерфейсами інтернет-користувача та продавця.
Оскільки в методі TicketShow нам видавало помилку неможливості з’єднатися з сервером то нам немає сенсу тестувати протестувати метод OnlineСon.
Висновок: Потребує тестування методом прозорої скриньки.
Enterticket – метод для Відправки відповіді на емейл клієнта. Метод призначений для роботи з інтерфейсами інтернет-користувача та продавця.
Оскільки в методі TicketShow нам видавало помилку неможливості з’єднатися з сервером то нам немає сенсу тестувати протестувати метод Enterticket.
Висновок: Потребує тестування методом прозорої скриньки.
DataModule. Модуль призначений для організації зв’язку з базою даних, включає в себе клас TDataModule.
TDataModule – клас який забезпечує звязок системи з БД (включє в себе набір стандартних компонент TADOConnection, TdataSource та TADOStoredProc).
Висновок: оскільки система має доступ до усіх таблиць БД, то даний клас працює коректно.
Тестування методом прозорої скриньки
Ті методи класів, у яких були виявлені помилки при тестуванні способом чорної скриньки були протестовані методом прозорої з метою виявлення джерела помилки.
Модуль AdminModule:
TUsers:
AddUser – Даний метод працював некоректно, тому розглянемо його виконання детальніше, розглянувши код програми (Рис. 21).
Як бачимо помилка знаходиться в області «Data Sourse» в інспекторі об’єктів, параметр DataSourse = DataSourse6, що не відповідає зображеній таблиці (тобто кнопки навігатора підключені до іншої таблиці). Щоб виправити цю помилку потрібно змінити параметр DataSourse = DataSourse5. Після внесених змін метод AddUser запрацював коректно.
DelUser – Даний метод працював некоректно, тому розглянемо його виконання детальніше, розглянувши код програми (Рис. 22).
/
Рис. 21
Як бачимо помилка знаходиться в області «Data Sourse» в інспекторі об’єктів, параметр DataSourse = Ds2, що не відповідає зображеній таблиці (тобто кнопки навігатора підключені до іншої таблиці). Щоб виправити цю помилку потрібно змінити параметр DataSourse = DataSourse7. Після внесених змін метод AddUser запрацював коректно.
EditUser – Даний метод працював некоректно, це було пов’язано з помилками вказаними вище. Некоректність виконання методу EditUser була напряму пов’язана з помилками які були і методах: AddUser, DelUser.
Після редагування та виправлення помилок 2-х попередніх методів метод EditUser працює коректно.
Interedit - Даний метод працював некоректно, тому розглянемо його виконання детальніше, розглянувши код програми (Рис. 22):
/
Рис. 22
В методі не було приєднання до вікна редагування. Тому ми прописуємо
/
Рис. 23
Таку саму операцію ми повторили з рештою кнопок, приєднавши їх до екрану зміни інтерфейсів. Після повторного тестування метод Interedit працює коректно.
Ttech
TicketShow - Даний метод працював некоректно, тому розглянемо його виконання детальніше, розглянувши код програми (Рис. 24):
/
Рис. 24
Так як початково таблиці створювались тестові, то метод хотів отримати те чого немає. Шляхом заміни компонент Datasource та таблиць на прив’язані до інтернет сервера, проблему було усунуто.
OnlineСon, Enterticket – помилки були зв’язані з попередньою безпосередньо і тому відповідно була автоматично усунуті.
2. Друга частина - це тестування інтерфейсу, а саме його методів перевірки внесених даних користувачами системи. Основні перевірки валідності введених даних виконуются на верхньому рівні (рівні інтерфейсу), тому тестувався модуль інтерфейсу MainModule.
Для тестування модуля MainModule використовувався метод чорної скриньки. Процес тестування проходив так: у поля різного формату вводилися неправильні дані (наприклад в числове поле вводились букви), після чого спостерігалась реакція системи.
3. Останній пункт тестування – це перевірка сумісності. На цьому кроці система “СУтПЕМ ЛеоТур” тестувалася на сумісність з різними операційними системами і програмним забезпеченням. В результаті тестування було підтверджено коректну роботу системи на всіх версіях ОС Windows починаючи з Windows XP.
Висновок:
На цій лабораторній роботі я освоїв основні методики етапу тестування. На цьому етапі, я виконав процес тестування для 3 модулів своєї системи. Було виявлено 8 помилок, які були пов’язані з некоректністю виконання функцій та неправильному введенні інформації користувачем.
08.02.2013 17:02-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора