Мръсни чинии тестване на уеб проекти

Съдържанието на статията

Принципите на работа на различните студия за уеб дизайн могат да бъдат коренно различни. Приоритетите са различни, подходите са различни. Но всичко се свежда до едно нещо: всеки има бъгове и трябва да се бори с тях.

ТЕСТЕРА Е ПОСЛЕДНО ЗАВЕДЕНИЕ. АКО НЕ НАМЕРИТЕ БЪГ, НИКОИ НЯМА ДА ГО НАМЕРИ ВЕЧЕ, — ПЪРВОТО ИНСТРУКЦИЯ НА ТЕХНИЧЕСКИЯ ДИРЕКТОР.

И сега уеб системата е готова. Тестерът започва да търси грешки. Тестването на сайта може да бъде разделено на три етапа: тестване за съответствие с ТЗ и стандартите, тестване на оформлението и опити за разбиване на уеб системата.

Тестване за съответствие с ТЗ и Стандарти

Това е основният етап на тестване. Първият проблем, с който се сблъсква тестерът, е да разбере техническите спецификации. Ето фрагмент от TK, описващ календара на събитията на уебсайта www.5chka.com (уебсайта на веригата магазини Pyaterochka):

ОТДЕЛЕТЕ НЕЩО ВИЗУАЛНО

Обектът „Събитие“ на сайта съответства на подраздела „Календар на IR събития“ в раздела „Връзки с инвеститорите“. Индексната му страница е страница със списък, съдържа: календар на събитията за текущия месец и списък с кратки описания на събитията. Календарът е таблица с датите на текущия месец. Ако за някой ден от месеца има събитие с дата, съответстваща на дадената дата, то този ден от месеца е препратка към:

—страница с пълно описание на това събитие, ако в системата има само едно събитие с тази дата; —към индексната страница на подраздела „Календар на IR събития“ със списък с кратки описания на събития за избраната дата.

Календарът също така съдържа връзки за превключване към следващия/предишния месец.

Само активен (нескрити) събития в хронологичен ред. По подразбиране се показват първите 10 събития по дата, започвайки от текущата дата. Всеки блок с кратко описание съдържа:

— дата на събитието; — заглавие на събитието; —връзка към страницата с пълно описание на това събитие (ако полето "текст" на това събитие не е празно).

Или по-сложен пример. Има онлайн магазин. Каталогът му има следната структура: в тях има директории и поддиректории (неограничено влагане), има продуктови групи в каталози и поддиректории, продукти в продуктови групи и параметри за продукти. В същото време нито един от горните обекти (с изключение на продукти и параметри) не се показва на сайта. И каталожното изображение (2 нива на влагане) и изображения на продуктови групи се показват на сайта. От какви мотиви е направено това е десетият въпрос и тук много лесно може да се объркате.

Но да кажем, че TOR е адекватен и тестерът е разбрал всичките му тънкости. Тогава този етап на тестване става доста банален. Използвайки примера с календара, тестването изглежда така:

Календарът се тества

ToR описва всички обекти, работата с тях и как трябва да бъдат показани на сайта (отпред). В различните уеб системи има различни обекти и работата с тях се извършва по различни начини. ТЗ също така описва възможностите на администратора: възможно ли е добавяне на нови страници към структурата на сайта, възможно ли е тяхното редактиране, промяна на реда им и други подобни. Стандартите се проверяват по същия начин.

Стандартите описват онези аспекти на уеб системата, които са еднакви за всички проекти.

Тестване на оформлението

Тестването на оформлението от своя страна е разделено на два етапа: оформление на динамично и статично съдържание. Оформление на динамично съдържание (т.е. изход на обекти)тествани на предишния етап (за съответствие с ТЗ). Оформлението на статичното съдържание може да се нарече „общо“ оформление, тъй като включва и общия графичен дизайн на сайта.

Internet Explorer версия 5.0 и по-нова
Mozilla Firefox 1.0.1 и по-нова версия
Mozilla 1.3 и по-нова версия
Opera 7.54 и по-висока (изключително рядка opera 6.0)

Преди шест месеца Netscape 7.0 беше в този списък и понякога клиенти (особено европейски и международни компании) изискват Safari. Оформлението в различните браузъри може да се различава драстично. Прост пример: FireFox и Internet Explorer (два от най-популярните браузъри днес) третират полетата на елементите на страницата и полетата по различен начин.

FireFox и Internet Explorer показват подложките и самите елементи по различен начин

Подробна информация за открити грешки Изходен код с описание на грешките

Често валидаторът ви позволява да идентифицирате скрити грешки, които могат да се появят само при определени обстоятелства. Например за новини се показват заглавието, изображението и съобщението. И ако дължината на съобщението на първата новина е повече от 300 знака, картината на втората новина „заминава“ някъде.

Тестването на оформлението е в същото време тестване на дизайна, тъй като дизайнерите на оформление обикновено се ръководят не от техническите спецификации, а от оформлението на дизайна. Ако дизайнерът е нарисувал нещо излишно или е забравил да нарисува нещо необходимо, това, разбира се, е грешка.

Опит за разбиване на уеб системата

Има легенда за тестер. Момичето получи работа като тестер в определена компания и беше помолена да демонстрира способността си да тества. Момичето отиде до настолната лампа, изключи я от контакта, постави ключа в положение между"включено" и "изключено" и включи щепсела обратно в контакта. Лампата изгоряла и момичето било наето. Добрият тестер трябва да има дарба да чупи всичко, до което се докосне. Защото ако една уеб система има слабо място, лек удар върху който ще я „изпусне“, тогава този удар определено ще се случи.

тестово съдържание

Отделен проблем е въпросът как трябва да изглежда тестовото съдържание. Препоръчваме да следвате две прости правила:

Съдържанието на теста трябва да е коректно от морална и етична гледна точка - не трябва да съдържа думи и изрази на ръба на цензурата и дори по-нецензурни (с които разработчиците и тестерите често грешат). В идеалния случай съдържанието на теста трябва да показва само какво представлява. Например за новини трябва да зададете параметри от следния тип. Заглавие - "Аз съм заглавието на новината", Обява - "и аз съм неговият анонс", Текст - "и аз съм текстът на новината, трябва да съм повече или по-малко дълъг, защото така обикновено се случва ..." и други подобни. Естествено, с някои вариации за разграничаване на една новина от друга.
Тестовото съдържание трябва ясно да се различава от реалното съдържание. Даденият пример с новините в това отношение не е много добър. Той не хваща окото. Въпросът как да се подчертае тестовото съдържание се решава "според ситуацията". Например, ако новината има и полето Изображение, тогава е достатъчно да зададете ярка картинка (очевидно изпъкваща от дизайна) с надпис „тест“ за всички тестови новини. Или можете просто да добавите префикс към всички полета с „AHTUNG! ТЕСТ!" или подобни.

Но без значение как съдържанието на теста се откроява, в края на тестването то трябва да бъде изтрито. Това се счита за добро възпитание.

Систематизиране на грешки, проследяване на грешки

И сега, най-накрая, всички грешки са открити. Сега имате нужда от тяхсистематизирам. За да направите това, има така наречените "бъг тракери" - програми, които пазят история на грешки. Най-често инструментите за проследяване на грешки са уеб базирани системи, организирани като форуми или блогове. Нека разберем систематизирането на грешките, като използваме Mantis инструмента за проследяване на грешки като пример.

Първото ниво на систематизиране на бъгове са проектите (уебсайтовете). Съвсем логично е да се отделят бъговете на един сайт от бъговете на друг сайт. Към проекта са "прикрепени" грешки, които имат още няколко нива на систематизация. Нека се спрем на тях по-подробно.

Състоянието на грешка дава представа какво коригиращо действие е предприето. Когато се добави грешка, нейният статус се определя като "нов". Разработчикът поправя грешката и определя статуса й като „разрешен“. След това тестерът проверява дали грешката наистина е разрешена. И ако бъгът е решен, определя статуса му като „затворен“.

Формуляр за редактиране на данни за грешки с избор на състояние

Категорията на грешки е много важно свойство за оптимизиране на труда. За всеки проект тестерът може да зададе произволен набор от категории. Най-често използвани:

Пример 1: Новините трябва да се показват в хронологичен ред, но те се показват на случаен принцип - очевидна програмна грешка.

Пример 2: Заглавието на новината трябва да е удебелено, а трябва да е в курсив - очевидна грешка в оформлението.

Пример 3: Трябва да се показва съобщение за новини, но не се показва. Може би програмистът е забравил да покаже съобщението или може би дизайнерът на оформлението го е форматирал неправилно и поради грешка на ниво HTML съобщението не се показва.

Списък с грешки в Mantis

Типични грешки

Да започнем с малко статистика. Независими статистически проучвания на DEFA Gruppe разкриха няколко интересни факта:

Топ типични грешки

Броят на тестовете на сайта също е важен. Сайтът трябва да бъде тестван средно четири пъти. Първият тест се прави, когато уеб системата е готова. Вторият тест се извършва след отстраняване на всички грешки (тъй като коригираме софтуерната част - пада оформлението, коригираме оформлението - Java скриптовете падат). Третият тест се прави, когато сайтът е изпълнен с реално съдържание. И четвъртият тест (бегъл) се извършва, след като сайтът е отворен на реален хостинг и в него се е излял поток от потребители.

Две думи за автоматизирането на процеса на тестване. Никоя програма не може да тества сайта. Тестването е творчески процес. Единственото нещо, което може да бъде автоматизирано, е проверката на оформлението за съответствие със стандартите на W3C. И, може би, тестване на уязвимостта на сайта (SQL инжекции, DoS атаки и т.н.).

И в заключение, народната мъдрост: ако разработчиците не ви харесват, значи сте добър тестер!