Тестов анализ и основи на тестването
Томас Хамилтън
⚡ Умно обобщение
Тестовият анализ, наричан още Тестова основа, е структуриран преглед на изисквания, проектни документи и други артефакти, използвани за извличане на тестваеми условия. Тази статия обяснява източниците, подробния работен процес и разположението на тестовия анализ във V-модела.
Тестовият анализ — известен още като тестова основа — се намира в самото начало на жизнения цикъл на тестването. Всяко тестово условие и тестов случай в крайна сметка tracВръщаме се към него. Разделите по-долу дефинират термина, обясняват източниците му, разглеждат работния процес на анализ и го поставят във V-модела.
Какво е тестов анализ?
Анализ на теста В софтуерното тестване е процесът на преглед на входните данни, използвани за определяне на тестови условия и тестови случаи. Тези входни данни – спецификации, изисквания, проектна документация, потребителски истории и подобни резултати – се наричат общо тестови артефактиЦелта на тестовия анализ е да сеtracЦелите на t-теста са достатъчно ясни, така че всяка от тях да може да се превърне в недвусмислено тестово условие. Тъй като анализираният материал формира основата, от която са извлечени всички тестове, той се нарича още Тестова основа.
Типични източници, от които тестерите извличат информация за тестовете, включват:
- SRS — Спецификация на софтуерните изисквания
- BRS — Спецификация на бизнес изискванията
- Функционални проектни документи
- Потребителски истории, критерии за приемане и wireframes
Тестерите могат също да генерират тестови условия, като изследват директно тестваното приложение или като се позовават на минал опит, но повечето тестови случаи са получени от тестови артефакти за поддържане tracлеснота.
👉 Запишете се за безплатен проект за тестване на софтуер на живо
Защо е важна тестовата база?
Тестовата база е най-важният фактор, определящ дали един тестов пакет улавя реални дефекти или преследва фантомни. Третирането ѝ като незадължителна е най-честата причина за избягали грешки да достигнат до продукцията. Солидният тестов анализ предоставя четири конкретни предимства:
- Tracвъзможност: Всеки тестов случай може да бъде свързан с конкретно изискване, което прави анализа на въздействието на промяната бърз и одитните прегледи безболезнени.
- Яснота на покритието: Revпреглед на пропуските в базовите повърхности — неопределени състояния на грешки, липсващи гранични случаи, неопределени нефункционални прагове — преди те да се превърнат в производствени инциденти.
- Съгласуване със заинтересованите страни: Когато екипът за тестване извлича условия от същите документи, върху които екипът за разработка изгражда, и двете страни споделят общо определение за „готово“.
- Ранно откриване на дефекти: Много дефекти в изискванията (неяснота, противоречия, липсващи критерии за приемане) се откриват по време на самия тестов анализ, много преди да бъде написан какъвто и да е код - най-евтиното място за тяхното отстраняване.
Често срещани източници на тестова основа
Различните артефакти захранват различни нива на тестване. Използвайте таблицата по-долу като бърза справка, когато решавате кой документ да се консултирате, докато пишете тестови случаи.
| Източник на артефакт | Най-подходящ за | Какво си бивш/аtract |
|---|---|---|
| Спецификация на бизнес изискванията (BRS) | Приемане и системно тестване | Цялостни бизнес правила, регулаторни ограничения, критерии за успех |
| Спецификация на софтуерните изисквания (SRS) | Тестване на системата | Функционални и нефункционални изисквания с измерими прагове |
| Функционални/технически проектни документи | Интеграционно тестване | Модулни интерфейси, поток от данни, спецификации за обработка на грешки |
| Потребителски истории и критерии за приемане | Agile sprint тестване | Поведенчески очаквания във формата „Дадено-Когато-Тогава“ |
| Wireframes и UI макети | Тестване на потребителския интерфейс / използваемостта | Оформление, навигация, правила за валидиране на входни данни |
| Приложение в процес на тестване (проучвателно) | Експлораторно и регресионно тестване | Недокументирано поведение, работни процеси в реалния свят, гранични случаи |
Как да извършите тестов анализ стъпка по стъпка
Ефективният тестов анализ следва повтаряем работен процес от пет стъпки, независимо от размера на проекта или методологията.
- Съберете и инвентаризирайте тестовата база. Съберете всеки артефакт, който описва предвиденото поведение — SRS, BRS, дизайнерска документация, потребителски истории, макети. Обърнете внимание кой документ притежава всяко изискване, така че tracУдобството остава непокътнато.
- Revоглед за тестваемост. Прочетете всеки артефакт, имайки предвид три въпроса: Измеримо ли е това твърдение? Недвусмислено ли е? Пълно ли е? Маркирайте всяко изискване, което не отговаря на една от тези проверки, и го повдигнете пред автора, преди да пишете тестове срещу него.
- Определете условията на тестване. За всяко проверимо твърдение, избройте условията, които се нуждаят от проверка (положителни пътища, отрицателни пътища, гранични стойности, обработка на грешки, сигурност, производителност). Тестово условие е abstracт „какво“ — например, „Системата отхвърля поръчки с нулево количество“ — различно от конкретното „как“ на тестовия случай.
- Приоритизирайте и групирайте условията. Класифицирайте всяко условие по риск и честота на употреба. Високорисковите и високочестотни условия получават подробно покритие; нискорисковите могат да бъдат комбинирани или избрани. Тук също така решавате кои условия са кандидати за автоматизация.
- Преобразувайте условията в тестови случаи. Всяко приоритизирано условие става едно или повече тестови случаи с предварителни условия, стъпки, тестови данни и очаквани резултати. Поддържайте изисквания tracМатрица на вероятността, свързваща всеки тестов случай с неговото първоначално изискване.
Следването на тази последователност избягва най-често срещаните грешки при тестовия анализ: писане на тестови случаи без ясна основа, пропускане на отрицателни сценарии и създаване на тестове, които не могат да бъдат свързани с изискване по време на сортирането на дефектите.
Тестов анализ във V-модела
V-моделът свързва всяка дейност по разработка със съответстваща дейност по тестване. Тестовият анализ се извършва на всяко ниво, като се използва кой от документите е наличен в този момент от жизнения цикъл.
Фигура 1: Тестов анализ по фазите на V-модел.
Казус: Извличане на тестови случаи от изискване на клиент
Да разгледаме сценарий, в който клиентът изпраща следното едноредово изискване.
Client requirement: Add search functionality to an eCommerce Store
Въпреки че приложението все още не е изградено, тестерът може да изведе няколко тестови условия, като анализира какво предполага изискването – както поведението „щастлив път“, така и режимите на отказ, които клиентът не е посочил изрично. Няколко примера включват:
- Проверете резултата от търсенето, когато не е въведена ключова дума.
- Проверете резултата от търсенето, когато не съществува съответстващ продукт за въведената ключова дума.
- Проверете резултата от търсенето, когато съществуват няколко съответстващи продукта за ключовата дума.
- Проверете поведението със специални символи, начални/последни интервали и много дълги входни данни.
- Проверете чувствителността към малки и големи букви и поведението при частично съвпадение.
- Проверете времето за реакция на търсенето при очаквано потребителско натоварване.
Тестерът взема изискването на клиента (тестовата основа), анализира го и го преобразува в тестови условия. Този модел се повтаря на всяка фаза от V-модела — тестовите планове и тестовите случаи се създават с помощта на който и да е документ, наличен в този момент от жизнения цикъл.
Видео: Обяснение на анализа на тестовете
Ако видеото не се зареди, гледайте го директно на YouTube.
