Пример за тестови случаи за уеб приложение (контролен списък)

по: Томас Хамилтън Томас Хамилтън
Hours Обновено

⚡ Умно обобщение

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

  • ️ Функционално на първо място: Валидирайте задължителните полета, дължините на границите, високосните години, делението на нула и поведението при изчакване, преди да започнете какъвто и да е козметичен преглед.
  • 🧭 Сигнали за използваемост: Проверете подравняването, подсказките, достъпа от клавиатурата, лентите за превъртане и възстановяването на съобщения за грешки, така че потребител, който използва системата за първи път, никога да не се затрудни.
  • 🌐 Матрица на съвместимостта: Повторете критичните потоци в Chrome, Firefox, Edge, Safari и мобилни браузъри, за да се разкрият разликите в оформлението и скриптовете.
  • 🗄️ Цялостност на базата данни: Сравнявайте стойностите от входния интерфейс със съхранените записи, проверявайте ключове, тригери, съхранени процедури и дължини на полетата и на двата слоя.
  • 🔌 API слой: Потвърждавайте кодове за състояние, схеми, удостоверяване, ограничения на скоростта и обработка на неуспехи надолу по веригата отделно от браузъра.
  • 🔐 Базови показатели за сигурност: Принудително HTTPS, криптиране на съхранени тайни, заключване на акаунти след многократни грешки и проверка за SQL инжектиране и груба сила.
  • ???? Производителност и достъп: Изпълнете скриптове за зареждане на профили с автоматизация вместо ръчно натоварване, след което потвърдете контраста на WCAG, етикетите и работата с клавиатурата.
Прочетете повече

Докато тествате уеб приложенията, трябва да имате предвид посочения по-долу шаблон. Споменатият по-долу контролен списък е почти приложим за всички видове уеб приложения в зависимост от бизнес изискванията.

Шаблонът по-горе показва как един лист може да съдържа сценарии за всяка област от контролния списък. За информация вижте тестване на уеб приложения преглед.

Сега нека разгледаме подробно всеки контролен списък:

Функционално тестване

Какво е функционално тестване?

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

Каква е целта или целта на функционалното тестване?

  • Целта на Функционално тестване е да проверите дали вашият продукт отговаря на предвидените функционални спецификации, споменати във вашата документация за разработка.

Примерни сценарии за функционален тест:

  • Тествайте всички задължителни полета трябва да бъдат валидирани.
  • Тествайте, че знакът звездичка трябва да се покаже за всички задължителни полета.
  • Тествайте системата да не показва съобщение за грешка за незадължителни полета.
  • Тествайте дали високосните години са валидирани правилно и не причиняват грешки/погрешни изчисления.
  • Тествайте, че цифровите полета не трябва да приемат азбуките и трябва да се покаже правилно съобщение за грешка.
  • Тествайте за отрицателни числа, ако е разрешено за числови полета.
  • Тестовото деление на нула трябва да се използва правилно за изчисления.
  • Тествайте максималната дължина на всяко поле, за да сте сигурни, че данните не са съкратени.
  • Тествайте изскачащото съобщение („Това поле е ограничено до 500 знака“) трябва да се покаже, ако данните достигнат максималния размер на полето.
  • Тествайте дали трябва да се покаже съобщение за потвърждение за операции за актуализиране и изтриване.
  • Тествайте стойностите на сумата, които трябва да се показват във валутен формат.
  • Тествайте всички полета за въвеждане за специални знаци.
  • Тествайте функцията за изчакване.
  • Тествайте функцията за сортиране.
  • Тествайте функционалността на наличните бутони
  • Тествайте Политиката за поверителност и ЧЗВ е ясно дефинирана и трябва да е достъпна за потребителите.
  • Тествайте, ако някоя функционалност се провали, потребителят се пренасочва към персонализираната страница за грешка.
  • Проверете дали всички качени документи са отворени правилно.
  • Тествайте дали потребителят трябва да може да изтегли качените файлове.
  • Тествайте имейл функционалността на системата.
  • Тествайте Java скриптът работи правилно в различни браузъри (IE, Firefox, Chrome, safari и Opera).
  • Тествайте, за да видите какво се случва, ако потребител изтрие бисквитки, докато е в сайта.
  • Тествайте, за да видите какво се случва, ако потребител изтрие бисквитки след посещение на сайт.
  • Тествайте, че всички данни в комбинираното/списъчно поле са подредени в хронологичен ред.

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

Тестване за ползваемост

Какво е тестване на използваемостта?

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

Каква е целта или целта на тестването за използваемост?

Тестът за използваемост установява лекотата на използване и ефективността на продукта, използвайки стандартни практики за тестване на използваемостта.

Примерни тестови случаи за използваемост

  • Съдържанието на уеб страницата трябва да е правилно, без никакви правописни или граматически грешки
  • Всички шрифтове трябва да са еднакви според изискванията.
  • Целият текст трябва да бъде правилно подравнен.
  • Всички съобщения за грешка трябва да са правилни без никакви правописни или граматически грешки и съобщението за грешка трябва да съвпада с етикета на полето.
  • Текстът на подсказката трябва да присъства за всяко поле.
  • Всички полета трябва да бъдат правилно подравнени.
  • Трябва да има достатъчно място между етикетите на полетата, колоните, редовете и съобщенията за грешки.
  • Всички копчета трябва да са в стандартен формат и размер.
  • Началната връзка трябва да присъства на всяка страница.
  • Деактивираните полета трябва да са сиви.
  • Проверете за повредени връзки и изображения.
  • Трябва да се покаже съобщение за потвърждение за всякакъв вид операция за актуализиране и изтриване.
  • Проверете сайта за различни разделителни способности (640 x 480, 600 × 800 и т.н.?)
  • Проверете дали крайният потребител може да управлява системата без разочарование.
  • Проверете дали разделът работи правилно.
  • Лентата за превъртане трябва да се появи само ако е необходимо.
  • Ако има съобщение за грешка при изпращане, информацията, попълнена от потребителя, трябва да е там.
  • Заглавието трябва да се показва на всяка уеб страница
  • Всички полета (текстово поле, падащо меню, бутон за избор и т.н.) и бутони трябва да са достъпни чрез клавишни комбинации и потребителят трябва да може да извършва всички операции с помощта на клавиатурата.
  • Проверете дали падащите данни не са съкратени поради размера на полето. Също така проверете дали данните са твърдо кодирани или управлявани чрез администратор.

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

СВЪРЗАНИ СТАТИИ

Тест за съвместимост

Какво е тестване за съвместимост?

  • Тестът за съвместимост се използва, за да се определи дали вашият софтуер е съвместим с други елементи на система, с която трябва да работи, напр. браузъри, Operaсистеми или хардуер.

Каква е целта или целта на тестването за съвместимост?

  • Целта на тестването за съвместимост е да се оцени колко добре работи софтуерът в определен браузър, Operaсистеми, хардуер или софтуер.

Примерни тестови сценарии за съвместимост:

  • Тествайте уебсайта в различни браузъри (т.е. Firefox, Chrome, Safari и Opera) и се уверете, че уебсайтът се показва правилно.
  • Тествайте дали използваната HTML версия е съвместима с подходящите версии на браузъра.
  • Тествайте правилното показване на изображенията в различни браузъри.
  • Тествайте дали шрифтовете могат да се използват в различни браузъри.
  • Тествайте дали кодът на java скрипт може да се използва в различни браузъри.
  • Тествайте анимираните GIF файлове в различни браузъри.

Последователното рендиране не доказва нищо за записите зад екрана. кръстосано тестване на браузъра Матрицата поддържа тази област управляема.

Тестване на бази данни

Какво е тестване на база данни?

  • In Тестване на база данни тестват се записи от задния край, които са били вмъкнати чрез уеб или десктоп приложения. Данните, които се показват в уеб приложението, трябва да съвпадат с данните, съхранявани в базата данни.

За да извърши тестването на базата данни, тестерът трябва да е наясно със споменатите по-долу точки:

  • Тестерът трябва да разбира напълно функционалните изисквания, бизнес логиката, потока на приложението и дизайна на базата данни.
  • Тестерът трябва да разбере таблиците, тригерите, процедурите за съхранение, изгледите и курсорите, използвани за приложението.
  • Тестерът трябва да разбира логиката на тригерите, процедурите за съхранение, изгледите и създадените курсори.
  • Тестерът трябва да разбере таблиците, които се засягат, когато операциите за вмъкване на актуализация и изтриване (DML) се изпълняват чрез уеб или настолни приложения.

С помощта на горепосочените точки тестерът може лесно да напише тестови сценарии за тестване на база данни.

Примерни тестови случаи за тестване на база данни:

  • Проверете името на базата данни: Името на базата данни трябва да съответства на спецификациите.
  • Проверете таблиците, колоните, типовете колони и настройките по подразбиране: Всички неща трябва да съответстват на спецификациите.
  • Проверете дали колоната позволява нула или не.
  • Проверете първичния и външния ключ на всяка таблица.
  • Проверете съхранената процедура:
  • Тествайте дали съхранената процедура е инсталирана или не.
  • Проверете името на съхранената процедура
  • Проверете имената на параметрите, типовете и броя на параметрите.
  • Тествайте параметрите дали са необходими или не.
  • Тествайте съхранената процедура, като изтриете някои параметри
  • Тествайте, когато изходът е нула, нулевите записи трябва да бъдат засегнати.
  • Тествайте съхранената процедура, като напишете проста SQL запитвания.
  • Тествайте дали запомнената процедура връща стойностите
  • Тествайте съхранената процедура с примерни входни данни.
  • Проверете поведението на всеки флаг в таблицата.
  • Уверете се, че данните се записват правилно в базата данни след всяко изпращане на страница.
  • Проверете данните, ако се изпълняват операциите DML (актуализиране, изтриване и вмъкване).
  • Проверете дължината на всяко поле: Дължината на полето в задния и предния край трябва да е еднаква.
  • Проверете имената на базата данни за QA, UAT и производство. Имената трябва да са уникални.
  • Проверете криптираните данни в базата данни.
  • Проверете размера на базата данни. Също така тествайте времето за отговор на всяка изпълнена заявка.
  • Проверете данните, показани в предния край, и се уверете, че са същите в задния край.
  • Проверете валидността на данните, като вмъкнете невалидните данни в базата данни.
  • Проверете тригерите.

Контролен списък за тестване на API

Повечето бизнес правила сега се намират зад REST или GraphQL крайни точки, така че само проверките на браузъра не могат да докажат, че системата работи. Тестването на крайни точки директно разкрива кон...tracдефекти в t и оторизацията много по-рано, отколкото може потребителският интерфейс.

Обхванете следните сценарии, преди крайната точка да бъде подписана:

Примерни тестови сценарии за API тестване:

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

Изпълнете този списък във всяка среда, тъй като подготовката и производството често предоставят различни набори от разрешения. Вижте API тестване преглед и ръчно тестване на REST API.

Няколко от тези проверки се припокриват с работата по сигурността.

Тестване на сигурността

Тестване на сигурността включва тест за идентифициране на всички недостатъци и пропуски от гледна точка на сигурността.

Примерни тестови сценарии за тестване на сигурността:

  • Уверете се, че уеб страницата, която съдържа важни данни като парола, номера на кредитни карти, тайни отговори за защитен въпрос и т.н., трябва да бъде изпратена чрез HTTPS (SSL).
  • Проверете дали важната информация като парола, номера на кредитни карти и т.н. трябва да се показва в криптиран формат.
  • Уверете се, че правилата за парола са приложени на всички страници за удостоверяване като Регистрация, забравена парола, промяна на парола.
  • Проверете дали паролата е променена, че потребителят не трябва да може да влезе със старата парола.
  • Проверете дали съобщенията за грешка не трябва да показват важна информация.
  • Проверете дали потребителят е излязъл от системата или потребителската сесия е изтекла, потребителят не трябва да може да навигира в сайта.
  • Потвърдете за директен достъп до защитените и незащитените уеб страници без влизане.
  • Уверете се, че опцията „Преглед на изходния код“ е деактивирана и не трябва да се вижда от потребителя.
  • Проверете дали потребителският акаунт се заключва, ако потребителят въвежда грешна парола няколко пъти.
  • Уверете се, че бисквитките не трябва да съхраняват пароли.
  • Проверете дали някоя функционалност не работи, системата не трябва да показва информация за приложение, сървър или база данни. Вместо това трябва да показва персонализираната страница за грешка.
  • Проверете атаките с инжектиране на SQL.
  • Проверете потребителските роли и техните права. Например заявеният не трябва да има достъп до страницата на администратора.
  • Проверете дали важните операции са записани в лог файловете и дали тази информация трябва да бъде tracвъзможно.
  • Уверете се, че стойностите на сесията са в шифрован формат в адресната лента.
  • Проверете дали информацията за бисквитките се съхранява в криптиран формат.
  • Проверете приложението за Brute Force Attacks

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

Тестване на производителността

Тестване на производителността се провежда за оценка на съответствието на система или компонент с определени изисквания за ефективност.

Общи тестови сценарии:

  • За определяне на производителността, стабилността и скалируемостта на приложение при различни условия на натоварване.
  • За да се определи дали текущата архитектура може да поддържа приложението при пикови потребителски нива.
  • За да определите кое оразмеряване на конфигурацията осигурява най-доброто ниво на производителност.
  • За идентифициране на тесните места в приложенията и инфраструктурата.
  • За да се определи дали новата версия на софтуера е оказала неблагоприятно въздействие върху времето за реакция.
  • За да оцените продукта и/или хардуера, за да определите дали може да се справи с очакваните обеми на натоварване.

Как се извършва тестване на производителността? Чрез ръчно тестване или чрез автоматизация

На практика не е възможно да се извърши ръчно тестване на ефективността поради някои недостатъци като:

  • Ще са необходими повече ресурси.
  • Не са възможни едновременни действия.
  • Не е налично правилно наблюдение на системата.
  • Не е лесно да се изпълни повтарящата се задача.

Следователно, за да преодолеем горните проблеми, трябва да използваме инструмента за тестване на производителността. По-долу е даден списък с някои популярни инструменти за тестване.

Една аудитория все още липсва: потребители, които достигат до тези екрани чрез помощни технологии.

Контролен списък за тестване на достъпността

Тестването за достъпност потвърждава, че хората, използващи екранни четци, навигация само с клавиатура или увеличение, могат да извършат същите пътешествия като всички останали. Това е и изискване за обществени поръчки, тъй като корпоративните...tracts често се позовават WCAG 2.2 Ниво AAТези дефекти са структурни и ранното им отстраняване струва много по-малко.

Примерни тестови сценарии за тестване на достъпността:

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

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

Въпроси и Отговори

Тестовият план е официален документ, обхващащ обхвата, графика, ресурсите, риска и критериите за излизане от дадена версия. Контролният списък е леко напомняне за покритие, изброяващо условията за проверка. Планът управлява проекта; контролният списък управлява отделната сесия за тестване.

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

Повечето екипи обвързват охранителното покритие с Ръководство за тестване на уеб сигурността на OWASP, достъпност до WCAG 2.2 и обща терминология на процеса към ISTQB. Тези препратки позволяват контролния списък да бъде одитиран, вместо да се основава единствено на екипния навик.

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

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

Обобщете тази публикация с: