Примерен шаблон за тестов план

Какво е шаблон за тестов план?

A Шаблон за тестов план е подробен документ, описващ стратегията за тестване, целите, графика, оценката, резултатите и ресурсите, необходими за тестване. Той помага да се определят усилията, необходими за валидиране на качеството, и служи като план, контролиран от мениджъра на тестването.

Създаване на План за тестване е задължително, за да се гарантира успехът на вашия тестов проект. Ако сте начинаещи в него, вижте Как да създадете тестов план.

Изтеглете примерен шаблон на тестов план

Структура на шаблона за тестов план

По-долу са обяснени важните компоненти на шаблона за тестов план:

• 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 Тестова среда
• 5. Термини/Акроними

1) Въведение

Въведението предоставя кратък преглед на стратегиите за тестване, процесите, работния процес и методологиите, използвани за проекта.

1.1) Обхват

---

Обхватът е разделен на две части, така че границата на тестване да остане недвусмислена.

1.1.1) В обхват

В „Обхват“ се определят характеристиките, функционалните или нефункционалните изисквания на софтуера, които ще бъде тествани.

1.1.2) Извън обхвата

„Извън обхвата“ определя характеристиките, функционалните или нефункционалните изисквания на софтуера, които НЯМА да бъде тествани.

1.2) Цел за качество

---

Тук споменавате общите цели, които екипът планира да постигне чрез ръчно тестване и автоматизирано тестване. Някои цели на типичен проект за тестване включват:

• Уверете се, че тестваното приложение (AUT) отговаря на функционалните и нефункционалните изисквания.
• Уверете се, че AUT отговаря на спецификациите за качество, определени от клиента.
• Идентифицирайте и отстранете грешки, преди приложението да бъде пуснато в експлоатация.

1.3) Роли и отговорности

---

Предоставете подробно описание на ролите и отговорностите на различните членове на екипа, като например:

• QA анализатор
• Тест мениджър
• Конфигурационен мениджър
• Разработчици
• Екип за инсталиране

Наред с други.

👉 Запишете се за безплатен проект за тестване на софтуер на живо

2) Методология на теста

Този раздел определя жизнения цикъл, нивата и правилата, използвани за управление на изпълнението на тестовете.

2.1) Преглед

---

Посочете причината за приемането на конкретна методология за тестване за проекта. Избраната методология за тестване за проекта може да бъде:

• Водопад
• повтарящ се
• Пъргав
• Екстремно програмиране

Избраната методология зависи от множество фактори. Можете да прочетете повече за методологията на тестване тук.

2.2) Тестови нива

---

Нивата на тестване определят видовете тестове, които ще се изпълняват върху тестваното приложение (AUT).Избраните нива зависят предимно от обхвата на проекта, времевите и бюджетните ограничения.

2.3) Сортиране на грешки

---

Целта на сортирането на вредители е да:

• Определете типа на решението за всяка грешка.
• Приоритизирайте грешките и определете график за всички грешки „За отстраняване“.

2.4) Критерии за спиране и изисквания за възобновяване

---

Критериите за спиране определят условията, при които цялата или част от процедурата за тестване ще бъде временно преустановена. Критериите за възобновяване определят кога тестването може да се възобнови след като е било преустановено.

2.5) Пълнота на теста

---

Тук определяте критериите, които ще считат тестването ви за завършено. Например, често срещани критерии за проверка на пълнотата на теста биха били:

• Постигнато е 100% покритие на тестовете.
• Всички ръчни и автоматизирани тестови случаи са изпълнени.
• Всички открити грешки са поправени или планирани за следващото издание.

3) Резултати от теста

Избройте всеки артефакт, създаден през жизнения цикъл на тестване. Предварителното им записване предотвратява пропуснати предавания между екипите.

4) Нужди от ресурси и околна среда

Избройте инструменти и инфраструктура за осигуряване на бюджети, лицензи и среди, преди да започне изпълнението.

4.1) Инструменти за тестване

---

Направете списък с инструменти, като например:

• Изисквания Tracкралски инструмент
• Буболечка Tracкралски инструмент
• Инструменти за автоматизация

Те са необходими за ефективно тестване на проекта.

4.2) Тестова среда

---

Споменете минимума железария изисквания, които ще бъдат използвани за тестване на приложението.

По-долу софтуер е необходимо в допълнение към специфичен за клиента софтуер:

• Windows 11 и по-горе
• Microsoft 365 (или Office 2021 и по-нови версии)
• MS Exchange и др.

5) Термини/акроними

Документирайте всички термини или акроними, използвани в проекта, така че новодошлите да могат да четат плана без двусмислие.

Изтеглете горния формат на шаблон на план за тестване

Примерен документ за тестов план: Пример за банково уеб приложение

Следният работен пример показва как се попълва горният шаблон за Guru99 Банково уеб приложение.

1. Въведение

Планът за тестване предписва обхвата, подхода, ресурсите и графика на всички тестови дейности за GuruПроект на Банка 99. Той определя елементите и характеристиките, които ще бъдат тествани, видовете извършени тестове, отговорния персонал и рисковете, свързани с плана.

1.1 Обхват

1.1.1 В обхвата

Всички характеристики на Guru99 Уебсайт на банката, дефиниран в софтуерните изисквания очила трябва да се тестват.

Име на модула	Приложими роли	Descriptйон
Запитване за баланс	Мениджър, Клиент	Клиент: Клиентът може да има няколко банкови сметки и може да преглежда само салдата по тях. Мениджър: Мениджърът може да преглежда баланса на всички клиенти под негово ръководство.
Прехвърляне на средства	Мениджър, Клиент	Клиент: Клиентът може да прехвърля средства от собствената си сметка към всяка целева сметка. Мениджър: Мениджърът може да прехвърля средства от всяка сметка източник към всяка сметка получател.
Мини изявление	Мениджър, Клиент	Мини извлечението показва последните 5 транзакции по сметката. Клиент: Вижда само мини-извлечението от собствените си сметки. Мениджър: Вижда мини-извлечението от всяка сметка.
Персонализирано изявление	Мениджър, Клиент	Персонализирано извлечение филтрира и показва транзакциите в сметка по дата или стойност на транзакцията. Клиент: Само по негови собствени сметки. Мениджър: Всякакъв акаунт.
Промяна на паролата	Мениджър, Клиент	Клиент: Може да променя паролата на собствения си акаунт. Мениджър: Може да променя паролата на собствения си акаунт, но не и на тези на клиентите си.
Нов Клиент	Мениджър	Мениджър: Мениджърът може да добави нов клиент.
Редактиране на клиент	Мениджър	Мениджър: Може да редактира данни като адрес, имейл и телефон на клиент.
Нов акаунт	Мениджър	Системата предлага 2 вида сметки: спестовни и текущи. Клиентът може да притежава множество спестовни сметки (единични или съвместни) и множество текущи сметки. Мениджър: Може да се добави нов акаунт за съществуващ клиент.
Редактиране на профила	Мениджър	Мениджър: Може да редактира данните на съществуващ акаунт.
Изтриване на профила	Мениджър	Мениджър: Може да изтрие акаунт, принадлежащ на клиент.
Изтриване на клиент	Мениджър	Клиент може да бъде изтрит само ако няма активни разплащателни или спестовни сметки. Мениджър: Може да изтрие клиент.
депозит	Мениджър	Мениджър: Може да депозира пари във всяка сметка, обикновено когато пари в брой се депозират в банков клон.
Оттегляне	Мениджър	Мениджър: Може да тегли пари от всяка сметка, обикновено когато тегли пари в брой в банков клон.

1.1.2 Извън обхвата

Тези функции не са тествани, защото не са част от спецификациите на софтуерните изисквания:

• Потребителски интерфейси
• Хардуерни интерфейси
• Софтуерни интерфейси
• Логически дизайн на базата данни
• Комуникационни интерфейси
• Сигурност и производителност на уебсайта

1.2 Цел за качество

Целите на теста са да провери функционалността на GuruУебсайт на банка 99. Проектът трябва да се фокусира върху тестването на банкови операции, като например управление на акаунти, теглене и запитване за баланс, до гаранция че всички тези операции работят Обикновено в реална бизнес среда.

1.3 Роли и отговорности

Проектът трябва да използва външни изпълнители членове като тестери, за да спестят от разходите по проекта.

Не.	Член	Задачи
1.	Тест мениджър	Управлява целия проект, определя посоката на проекта и осигурява подходящи ресурси.
2.	тестер	Идентифицира и описва подходящи техники за тестване, инструменти и архитектура за автоматизация; проверява подхода за тестване; изпълнява тестове; регистрира резултатите; докладва за дефекти. Външни членове.
3.	Разработчик в теста	Внедрява тестови случаи, тестови програми, тестови пакети и др.
4.	Тестов администратор	Изгражда и поддържа тестовата среда и ресурсите; подкрепя тестерите по време на изпълнението.
5.	Членове на SQA	Поемете отговорност за осигуряване на качеството и потвърдете дали процесът на тестване отговаря на определените изисквания.

2. Методология на теста

2.1 Преглед

- GuruПроектът на 99 Bank следва Agile-съвместима методология за тестване, която позволява на тестерите да се съобразят с бързите спринтове за разработка, като същевременно поддържат структурирана документация.

2.2 Тестови нива

в GuruПо проект на Банка 99 трябва да се проведат три вида тестове:

• Тестване на интеграция: Отделните софтуерни модули се комбинират и тестват като група.
• Тестване на системата: Провежда се по цялостна, интегрирана система за оценка на съответствието със зададените изисквания.
• Тестване на API: Тества всеки API, предоставен от тествания софтуер.

2.3 Сортиране на грешки

Срещите за сортиране на грешки се провеждат два пъти седмично, за да се класифицира тежестта на дефекта, собственикът и целевата версия на корекцията.

2.4 Критерии за спиране и изисквания за възобновяване

If 40% тестови случаи имат Неуспешно, преустановете тестването, докато екипът за разработка не поправи всички неуспешни случаи.

2.5 Пълнота на теста

• Указва критериите, които обозначават a успешно завършване на тестова фаза.
• Скорост на бягане е задължително при 100% освен ако не е посочена ясна причина.
• Процент на преминаване is 80%постигането на процент на успешно преминаване е задължителен.

2.6 Задачи по проекта, оценка и график

Task	Потребители	Очаквано усилие
Създайте спецификацията на теста	Дизайнер на тестове	170 човекочаса
Извършване на тестово изпълнение	Тестер, тест администратор	80 човекочаса
Test Report	тестер	10 човекочаса
Тестова доставка	Тест мениджър	20 човекочаса
Обща сума	-	280 човекочаса

График: Екипът се ангажира да изпълни тези задачи в рамките на договорения прозорец за тестов цикъл.

3. Тестови резултати

Тестови резултати за GuruПроектът на банка 99 е организиран в три фази.

Преди фазата на тестване:

• Документ за план за тестване.
• Тестови случаи документи.
• Спецификации на тестовия дизайн.

По време на фазата на тестване:

• Симулатори на тестови инструменти.
• Данни за теста.
• тест tracматрица на ефективността, регистрационни файлове за грешки и регистрационни файлове за изпълнение.

След приключване на циклите на тестване:

• Резултати и доклади от тестове.
• Доклад за дефект.
• Указания за процедурата по инсталиране и тестване.
• Бележки по изданието.

4. Нужди от ресурси и околна среда

4.1 Инструменти за тестване

Не.	Средство	Descriptйон
1.	Сървър	Сървър на база данни, работещ MySQL и уеб сървър, работещ с Apache.
2.	Инструмент за тестване	Инструмент, който може автоматично да генерира резултати от тестове в предварително дефиниран вид и да автоматизира изпълнението на тестовете.
3.	мрежа	Гигабитова LAN мрежа и една интернет линия с минимална скорост от 5 Mb/s.
4.	компютър	Поне 4 работещи работни станции Windows 11, с 8 GB RAM и 3.4 GHz процесор.

4.2 Тестова среда

Този подраздел изброява минималните хардуерни и софтуерни изисквания, използвани за тестване на приложението. В допълнение към специфичния за клиента софтуер е необходим следният софтуер:

• Windows 11 и по-горе
• Microsoft 365 (или Office 2021 и по-нови версии)
• MS Exchange и др.

Как изкуственият интелект помага при планирането на тестовете

Съвременното планиране на тестове все по-често използва изкуствен интелект за компресиране на усилията и за отстраняване на слепи зони. Генеративни асистенти като ChatGPT, Claude или Gemini може да изготви първоначален план за тестване от документ с изисквания, да предложи липсващи гранични случаи и да създаде tracматрици на надеждност автоматично. Моделите за машинно обучение маркират рискови модули от исторически данни за дефекти, helpping Мениджърът на тестовете фокусира усилията си там, където е най-важно.

Въпреки това, помощта от изкуствен интелект не замества човешката преценка. RevОценяващите трябва да валидират обхвата, регулаторното покритие и бизнес намеренията, преди да одобрят който и да е план, генериран от ИИ. Отнасяйте се към предложенията, свързани с ИИ, като към първа чернова, а не като към окончателен документ.

Най-добри практики за ефективен план за тестване

Добре написаният план за тестване осигурява координиране на действията на всички заинтересовани страни. Прилагайте тези най-добри практики, когато създавате документа си:

• Бъдете кратки: Използвайте ясен език и списъци с водещи точки; избягвайте жаргон, който забавя читателите без контрол на качеството.
• Направи го Reviewable: Споделяйте рано с разработчици и бизнес анализатори, за да откриете липсващите изисквания.
• Количествено определяне на критериите за излизане: Дефинирайте числово покритие, процент на преминаване и прагове за дефекти.
• Свържете рисковете със смекчаващи мерки: Свържете всеки риск със стратегия за ограничаване или резервен подход.
• Контрол на версиите на плана: Съхранявайте го в инструмент за документиране, за да track промени в целия проект.

Въпроси и Отговори