Тест кейс (test case) или тестов скрипт (test script) в софтуерното инженерство е съвкупност от условия, които трябва да се проверят дали едно приложение или един компонент от него работи така както е проектиран.
Механизмът на проверяване дали една система или компонент pass-ват или fail-ват теста се нарича test oracle. Понякога този „оракул“ може да е някакво изискване или пък достатъчно условие. Може да са нужни няколко тест кейса да се определни дали един софтуер е годен за пускане на пазара или не. Също така тест кейсовете сe складират като в нещо като папка, която се нарича test suite (букв. превод колекция).
Също като в 1 кулинарна книга, тест case-овете се състоят от 2 части :
1)Списък с продуктите;
2)Инструкции как да готвим – печем,варим и т.н.
В нашият случай са:
1)Исиквания;
2)Инструкции;
Хубав и олеснен пример за тест кейс тук:
https://i.ytimg.com/vi/eFywmQGoSWo/maxresdefault.jpg
Форматът на тест кейса е препоръчителен да бъде със следните полета:
test case ID – това е „документа на самоличност на самия тест кейс“. Чрез този уникален идентификационен номер лесно се разграничават различните кейсове. Обикновено инструментите за тестване номерират и именуват самите тест кейсове вместо нас.
test title – Заглавие – добре е да се опомене какво се тества и обикновено това е първото нещо, което гледаш при сортиране на самите кейсове.
test designer и test date ; test executed by и execution date – като тук са имена на тестърите и датата, на която е извършено тестването.
test case description (описание) или test steps (стъпки за тестване). Както се вижда по-горе има стъпки за изпълнение.
related requirement(s) – изиквания свързани с кейса – какво е необходимо, за да се случи и т.н още наречени pre-conditions.
expected results – какви резултати очакваме в случай, че успее. Добре е да се разбира какво трябва да се случи.
post conditions – в какво състояние остава системата. Трябва да може един тестър след като направи тестването да може да върне приложението към първоначалното ѝ състояние и да може да тества отново. Пример : тест кейс, при който добавяш нов потребител с име и парола. Трябва също така да можеш да го изтриеш и да започнеш наново.
Test data;
test priority – тестов приоритет - в зависимост от това колко е критичен бъга може да е среден или висок, а ниския обикновено е някакъв по-незначителен интефейс.
Requirements reference – референции или препратки към други кейсове. Това е добре, понеже можеш да направиш traceability matrix (матрица за проследяване)
https://en.wikipedia.org/wiki/Traceability_matrix както тук в Уикито. Това е таблица определяща пълнотата на проследяване на релациите м/у няколко тест кейса и версиите. Едно нещо може да го има в една версия, във следващата да се добави друго и т.н, а също така и дали имат нещо общо помежду си, дали са свързани и така ако някой feature се премахне може да се проследи какви евентуални проблеми могат да настъпят и от коя версия биха се появили те.
Status – pass/fail – дали самият тест е минал успешно или се е провалил.
notes/comments – бележки и коментари
Като не е нужно всички те да се използват. Може и да се добавят и Defect ID/Link – препратка към дефектно ID или към log-а и Automation? (Yes/No) – Като така може да се види дали тестването е било автоматизирано или не.
Надявам се придоби представа какво е то кейс и как изглежда, както и какъв е препоръчителният формат на самия кейс – ID, дата, име на тестър, какво ни трябва, какво очакваме и т.н.
