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

180 web application testing example test cases

Примери за тестване на уеб приложения: Това е пълен контролен списък за тестване както на уеб базирани, така и на настолни приложения.

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

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

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

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

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

Препоръчан инструмент:

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

=> Изтеглете TestRail Tool Test Management Tool

Значение на използването на контролен списък за тестване

# 1) Поддържането на стандартно хранилище на тестови случаи за многократна употреба за вашето приложение ще гарантира, че най-често срещаните грешки ще бъдат улавяни по-бързо.
# две) Контролният списък помага за бързо попълване на тестови случаи за нови версии на приложението.
# 3) Повторното използване на тестовите случаи помага да се спестят пари за ресурси за писане на повтарящи се тестове.
# 4) Важни тестови случаи ще бъдат обхванати винаги, като по този начин е почти невъзможно да се забрави.
# 5) Контролният списък за тестване може да бъде изпратен от разработчиците, за да се гарантира дали най-често срещаните проблеми са отстранени в самата фаза на разработка.

Бележки:

• Изпълнете тези сценарии с различни потребителски роли, напр. администратор, гост потребител и т.н.
• За уеб приложения тези сценарии трябва да се тества в множество браузъри като IE, FF, Chrome и Safari с версии, одобрени от клиента.
• Тествайте с различни разделителни способности на екрана като 1024 x 768, 1280 x 1024 и т.н.
• Приложението трябва да бъде тествано на различни дисплеи като LCD, CRT, преносими компютри, таблети и мобилни телефони.
• Тествайте приложение на различни платформи като Windows, Mac, Linux операционни системи и т.н.

Какво ще научите:

• Примери за тестване на 180+ теста за уеб приложения
  • Общи сценарии за изпитване
  • Сценарии за тестване на графичен интерфейс и използваемост
    • Тестови сценарии за критерии за филтриране
    • Тестови сценарии за резултатна мрежа
    • Тестови сценарии за прозорец
  • Тестови сценарии за тестване на база данни
    • Тествайте сценарии за функционалност при качване на изображения
    • Тестови сценарии за изпращане на имейли
    • Тествайте сценарии за експортна функционалност на Excel
  • Сценарии за тестване на ефективността
  • Тестови сценарии за тестване на сигурността
• 100+ готови за изпълнение тестови случаи (контролни списъци)
  • Пълният контролен списък (тестови случаи) за най-често срещаните компоненти на AUT
    • Контролен списък # 1: Контролен списък за мобилно тестване
    • Контролен списък # 2: Контролен списък за тестване на формуляри / екрани
    • Контролен списък # 3: Контролен списък за полеви тестове на текстово поле
    • Контролен списък # 4: Контролен списък за тестване на падащ списък или падащ списък
    • Контролен списък # 5: Контролен списък с полеви тестове
    • Контролен списък # 6: Контролен списък за тестване на радиобутони
    • Контролен списък # 7: Сценарии за тестване на полето за дата
    • Контролен списък # 8: Сценарии за тестване на бутони за запазване
    • Контролен списък # 9: Сценарии за тестване на бутон за отмяна
    • Контролен списък # 10: Изтриване на точки за тестване на бутони
    • Контролен списък # 11: За проверка на засегнатите райони след запазване или актуализиране
    • Контролен списък # 12: Списък за тестване на мрежа от данни
  • Препоръчително четене

Примери за тестване на 180+ теста за уеб приложения

Предположения: Да приемем, че вашето приложение поддържа следните функционалности

• Форми с различни полета
• Детски прозорци
• Приложението взаимодейства с базата данни
• Различни критерии за филтър за търсене и показване на резултати
• Качване на изображение
• Изпращане на имейл функционалност
• Функционалност за експортиране на данни

Общи сценарии за изпитване

1. Всички задължителни полета трябва да бъдат валидирани и обозначени със звездичка (*).
2. Съобщенията за грешки при проверка трябва да се показват правилно в правилната позиция.
3. Всички съобщения за грешки трябва да се показват в същия CSS стил ( Например, използвайки червен цвят)
4. Общите съобщения за потвърждение трябва да се показват, използвайки CSS стил, различен от стила на съобщенията за грешка ( Например, използвайки зелен цвят)
5. Текстът на подсказките трябва да има смисъл.
6. Падащите полета трябва да имат първия запис като празен или текст като „Избор“.
7. „Изтриване на функционалност“ за всеки запис на страница трябва да поиска потвърждение.
8. Изберете / премахнете избора на всички записи трябва да бъде предоставена, ако страницата поддържа функционалност за добавяне / изтриване / актуализиране на записи
9. Стойностите на сумите трябва да се показват с правилни символи за валута.
10. Трябва да се осигури сортиране по подразбиране на страници.
11. Функционалността на бутона за нулиране трябва да задава стойности по подразбиране за всички полета.
12. Всички цифрови стойности трябва да бъдат форматирани правилно.
13. Въведете полета за въвеждане за максимална стойност на полето. Входящи стойности, по-големи от посочената максимална граница, не трябва да се приемат или съхраняват в базата данни.
14. Проверете всички полета за въвеждане за специални символи.
15. Полевите етикети трябва да са стандартни, напр. полето, приемащо собственото име на потребителя, трябва да бъде етикетирано правилно като „Име“.
16. Проверете функционалността за сортиране на страници след операции за добавяне / редактиране / изтриване на който и да е запис.
17. Проверете за функционалност за изчакване. Стойностите на времето за изчакване трябва да могат да се конфигурират. Проверете поведението на приложението след изчакване на операцията.
18. Проверете бисквитките, използвани в приложение.
19. Проверете дали файловете за изтегляне сочат към правилните файлови пътища.
20. Всички ключове на ресурсите трябва да могат да се конфигурират в конфигурационни файлове или база данни вместо твърдо кодиране.
21. Стандартните конвенции трябва да се спазват през цялото време за именуване на ключове за ресурси.
22. Проверете маркирането за всички уеб страници (проверете HTML и CSS за синтаксични грешки), за да се уверите, че е в съответствие със стандартите.
23. Срив на приложението или недостъпни страници трябва да бъдат пренасочени към страницата за грешка.
24. Проверете текста на всички страници за правописни и граматически грешки.
25. Проверете числовите полета за въвеждане със стойности за въвеждане на символи. Трябва да се появи правилно съобщение за проверка.
26. Проверете за отрицателни числа, ако е позволено за числови полета.
27. Проверете броя на полетата с десетични числа.
28. Проверете функционалността на бутоните, налични на всички страници.
29. Потребителят не трябва да може да изпрати страница два пъти, като натисне бутона за изпращане бързо последователно.
30. За всякакви изчисления трябва да се обработват грешки, разделени на нула.
31. Входящите данни с първата и последната празна позиция трябва да се обработват правилно.

java копира 2d масив в друг масив

Сценарии за тестване на графичен интерфейс и използваемост

1. Всички полета на страница ( Например, текстово поле, радио опции, падащи списъци) трябва да бъдат правилно подравнени.
2. Числовите стойности трябва да бъдат обосновани правилно, освен ако не е посочено друго.
3. Трябва да се осигури достатъчно пространство между полевите етикети, колони, редове, съобщения за грешки и т.н.
4. Лентата за превъртане трябва да бъде активирана само когато е необходимо.
5. Размерът, стилът и цветът на шрифта за заглавие, текст за описание, етикети, данни за полето и информация за мрежата трябва да бъдат стандартни, както е посочено в SRS.
6. Текстовото поле за описание трябва да е многоредово.
7. Деактивираните полета трябва да са в сиво и потребителите не трябва да могат да фокусират върху тях.
8. При щракване върху полето за въвеждане на текст, показалеца на стрелката на мишката трябва да се промени на курсора.
9. Потребителят не трябва да може да пише в падащите списъци за избор.
10. Информацията, попълнена от потребителите, трябва да остане непокътната, когато има съобщение за грешка при изпращане на страница. Потребителят трябва да може да изпрати формуляра отново, като коригира грешките.
11. Проверете дали в съобщенията за грешки се използват подходящи етикети на полета.
12. Стойностите на падащото поле трябва да се показват в дефиниран ред на сортиране.
13. Tab и Shift + Tab order трябва да работят правилно.
14. Опциите за радио по подразбиране трябва да бъдат предварително избрани при зареждане на страницата.
15. Полезни съобщения за помощ на ниво поле и страница трябва да са налични.
16. Проверете дали правилните полета са маркирани в случай на грешки.
17. Проверете дали опциите на падащия списък са четливи и не са съкратени поради ограничения на размера на полето.
18. Всички бутони на дадена страница трябва да бъдат достъпни чрез клавишни комбинации и потребителят трябва да може да изпълнява всички операции с помощта на клавиатура.
19. Проверете всички страници за счупени изображения.
20. Проверете всички страници за прекъснати връзки.
21. Всички страници трябва да имат заглавие.
22. Съобщенията за потвърждение трябва да се показват преди извършване на каквато и да е операция за актуализиране или изтриване.
23. Пясъчен часовник трябва да се показва, когато приложението е заето.
24. Текстът на страницата трябва да бъде подравнен вляво.
25. Потребителят трябва да може да избере само една радио опция и всяка комбинация за отметки.

Тестови сценарии за критерии за филтриране

1. Потребителят трябва да може да филтрира резултатите, като използва всички параметри на страницата.
2. Прецизиране на функционалността за търсене трябва да зареди страницата за търсене с всички избрани от потребителя параметри за търсене.
3. Когато за извършване на операцията за търсене са необходими поне един критерий за филтриране, уверете се, че се показва правилното съобщение за грешка, когато потребителят изпрати страницата, без да избира критерии за филтриране.
4. Когато изборът на поне един критерий за филтриране не е задължителен, потребителят трябва да може да изпрати страницата и критериите за търсене по подразбиране да свикнат с резултатите от заявката.
5. Съобщенията за правилна проверка трябва да се показват за всички невалидни стойности за критериите за филтриране.

Тестови сценарии за резултатна мрежа

1. Символът за зареждане на страница трябва да се показва, когато отнема повече от стандартното време за зареждане на страницата с резултати.
2. Проверете дали всички параметри за търсене се използват за извличане на данни, показани в мрежата с резултати.
3. Общият брой резултати трябва да се покаже в мрежата с резултати.
4. Критериите за търсене, използвани за търсене, трябва да бъдат показани в мрежата с резултати.
5. Стойностите на мрежата с резултати трябва да бъдат сортирани по колона по подразбиране.
6. Сортираните колони трябва да се показват с икона за сортиране.
7. Решетките с резултати трябва да включват всички посочени колони с правилни стойности.
8. Функцията за сортиране по възходящ и низходящ ред трябва да работи за колони, поддържани от сортиране на данни.
9. Решетките с резултати трябва да се показват с правилно разстояние между колоните и редовете.
10. Пагинацията трябва да бъде активирана, когато има повече резултати от броя на резултатите по подразбиране на страница.
11. Проверете за функционалност за страниране на следваща, предишна, първа и последна страница.
12. Дублирани записи не трябва да се показват в мрежата с резултати.
13. Проверете дали всички колони са видими и хоризонтална лента за превъртане е активирана, ако е необходимо.
14. Проверете данните за динамични колони (колони, чиито стойности се изчисляват динамично въз основа на останалите стойности на колони).
15. За решетките с резултати, показващи отчети, проверете реда „Общо“ и проверете общия брой за всяка колона.
16. За решетките с резултати, показващи отчети, проверете данните от реда „Общо“, когато е активирана пагинацията и потребителят се придвижва до следващата страница.
17. Проверете дали се използват правилни символи за показване на стойности на колони, напр. За изчисляване на процента трябва да се покаже символ%.
18. Проверете данните на мрежата с резултати, за да разберете дали е активиран диапазонът от дати.

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

1. Проверете дали размерът на прозореца по подразбиране е правилен.
2. Проверете дали размерът на прозореца на детето е правилен.
3. Проверете дали на страницата има поле с фокус по подразбиране (като цяло фокусът трябва да бъде зададен в първото поле за въвеждане на екрана).
4. Проверете дали дъщерните прозорци се затварят при затваряне на родителския / отварящия прозорец.
5. Ако детският прозорец е отворен, потребителят не трябва да може да използва или актуализира никое поле във фонов или родителски прозорец
6. Проверете дали прозорецът минимизира, увеличава и затваря функционалността.
7. Проверете дали прозорецът може да се преоразмерява.
8. Проверете функционалността на лентата за превъртане за прозорци за родители и деца.
9. Проверете функционалността на бутона за отмяна за дъщерния прозорец.

Тестови сценарии за тестване на база данни

1. Проверете дали правилните данни се записват в базата данни при успешно изпращане на страница.
2. Проверете стойностите за колони, които не приемат нулеви стойности.
3. Проверете за целостта на данните. Данните трябва да се съхраняват в единични или множество таблици въз основа на дизайна.
4. Имената на индексите трябва да се дават съгласно стандартите, напр. IND__
5. Таблиците трябва да имат колона с първичен ключ.
6. Колоните в таблицата трябва да имат налична информация за описание (с изключение на одитните колони като създадена дата, създадена от и т.н.)
7. За всяка база данни за добавяне / актуализиране на база данни трябва да се добави дневник.
8. Трябва да се създадат необходимите индекси на таблици.
9. Проверете дали данните са ангажирани с базата данни само когато операцията е завършена успешно.
10. Данните трябва да бъдат върнати обратно в случай на неуспешни транзакции.
11. Името на базата данни трябва да се дава според типа на приложението, т.е. тест, UAT, пясъчник, на живо (въпреки че това не е стандарт, това е полезно за поддръжка на база данни)
12. Логическите имена на базата данни трябва да се дават според името на базата данни (отново това не е стандартно, но е полезно за поддръжка на DB).
13. Съхранените процедури не трябва да се именуват с префикс “sp_”
14. Проверете дали стойностите за колони за одит на таблици (като създадена дата, създадена от, актуализирана, актуализирана от, е изтрита, изтрити данни, изтрити от и т.н.) са попълнени правилно.
15. Проверете дали входните данни не са пресечени, докато записвате. Дължината на полето, показана на потребителя на страницата и в схемата на базата данни, трябва да бъде еднаква.
16. Проверете числовите полета с минимални, максимални и плаващи стойности.
17. Проверете числовите полета с отрицателни стойности (както за приемане, така и за неприемане).
18. Проверете дали опциите за избор на бутон и падащ списък са записани правилно в базата данни.
19. Проверете дали полетата на базата данни са проектирани с правилния тип данни и дължината на данните.
20. Проверете дали всички ограничения на таблицата като първичен ключ, външен ключ и др. Са приложени правилно.
21. Тествайте съхранените процедури и тригери с примерни входни данни.
22. Интервалите за водещо и последващо поле на въвеждане трябва да бъдат съкратени, преди да се ангажират данни в базата данни.
23. Не трябва да се допускат нулеви стойности за колоната Първичен ключ.

Тествайте сценарии за функционалност при качване на изображения

(Приложимо и за други функции за качване на файлове)
1. Проверете за качен път на изображение.
2. Проверете качването на изображения и променете функционалността.
3. Проверете функционалността за качване на изображения с файлове с изображения с различни разширения ( Например, JPEG, PNG, BMP и др.)
4. Проверете функционалността за качване на изображения с изображения с пространство или друг разрешен специален символ в името на файла.
5. Проверете качването на дублирано име на изображение.
6. Проверете качването на изображение с размер на изображението по-голям от максимално разрешения размер. Трябва да се покаже правилното съобщение за грешка.
7. Проверете функционалността за качване на изображения с типове файлове, различни от изображения ( Например, txt, doc, pdf, exe и др.). Трябва да се покаже правилно съобщение за грешка.
8. Проверете дали изображения с определена височина и ширина (ако са определени) се приемат по друг начин отхвърлени.
9. Лентата за напредъка при качване на изображения трябва да се появи за изображения с голям размер.
10. Проверете дали функционалността на бутона за отмяна работи между процеса на качване.
11. Проверете дали диалоговият прозорец за избор на файлове показва само поддържаните файлове в списъка.
12. Проверете функционалността за качване на множество изображения.
13. Проверете качеството на изображението след качване. Качеството на изображението не трябва да се променя след качването.
14. Проверете дали потребителят е в състояние да използва / преглежда качените изображения.

Тестови сценарии за изпращане на имейли

(Тук не са включени тестови случаи за съставяне или валидиране на имейли)
(Уверете се, че сте използвали фиктивни имейл адреси, преди да изпълните тестове, свързани с имейл)
1. Шаблонът за имейл трябва да използва стандартен CSS за всички имейли.
2. Имейл адресите трябва да бъдат валидирани преди изпращане на имейли.
3. Специалните знаци в шаблона на тялото на имейла трябва да се обработват правилно.
4. Специфични за езика знаци ( Например, Руски, китайски или немски езици) трябва да се обработват правилно в шаблона на тялото на имейла.
5. Темата на имейла не трябва да бъде празна.
6. Полетата на резервоари, използвани в шаблона за имейл, трябва да бъдат заменени с действителни стойности, напр. {Име} {Фамилия} трябва да бъде заменено с име и фамилия на дадено лице правилно за всички получатели.
7. Ако в тялото на имейла са включени отчети с динамични стойности и данните за отчета трябва да бъдат изчислени правилно.
8. Името на подателя на имейл не трябва да бъде празно.
9. Имейлите трябва да се проверяват в различни имейл клиенти като Outlook, Gmail, Hotmail, Yahoo! поща и т.н.
10. Поставете отметка за изпращане на функционалност по имейл, като използвате полета TO, CC и BCC.
11. Проверете имейли с обикновен текст.
12. Проверете имейлите в HTML формат.
13. Проверете горния и долния колонтитул на имейла за лого на компанията, политика за поверителност и други връзки.
14. Проверете имейлите с прикачени файлове.
15. Поставете отметка, за да изпращате функционалността на имейли до единични, многократни или получатели от списъка за разпространение.
16. Проверете дали отговорът на имейл адреса е верен.
17. Поставете отметка за изпращане на голям обем имейли.

Тествайте сценарии за експортна функционалност на Excel

1. Файлът трябва да бъде експортиран в правилното разширение на файла.
2. Името на файла за експортирания файл на Excel трябва да отговаря на стандартите, Например, ако името на файла използва клеймото за време, то трябва да бъде заменено правилно с действително клеймо по време на експортиране на файла.
3. Проверете за формат на датата, ако експортираният файл на Excel съдържа колони с дата.
4. Проверете форматирането на числата за числови или валутни стойности. Форматирането трябва да е същото, както е показано на страницата.
5. Експортираният файл трябва да има колони с правилни имена на колони.
6. Сортирането на страници по подразбиране трябва да се извършва и в експортирания файл.
7. Данните на Excel файла трябва да бъдат форматирани правилно със стойности за горен и долен колонтитул, дата, номера на страници и т.н. за всички страници.
8. Проверете дали данните, показани на страница и експортирания файл на Excel, са еднакви.
9. Проверете функционалността за експортиране, когато е активирано разбиването на страници.
10. Проверете дали бутонът за експортиране показва правилната икона според експортирания тип файл, Например, Икона на файл на Excel за xls файлове
11. Проверете функционалността за експортиране на файлове с много голям размер.
12. Проверете функционалността за експортиране за страници, съдържащи специални знаци. Проверете дали тези специални знаци се експортират правилно във файла на Excel.

Сценарии за тестване на ефективността

1. Проверете дали времето за зареждане на страницата е в приемливия диапазон.
2. Проверете зареждането на страницата при бавни връзки.
3. Проверете времето за реакция за всяко действие при леки, нормални, умерени и тежки условия на натоварване.
4. Проверете работата на съхранените процедури и тригери на база данни.
5. Проверете времето за изпълнение на заявката към базата данни.
6. Проверете за тестване на натоварване на приложението.
7. Проверете за стрес тестване на приложението.
8. Проверете използването на процесора и паметта при условия на пиково натоварване.

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

1. Проверете за SQL инжекционни атаки.
2. Защитените страници трябва да използват протокола HTTPS.
3. Сривът на страницата не трябва да разкрива информация за приложение или сървър. За това трябва да се покаже страницата за грешка.
4. Избягайте от специалните символи във входа.
5. Съобщенията за грешки не трябва да разкриват чувствителна информация.
6. Всички идентификационни данни трябва да бъдат прехвърлени по шифрован канал.
7. Тествайте сигурността на паролата и прилагането на политиката за пароли
8. Проверете функционалността за излизане от приложението.
9. Проверете за атаки с груба сила.
10. Информацията за бисквитките трябва да се съхранява само в криптиран формат.
11. Проверете продължителността на бисквитката на сесията и прекратяването на сесията след изчакване или излизане.
11. Сесийните токени трябва да се предават по защитен канал.
13. Паролата не трябва да се съхранява в бисквитки.
14. Тест за атаки за отказ на услуга.
15. Тест за изтичане на памет.
16. Тествайте неоторизиран достъп до приложения чрез манипулиране на стойности на променливи в адресната лента на браузъра.
17. Тествайте предаването на разширения на файлове, така че exe файловете да не се качват и изпълняват на сървъра.
18. Чувствителните полета като пароли и информация за кредитни карти не трябва да трябва да се активират автоматично попълване.
19. Функцията за качване на файлове трябва да използва ограничения на типа на файла, както и антивирус за сканиране на качени файлове.
20. Проверете дали списъкът с директории е забранен.
21. Паролите и други чувствителни полета трябва да бъдат маскирани, докато пишете.
22. Проверете дали функционалността на забравената парола е защитена с функции като временен изтичане на паролата след определени часове и дали е зададен защитен въпрос, преди да промените или поискате нова парола.
23. Проверете функционалността на CAPTCHA.
24. Проверете дали важни събития са регистрирани в регистрационни файлове.
25. Проверете дали привилегиите за достъп са приложени правилно.

Тестове за проникване на тестове - Изброих около 41 тестови случая за тестване на проникване на тази страница .

Наистина бих искал да благодаря Деваншу лавания (Старши QA инженер, работещ за I-link Infosoft), за да ми помогне да подготвя този изчерпателен контролен списък за тестване.

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

Актуализирано:

100+ готови за изпълнение тестови случаи (контролни списъци)

Можете да използвате този списък, за да тествате най-често срещаните компоненти на AUT

Как да тествате ефективно най-често срещаните компоненти на вашия AUT, всеки път?

Тази статия е списък с общи проверки на най-често срещаните елементи на AUT - който е съставен за удобство на тестерите (особено в гъвкавата среда, където се случват чести краткосрочни издания).

Всеки AUT (Application Test Test) е уникален и има много специфична бизнес цел. Отделните аспекти (модули) на AUT обслужват различни операции / действия, които са от решаващо значение за успеха на бизнеса, който AUT поддържа.

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

Някои често срещани компоненти на AUT:

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

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

Нека продължим със списъка с най-често валидиране за Уеб или настолно приложение страници / формуляри.

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

алгоритъм за сортиране на подбор c ++

Цел на този изчерпателен контролен списък:

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

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

Пълният контролен списък (тестови случаи) за най-често срещаните компоненти на AUT

Забележка:Можете да използвате тези контролни списъци във формата на Microsoft Excel (изтеглянето е предоставено в края на статията). Можете дори да проследявате изпълнението на теста в един и същ файл с резултати за пропускане / неуспех и състояние.

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

Контролен списък # 1: Контролен списък за мобилно тестване

Контролен списък # 2: Контролен списък за тестване на формуляри / екрани

Контролен списък # 3: Контролен списък за полеви тестове на текстово поле

Текстово поле:

BVA (размер) за текстово поле:

Мин -> -> Пропуск
Мин-1 -> -> Неуспех
Мин. + 1 -> -> Пропуск
Max-1 -> -> Pass
Макс. + 1 -> -> Неуспех
Max -> -> Pass

ECP за текстово поле:

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

Списъчно поле / падащо меню:

Контролен списък # 5: Контролен списък с полеви тестове

Checkbox:

Контролен списък # 6: Контролен списък за тестване на радиобутони

Радио бутон:

Контролен списък # 7: Сценарии за тестване на полето за дата

Поле за дата:

Контролен списък # 8: Сценарии за тестване на бутони за запазване

Запазване / актуализиране:

Контролен списък # 9: Сценарии за тестване на бутон за отмяна

Отказ:

Контролен списък # 10: Изтриване на точки за тестване на бутони

Изтрий:

Контролен списък # 11: За проверка на засегнатите райони след запазване или актуализиране

След запазване / актуализиране:

Контролен списък # 12: Списък за тестване на мрежа от данни

Решетка за данни:

Редактиране на функционалността на връзката

Въпреки че този списък може да не е изчерпателен, той наистина е обширен.

ИЗТЕГЛИ==> Можете да изтеглите всички тези контролни списъци във формат MS Excel: Изтеглете във формат Excel

Точки за отбелязване:

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

Моля, не се колебайте да направите това пълен контролен списък, като добавите още тестови случаи / сценарии или отрицателни тестови случаи в раздела за коментари по-долу.

Освен това ще се радвам да споделите това с приятелите си!

PREV Урок | СЛЕДВАЩ урок

Препоръчително четене

• Как се пишат тестови случаи: Крайното ръководство с примери
• Тестване на бисквитки на уебсайтове и тестови случаи за тестване на бисквитки на уеб приложения
• Примерен шаблон за тестови случаи с примери за тестови случаи (Изтегляне)
• Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
• Ръководство за тестване на сигурността на уеб приложения
• Тестване на приложения - в основите на софтуерното тестване!
• Инсталирайте приложението си на устройство и започнете да тествате от Eclipse
• TDD Vs BDD - Анализирайте разликите с примери