Какво представлява шаблонът на тестовия план?
ШАБЛОН НА ПЛАН ЗА ИЗПИТВАНЕ е подробен документ, който описва тестовата стратегия, цели, график, оценка и резултати и ресурси, необходими за тестване. Тестовият план ни помага да определим усилията, необходими за проверка на качеството на тестваното приложение. Планът на теста служи като план за провеждане на дейности по тестване на софтуер като дефиниран процес, който се следи подробно и контролира от ръководителя на теста.
Създаването на план за тестване е задължително, за да се гарантира успехът на вашия проект за тестване на софтуер. Ако сте нов в планирането на теста, направете справка в този урок за създаване на план за тестване
Изтеглете примерния шаблон за план за тестване
По-долу намерете важни съставки на тестовия план-
- 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) Извън обхвата
Out Of Scope определя характеристиките, функционалните или нефункционалните изисквания на софтуера, който НЯМА да бъде тестван
1.2) Качество Цел
Тук споменете общата цел, която планирате да постигнете с ръчното си тестване и тестването за автоматизация.
Някои цели на вашия проект за тестване могат да бъдат
- Уверете се, че тестваното приложение отговаря на функционални и нефункционални изисквания
- Уверете се, че AUT отговаря на спецификациите за качество, определени от клиента
- Грешки / проблеми са идентифицирани и отстранени, преди да стартират
1.3) Роли и отговорности
Подробно описание на ролите и отговорностите на различните членове на екипа като
- QA анализатор
- Тест мениджър
- Configuration Manager
- Разработчици
- Инсталационен екип
Сред други
2) Методология на теста
2.1) Общ преглед
Споменете причината за приемането на определена методология за тестване на проекта. Методологията на теста, избрана за проекта, може да бъде
- WaterFall
- Итеративен
- Пъргав
- Екстремно програмиране
Избраната методология зависи от множество фактори. Можете да прочетете за методологията на теста тук
2.2) Тестови нива
Тестовите нива определят видовете тестване, които да се изпълняват в тестваното приложение (AUT ). Нивата на тестване преди всичко зависят от обхвата на проекта, времевите и бюджетните ограничения.
2.3) Проверка на грешки
Целта на триажа е да
- За да дефинирате типа резолюция за всяка грешка
- За да приоритизирате грешките и да определите график за всички „To Be Fixed Bugs“.
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 В обхвата
Всички характеристики на websiteGuru99 Bank, дефинирани в спецификациите на софтуерните изисквания, трябва да бъдат подобрени
| Име на модула | Приложими роли | Описание |
| Запитване за баланс | Мениджър клиент | Клиент : Клиентът може да има множество банкови сметки. Той може да преглежда баланса само на своите сметкиМениджър : Мениджърът може да вижда баланса на всички клиенти, които попадат под неговия надзор |
| Прехвърляне на средства | Мениджър клиент | Клиент: Клиентът може да прехвърли средства от „собствената си” сметка към всяка сметка на местоназначение.Мениджър : Мениджърът може да прехвърля средства от всяка банкова сметка източник към сметка дестинация |
| Мини изявление | Мениджър клиент | Мини извлечение ще покаже последните 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 вида тестване.
- Интеграционно тестване (Отделни софтуерни модули се комбинират и тестват като група)
- Тестване на системата : Проведено върху цялостна , интегрирана система за оценка на съответствието на системата с посочените изисквания
- API тестване: Тествайте всички API, създадени за тествания софтуер
2.3 Проверка на бъгове
2.4 Критерии за спиране и изисквания за възобновяване
Ако членовете на екипа съобщят, че има 40% от неуспешните тестови случаи , спрете тестването, докато екипът за разработка поправи всички неуспешни случаи.
2.5 Пълнота на теста
- Определя критериите, които означават успешно завършване на тестова фаза
- Изпълнете скорост е задължително да е 100% , освен ако не е дадена ясна причина.
- Пропусквателната способност е 80%, постигането на пропусквателна способност е задължително
2.6 Проектна задача и оценка и график
| Задача | Членове | Оценете усилията |
| Създайте спецификацията на теста | Дизайнер на тестове | 170 човекочас |
| Извършете тестово изпълнение | Тестер, администратор на тестове | 80 човекочас |
| Протокол от теста | Тестер | 10 човекочас |
| Тестова доставка | 20 човекочас | |
| Обща сума | 280 човеко-час |
График за изпълнение на тези задачи
3 Тестови резултати
Осигурени са тестови резултати, както по-долу
Преди фаза на тестване
- Документ за планове за изпитване.
- Документи за тестови случаи
- Спецификации на тестовия дизайн.
По време на тестването
- Симулатори на тестови инструменти.
- Тестови данни
- Тествайте проследяващата способност на матрицата - Регистрационни файлове за грешки и регистрационни файлове за изпълнение.
След приключване на тестовите цикли
- Резултати от тестове / отчети
- Доклад за дефекти
- Инструкции за процедури за инсталиране / изпитване
- Бележки към изданието
4 Нужди от ресурси и околна среда
4.1 Инструменти за тестване
| Не. | Ресурси | Описания |
| 1. | Сървър | Нуждаете се от сървър на база данни, който да инсталира MySQL сървър Уеб сървър, който да инсталира Apache Server |
| 2. | Инструмент за тестване | Разработете инструмент за тестване, който може автоматично да генерира резултата от теста до предварително дефинираната форма и автоматично изпълнение на теста |
| 3. | Мрежа | Настройте LAN Gigabit и 1 интернет линия със скорост най-малко 5 Mb / s |
| 4. | Компютър | Най-малко 4 компютъра с Windows 7, Ram 2GB, CPU 3.4GHZ |
4.2 Тестова среда
Тествайте средата, за да бъде настроена, както е показано на фигурата по-долу