Бакалавърска програма Информатика Бакалавърска теза на тема Web базирана хотелска система за резервации Разработил : Александър Тодоров Факултетен Номер : F26193
Изтегляне 1.56 Mb.
|
- Навигация на страницата:
- Какво е тестването Тестването може да бъде дефинирано като операция върху приложение което контролира неговото качеството. Какво е качество
- Защо тестването е важно
- Теория на Software тестване.
- Изпращане на продукта до дизайнерите да решат как точно ще работи.
- Изпращане на група от програмисти за започване на програмирането
- Тестване от разработчика – Client Side Testing Html тест
- Тестване от независим специалист и мениджър на проекта от страна на разработчика.
- 7.1. Бъдещи подобрения
- 8. Използвана литература и online източници
- Списък на програмните фрагменти
Тестване на приложението Тестването на сайта заема до 30% от времето за работа по проекта. Това е един от най-отговорните етапи на работата. Нашият проект ще мине през три теста:
Всеки етап от тестовете е придружен от описание на списък с грешки и приключва с работата по тяхното отстраняване. Ползите Прилагането на препоръките, получени при тестване за ползваемост ще подобри ползваемостта на сайта ни: информацията става по-намираема, текстовете по-ясни и точни, а взаимодействието на потребителите с продукта по-леко, удобно и приятно за тях. С помощта на тестване за ползваемост може да направим сайта ни:
Какво е тестването? Тестването може да бъде дефинирано като операция върху приложение което контролира неговото качеството. Какво е качество? За тестова цел, качество принципно се дефинира като облага на продукт ( облик ) минус проблемите в него предоставени от клиента. Като цяло, клиента дава последната дума дали ще закупи продукта или ще се откаже, като избере продукт на конкуренцията. Би било твърде късно в продуктовият цикъл да разберем нуждите на клиента и да ги посрещнем, затова тестовата организация трябва да се осигури, че продукта ще изпълни тези изисквания още по време на разработката му. Продукта трябва да работи както клиента е очаквал. Project manager или бизнес анализатора са на страната на програмиста и работят директно с клиента за разбирането на неговите желания, а тестера и тестовата организация са от страната на изискванията на потребителите. Тези две групи се срещат по средата като разбиране на организацията, какво клиента очаква и възможностите продукта да изпълни тези очаквания. Защо тестването е важно? Тестването на software-а от самото начало в производственият му цикъл, ще го направи по-евтин в по-дълъг период от време. Грешките могат да бъдат намерени на време, от по-ранното дискутиране на дадената архитектура до по-късното обаждане на клиента за сигнализирането им. Докато процеса на разработка напредва, това би струвало по-малко за оправянето им. Излиза много по-евтино и лесно да се оправи грешка в изречението на документацията отколкото много програмисти да оправят дадена грешка по време на производството. Какво правят тестерите? Като цяло тестерите или тестерските организации трябва да намират проблеми и да ги предоставят за дискутиране. Някои източници дефинират ролята на тестера да намира проблеми и да ги оправя, но тази дефиниция игнорира много реалната ситуация, че не може се да оправя всяка грешка, която е намерил и това, че не може да намери всички грешки. Някои от тях на се достатъчно важни за да се оправят. Може да прекараш цял живот в тестване на един продукт и да не намериш всички грешки. Готовият софтуер трябва да бъде доставен и той ще бъде доставен с някоя грешка. Тестерите трябва да се сигурни, че тези грешки са трудни за разбиване. Кой са тестерите? Позициите в тестова или QA организация се дефинират под различни имена: software test engineer, test engineer, tester, software tester, software verifier, build manager, build engineer, configuration manager, release manager, QA analyst, QA engineer, software analyst и други. Всяка една от тези позиции има своите специални изисквания като се съобразява със софтуера които произвежда тази компания. Какво е грешка ( Bug )? Грешка е неочаквано действие: софтуерът прави нещо което мислиш, че не е правилно. Това може да бъде от плана на информацията или дума на error message до разваляне на цялата система. Грешка е нещо което потребителя на би харесал или нещо което би попречило на потребителите да достигнат тяхната крайна цел. Теория на Software тестване. Всички проекти има начало и край, и много действия между тях. Софтуерните продукти могат да стартират с очертано дефинирани събития и точки, но по-често те не са. Принципно действията на са разделени и описани в началото на започването на проекта или не са, по същия начин действията са представени под една форма или друга. Цикъл на продукта От къде идва софтуера? Продукта започва като нечия родена идея. Знаете ли, аз от какво се нуждая ..... така започва принципно една идея. Знаеш ли от къде мога да направя малко пари.....Организацията може да вземе много различни действия ( на основата на какво точно ще съдържа даденият проект ), но тези действия се провалят в началото на продуктовият цикъл:
В идеалният програмистки свят, идеите са написани на хартия наречена спецификация на продукта, с детайлно описание на ядрото на компонентите и какво е нужно за тях, всеки един от тях как ще е композиран и техните функции. Програмирането може да изследва кода в началото, за да помогне в спецификацията и да се покаже как ще продължи програмирането. Тестването, Програмирането, Project management, анализа и други четат тази документация намират места където framework не е подобаващо попълнен или липсва някои модул. Веднъж основната архитектура да бъде одобрена, програмирането започва да създава структурата от самото начало, какво точно трябва да има там. Например, ако продукта е онлайн, структурата на базата от данни трябва да бъде описана добре, за взимане на информацията, да се търси в нея и така нататък. Веднъж тази информация да бъде систематизирана, планът трябва да бъде така оформен, така че да се знае какво точно ще бъде началото. Дали хората които ще си създадат account и дали системата ще ги разпознава всеки път като влезнат наново или просто ще си въвеждат техният адрес и информацията когато пазаруват. Този процес от програмиране, ще изчисти някои технически подробности, като ще скицира пълнотата преди да бъде написан кода.
За съжаление този втори преглед е какво обикновено се случва. Принципно след като се каже „ Ти знаеш какво аз ще ползвам ”....значи, някои включва компютъра и започва да програмира прототипа. Този човек в последствие казва на приятел или мениджър, които ще се включи в последствие. Другите се включват и мениджмънта вижда, че проекта е започнал. Тестерът може да бъде включен, както и архитекта също, но ще бъде твърде късно да се прави нещо освен слаба промяна на някои компонент. Крайният резултат на този вид проект обикновено е продукт с няколко архитектурни изгледа, които имат защитен проблем. Затова се налага да бъде написана следваща версия. Тестване от разработчика – Client Side Testing Html тест  
Фигура 23 Илюстрация на връзките на елементите, атрибутите и стойностите в Html кода. Html кода ни трябва да бъде добре оформен и удобен за четене. Тестването на нашият код премина по следният принцип. След като го получихме от дизайнера, му поставихме PHP кодовете в него и го качихме на web сървър, и започнахме да сърфирме из него. По този начин разбрахме как точно сървъра ще го разчете и дали ще се получат някои грешки. След направените действия в нашият Html код не бяха забелязани подобни грешки.
JS тест JavaScript ни трябва да бъде прецизно написан защото е case-sensitive език. Неговите грешки могат да ни донесат голямо главоболие при изпълнението му. Често се случва, ако има js грешки web търсачките да игнорират сайта ни.
За JS менюто се появиха грешки още в самото начало на неговото разчитане. Смесването на JS кода и PHP кода ни докара доста главоболя от рода на: - изписването на js кода със PHP функции, за изписването му се нуждаехме от правилно систематизиране на двата кода, да следят всички препинателни знаци като: „\ , ‘’,\r ” и други. При съставянето на кода бяхме изпуснали няколко подобни знака и понеже js е много капризен този модул не работеше. А за оправяното му ни бяха нужни 16 часа „ търсене ” За JS редактора се появиха грешки при реализирането му в системата, те са: - тук се появиха проблеми при писане на HTML кода в самият редактор, той не го разчиташе правило и в базата от данни не се записваше нужният ни тагов текст, но този проблем не можеше да бъде премахнат, защото щяха да се загубят други негови важни функционалности, затова след споразумение с клиента този бъг беше забравен. Тази функционалност в js редактора се ползва за по-добра защита на приложението от хакерски атаки, като премахва HTML тагове. PHP тест Основната ни функционалност се базира на PHP4 програмиране. Затова е нужно кодът ни да бъде максимално изчистен от грешки за правилното му функциониране и максимално подреден за четене.
Тестването на online транзакцията се осъществява по следният начин. От банката, която ще ползваме ни предоставиха тестов достъп до техният разплащателен сървър, чрез които можехме да тестваме разплащателният модул с стандартни тестови пароли и кредитни карти. Първоначално бяхме замислили да направим транзакцията с отваряне на сокет ( socket ), чрез които да изпращаме изгенерираният xml документ, но тук се появи проблема, че при криптирана връзка ssl сървърът не ни позволи достъп. Затова се наложи да се използва друг програмен метод, като пращане на xml документа, чрез curl библиотеката на PHP, с която отваряхме ssl конекция и пращахме документа до сървъра. Другият проблем, които се появи беше грешка която банковият сървър ни връщаше при изпращането на документа. Проблемът беше синтактичен т.е. не правилното структуриране на xml документа от програмистка страна. След продължително четене и разучаване на банковата документация се стигна и до желаният резултат, върнат xml документ от банковият сървър с таг “ RESULT “ – approved. Тестването на .htaccess файла се реализира по следният начин. За да бъде приложението ни максимално оптимизирано по всички изисквания за SEO оптимизация на url адресите, беше нужно да се преконфигурира този файл. Пренаписването му го направихме чрез PHP код, които ползва функции за писане в файл ( fopen, fread, fwrite). Тази реализация се осъществи, чрез заявки към базата от данни, чрез която взимахме всички заглавия за всяка една новина, статична страница и други като създавахме rewrite рулове с тези имена. Проблемът които се появи тук, е че всеки един препинателен знак трябва да се превърне в ( „ _” ) за да може създадената връзка да бъде разчетена, като линк от клиентския браузър, защото браузера инпретира всеки един препинателен знак като ASKII символ. Като всеки един друг сайт е нужно тестване на „ кошницата ” на сайта. Нейният тест мина в следене на правилно въведени продукти като: дати, хотели, цени, стай и крайна цена. Тестване на премахване на част от поръчката. Добавяне на допълнителни резервации, следене на сесията на поръчката за загуби при сърфиране из други страници. Проблем тук не се появи. Понеже базата от данни на сайта съдържа изключително голям обем от дати, беше нужно да се направи тест само за визуализирането на датите. Като се следеше стриктното редактиране на тази дати в модула за администрация на стайте, и същевременно визуализирането им във външната част на сайта. Проблеми се появяваха като не записани дати, не редактирани дати и не добре сметнати timestamp формати на датите. След като клиента е направил поръчка за даден хотел и си е платил, нашата система му създава потребителски акаунт, които му се изпраща на email-a. Като преди това му се генерира произволно избрана парола. Тук теста мина перфектно без никакви забележки. За генерирането на всички мета и алт тагове използвахме SELECT заявки към базата от данни. При тях нямаше почти никакви проблеми, като изключим че някои страници бяха забравени да им се добави нужният програмен код. Тестване от независим специалист и мениджър на проекта от страна на разработчика. При тестването на нашето приложение този тест беше съчетан с теста на developer-a. Тестване от Възложителя Тестването на клиента е преминало почти през същите етапи като тестването на developer-a, но клиента винаги ще поиска и нещо допълнително, което не е било предварително уговорено в пропосала. Затова след техният тест, се направи виртуална среща между project manager-а и клиента, чрез която беше обсъден целият техен тест и естествено допълненията които те поискаха наречени „ бъгове ”.
Бакалавърската теза е проектирана и реализирана на следните доменни: www.hostels247.com, www.hostels247.net . Създадена е Web базирана хотелска система за резервации, като нейното използване улеснява работата и търсенето на потенциални клиенти във цял свят. Интерфейса е удобен за употреба и максимално опростен за по-бързо възприемане от потребителите. Системата може да се използва от всеки компютър, свързан със сървъра. Тя дава възможността за:
7.1. Бъдещи подобрения Системата може да бъде усъвършенствана с добавяне на следните функционалностти. Може да се направи модул в админската част, чрез които да се прави бекъп на всички регистрирани хотели и клиенти на определен период от време. Това ще даде по – голяма сигурност на сайта. Може да се направи кеширане на страниците, това ще подобри бързината на зареждане на всяка една страница, а същевременно ще се намали трафика на сървъра. Може да се добавят и други езици, това би довело по–голям брой потребители, а също така и до повече поръчки. Всичко това е обект на евентуални бъдещи изисквания от страна на фирмата, използваща информационната система, които към момента на задаване на дипломната работа на се били споменати. 8. Използвана литература и online източници
Петя Милкова, София, България Авторът е маркетинг консултант на хотели, както и представител на Booking.com за България и Румъния. - PiperJaffray - http://www.piperjaffray.com/ Centre for Regional and Tourism Research in Denmark - http://www.crt.dk/UK/staff/chm/trends.htm - http://internetmarketinghotels.blogspot.com/ Петя Милкова, София, България
- http://www.iseca.org/downloads/2003_2004-1/papers/42882_42924_43293_ISP.pdf от курсова работа на тема: Сигурен интернет доставчик Списък на фигурите Фигура 1 Схема на действията при разплащане чрез SSL......................................... 25 Фигура 2 Схема на базата от данни............................................................................. 53 Фигура 3 Началната страница на сайта....................................................................... 82 Фигура 4 Страницата Новини...................................................................................... 83 Фигура 5 Детайлна страница за даден хотел............................................................... 83 Фигура 6 Детайлна страница за даден хотел и неговата заетост на стаите за определен период................................................................................................................... 84 Фигура 7 Подробно търсене.......................................................................................... 84 Фигура 8 Информационна страница за дадена дестинация....................................... 85 Фигура 9 Страница с контакт форма............................................................................ 85 Фигура 10 Страница за регистрация на хотел............................................................... 87 Фигура 11 Страница,чрез която се влиза в хотелският панел..................................... 88 Фигура 12 Страница с направена зачква за поръчка и с полета за въвеждане на данни от кредитна карта........................................................................................................ 89 Фигура 13 Визуализиране на емаила които се изпраща до клиента след поръчка.................................................................................................................................... 89 Фигура 14 Страница с опците на администараторският панел за хотела...................................................................................................................................... 90 Фигура 15 Модул от хотелският администраторски панел за качване на снимки..................................................................................................................................... 90 Фигура 16 Модул от хотелският администраторски панел за оптимизиране на заетостта на стаите за даден хотел………………………................................................... 92 Фигура 17 Модул от хотелският администраторки панел за преглед на направените поръчки към него, подредени по дати................................................................................. 92 Фигура 18 Страница с детайлна поръчка направена към хотел........................................................................................................................................ 93 Фигура 19 Страница от администраторският панел на сайта със всички модули към него.......................................................................................................................................... 93 Фигура 20 Модул от администратоският панел на сайта които визуализира всички регистрирани хотели.............................................................................................................. 94 Фигура 21 Модул от администраторският панел които визуализира всички регистрирани клиенти които са направили поръчки......................................................... 95 Фигура 22 Администраторска детайлна страница на поръчка................................... 95 Фигура 23 Страница от която се редактира всяка една новина от администратора..................................................................................................................... 96 Фигура 24 Модул които показва всички текстови страници с опците им за редакция.................................................................................................................................. 96 Списък на таблиците Таблица 1 Част от по – важните разработени файлове................................................. 54 Таблица 2 Търговските параметри за HTTPS POST..................................................... 59 Таблица 3 Върнатите стойност от POST........................................................................ 59 Таблица 4 Описание на XML API документ.................................................................. 61 Списък на програмните фрагменти Програмен фрагмент 1 Примерен XML документ...................................................... 63 Програмен фрагмент 2 XML документ които се ползва от нашият сайт.................. 63 Програмен фрагмент 3 Функционална част от програмният код е за проверка на свободна стая и запълването на поребителската кошница…............................................ 65 Програмен фрагмент 4 Част от програмният код, които реализира online транзакцията за разплащане.................................................................................................. 76 Използвани съкращения PHP Hypertext Preprocessor HTML Hypertext Markup Language DHTML Dynamic HTML CSS Cascading Style Sheets JS JavaScript .NET Programme Language API Application Programming Interface XML Extensible Markup Language Flash Animation Language SEO Search Engine Optimization MySQL The most popular open source database .swf Flash extension ANSI American National Standarts Institute Linux Free Operation System ODBC Open Database Connectivity Overview PC Personal Computer RDBMS Relation Database Management System SSL Secure Socet Layer HTTPS Hyper Transfer Protocol over Secure Socet Layer CMS Content Management System ISO International Organization for Standartization UK United Kingdom Zend Open source Software Framework MSSQL Microsoft SQL Server POP3 The post office protocol version 3 SMTP Simple Mail Transfer Protocol FTP File Transfer Protocol .jpg Photo file extension Apache Name of the web serever WEB The World Wide Web GUI Graphical User Interface PC Personal Computer CMS Content management system IIS Internet Information Services SSI Server Side Includes Изтегляне 1.56 Mb. Сподели с приятели:
|