Тестване на уебсайтове и SAAS приложения

В повечето случаи тестването на уеб приложения е по-сложно от тестването на конвенционален софтуер. Трудността се дължи на:

Спецификата на работата с уеб приложения е, че тези приложения имат публичен достъп, така че е необходимо внимателно да се организира защитата на данните, предавани от потребителя;
Архитектура на уеб приложение. Обикновено едно приложение има следната архитектура:
уеб сървър;
сървър за приложения;
база данни.

Предизвикателства при тестване на уеб приложения

Разпределените компоненти на системата умножават трудността на тестването:

Трудности при локализиране на грешката, възникнала в различни части на мрежовата система;
При функционалното тестване от страна на клиента виждаме симптомите на грешка, но не и самата грешка.
Срокове за тестване и неясни/непълни изисквания за разработени продукти;
Неправилни практики за разработка на софтуер.

Ние решаваме проблемите на функционалното тестване на уеб приложения чрез разработване на тестови пакети, които:

Може да бъде завършено в рамките на времето, определено за тестване;
Осигурете достатъчно покритие на съществуващата функционалност с тестове;
Те ви позволяват да изберете необходимото подмножество от тестове в различни ситуации от процеса на разработка (например, извършване на промени само в отделен модул, намаляване на времето, определено за пускане на версията в процес на разработка и т.н.).

Изграждане на процес на тестване на качеството

Започнете процеса на тестване на етапа на генериране на изисквания за самото интернет приложение или добавената функционалност;
Оценка на рентабилносттаприлагане на автоматизирани тестове. И по-нататъшното му организиране в случай на прилагане;
Докладване. Описани са различни документи за контрол и съхраняване на резултатите от процеса на тестване: ТЗ за тестване, ежедневни отчети, пълни доклади за тестване на приложения с препоръки за пускане;
Разделяне на задачите. Предлага се да се поверят задачи като проектиране на тестове, автоматизация на тестове, изпълнение на тестове на различни служители на отдела;
Делегиране на правомощия. Ако служителят, работещ по конкретна задача, разбира ситуацията по-добре от ръководителя на този проект, тогава той трябва да прехвърли част от управленските функции. Защото ще му бъде по-лесно да намери изход от спорна ситуация и да разреши евентуални проблеми;
Използване на въртене. Основното е да преместите тестери между отделите на ИТ отдела, за да разберете по-добре процеса на разработка и да развиете нови професионални умения сред служителите.

Инструменти и скриптове за тестване на уеб приложения

Тестване на гранични стойности – използване на гранични стойности. Техника за проектиране на тестове, предназначена да помогне на тестера да избере най-ефективните стойности от диапазони от стойности. Приложим е на всички тестови нива: тестови нива на единица, интеграция, система и системна интеграция. Тази техника е доста проста и включва 3 стъпки: дефиниране на диапазон от стойности; определяне на границите на ареала; създаване на тестови случаи (3-4 за всяка граница);

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

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

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

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

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

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

Преди всичко;
По-задълбочено.

Тестване по двойки – тестване по двойки. Тази техника се използва, когато има голям брой комбинации, които трябва да бъдат тествани, и изключването на всякакви комбинации изглежда рисковано. И ако броят на комбинациите е толкова голям, тогава най-вероятно няма да има достатъчно ресурси за проектиране и преминаване на тестови случаи. Когато използвате тестване по двойки, се тестват комбинации от двойки стойности на променливи, а не всички комбинации от стойности за всички променливи. Тази техника значително намалява броя на комбинациите за тестване. Има два начина да го приложите:

Ортогонални масиви - подходът е да се разработи двуизмерен масив от комбинации от стойности на входни данни със следните свойства:

Ако изберете две колони от масива, те съдържат всички комбинации от стойностите на тези две колони;
Аконякаква двойка стойности на две колони се среща няколко пъти, тогава всички възможни сдвоени комбинации от стойности на тези колони трябва да се срещат еднакъв брой пъти.

За да се конструира такъв масив, се използват специални помощни програми за генериране на ортогонални масиви въз основа на входните данни и броя на техните възможни стойности;

Алгоритъм за всички двойки - Тази комбинаторна техника е създадена специално за тестване по двойки. Същността му е да се изберат такива комбинации от променливи, така че да има всички възможни комбинации от стойности за всяка двойка променливи. Когато използвате този метод, се използват и специални помощни програми, които ви позволяват да изградите всички двойки променливи на алгоритъма AllPairs според таблица с всички променливи и техните стойности;

Поставяне на задача чрез scrum методологии

Схемата за пускане на разработване на интернет приложения предполага пускането на нова версия на всеки 2-3 седмици. В тази ситуация тестването отнема порядък по-малко време, отколкото при разработването на конвенционален софтуер. Ние организираме процеса на тестване чрез решаване на следните проблеми:

Избор на тестове (избор на правила и критерии за подбор);
Обработващи елементи с размити изисквания;
Разпределение на задачите между членовете на екипа;
Избор на метрика за оценка на резултатите от теста и качеството на работа;
Формиране на подходяща отчетност.
Тестване в процеса на размита разработка.