След като вече сме описали основните моменти от тест сценария, дефинирали сме си критерии за успеваемост, човешки и материален ресурс, идва ред да опишем и тестовете, които ще извършим върху нашето приложение. Ще Ви дам примерен вариант на тестове, които задължително трябва да извършите. Вие може да си допълните или редактирате тези, според спецификата на проекта. Всички показатели са примерни и подлежат на редакция.
Функционални тестове
С провеждането на функционалните тестове се цели да се съпоставят реалните действия и състояние на системата с тези описани във функционалната спецификация. При наличие на разминавания с функционалната спецификация ще се направят предложения и препоръчки за тяхното отстраняване. Провеждането на този вид тестове е запланувано за всеки един етап и версия, от разработката на портала.
| Цел: | Проверка на всички функционалности на системата, според наличните отнасящи се до пълната функционалност на всеки един модул, включително навигация, входящи данни, процеси и тяхното повторение. |
| Техника: | Изпълнение на целия набор от написаните ТС, като се изпозват валидни и невалидни данни за всеки един от параметрите, за да е в състояние да се потвърди:
|
| Критерии за успешно завършване на тези тестове: |
|
| Бележки: |
Performance testing – тестове за проверка на състоянието на системата
При провеждането на тези тестове се цели да се провери системата при различно натоварване в зависимост серия симулирани действия, предприемани от крайният потребител. Ще се подходи към тестване на хардуерната конфигурация и това каква ще бъде нейната реакция при екстремални условия.
Провеждането на този вид тестове ще се осъществи след като бъде завършена първата версия на On demand системата и се пусне бета версия на приложението.
| Цел: | Проверка на състоянието на системата и функционалностите, които протичат при следните условия:
– нормална среда на функциониране на система – натоварена среда на функциониране на система |
| Техника: | Използване на ТС създадени за проверка на функционалностите на системата.
Тук се увеличават до критичен максимум обема информация / елементи, които се подават към системата, посредство скрипт за провеждане на автоматизирани тестове. Провеждането на тези тестове трябва да се извърши първо от един регистриран потребител, след което да се повтори с множество симулирани заявки, посредством интрумент за автоматизирани тестове. |
| Критерии за успешно завършване на тези тестове: |
|
| Бележки: |
Load Testing
Задачата на тези тестове е да провери състоянието на системата в процес на натоварване. Ще се изследва необходимото време от създаване на дадена заявка от потребител до получаването на краен резултат като вузуализиция в портала. Провеждането на този вид тестове ще се осъществи след като бъде завършена първата стабилна версия на On demand системата.
| Цел: | Проверка на функционалностите на система според определено време за натоварване. |
| Техника: | Създаване на ТС, които да потвърдят правилното дейстие на проверяваната функционалност.
Осъществяване на промяна за брой на симулираните заявки и времето за изпълнение на всяка една от тях. Тези тестове ще се извършват, чрез инструмент за провеждане на автомазирани тестове |
| Критерии за успешно завършване на тези тестове: |
|
| Бележки: |
Stress Testing
Целта е да се изследва системата в процес на наторване. Ще се симулират определен брой виртуални потребители, възпроизвеждащи заявки към системата. Всичко това ще се проведе, за да се отчете състоянието на системата при максимален трафик. Тестовете ще се осъществи основно върху използването на модулите „Приложения” и „Абонаменти”, защото там се очаква да е най-натоварената част от системата.
Провеждането на този вид тестове ще се осъществи след като бъде завършена първата версия на On demand системата – бета версия.
| Цел: | Проверка на системата според написаните ТС за функционални тестове. Тук ще се проверява системата в режим на натоварване, според следните параметри:
– липса на достатъчно памет на сървърната машина (RAM) – максимален брой на свързаните клиенти (connections) – извършване на едно и също действие, по едно и също време от две и/или повече регистрации. |
| Техника: | Използване на ТС, създадени за провеждането на Load или Performance тестове.
Тестове трябва да бъдат извършени от една и съща машина, като паметта на сървъра трябва да бъде намалена (или лимитирана). |
| Критерии за успешно завършване на тези тестове: | Всички сценарии бъдат изпълнени, като се определят минимум ресурси за правилното фукциониране на система без да се отчитат грешки в нея. |
| Бележки: |
Regression Testing
С провеждането на този вид тестове ще се потвърди дали вече отстранените бъгове и дефекти, не се репродуцират в следващите версии. Този вид тестове ще се провежда за всяка една версия на продукта, с цел максимално ефективно управление на качеството.
| Цел: | Проверка на документираните бъгове / дефекти за тяхното отстраняване. При репродуциране отново се документират. |
| Техника: | Използване на ТС, създадени за провеждането на функционални тестове |
| Критерии за успешно завършване на тези тестове: |
|
| Бележки: |
User-interface testing
Провеждането на тези тестове е да се определи до каква степен потребителят е максимално улеснен при ползването на услугите от портала. Тестове за ползваемост се проведат и за да се установи до колко е лесна ориентацията в портала, и дали всички менюта и опции за леснодостъпни за потребителят, и дали следват логиката.
| Цел: | Потвърждаване на следните параметри:
– Навигацията в системата отговаря на бизнес логиката и логиката на процесите – Всички обекти отговарят на стандартите, включително менюта, размери, полета, позиции. |
| Техника: | Провеждане на тестове за всеки един екран , за да се провери за размествания по екрана, размествания на обекти и полета, използвайки браузъри с различни ядра – Internet Explorer, Mozilla Firefox, Opera. |
| Критерии за успешно завършване на тези тестове: | Всеки един екран отговаря на стандартите и изискванията.
Липса на различия по дизайна, използвайки различни браузъри |
| Бележки: |
what do you think?