Шаблон на тестов план (примерен документ)
Какво представлява шаблонът на тестов план?
Шаблон за тестов план е подробен документ, който описва тестовата стратегия, целите, графика, оценката и резултатите, както и ресурсите, необходими за тестването. Тестовият план ни помага да определим усилията, необходими за валидиране на качеството на тестваното приложение. Тестовият план служи като план за провеждане на дейности по тестване на софтуер като дефиниран процес, който се наблюдава и контролира внимателно от мениджъра на тестовете.
Създаване на План за тестване е задължително, за да се гарантира успех на вашия проект за тестване на софтуер. Ако сте нов в планирането на тестове, вижте този урок Как да създадете тестов план
Изтеглете примерен шаблон на тестов план
Шаблон за тестов план
По-долу намерете важни съставни части на тестовия план-
- 1 Въведение
- 1.1 Обхват
- 1.1.1 В обхват
- 1.1.2 Извън обхвата
- 1.2 Цел за качество
- 1.3 Роли и отговорности
- 2 Методология на теста
- 2.1 Преглед
- 2.2 Тестови нива
- 2.3 Сортиране на грешки
- 2.4 Критерии за спиране и изисквания за възобновяване
- 2.5 Пълнота на теста
- 3 Резултати от теста
- 4 Нужди от ресурси и околна среда
- 4.1 Инструменти за тестване
- 4.2 Тестова среда
1) Въведение
Кратко представяне на тестовите стратегии, процеса, работния процес и методологиите, използвани за проекта
1.1) Обхват
1.1.1) В обхват
Обхватът определя функциите, функционалните или нефункционалните изисквания на софтуера, който ще бъде изпитан
1.1.2) Извън обхвата
Извън обхвата определя характеристиките, функционалните или нефункционалните изисквания на софтуера, който НЯМА да бъде изпитан
1.2) Цел за качество
Тук споменете общата цел, която планирате да постигнете с вашето ръчно тестване и автоматизирано тестване.
Някои цели на вашия проект за тестване могат да бъдат
- Уверете се, че Тестваното приложение отговаря на функционалните и нефункционалните изисквания
- Уверете се, че AUT отговаря на спецификациите за качество, определени от клиента
- Бъгове/проблеми се идентифицират и коригират преди пускане на живо
1.3) Роли и отговорности
Подробно описание на ролите и отговорностите на различни членове на екипа
- QA анализатор
- Тест мениджър
- Конфигурационен мениджър
- Разработчици
- Екип за инсталиране
Сред други
2) Методология на теста
2.1) Преглед
Споменете причината за приемането на конкретна тестова методология за проекта. Избраната за проекта методология за изпитване може да бъде
- Водопад
- повтарящ се
- Пъргав
- Екстремно програмиране
Избраната методология зависи от множество фактори. Можете да прочетете за методологията на теста тук
2.2) Тестови нива
Тестовите нива определят типовете тестове, които да се изпълнят на тестваното приложение (AUT). Нивата на тестване зависят основно от обхвата на проекта, времеви и бюджетни ограничения.
2.3) Сортиране на грешки
Целта на триажа е да
- За да определите вида на разрешаването на всяка грешка
- За приоритизиране на грешки и определяне на график за всички „бъгове, които трябва да бъдат коригирани“.
2.4) Критерии за спиране и изисквания за възобновяване
Критериите за спиране определят критериите, които да се използват за спиране на цялата или част от процедурата за тестване, докато критериите за възобновяване определят кога тестването може да се възобнови, след като е било спряно
2.5) Пълнота на теста
Тук определяте критериите, които ще считат вашето тестване за завършено.
Например, няколко критерия за проверка на пълнотата на теста биха били
- 100% покритие на теста
- Изпълнени са всички ръчни и автоматизирани тестови случаи
- Всички открити грешки са коригирани или ще бъдат коригирани в следващото издание
3) Резултати от теста
Тук споменете всички тестови артефакти, които ще бъдат доставени по време на различни фази от жизнения цикъл на тестване.
Ето простите резултати
|
4) Нужди от ресурси и околна среда
4.1) Инструменти за тестване
Направете списък с инструменти като
- Инструмент за проследяване на изискванията
- Инструмент за проследяване на грешки
- Инструменти за автоматизация
Изисква се за тестване на проекта
4.2) Тестова среда
Споменава минимума железария изисквания, които ще бъдат използвани за тестване на приложението.
Следващ софтуеъри са необходими в допълнение към специфичния за клиента софтуер.
- Windows 8 и по-горе
- Office 2013 и по-нова версия
- MS Exchange и др.
5) Термини/акроними
Споменете всички термини или акроними, използвани в проекта
ТЕРМИН/АКРОНИМ | ОПРЕДЕЛЕНИЕ |
---|---|
API | Интерфейс на приложната програма |
AUT | Приложението се тества |
Изтеглете горния формат на шаблон на план за тестване
Примерен тестов план Документ Банкиране Уеб приложение Пример
1 Въведение
Тестовият план е предназначен да предпише обхвата, подхода, ресурсите и графика на всички тестови дейности на проекта Guru99 Bank. Планът идентифицира елементите, които трябва да бъдат тествани, характеристиките, които трябва да бъдат тествани, видовете тестове, които трябва да бъдат извършени, персонала, отговорен за тестването, ресурсите и графика, необходими за завършване на тестването, и рисковете, свързани с плана.1.1 Обхват
1.1.1 В обхвата
Всички функции на уебсайта Guru99 Bank, които са дефинирани в софтуерните изисквания очила трябва да се тестватИме на модула | Приложими роли | Descriptйон |
---|---|---|
Запитване за баланс | Мениджър Клиент | Клиентски: Един клиент може да има няколко банкови сметки. Той може да вижда баланса само на своите сметки Мениджър: Мениджърът може да види баланса на всички клиенти, които са под негов надзор |
Прехвърляне на средства | Мениджър Клиент | Клиент: Клиентът може да прехвърли средства от своята „собствена“ сметка към всяка целева сметка. Мениджър: Мениджърът може да прехвърля средства от всяка изходна банкова сметка към целевата сметка |
Мини изявление | Мениджър Клиент | Мини извлечение ще покаже последните 5 транзакции на акаунт Клиент: Клиентът може да види мини извлечение само за своите „собствени“ сметки Мениджър: Мениджърът може да види мини-извлечение на всяка сметка |
Персонализирано изявление | Мениджър Клиент | Персонализирано извлечение ви позволява да филтрирате и показвате транзакции в акаунт въз основа на дата, стойност на транзакцията Клиент: Клиентът може да види персонализирано извлечение само на своите „собствени“ сметки Мениджър: Мениджърът може да види персонализирано извлечение на всяка сметка |
Промяна на паролата | Мениджър Клиент | Клиент: Клиентът може да промени паролата само на своя акаунт. Мениджър: Мениджърът може да промени паролата само на своя акаунт. Той не може да променя паролите на своите клиенти |
Нов Клиент | Мениджър | Мениджър: Мениджърът може да добави нов клиент. |
Мениджър | Мениджър: Мениджърът може да редактира подробности като адрес, имейл, телефон на клиент. | |
Нов акаунт | Мениджър | Понастоящем системата предоставя 2 вида сметки • Спестовни • Текущи Клиентът може да има няколко спестовни сметки (една на свое име, друга на общо име и т.н.). Той може да има множество текущи сметки за различни компании, които притежава. Или може да има множество текущи и спестовни сметки. Мениджър: Мениджърът може да добави нов акаунт за съществуващ клиент. |
Редактиране на профила | Мениджър | Мениджър: Мениджърът може да добави данни за редактиране на акаунт за съществуващ акаунт |
Изтриване на профила | Мениджър | Мениджър: Мениджърът може да добави или изтрие акаунт за клиент. |
Изтриване на клиент | Мениджър | Клиент може да бъде изтрит само ако няма активни разплащателни или спестовни сметки Мениджър: Мениджърът може да изтрие клиент. |
депозит | Мениджър | Мениджър: Мениджърът може да депозира пари във всяка сметка. Обикновено се прави, когато парите се депозират в банков клон. |
Оттегляне | Мениджър | Мениджър: Мениджърът може да тегли пари от всяка сметка. Обикновено се прави, когато се теглят пари в брой в банков клон. |
1.1.2 Извън обхвата
Тези функции не се тестват, защото не са включени в спецификациите на софтуерните изисквания- Потребителски интерфейси
- Хардуерни интерфейси
- Софтуерни интерфейси
- Базата данни е логична
- Комуникационни интерфейси
- Сигурност и производителност на уебсайта
1.2 Цел за качество
Целите на теста са да провери Функционалността на уебсайта Guru99 Bank, проектът трябва да се съсредоточи върху тестването на банкова операция като управление на сметката, теглене и баланс… и т.н. към гаранция всички тези операции могат да работят Обикновено в реална бизнес среда.1.3 Роли и отговорности
Проектът трябва да използва възлагат членове като тестер, за да спестят разходите по проекта.Не. | Член | Задачи |
---|---|---|
1. | Тест мениджър | Управлявайте целия проект Дефинирайте насоките на проекта Придобийте подходящи ресурси |
2. | тест | Идентифициране и описание на подходящи тестови техники/инструменти/архитектура за автоматизация Проверка и оценка на тестовия подход Изпълнение на тестовете, Регистриране на резултатите, Докладване на дефектите. Изнесени членове |
3. | Разработчик в теста | Внедряване на тестови случаи, тестова програма, тестов пакет и др. |
4. | Тестов администратор | Изгражда и гарантира, че тестовата среда и активите се управляват и поддържат Поддръжка на тестер за използване на тестовата среда за изпълнение на тестове |
5. | Членове на SQA | Поемете отговорността за осигуряване на качеството Проверете, за да потвърдите дали процесът на тестване отговаря на определени изисквания |
2 Методология на теста
2.1 Преглед
2.2 Тестови нива
В проекта Guru99 Bank трябва да се проведат 3 вида тестове.- Integration Тестване (Индивидуалните софтуерни модули се комбинират и тестват като група)
- Система Тестване: Проведено на a завърши, интегрирани система за оценка на съответствието на системата с нейните определени изисквания
- Тестване на API: Тествайте всички API, създадени за тествания софтуер
2.3 Сортиране на грешки
2.4 Критерии за спиране и изисквания за възобновяване
Ако членовете на екипа докладват, че има 40% От тестовите случаи Неуспешно, спрете тестването, докато екипът за разработка коригира всички неуспешни случаи.2.5 Пълнота на теста
- Указва критериите, които обозначават a успешно завършване на тестова фаза
- бягане ставка е задължително да бъде 100% освен ако не е посочена ясна причина.
- Pass скоростта е 80% постигането на процент на преминаване е задължителен
2.6 Проектна задача и оценка и график
Task | Потребители | Оценете усилията |
---|---|---|
Създайте спецификацията на теста | Дизайнер на тестове | 170 човекочаса |
Извършване на тестово изпълнение | Тестер, тест администратор | 80 човекочаса |
Test Report | тестер | 10 човекочаса |
Тестова доставка | 20 човекочаса | |
Обща сума | 280 човекочаса |
3 Резултати от теста
Резултатите от теста са предоставени по-долу Преди тестовата фаза- Документ за тестови планове.
- Тестови случаи документи
- Спецификации на тестовия дизайн.
- Резултати/доклади от тестове
- Доклад за дефект
- Указания за процедури за инсталиране/тест
- Бележки към изданието
4 Нужди от ресурси и околна среда
4.1 Инструменти за тестване
Не. | Ресурси | Descriptйони |
---|---|---|
1. | Сървър | Нуждаете се от сървър за база данни, който да инсталирате MySQL сървър Уеб сървър, който инсталира Apache сървър |
2. | Инструмент за тестване | Разработете инструмент за тестване, който може автоматично да генерира резултата от теста в предварително зададената форма и автоматизирано изпълнение на теста |
3. | мрежа | Настройте LAN Gigabit и 1 интернет линия със скорост поне 5 Mb/s |
4. | компютър | Работят поне 4 компютъра Windows 7, RAM 2GB, CPU 3.4GHZ |
4.2 Тестова среда
Той споменава минималните хардуерни и софтуерни изисквания, които ще бъдат използвани за тестване на приложението. Необходим е следният софтуер в допълнение към специфичния за клиента софтуер.- Windows 11 и по-горе
- Office 2021 и по-нова версия
- MS Exchange и др.