Какво е тест кейс?

+5 гласа
2,497 прегледа
попитан 2016 май 18 в Тестване на софтуер от Kalina.Mincheva. (1,330 точки)
Някой може ли да ми даде пример за тест кейс? Чета в книгите, но имам нужда от нещо на разбираем език и ако може с добър пример. Благодаря предварително!

1 отговор

+1 глас
отговорени 2016 май 19 от Daniel Ivanov (11,160 точки)
избран 2016 май 20 от Mitko Vasilev
 
Най-добър отговор
Тест кейс (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, дата, име на тестър, какво ни трябва, какво очакваме и т.н.
...