how write test cases
В този задълбочен практически урок за това как да се пишат тестови случаи, аз разгледах подробностите за това какво е тестово дело, неговата стандартна дефиниция и техники за проектиране на тестови казуси.
Какво е тест?
Тестовият случай има компоненти, които описват въвеждане, действие и очакван отговор, за да се определи дали дадена функция на приложение работи правилно.
Тестовият случай е набор от инструкции за „КАК“ за валидиране на определена цел / цел на теста, които, когато бъдат следвани, ще ни кажат дали очакваното поведение на системата е удовлетворено или не.
Списък с уроци, включени в тази серия за писане на тестови случаи:
Как да пиша:
Урок # 1: Какво е тестово дело и как се пишат тестови случаи (този урок)
Урок # 2: Примерен шаблон за тестов пример с примери (Изтегляне) (трябва да се прочете)
Урок № 3: Писане на тестови случаи от SRS документ
Урок № 4: Как да напиша тестови случаи за даден сценарий
Урок № 5: Как да се подготвите за писане на тестови казуси
Урок # 6: Как да пиша отрицателни тестови случаи
Примери:
Урок № 7: 180+ примерни тестови случая за уеб и настолни приложения
Урок № 8: 100+ готови за изпълнение тестови сценарии (контролен списък)
Техники на писане:
Урок № 9: Графика за причините и последиците - Техника за писане на динамични тестови случаи
Урок № 10: Техника за държавно преходно изпитване
Урок # 11: Техника за тестване на ортогонален масив
Урок # 12: Техника за отчитане на грешки
Урок № 13: Техника за проектиране на теста за проверка на полевата таблица (FVT)
Тестови случаи срещу тестови сценарии:
Урок # 14: Тестови случаи срещу тестови сценарии
Урок # 15: Разлика между тестовия план, тестовата стратегия и тестовия случай
Автоматизация:
Урок # 16: Как да изберем правилни тестови случаи за тестване за автоматизация
Урок # 17: Как да превеждам ръчни тестови случаи в скриптове за автоматизация
Инструменти за управление на тестове:
Урок # 18: Най-добрите инструменти за управление на тестове
Урок № 19: TestLink за управление на тестови случаи
Урок № 20: Създаване и управление на тестови случаи с помощта на HP Quality Center
Урок # 21: Изпълнение на тестови случаи с използване на ALM / QC
Специфични за домейн случаи:
Урок # 22: Тестови случаи за ERP приложение
Урок № 23: JAVA Приложни тестови случаи
Урок # 24: Анализ на гранична стойност и разделяне на еквивалентност
Нека да продължим с първия урок от тази поредица.
Препоръчани инструменти:
Преди да продължите с процеса на писане на тестови случаи, препоръчваме да изтеглите този инструмент за управление на тестови случаи. Това ще улесни процеса на писане на тестови случаи, споменат в този урок:
# 1) TestRail
=> Изтеглете TestRail Tool Test Management Tool
# 2) TestMonitor
Онлайн управление на тестове от най-високо ниво. Революционно лесно.
TestMonitor е цялостен инструмент за управление на тестове за всяка организация. Прост, интуитивен подход към тестването. Независимо дали внедрявате корпоративен софтуер, имате нужда от QA, създавате качествено приложение или просто се нуждаете от помощ в тестовия си проект, TestMonitor ви покрива.
=> Посетете уебсайта TestMonitor
Какво ще научите:
- Какво е тестово дело и как се пишат тестови случаи?
- Съвети за писане на тестове
- Как да постигна върхови постижения в документацията за тестови случаи
- Полезни съвети и трикове
- # 1) Дали вашият тестов документ е в добра форма?
- # 2) Не забравяйте да покриете отрицателните случаи
- # 3) Имайте атомни тестови стъпки
- # 4) Приоритизирайте тестовете
- # 5) Последователност има значение
- # 6) Добавете клеймо за време и име на тестера към коментарите
- # 7) Включете подробности за браузъра
- # 8) Съхранявайте два отделни листа - „Грешки“ и „Резюме“ в документа
- Полезни съвети и трикове
- Как да НЕ пиша тестове
- Как да подобрим ефективността на тестовите случаи
- Значение на стандартизирането на тестовите случаи
Какво е тестово дело и как се пишат тестови случаи?
Писането на ефективни казуси е умение. И можете да го научите от опита и познанията на тестваното приложение.
За основни инструкции как да пишете тестове, моля, проверете следното видео:
Горните ресурси трябва да ни дадат основите на процеса на писане на тестове.
Нива на процеса на изпитване:
- Ниво 1: На това ниво ще напишете основни случаи от наличната спецификация и потребителска документация.
- Ниво 2: Това е практически етап в които случаите на писане зависят от действителния функционален и системен поток на приложението.
- Ниво 3: Това е етапът, в който ще групирате някои случаи и напишете тестова процедура . Тестовата процедура не е нищо друго освен група малки случаи, може би максимум 10.
- Ниво 4: Автоматизация на проекта. Това ще сведе до минимум човешкото взаимодействие със системата и по този начин QA може да се съсредоточи върху актуализираните в момента функционалности за тестване, вместо да остане зает с тестване на регресия.
Защо пишем тестове?
Основната цел на писането на казуси е за валидиране на тестовото покритие на приложение.
Ако работите в която и да е организация CMMi, тогава тестовите стандарти се следват по-отблизо. Писането на казуси носи някакъв вид стандартизация и минимизира ad hoc подхода при тестване.
Как да пиша тестови случаи?
Полета:
- Идент
- Единица за тестване: Какво да бъде проверено?
- Предположения
- Данни от теста: Променливи и техните стойности
- Стъпки за изпълнение
- очакван резултат
- Действителен резултат
- Pass / Fail
- Коментари
Основен формат на изложението на тестовия случай
Проверете
Използвайки (име на инструмент, име на етикет, диалогов прозорец и др.)
С (условия)
Да се (какво се връща, показва, демонстрира)
Проверете: Използва се като първата дума от тестовото твърдение.
Използвайки: За да се идентифицира какво се тества. Можете да използвате ‘влизане’ или ‘избор’ тук, вместо да използвате в зависимост от ситуацията.
За всяко приложение трябва да покриете всички видове тестове като:
- Функционални случаи
- Отрицателни случаи
- Случаи на гранична стойност
Докато пишете тези всички ваши TC трябва да са прости и лесни за разбиране .
**************************************************
Съвети за писане на тестове
Една от най-честите и основни дейности на софтуерния тестер (SQA / SQC лице) е да пише тестови сценарии и случаи.
Има някои важни и критични фактори, които са свързани с тази основна дейност. Нека първо да видим птичи поглед върху тези фактори.
Важни фактори, свързани с процеса на писане:
а) ТК са склонни към редовна ревизия и актуализация:
Живеем в непрекъснато променящ се свят и същото важи и за софтуера. Софтуерните изисквания се отразяват пряко върху случаите. Винаги, когато изискванията се променят, TC трябва да се актуализират.
И все пак не само промяната в изискването може да доведе до преразглеждане и актуализиране на ТК. По време на изпълнението на ТК възникват много идеи в съзнанието и могат да бъдат идентифицирани много под-условия на един ТК. Всичко това води до актуализация на TC и понякога дори води до добавяне на нови TC.
Освен това, по време на регресионно тестване, няколко поправки и / или пулсации изискват ревизирани или нови TC.
б) ТК са склонни да се разпространяват между тестерите, които ще изпълнят тези:
Разбира се, едва ли има такава ситуация, при която един тестер да изпълни всички TC. Обикновено има няколко тестера, които тестват различни модули на едно приложение. Така че TC са разделени между тестерите според притежаваните от тях области на тестваното приложение.
Някои TC, свързани с интеграцията на приложение, могат да бъдат изпълнени от множество тестери, докато другите TC могат да бъдат изпълнени само от един тестер.
в) ТК са склонни към клъстериране и групиране:
Нормално и обичайно е, че ТК, принадлежащи към един тестов сценарий, обикновено изискват изпълнението им в някаква конкретна последователност или под формата на група. Може да има определени предпоставки за ТС, които изискват изпълнението на други ТС, преди да се стартира.
По същия начин, според бизнес логиката на AUT, един TC може да допринесе за няколко условия за изпитване, а едно условие за тест може да се състои от множество TC.
г) ТК имат тенденция на взаимозависимост:
Това също е интересно и важно поведение на ТК, което означава, че те могат да бъдат взаимно зависими един от друг. От средни до големи приложения със сложна бизнес логика, тази тенденция е по-видима.
Най-ясната област на всяко приложение, където това поведение определено може да се наблюдава, е оперативната съвместимост между различни модули на едни и същи или дори различни приложения. Просто казано, навсякъде, където различните модули едно приложение или множество приложения са взаимно зависими, същото поведение се отразява и в TC.
д) ТК са склонни към разпространение сред разработчиците (особено в тестова среда за разработка):
Важен факт за TC е, че те не трябва да се използват само от тестерите. В нормалния случай, когато дадена грешка е отстранена от разработчиците, те косвено използват TC за отстраняване на проблема. По същия начин, ако се проследява разработената от теста разработка, тогава TCs се използват директно от разработчиците, за да се изгради тяхната логика и да се обхванат всички сценарии в техния код, които са адресирани от TC.
Съвети за писане на ефективни тестове:
Имайки предвид горните 5 фактора, ето няколко съвета за писане на ефективни TC.
Да започваме!!!
# 1) Нека бъде просто, но не твърде просто; направете го сложен, но не твърде сложен:
Това твърдение изглежда парадокс. Но, обещавам, че не е така. Дръжте всички стъпки на TCs атомни и точни. Споменете стъпките с правилната последователност и правилно картографиране към очакваните резултати. Тестовият случай трябва да бъде обясним сам по себе си и лесен за разбиране. Това искам да го направя просто.
Сега превръщането му в сложно означава да го интегрирате с плана за изпитване и други TC. Обърнете се към другите TC, съответните артефакти, GUI и т.н., когато и когато е необходимо. Но направете това по балансиран начин. Не правете тестер, за да се движите насам-натам в купчината документи за попълване на един сценарий на тест.
От друга страна, дори не позволявайте на тестера да документира тези TC по много компактен начин. Докато пишете TC, винаги помнете, че вие или някой друг ще трябва да ги преразгледате и актуализирате.
# 2) След документиране на тестовите случаи, прегледайте веднъж като тестер:
Никога не си мислете, че работата е свършена, след като сте написали последния TC от тестовия сценарий. Отидете в началото и прегледайте веднъж всички TC, но не с мисленето на писател на TC или планиращ тестване. Прегледайте всички TC с мисълта на тестера. Мислете рационално и се опитайте да стартирате вашите TC.
Оценете всички стъпки и вижте дали сте ги споменали ясно по разбираем начин и очакваните резултати са в хармония с тези стъпки.
Уверете се, че данни от теста посочен в TCs е осъществим не само за действителните тестери, но също така е в съответствие с обстановката в реално време. Уверете се, че няма конфликт на зависимост между TC и проверете дали всички препратки към други TC / артефакти / GUI са точни. В противен случай тестерите може да имат големи проблеми.
# 3) Обвързване, както и облекчаване на тестерите:
Не оставяйте тестовите данни на тестери. Дайте им набор от входни данни, особено когато трябва да се извършват изчисления или поведението на приложението зависи от входните данни. Можете да им позволите да решат стойностите на тестовите данни, но никога да не им давате свободата сами да избират тестовите данни.
Тъй като, умишлено или неволно, те могат да използват едни и същи тестови данни отново и отново и някои важни тестови данни могат да бъдат игнорирани по време на изпълнението на TC.
Поддържайте тестерите спокойни, като организирате ТК според категориите за тестване и свързаните области на приложение. Ясно, инструктирайте и споменете кои TC са взаимно зависими и / или групирани. По същия начин изрично посочете кои TC са независими и изолирани, така че тестващият да може да управлява съответно цялостната си дейност.
В този момент може да ви е интересно да прочетете за анализа на граничната стойност, който е стратегия за проектиране на тестови случаи, която се използва при тестване на черна кутия. Щракнете тук за да научите повече за него.
# 4) Бъдете сътрудник:
Никога не приемайте FS или документа за проектиране такъв, какъвто е. Вашата работа не е просто да преминете през FS и да идентифицирате тестовите сценарии. Като QA ресурс, никога не се колебайте да допринесете за бизнеса и да давате предложения, ако смятате, че нещо може да се подобри в приложението.
Предложете и на разработчиците, особено в среда за разработка, управлявана от TC. Предложете падащи списъци, контроли на календара, списък за избор, групови радио бутони, по-смислени съобщения, предупреждения, подкани, подобрения, свързани с използваемостта и т.н.
Като QA, не просто тествайте, но направете разлика!
# 5) Никога не забравяйте крайния потребител:
Най-важният участник е „Крайният потребител“, който най-накрая ще използва приложението. Така че, никога не го забравяйте на който и да е етап от писането на специалисти. Всъщност Крайният потребител не трябва да бъде пренебрегван на всеки етап от SDLC. И все пак акцентът ми до момента е просто свързан с темата ми.
Така че, по време на идентифицирането на тестови сценарии, никога не пренебрегвайте онези случаи, които ще бъдат използвани най-вече от потребителя, или случаите, които са от критично значение за бизнеса, дори ако са по-рядко използвани. Останете на мястото на Крайния потребител и след това преминете през всички TC и преценете практическата стойност на изпълнението на всичките ви документирани TC.
**************************************************
Как да постигна върхови постижения в документацията за тестови случаи
Като софтуерен тестер, вие със сигурност ще се съгласите с мен, че изготвянето на перфектен тестов документ е наистина предизвикателна задача.
Винаги оставяме малко възможности за подобрение в нашата Документация на тестовия случай . Понякога не можем да осигурим 100% покритие на теста чрез ТС, а понякога шаблонът на теста не е на ниво или липсва добра четливост и яснота на нашите тестове.
Като тестер, всеки път, когато бъдете помолени да напишете тестова документация, не просто стартирайте по ad hoc начин. Много е важно да разберете целта на написването на тестови казуси много преди да започнете да работите по документацията.
Тестовете винаги трябва да са ясни и ясни. Те трябва да бъдат написани по начин, който предлага на тестера лесно да проведе цялостното тестване, като следва стъпките, определени във всеки от тестовете.
Освен това документът за тестовия случай трябва да съдържа толкова случаи, колкото е необходимо, за да се предоставят пълни покритие на теста . Например , трябва да се опитате да обхванете тестването за всички възможни сценарии, които могат да възникнат във вашето софтуерно приложение.
Имайки предвид горните точки, нека сега ви преведа през обиколка за това как да постигнете върхови постижения в тестовата документация.
Полезни съвети и трикове
Тук ще ви дам някои полезни насоки, които могат да ви дадат крачка в документацията за теста от останалите.
# 1) Дали вашият тестов документ е в добра форма?
Най-добрият и лесен начин да организирате своя тестов документ е като го разделите на много полезни раздели. Разделете цялото тестване на множество тестови сценарии. След това разделете всеки сценарий на множество тестове. И накрая, разделете всеки случай на няколко тестови стъпки.
Ако използвате Excel, тогава документирайте всеки тестов случай на отделен лист от работната книга, където всеки тестов случай описва един пълен тестов поток.
# 2) Не забравяйте да покриете отрицателните случаи
Като тестер на софтуер, трябва да мислите нестандартно и да начертаете всички възможности, с които се намира вашето приложение. Ние, като тестери, трябва да проверим дали всеки неаутентичен опит за влизане в софтуера или някакви невалидни данни, които да преминават през приложението, трябва да бъдат спрени и докладвани.
По този начин отрицателният случай е толкова важен, колкото и положителният случай. Уверете се, че за всеки сценарий, който имате два тестови случая - един положителен и един отрицателен . Положителният трябва да покрива предвидения или нормалния поток, а отрицателният - неволния или извънредния поток.
# 3) Имайте атомни тестови стъпки
Всяка тестова стъпка трябва да бъде атомна. Не трябва да има допълнителни под-стъпки. Колкото по-опростена и ясна е тестовата стъпка, толкова по-лесно би било да продължите с тестването.
# 4) Приоритизирайте тестовете
Често имаме строги срокове, за да завършим тестването за приложение. В този случай може да пропуснем тестване на някои от важните функционалности и аспекти на софтуера. За да избегнете това, трябва да маркирате приоритет с всеки тест, докато го документирате.
Можете да използвате всяко кодиране за определяне на приоритета на теста. Като цяло е по-добре да използвате някое от трите нива, висока, средна и ниска , или 1, 50 и 100. Така че, когато имате строг график, трябва първо да попълните всички тестове с висок приоритет и след това да преминете към тестове със среден и нисък приоритет.
Например - за уебсайт за пазаруване проверката на отказа за достъп за невалиден опит за влизане в приложението може да бъде случай с висок приоритет, проверката на показването на съответните продукти на потребителския екран може да бъде случай със среден приоритет и проверка на цвета на текста, показан на екранните бутони могат да бъдат тест с нисък приоритет.
# 5) Последователност има значение
Потвърдете дали последователността от стъпки в теста е абсолютно правилна. Грешната последователност от стъпки може да доведе до объркване. За предпочитане стъпките трябва също да определят цялата последователност от влизане в приложението до излизане от приложението за определен сценарий, който се тества.
# 6) Добавете клеймо за време и име на тестера към коментарите
Може да има случай, в който тествате приложение, някой прави модификации паралелно на същото приложение или някой може да актуализира приложението, след като тестването ви приключи. Това води до ситуация, при която резултатите от теста ви могат да варират във времето.
Така че, винаги е по-добре да добавите отметка за време с името на тестера в коментарите за тестване, така че резултатът от теста (преминаване или неуспех) да може да бъде приписан на състоянието на приложението по това време. Като алтернатива можете да получите „ Дата на изпълнение “, Добавена отделно към тестовия случай, която изрично ще идентифицира времевия печат на теста.
# 7) Включете подробности за браузъра
Както знаете, ако това е уеб приложение, резултатите от теста могат да се различават в зависимост от браузъра, на който се изпълнява тестът. За улеснение на други тестери, разработчици или който преглежда тестовия документ, трябва да добавите името и версията на браузъра към случая, за да може дефектът да бъде репликиран лесно.
# 8) Съхранявайте два отделни листа - „Грешки“ и „Резюме“ в документа
Ако документирате в ексел, първите два листа на работната книга трябва да бъдат Резюме и Грешки. Обобщеният лист трябва да обобщи тестовия сценарий, а листът за грешки трябва да изброи всички проблеми, срещани по време на тестването. Значението на добавянето на тези два листа е, че ще даде ясно разбиране за тестването на читателя / потребителя на документа.
Така че, когато времето е ограничено, тези два листа могат да се окажат много полезни за предоставяне на общ преглед на тестването.
Тестовият документ трябва да осигурява възможно най-доброто покритие на теста, отлична четливост и трябва да следва един стандартен формат през цялото време.
Можем да постигнем върхови постижения в тестовата документация, като имаме предвид само няколко важни съвета, като организирането на документа на тестовия случай, като приоритизираме ТС, разполагаме с всичко в правилната последователност, включително всички задължителни подробности за изпълнение на ТК, и предоставяме ясни и ясни тестови стъпки, и т.н., както е обсъдено по-горе.
**************************************************
Как да НЕ пиша тестове
Прекарваме по-голямата част от времето си в писане, преглед, изпълнение или поддържане на тези. Доста жалко, че тестовете са и най-податливите на грешки. Разликите в разбирането, практиките на организационното тестване, липсата на време и т.н. са някои от причините, поради които често виждаме тестове, които оставят много да се желае.
На нашия сайт има много статии по тази тема, но тук ще видим Как да НЕ се пишат тестови случаи - няколко съвета, които ще помогнат за създаването на отличителни, качествени и ефективни тестове.
Нека да прочетем и да отбележим, че тези съвети са както за нови, така и за опитни изпитатели.
3 Най-често срещани проблеми в тестовите случаи
- Композитни стъпки
- Поведението на приложението се приема като очаквано поведение
- Множество условия в един случай
Тези три трябва да са в списъка ми с 3 най-често срещани проблема в процеса на писане на тестове.
Интересното е, че това се случва както с нови, така и с опитни тестери и ние просто продължаваме да следваме едни и същи дефектни процеси, без да осъзнаваме, че няколко прости мерки могат лесно да поправят нещата.
Нека да стигнем до него и да обсъдим всеки по-подробно:
# 1) Композитни стъпки
На първо място, какво е съставна стъпка?
Например, вие давате указания от точка А до точка Б: ако кажете, че „Отидете до мястото XYZ и след това до ABC“, това няма да има много смисъл, защото тук се оказваме, че мислим - „Как да стигнете до XYZ на първо място “- вместо това започнете с„ Завийте наляво оттук и отидете на 1 миля, след което завийте надясно по Rd. № 11 за пристигане в XYZ ”може да постигне по-добри резултати.
Абсолютно същите правила важат и за тестовете и стъпките му.
Например Пиша тест за Amazon.com - направете поръчка за всеки продукт.
По-долу са моите тестови стъпки (Забележка: Пиша само стъпките, а не всички останали части от теста, като очаквания резултат и т.н.)
да се . Стартирайте Amazon.com
б . Потърсете продукт, като въведете ключовата дума / име на продукта в полето „Търсене“ в горната част на екрана.
° С . От показаните резултати от търсенето изберете първия.
д . Кликнете върху Добавяне в кошницата на страницата с подробности за продукта.
е . Плащане и плащане.
е . Проверете страницата за потвърждение на поръчката.
Сега, можете ли да определите кое от тях е съставна стъпка? Надясно - Стъпка (д)
Не забравяйте, че тестовете винаги са свързани с „Как“ да тествате, така че е важно да напишете точните стъпки на „Как да платите и да платите“ във вашия тест.
Следователно горният случай е по-ефективен, когато е написан по-долу:
да се . Стартирайте Amazon.com
б . Потърсете продукт, като въведете ключовата дума / име на продукта в полето „Търсене“ в горната част на екрана.
° С . От показаните резултати от търсенето изберете първия.
д . Кликнете върху Добавяне в кошницата на страницата с подробности за продукта.
е . Кликнете върху Плащане в страницата на пазарската количка.
е . Въведете информация за CC, доставка и информация за фактуриране.
ж . Щракнете върху Плащане.
з . Проверете страницата за потвърждение на поръчката.
Следователно съставна стъпка е тази, която може да бъде разделена на няколко отделни стъпки. Следващия път, когато пишем тестове, нека всички обърнем внимание на тази част и съм сигурен, че ще се съгласите с мен, че правим това по-често, отколкото осъзнаваме.
# 2) Поведението на приложението се приема като очаквано поведение
Все повече проекти трябва да се справят с тази ситуация в наши дни.
най-доброто място за гледане на безплатни аниме
Липсата на документация, екстремно програмиране, бързи цикли на разработка са малко причини, които ни принуждават да разчитаме на приложението (по-стара версия или така) или да напишем тестовете, или да базираме самото тестване. Както винаги, това е доказана лоша практика - не винаги наистина.
Безобидно е, стига да запазите отворен ум и да запазите очакването, че - „AUT може да бъде сгрешен“. Едва когато не мислите, че е така, нещата работят зле. Както винаги, ще оставим примерите да говорят.
Ако следното е страницата, за която пишете / проектирате стъпките за тестване:
Случай 1:
Ако стъпките ми за тестов случай са както по-долу:
- Стартирайте сайта за пазаруване.
- Щракнете върху Доставка и връщане - Очакван резултат: Страницата за доставка и връщане се показва с „Поставете информацията си тук“ и бутон „Напред“.
Тогава това е неправилно.
Случай 2:
- Стартирайте сайта за пазаруване.
- Кликнете върху Доставка и връщане.
- В текстовото поле ‘Въведете номер на поръчката’, налично на този екран, въведете номер на поръчката.
- Щракнете върху Напред - Очакван резултат: Показват се подробностите за поръчката, свързани с доставката и връщанията.
Случаят 2 е по-добър тестов случай, тъй като въпреки че референтното приложение се държи неправилно, ние го приемаме само като насока, правим допълнителни изследвания и записваме очакваното поведение според очакваната правилна функционалност.
Долен ред: Приложението като справка е бърз пряк път, но идва със собствени опасности. Докато сме внимателни и критични, това води до невероятни резултати.
# 3) Множество условия в един случай
Още веднъж, нека се учим от Пример .
Обърнете внимание на стъпките по-долу за тестване: По-долу са тестовите стъпки в рамките на един тест за функция за вход.
а. Въведете валидни данни и щракнете върху Изпращане.
б. Оставете полето за потребителско име празно. Щракнете върху Изпращане.
° С. Оставете полето за парола празно и щракнете върху Изпращане.
д. Изберете вече влезли потребителско име / парола и щракнете върху Изпращане.
Това, което трябваше да бъдат 4 различни случая, се комбинира в едно. Може би си мислите - Какво лошо има в това? Спестява много документация и това, което мога да направя в 4, правя го в 1- не е ли чудесно? Е, не съвсем. Причини?
Прочетете на:
- Ами ако едно от условията не успее - трябва да отбележим целия тест като „неуспешен“. Ако маркираме целия случай „неуспешно“, това означава, че и четирите условия не работят, което всъщност не е вярно.
- Тестовете трябва да имат поток. От предварително условие до стъпка 1 и всичко през стъпките. Ако следвам този случай, в стъпка (а), ако е успешен, ще бъда влязъл на страницата, където опцията „вход“ вече не е налична. И така, когато стигна до стъпка (b) - къде тестващият ще въведе потребителското име? Виждате ли, потокът е нарушен.
Следователно, напишете модулни тестове . Звучи като много работа, но всичко, което ви е необходимо, е да разделите нещата и да използвате най-добрите ни приятели Ctrl + C и Ctrl + V, за да работите за нас. :)
**************************************************
Как да подобрим ефективността на тестовите случаи
Софтуерните тестери трябва да пишат тестовете си от по-ранния етап от жизнения цикъл на софтуера, най-добре по време на фазата на софтуерните изисквания.
Ръководителят на тестове или QA мениджър трябва да събере и подготви максимално възможните документи съгласно списъка по-долу.
Колекция от документи за изпитване
# 1) Документ за потребителски изисквания
Това е документ, който изброява бизнес процеса, потребителските профили, потребителската среда, взаимодействието с други системи, подмяната на съществуващи системи, функционалните изисквания, нефункционалните изисквания, изискванията за лицензиране и инсталиране, изискванията за производителност, изискванията за сигурност, използваемостта и паралелните изисквания и т.н. .,
# 2) Документ за делови случаи
Този документ описва подробно случай на употреба сценарий на функционалните изисквания от гледна точка на бизнеса. Този документ обхваща бизнес участниците (или системата), цели, предварителни условия, последващи условия, основен поток, алтернативен поток, опции, изключения от всеки бизнес поток на системата според изискванията.
# 3) Документ за функционални изисквания
Този документ описва подробно функционалните изисквания на всяка функция за системата според изискванията.
Обикновено документът за функционални изисквания служи като общо хранилище както за екипа за разработка и тестване, така и за заинтересованите страни по проекта, включително клиентите за ангажираните (понякога замразени) изисквания, които трябва да се третират като най-важния документ за всяка разработка на софтуер.
# 4) План за софтуерен проект (по избор)
Документ, който описва подробности за проекта, цели, приоритети, етапи, дейности, организационна структура, стратегия, мониторинг на напредъка, анализ на риска, предположения, зависимости, ограничения, изисквания за обучение, отговорности на клиентите, график на проекта и т.н.,
# 5) QA / План за тестване
Този документ подробно описва системата за управление на качеството, стандартите за документация, механизма за контрол на промените, критичните модули и функционалности, системата за управление на конфигурацията, плановете за тестване, проследяването на дефекти, критериите за приемане и т.н.
The план за изпитване документът се използва за идентифициране на функциите, които трябва да бъдат тествани, функции, които не трябва да бъдат тествани, разпределение на екипи за тестване и техния интерфейс, изисквания за ресурси, график на тестване, писане на тестове, покритие на теста, тестови резултати, предпоставка за изпълнение на теста, докладване на грешки и проследяване механизъм, тестови показатели и т.н.,
Истински пример
Нека да видим как да напишем ефективно тестови случаи за познат и прост екран „Вход“, както е показано на фигурата по-долу. The подход на тестване ще бъде почти еднакъв дори за сложни екрани с повече информация и критични функции.
# 1) Първият подход за всеки процес на тестов случай ще бъде да се получи прототип на екрана (или телени рамки), както е посочено по-горе, ако е наличен. Това може да не е налично за някои от функционалностите и зависи от критичността на проектирането на прототип в по-ранните етапи на разработване.
Но ако SRS Документ (Спецификация на софтуерните изисквания) е на разположение за проекта, повечето от прототипите на екрана са разработени от екипа на проекта. Този вид екран опростява работата на тестера и повишава ефективността на тестовете.
# две) След това спецификации за функционални изисквания . Зависи от организационния процес, той ще бъде достъпен в набор от множество документи.
Така че, решете най-добрия документ за писане на казуси, или той може да бъде документ за потребителски изисквания или функционални спецификации изисквания (или дори SRS документ, ако може да бъде разбираем удобно от екипа за тестване), който ще даде пълен функционален поток на избрания функция, която ще бъде тествана.
# 3) След като прототипът на екрана и функционалните спецификации са на място, тестерът трябва да започне да пише случаите със следния подход и критерии.
- Потребителски тестове :Контролите / полетата, които са видими за потребителя. Налични са статичен контрол и динамични контроли за функцията, която ще бъде тествана. Например, в горния екран за вход текстовете „Потребителско име и парола“ са статични полета, които не изискват никакво потребителско взаимодействие, само за показване на текста.
- Функционални случаи :От друга страна, бутонът за вход и хипервръзките (Забравена парола? & Регистрация) са динамични полета, които изискват потребителско взаимодействие чрез щракване върху контролите, които след това ще извършат някакво действие.
- Случаи на база данни :След като потребителят въведе потребителското име и паролата, тестовете могат да бъдат написани, за да се провери свързаната база данни за това дали потребителското име и паролата са проверени в правилната база данни и таблицата и дали потребителят има разрешение да влезе в тестваното приложение.
- Тестове на процеса :Това е свързано с процеса (а не с действията, свързани с видимите контроли на разположение на екрана), свързани с характеристиката и функционалността. Например, щракването върху връзката Забравена парола в горния примерен екран може да изпрати имейл до потребителя. Така че, може би имейл трябва да бъде тестван за правилния процес и потвърждение.
4) И накрая, запазете „ BAOE мантра ”, Означава i) Основен поток ii) Алтернативен поток iii) Опции и iv) Изключения за пълното покритие на функционалния поток и характеристика, която ще бъде тествана. Всяка концепция трябва да се прилага за положителни и отрицателни тестове.
Например, нека видим простия подход BAOE за примерния екран за вход по-горе.
- Основен поток: Въведете пътя на URL адреса за вход във всеки браузър и въведете необходимата информация и влезте в приложението.
- Алтернативен поток: Инсталирайте приложението на мобилно устройство и въведете необходимата информация и влезте в приложението.
- Настроики: Какви са възможностите за достъп до същия екран за вход? Например, след влизане в приложението, щракването върху „Изход“ може да доведе до същия екран или ако времето за изчакване на сесията или сесията изтече, потребителят може да дойде на екрана за вход.
- Изключения: Какви са изключенията, ако тестовете ми са отрицателни? Например, ако в екрана за вход се въведат грешни идентификационни данни, дали потребителят ще получи съобщение за грешка или няма свързано действие.
С цялата тази информация в ръка, нека започнем да пишем TC за екрана за вход, във формат с пълното покритие и проследимост и с подробна информация. Логическата последователност и номериране на идентифицирането на „ Идент. № на тестовия случай “ ще бъде много полезно за бърза история на изпълнение на тестови случаи.
Прочетете също=> 180+ проби, готови за използване на тестови случаи за уеб и настолни приложения.
Документ за тест
Забележка : Тестовите колони не се ограничават до примерния тестов документ по-долу, който може да се поддържа в Excel лист, за да има толкова колони, колкото е необходимо за пълна матрица за проследяване, а именно, приоритет, цел на тестване, вид на тестване, местоположение на екранна снимка и т.н.,
Прочетете също=> Примерен шаблон за тестов пример с примери.
За улеснение на простотата и четливостта на този документ, нека напишем подробно стъпките за възпроизвеждане, очакваното и действителното поведение на тестовете за екрана за вход по-долу.
Забележка : Добавете колона „Действително поведение“ в края на този шаблон.
Не. | Стъпки за възпроизвеждане | Очаквано поведение |
---|---|---|
7. | Щракнете върху връзката за регистрация | Кликването върху връзката трябва да отведе потребителя до съответния екран. |
1. | Отворете браузър и въведете URL за екрана за вход. | Трябва да се покаже екранът за влизане. |
2. | Инсталирайте приложението в телефона с Android и го отворете. | Трябва да се покаже екранът за влизане. |
3. | Отворете екрана за вход и проверете наличните текстове правилно написани. | Текстът „Потребителско име“ и „Парола“ трябва да се покаже преди свързаното текстово поле. Бутонът за вход трябва да има надпис „Вход“. „Забравена парола?“ И „Регистрация“ трябва да са достъпни като връзки. |
Четири. | Въведете текста в полето Потребителско име. | Текстът може да се въведе чрез щракване с мишката или фокус с помощта на раздела. |
5. | Въведете текста в полето за парола. | Текстът може да се въведе чрез щракване с мишката или фокус с помощта на раздела. |
6. | Щракнете върху Забравена парола? Връзка. | Кликването върху връзката трябва да отведе потребителя до съответния екран. |
8. | Въведете потребителското име и паролата и щракнете върху бутона Вход. | Кликването върху бутона за вход трябва да отвори съответния екран или приложение. |
9. | Отидете до базата данни и проверете дали правилното име на таблица е потвърдено спрямо входните идентификационни данни. | Името на таблицата трябва да бъде проверено и да бъде актуализиран флаг за състояние за успешно или неуспешно влизане. |
10. | Щракнете върху Login без да въвеждате текст в полетата User Name и Password. | Щракнете върху бутона Вход, за да предупредите съобщение „Потребителско име и парола са задължителни“. |
единадесет. | Щракнете върху Login без да въвеждате текст в полето User Name, а да въвеждате текст в полето Password. | Щракнете върху бутона Вход, за да предупредите съобщение в полето „Паролата е задължителна“. |
12. | Щракнете върху Login без да въвеждате текст в полето Password, а да въвеждате текст в полето User Name. | Щракнете върху бутона Вход, за да предупредите съобщение в полето „Потребителското име е задължително“. |
13. | Въведете максимално разрешения текст в полетата Потребителско име и парола. | Трябва да приеме максимално позволените 30 знака. |
14. | Въведете потребителско име и парола, като започнете със специалните знаци. | Не трябва да приема текста, започващ със специални знаци, което не е разрешено при регистрация. |
петнадесет. | Въведете потребителско име и парола, започвайки с празни интервали. | Не трябва да приема текста с празни интервали, което не е разрешено при регистрация. |
16. | Въведете текста в полето за парола. | Не трябва да показва действителния текст, вместо да показва звездичка *. |
17. | Обновете страницата за вход. | Страницата трябва да се освежи, като полетата за потребителско име и парола са празни. |
18. | Въведете потребителското име. | В зависимост от настройките за автоматично попълване в браузъра, предварително въведените имена на потребители трябва да се показват като падащо меню. |
19. | Въведете паролата. | В зависимост от настройките за автоматично попълване на браузъра, предварително въведените пароли НЕ трябва да се показват като падащо меню. |
двайсет. | Преместете фокуса към връзката Забравена парола, като използвате Tab. | Както щракването с мишката, така и клавишът за въвеждане трябва да могат да се използват |
двадесет и едно. | Преместете фокуса към връзката Регистрация, като използвате Tab. | Както щракването с мишката, така и клавишът за въвеждане трябва да бъдат използваеми. |
22. | Опреснете страницата за вход и натиснете клавиша Enter. | Бутонът за влизане трябва да бъде фокусиран и съответното действие трябва да бъде задействано. |
2. 3. | Опреснете страницата за вход и натиснете клавиша Tab. | Първият фокус в екрана за вход трябва да бъде полето User Name. |
24. | Въведете потребителя и паролата и оставете страницата за вход неактивна за 10 минути. | Сигналът в полето за съобщение „Сесията е изтекла, въведете потребителско име и парола отново“ трябва да се покаже с изчистени и двете полета за потребителско име и парола. |
25. | Въведете URL за вход в браузърите Chrome, Firefox и Internet Explorer. | Екранът за един и същ вход трябва да се показва без особени отклонения във външния вид и усещането и подравняването на контролите за текст и формуляр. |
26. | Въведете идентификационните данни за вход и проверете активността за влизане в браузърите Chrome, Firefox и Internet Explorer. | Действието на бутона за вход трябва да бъде едно и също във всички браузъри. |
27. | Проверете дали връзката Забравена парола и регистрация не е нарушена в браузърите Chrome, Firefox и Internet Explorer. | И двете връзки трябва да водят до съответните екрани във всички браузъри. |
28. | Проверете дали функционалността за влизане работи правилно в мобилните телефони с Android. | Функцията за влизане трябва да работи по същия начин, както е налична в уеб версията. |
29. | Проверете дали функцията за влизане работи правилно в Tab и iPhone. | Функцията за влизане трябва да работи по същия начин, както е налична в уеб версията. |
30. | Проверете екрана за влизане позволява едновременните потребители на системата и всички потребители получават екрана за вход без забавяне и в рамките на определеното време от 5-10 секунди. | Това трябва да се постигне с помощта на много комбинации от операционна система и браузъри, физически или виртуално, или може да се постигне с помощта на някакъв инструмент за тестване на производителността / натоварването. |
Събиране на тестови данни
Когато се пише тестовият случай, най-важната задача за всеки тестер е да събере данните от теста. Тази дейност се пропуска и пренебрегва от много тестери с предположението, че тестовите случаи могат да бъдат изпълнени с някои примерни данни или фиктивни данни и могат да бъдат подадени, когато данните наистина се изискват. Това е критично погрешно схващане, че подаването на примерни данни или входни данни от паметта на ума по време на изпълнение на тестови случаи.
Ако данните не бъдат събрани и актуализирани в тестовия документ по време на писането на тестовете, тестерът ще прекара необичайно повече време за събиране на данните по време на изпълнението на теста. Данните от теста трябва да се събират както за положителни, така и за отрицателни случаи от цялата гледна точка на функционалния поток на характеристиката. Документът за бизнес употреба е много полезен в тази ситуация.
Намерете примерен документ с тестови данни за тестовете, написани по-горе, което от своя страна ще бъде полезно за това колко ефективно можем да събираме данните, които ще улеснят работата ни по време на изпълнението на теста.
да не | Цел на тестовите данни | Действителни данни от теста |
---|---|---|
7. | Тествайте потребителското име и парола с всички малки знаци | администратор (admin2015) |
1. | Тествайте правилното потребителско име и парола | Администратор (admin2015) |
2. | Тествайте максималната дължина на потребителско име и парола | Администратор на основната система (admin2015admin2015admin2015admin) |
3. | Тествайте празните места за потребителско име и парола | Въведете празни интервали, като използвате клавиша за интервал за потребителско име и парола |
Четири. | Тествайте неправилното потребителско име и парола | Администратор (активиран) (digx ## $ taxk209) |
5. | Тествайте потребителското име и парола с неконтролирани интервали между. | Admin istrator (администратор 2015) |
6. | Тествайте потребителското име и парола, започвайки със специални знаци | $% # @ # $ Администратор (% # * # ** # администратор) |
8. | Тествайте потребителското име и парола с всички главни символи | АДМИНИСТРАТОР (АДМИНИСТРАТОР 2015) |
9. | Тествайте Вход с едно и също потребителско име и парола едновременно с множество системи. | Администратор (admin2015) - за Chrome в една и съща машина и различна машина с операционна система Windows XP, Windows 7, Windows 8 и Windows Server. Администратор (admin2015) - за Firefox в една и съща машина и различна машина с операционна система Windows XP, Windows 7, Windows 8 и Windows Server. Администратор (admin2015) - за Internet Explorer в една и съща машина и различна машина с операционна система Windows XP, Windows 7, Windows 8 и Windows Server. |
10. | Тествайте Вход с потребителско име и парола в мобилното приложение. | Администратор (admin2015) - за Safari и Opera в мобилни телефони Android, iPhone и таблети. |
**************************************************
Значение на стандартизирането на тестовите случаи
В този зает свят никой не може да прави повтарящи се неща всеки ден със същото ниво на интерес и енергия. Особено не ми е страстно да правя една и съща задача отново и отново на работа. Харесва ми да управлявам нещата и да спестявам време. Всеки в ИТ трябва да е такъв.
Всички ИТ компании изпълняват различни видове проекти. Тези проекти могат да бъдат базирани на продукти или услуги. От тези проекти повечето от тях работят около уебсайтове и тестване на уебсайт . Добрата новина за това е, че всички уебсайтове имат много прилики. И ако уебсайтовете са за един и същи домейн, те също имат няколко общи характеристики.
Въпросът, който винаги ме смущава, е следният: „Ако повечето приложения са сходни, например: като сайтове за търговия на дребно, които са били тествани хиляди пъти преди това,„ Защо трябва да пишем тестови случаи за още един сайт за търговия от нулата? ” Няма ли да спести много време, като извади съществуващите тестови скриптове, използвани за тестване на предишен сайт за търговия на дребно?
Разбира се, може да има някои малки ощипвания, които може да се наложи да направим, но като цяло е по-лесно, ефективно, спестява време и пари и по този начин винаги помага да се поддържат нивата на лихвите на тестерите. Кой обича да пише, преглежда и поддържа едни и същи случаи многократно, нали? Повторното използване на съществуващите тестове може да реши това до голяма степен и вашите клиенти също ще намерят това умно и логично.
Така че логично започнах да изтеглям съществуващите скриптове от подобни уеб-базирани проекти, направих промени и направих бърз преглед на тях. Също така използвах цветно кодиране, за да покажа направените промени, така че рецензентът може да се фокусира само върху частта, която е променена.
Причини за повторно използване на тестови случаи
# 1) Повечето функционални области на уебсайта са почти вход - регистрация, добавяне в кошницата, списък с желания, плащане, опции за доставка, опции за плащане, съдържание на страницата на продукта, наскоро разглеждани, подходящи продукти, промоционални кодове и т.н.
# две) Повечето от проектите са само подобрения или промени в съществуващата функционалност.
# 3) Системите за управление на съдържанието, които дефинират слотовете за качване на изображения със статични и динамични начини, също са общи за всички уебсайтове.
# 4) Уебсайтовете за търговия на дребно имат КСО Система (Обслужване на клиенти) също.
# 5) Backend система и складово приложение, използващо JDA, също се използват от всички уебсайтове.
# 6) Понятието бисквитки, времето за изчакване и сигурността също са често срещани.
# 7) Уеб-базираните проекти често са склонни към промени в изискванията.
# 8) The видове тестове необходими са често срещани като браузъра тестване на съвместимостта , тестване на производителността , тестване на сигурността
Виждате ли, има много общи и подобни неща.
След като казахме, че повторната употреба е пътят, понякога самите модификации могат или не могат да отнемат повече или по-малко време. Понякога човек може да почувства, че е по-добре да започне от нулата, отколкото да модифицира толкова много.
Това може лесно да бъде обработено чрез създаване на набор от стандартни тестови случаи за всяка от общите функционалности.
Какво е стандартен тест в уеб тестване?
- Създайте тестови случаи, които са завършени - стъпки, данни, променлива и т.н. Това ще гарантира, че не-подобни данни / променлива могат просто да бъдат заменени, когато се изисква подобен тестов случай.
- Критериите за вход и изход трябва да бъдат правилно дефинирани.
- Модифицируемите стъпки или изявлението в стъпките трябва да бъдат маркирани в различен цвят за бързо намиране и замяна.
- Езикът, използван за създаването на стандартен тестов случай, трябва да е общ.
- Всички характеристики на всеки уебсайт трябва да бъдат обхванати в тестовите случаи.
- Името на тестовите случаи трябва да бъде името на функционалността или характеристиката, която тестовият случай покрива. Това значително ще улесни намирането на тестовия случай от комплекта.
- Ако има някакъв основен или стандартен пример или GUI файл или екранна снимка на функцията, тогава тя трябва да бъде приложена със съответните стъпки.
Използвайки горните съвети, можете да създадете набор от стандартни скриптове и да ги използвате с малко или необходими модификации за различни уебсайтове.
Тези стандартни тестови случаи също могат да бъдат автоматизирани, но отново фокусирането върху повторната употреба винаги е плюс. Също така, ако автоматизация се основава на графичен интерфейс, повторното използване на скриптове в множество URL адреси или сайтове е нещо, което аз лично никога не намирах за ефективно.
Използването на стандартен набор от ръчни тестови случаи за различни уебсайтове с незначителни модификации е най-добрият начин за извършване на тестване на уебсайт. Всичко, от което се нуждаем, е да създадем и поддържаме тестовите случаи с подходящи стандарти и употреба.
Заключение
Подобряването на ефективността на тестовите случаи не е просто дефиниран термин, но е упражнение и може да бъде постигнато чрез зрял процес и редовна практика.
Екипът за тестване не трябва да се уморява да се включва в подобряването на такива задачи, тъй като това е най-добрият инструмент за по-големи постижения в света на качеството, това е доказано в много от тестващите организации по света за критични за мисия проекти и сложни приложения.
Надявам се, че бихте получили огромни познания по концепцията за тестови случаи. Гледайте нашата поредица от уроци, за да научите повече за тестовите случаи и не се колебайте да изразите мислите си в раздела за коментари по-долу!
Препоръчително четене
- Функционално тестване срещу нефункционално тестване
- Ръководство за тестване на преносимост с практически примери
- Видове тестване на софтуер: Различни видове тестване с подробности
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Алфа тестване и бета тестване (Пълно ръководство)
- Какво е системно тестване - Ръководство за крайни начинаещи
- ISTQB Тестване за сертифициране Примерни въпроси с отговори
- Как да напиша седмичен отчет за състоянието на тестване на софтуер