План тестування — це докладний документ, який описує області тестування програмного забезпечення та дії. У ньому викладено стратегію тестування, цілі, графік тестування, необхідні ресурси (людські ресурси, програмне та апаратне забезпечення), оцінку тесту та результати тестування.

План тестування є основою для тестування кожного програмного забезпечення. Це найважливіша діяльність, яка забезпечує наявність усіх списків запланованих заходів у відповідній послідовності.

План тестування — це шаблон для проведення заходів з тестування програмного забезпечення як визначеного процесу, який повністю контролюється та контролюється менеджером з тестування. План тестування готують керівник тестування (60%), менеджер тестування (20%) та інженер тестування (20%).

Типи тестового плану

Існує три види плану тестування

• Генеральний план тестування
• План етапу тестування
• Плани тестування для певного типу

Генеральний план тестування

Генеральний план тестування – це тип плану тестування, який має кілька рівнів тестування. Він включає повну стратегію тестування.

План етапу тестування

План фазового тестування — це тип плану тестування, який стосується будь-якої фази стратегії тестування. Наприклад, список інструментів, список тестів тощо.

Конкретні плани тестування

Спеціальний план тестування, розроблений для основних типів тестування, як-от тестування безпеки, тестування навантаження, тестування продуктивності тощо. Іншими словами, спеціальний план тестування, розроблений для нефункціонального тестування.

Як написати план тестування

Складання плану тестування є найважливішим завданням процесу управління тестуванням. Відповідно до IEEE 829 виконайте наступні сім кроків, щоб підготувати план тестування.

• Спочатку проаналізуйте структуру та архітектуру продукту.
• Тепер розробіть стратегію тестування.
• Визначте всі цілі тесту.
• Визначте область тестування.
• Визначте всі корисні ресурси.
• Плануйте всі дії належним чином.
• Визначте всі результати тесту.

Компоненти або атрибути плану тестування

План тестування складається з різних частин, які допомагають нам вивести всю діяльність тестування.

Цілі: Він складається з інформації про модулі, функції, тестові дані тощо, які вказують на мету програми, тобто поведінку програми, мету тощо.

Сфера застосування: Він містить інформацію, яку потрібно протестувати з відповідною програмою. Обсяг можна далі розділити на дві частини:

• За обсягом
• Поза межами

В обсязі: Це ті модулі, які потребують ретельного (детального) тестування.

Вихідний обсяг: Це ті модулі, які не потребують ретельного тестування.

Наприклад , Припустимо, у нас є програма Gmail для тестування, де функції, які потрібно перевірити як от Створення пошти, Надіслані, Вхідні, Чернетки і функції, які не підлягають перевірці як от Довідка і так далі, що означає, що на етапі планування ми вирішимо, яку функціональність потрібно перевірити чи ні, виходячи з обмеження часу, зазначеного в продукті.

Зараз як ми вирішуємо, які функції не тестувати?

У нас є такі аспекти, за якими ми можемо вирішити, яку функцію не тестувати:

• Як ми бачимо вище Довідка функції не тестуватимуться, оскільки їх написав і розробив технічний автор, а перевірив інший професійний автор.
• Припустімо, що у нас є одна програма, яка має P, Q, R і S функції, які необхідно розробити на основі вимог. Але тут функція S вже розроблена та використовується іншою компанією. Отже, команда розробників придбає S у цієї компанії та інтегруватиме додаткові функції, такі як P, Q і R.

Тепер ми не будемо виконувати функціональне тестування функції S, оскільки вона вже використовувалася в режимі реального часу. Але ми проведемо тестування інтеграції та тестування системи між функціями P, Q, R і S, оскільки нові функції можуть не працювати належним чином із функцією S, як ми можемо бачити на зображенні нижче:

• Припустимо, що в першому випуску продукту розроблені елементи, як-от P, Q, R, S, T, U, V, W…..X, Y, Z . Тепер клієнт надасть вимоги до нових функцій, які покращують продукт у другому випуску, і нові функції є A1, B2, C3, D4 і E5.

Після цього ми напишемо область під час тестового плану як

Область застосування

Функції для перевірки

A1, B2, C3, D4, E5 (нові функції)

P, Q, R, S, T

Функції, які не підлягають тестуванню

W…..X, Y, Z

Тому ми спочатку перевіримо нові функції, а потім продовжимо роботу зі старими функціями, оскільки це може вплинути після додавання нових функцій, що означає, що це також вплине на області впливу, тому ми виконаємо один раунд регресивного тестування для P, Q , R…, T особливості.

Методика тестування:

Він містить інформацію про виконання різних видів тестування, як-от функціональне тестування, інтеграційне тестування, системне тестування тощо в додатку. У цьому ми вирішимо, який тип тестування; ми будемо використовувати різні функції на основі вимог програми. І тут ми також повинні визначити, який тип тестування ми будемо використовувати в методологіях тестування, щоб усі, як-от керівництво, команда розробників і команда тестування, могли легко зрозуміти, оскільки умови тестування не є стандартними.

Наприклад, для окремого застосування, наприклад Adobe Photoshop , ми проведемо наступні види тестування:

Тестування диму → Функціональне тестування → Тестування інтеграції → Тестування системи → Тестування Adhoc → Тестування сумісності → Тестування регресії → Тестування глобалізації → Тестування доступності → Тестування зручності використання → Тестування надійності → Тестування відновлення → Тестування встановлення або видалення

І припустимо, що ми повинні перевірити https://www.jeevansathi.com/ програми, тому ми будемо проводити такі види тестування:

Підхід

Цей атрибут використовується для опису потоку програми під час виконання тестування та для використання в майбутньому.

Ми можемо зрозуміти потік програми за допомогою наведених нижче аспектів:

Пишучи сценарії високого рівня Написавши потоковий графік

Пишучи сценарії високого рівня

Наприклад , припустімо, ми тестуємо Gmail застосування:

• Увійдіть у Gmail – надсилає електронний лист і перевіряє його наявність на сторінці «Надіслані».
• Увійдіть до …….
• ……
• …....

Ми пишемо це, щоб описати підходи, які необхідно використовувати для тестування продукту, і лише для критичних функцій, де ми будемо писати сценарії високого рівня. Тут ми не будемо зосереджуватися на охопленні всіх сценаріїв, тому що окремий інженер-випробувач може вирішити, які функції потрібно тестувати, а які ні.

Написавши потоковий графік

Потоковий графік написаний тому, що написання сценаріїв високого рівня займає багато часу, як ми можемо бачити на зображенні нижче:

Ми створюємо потокові графіки, щоб отримати такі переваги, як:

• Покриття легко
• Об’єднати легко

Підхід можна розділити на дві частини, які є такими:

• Підхід зверху вниз
• Підхід знизу вгору

Успенський

Він містить інформацію про проблему чи проблему, яка могла виникнути під час процесу тестування, і коли ми пишемо плани тестування, будуть зроблені гарантовані припущення, як-от ресурси та технології тощо.

Ризик

Це проблеми, з якими нам потрібно зіткнутися, щоб перевірити програму в поточному випуску, і якщо припущення не справдяться, це означає ризики.

Наприклад, дія для програми, дата випуску переноситься.

План пом'якшення наслідків або план дій у надзвичайних ситуаціях

Це резервний план, який підготовлений для подолання ризиків або проблем.

Давайте розглянемо один приклад для припущення, ризику та плану на випадок непередбачених обставин разом, оскільки вони тісно пов’язані один з одним.

У будь-якому продукті, припущення ми зробимо так, що всі 3 інженери-випробувачі будуть присутні до завершення продукту, і кожному з них буде призначено різні модулі, такі як P, Q і R. У цьому конкретному сценарії ризик може бути так, якби інженер-випробувач покинув проект посередині.

Тому резервний план буде призначено основного та підлеглого власника для кожної функції. Отже, якщо один інженер-випробувач піде, підлеглий власник бере на себе цю особливість, а також допомагає новому інженеру-випробувачу, щоб він/вона міг зрозуміти призначені їм модулі.

Припущення, ризики та план пом’якшення чи дій у непередбачених ситуаціях завжди точно вказуються на самому продукті. Нижче наведено різні типи ризиків:

• Точка зору клієнта
• Ресурсний підхід
• Технічний висновок

Роль і відповідальність

Він визначає повне завдання, яке має виконати вся команда тестування. Коли приходить великий проект, тоді Менеджер тестування це особа, яка пише тестовий план. Якщо є 3-4 невеликі проекти, тоді керівник тестування призначить кожен проект кожному керівнику тестування. Потім керівник тестування пише план тестування для проекту, який йому/їй призначено.

Давайте подивимося один приклад, де ми зрозуміємо ролі та відповідальність керівника тестування, керівника тестування та інженерів з тестування.

Посада: менеджер тестування

Ім'я: Райан

Відповідальність:

• Підготувати (написати та переглянути) план тестування
• Проведіть зустріч з командою розробників
• Проведіть зустріч з командою тестування
• Провести зустріч із замовником
• Проводьте одну місячну зустріч
• Підписати повідомлення про випуск
• Обробка ескалацій і проблем

Посада: керівник випробувань

Ім'я: Харві

Відповідальність:

• Підготувати (написати та переглянути) план тестування
• Проводьте щоденні зустрічі
• Перегляньте та затвердіть тестовий приклад
• Підготувати RTM і звіти
• Призначити модулі
• Графік обробки

Роль: інженер-випробувач 1, інженер-випробувач 2 та інженер-випробувач 3

Ім'я: Луї, Джессіка, Донна

Призначте модулі: M1, M2 і M3

Відповідальність:

• Пишіть, переглядайте та виконуйте тестові документи, які складаються з тестових випадків і тестових сценаріїв
• Прочитайте, перегляньте, зрозумійте та проаналізуйте вимогу
• Напишіть потік програми
• Виконайте тестовий приклад
• RTM для відповідних модулів
• Відстеження дефектів
• Підготуйте звіт про виконання тесту та передайте його керівнику тестування.

розклад

Він використовується для пояснення часу початку роботи, що потрібно зробити, або цей атрибут охоплює, коли саме має починатися та закінчуватися кожна тестова діяльність? І точні дані також згадуються для кожної тестової діяльності на певну дату.

Тому, як ми бачимо на зображенні нижче, для конкретної діяльності буде дата початку та дата завершення; для кожного тестування конкретної збірки буде вказана дата.

Наприклад

• Написання тестів
• Процес виконання

Відстеження дефектів

Зазвичай це робиться за допомогою інструментів, оскільки ми не можемо відстежувати статус кожної помилки вручну. Ми також коментуємо, як ми повідомляємо про помилки, виявлені під час процесу тестування, і надсилаємо їх назад команді розробників, і як команда розробників відповість. Тут ми також згадуємо пріоритет помилок, таких як високий, середній і низький.

Нижче наведено різні аспекти відстеження дефектів:

Методи відстеження помилки
…..
……
……
……Інструменти відстеження помилок
Ми можемо прокоментувати назву інструменту, який ми будемо використовувати для відстеження помилок. Одними з найбільш часто використовуваних інструментів відстеження помилок є Jira, Bugzilla, Mantis і Trac тощо.<Суворість
Ступінь тяжкості може бути наступним:
Блокатор або шоустопер
…..
….. (Поясніть це на прикладі в плані тесту)
Наприклад , в модулі буде дефект; ми не можемо йти далі, щоб перевірити інші модулі, оскільки якщо помилку заблоковано, ми можемо продовжити перевірку інших модулів.
Критичний
……
….. (Поясніть це на прикладі в плані тесту)
У цій ситуації недоліки вплинуть на бізнес.
Майор
….
…. (Поясніть це на прикладі в плані тесту)
незначний
…..
….. (Поясніть це на прикладі в плані тесту)
Це ті дефекти, які впливають на зовнішній вигляд програми.Пріоритет
Високий P1
…..
Середній-P2
…..
Низький Р3
…..
…..
P4

Тому, виходячи з пріоритету помилок, таких як високий, середній і низький, ми класифікуємо його як P1, P2, P3 і P4.

Тестове середовище

Це середовища, у яких ми будемо тестувати програму, і тут у нас є два типи середовищ, які є програмне забезпечення і обладнання конфігурація.

The конфігурація програмного забезпечення означає подробиці про різні Операційні системи як от Windows, Linux, UNIX і Mac і різноманітні Браузери люблю Google Chrome, Firefox, Opera, Internet Explorer , і так далі.

І конфігурація обладнання означає інформацію про різні розміри RAM, ROM і процесори .

Наприклад

• The програмне забезпечення включає наступне:

Сервер

Примітка. Наведені вище сервери – це сервери, які використовуються групою тестувальників для перевірки програми.

Клієнт

Примітка. У наведених вище деталях описано різні операційні системи та браузери, у яких команда тестувальників перевірятиме додаток.

• The Обладнання включає наступне:

Сервер : Sun StarCat 1500

Цей конкретний сервер може бути використаний групою тестувальників для перевірки своєї програми.

Клієнт:

Він має таку конфігурацію, яка виглядає наступним чином:

Примітка. Це надасть конфігурацію систем інженерів-випробувачів, які є командою тестування.

Процес встановлення програмного забезпечення
……
…..
…..

Команда розробників надасть конфігурацію встановлення програмного забезпечення. Якщо команда розробників ще не забезпечить процес, ми запишемо це як Розробка на основі завдань (TBD) у плані тестування.

Критерії входу та виходу

Це необхідна умова, яка повинна бути виконана перед початком і зупинкою процесу тестування.

Критерії вступу

Критерії вступу містять такі умови:

• Тестування білого ящика має бути завершено.
• Зрозуміти та проаналізувати вимоги та підготувати тестові документи або коли тестові документи будуть готові.
• Тестові дані повинні бути готові.
• Необхідно підготувати збірку або додаток
• Модулі або функції потрібно призначити різним інженерам-випробувачам.
• Необхідний ресурс має бути готовий.

Критерії виходу

Критерії виходу містять такі умови:

• Коли всі тестові випадки виконано.
• Більшість тестів має бути пройшли .
• Залежить від серйозності помилок, що означає, що не повинно бути жодного блокувальника чи основної помилки, тоді як деякі незначні помилки існують.

Перш ніж ми почнемо виконувати функціональне тестування, все вищесказане Критерії вступу слід дотримуватися. Після того, як ми виконаємо функціональне тестування та перед тим, як ми проведемо інтеграційне тестування, потім Критерії виходу з слід дотримуватися функціонального тестування, оскільки % критеріїв виходу визначається на зустрічі з менеджером із розробки та тестування, оскільки їх співпраця може досягти цього відсотка. Але якщо критерії виходу функціонального тестування не дотримуються, ми не можемо перейти до інтеграційного тестування.

тут залежно від тяжкості помилки означає, що команда тестування вирішила продовжити роботу на наступних етапах.

Автоматизація тестування

При цьому ми вирішимо наступне:

• Яку функцію потрібно автоматизувати, а яку – ні?
• Який інструмент автоматизації тестування ми будемо використовувати на якій системі автоматизації?

Ми автоматизуємо тестовий приклад лише після першого випуску.

Тут виникає питання, на якій підставі ми буде вирішити, які функції потрібно перевірити?

Як ми бачимо на зображенні вище, функції, які найчастіше використовуються, потрібно тестувати знову і знову. Припустімо, ми повинні перевірити програму Gmail, де є основні функції Створення пошти, Надіслані та Вхідні . Тому ми будемо тестувати ці функції, оскільки виконання ручного тестування займає більше часу, а також стає монотонною роботою.

тепер, як ми вирішуємо, які функції не будемо тестувати?

Припустимо допомога Функція програми Gmail не тестується знову і знову, оскільки ці функції не використовуються регулярно, тому нам не потрібно перевіряти її часто.

Але якщо деякі функції нестабільні та мають багато помилок , що означає, що ми не будемо тестувати ці функції, оскільки їх потрібно тестувати знову і знову під час ручного тестування.

Якщо є функція, яку потрібно часто перевіряти , але ми очікуємо зміни вимог для цієї функції, тому ми не перевіряємо це, оскільки змінювати тестові випадки вручну зручніше порівняно зі зміною сценарію автоматизованого тестування.

Оцінка зусиль

У цьому плані ми плануємо зусилля, яких має докласти кожен член команди.

Тестовий результат

Це документи, які є виходом команди випробувань, які ми передали замовнику разом із продуктом. Він включає наступне:

План тестування Тестові випадки Тестові сценарії RTM (матриця відстеження вимог) Звіт про дефект Звіт про виконання тесту Графіки та показники Примітки до випуску

Графіки та показники

Графік

Тут ми обговоримо види графіки ми надішлемо, а також надамо зразок кожного графіка.

Як ми бачимо, у нас є п’ять різних графіків, які показують різні аспекти процесу тестування.

Графік 1: Тут ми покажемо, скільки дефектів було виявлено та скільки дефектів було виправлено в кожному модулі.

Графік 2: На рисунку 1 показано, скільки критичних, серйозних і незначних дефектів було виявлено для кожного модуля та скільки їх було виправлено для відповідних модулів.

Графік 3: На цьому конкретному графіку ми представляємо побудувати мудрий графік , що означає, що в кожній збірці скільки дефектів було виявлено та виправлено для кожного модуля. На основі модуля ми визначили баги. Ми додамо Р щоб показати кількість дефектів у P і Q, а також додаємо С щоб показати дефекти в P, Q і R.

Графік 4: Керівник тестування розробить Аналіз тенденцій помилок графік, який створюється щомісяця, а також надсилати його керівництву. І це схоже на передбачення, яке робиться в кінці продукту. І тут ми теж можемо оцінити виправлення помилок як ми можемо це спостерігати дуга має тенденція до зростання на зображенні нижче.

Графік 5: The Менеджер тестування розробив цей тип графіка. Цей графік призначений для розуміння розриву в оцінці помилок і фактичних помилок, які виникли, і цей графік також допомагає покращити оцінку помилок у майбутньому.

Метрики

Як і вище, ми створюємо графік розподілу помилок, який зображено на малюнку 1, і за допомогою вищезазначених даних ми також розробляємо показники.

Наприклад

На наведеному вище малюнку ми зберігаємо записи про всіх інженерів-випробувачів у конкретному проекті та про те, скільки дефектів було виявлено та виправлено. Ми також можемо використовувати ці дані для майбутнього аналізу. Коли з’являється нова вимога, ми можемо вирішити, кому надати складну функцію для тестування на основі кількості дефектів, які вони виявили раніше відповідно до наведених вище показників. І ми будемо в кращій ситуації, щоб знати, хто може дуже добре впоратися з проблемними функціями та знайти максимальну кількість дефектів.

Примітка до випуску: Це документ, який готується під час випуску продукту та підписується керівником випробувань.

На зображенні нижче ми бачимо, що кінцевий продукт розроблений і розгорнутий для клієнта, а назва останнього випуску: Бета .

The Примітка до випуску складається з наступного:

перейменування каталогу

• Посібник користувача.
• Список незавершених і відкритих дефектів.
• Список доданих, змінених і видалених функцій.
• Список платформи (операційна система, апаратне забезпечення, браузери), на якій тестується продукт.
• Платформа, на якій продукт не тестується.
• Список помилок, виправлених у поточному випуску, і список виправлених помилок у попередньому випуску.
• Процес встановлення
• Версії програмного забезпечення

Наприклад

Припустимо, що Бета є другим випуском програми після першого Альфа звільняється. Деякі дефекти, виявлені в першому випуску та виправлені в наступному випуску. І тут ми також вкажемо на список нещодавно доданих, змінених і видалених функцій від альфа-версії до бета-версії.

Шаблон

Ця частина містить усі шаблони для документів, які використовуватимуться в продукті, і всі інженери-випробувачі використовуватимуть у проекті лише ці шаблони, щоб підтримувати узгодженість продукту. Тут у нас є різні типи шаблонів, які використовуються під час усього процесу тестування, наприклад:

• Шаблон тестового кейсу
• Шаблон огляду тестового випадку
• Шаблон RTM
• Шаблон звіту про помилку
• Звіт про виконання тесту

Давайте подивимося один зразок документа плану тестування

Сторінка-1

Сторінка3-сторінка18

Сторінка-20

На сторінці 1 ми в першу чергу заповнюємо лише Версії, автор, коментарі та рецензент поля, і після того, як менеджер затвердить це, ми зазначимо деталі в Затверджено та дата затвердження поля.

Здебільшого план тестування затверджується керівником тестування, а інженери з тестування лише переглядають його. І коли з’являться нові функції, ми змінимо план тестування та внесемо необхідні зміни Версія поле, а потім його буде знову надіслано для подальшого перегляду, оновлення та затвердження менеджеру. План тестування необхідно оновлювати щоразу, коли відбуваються будь-які зміни. На сторінці 20, Список літератури вкажіть деталі щодо всіх документів, які ми збираємося використовувати для написання документа плану тестування.

Примітка:

Хто пише тестовий план?

• Тестовий провід→60%
• Менеджер тестів→20%
• Інженер-випробувач→20%

Тому, як ми бачимо вище, у 60% продукту план тестування пише Test Lead.

Хто перевіряє план тестування?

• Test Lead
• Менеджер тестування
• Інженер-випробувач
• Замовник
• Команда розробників

Тестовий інженер переглядає план тестування з точки зору свого модуля, а керівник тестування переглядає план тестування на основі думки клієнта.

Хто затверджує план тестування?

• Замовник
• Менеджер тестування

Хто пише тестовий приклад?

• Test Lead
• Інженер-випробувач

Хто перевіряє тестовий приклад?

• Інженер-випробувач
• Test Lead
• Замовник
• Команда розвитку

Хто затверджує тестові приклади?

• Менеджер тестування
• Test Lead
• Замовник

Рекомендації щодо плану тестування

• Згорніть план тестування.
• Уникайте дублювання та надмірності.
• Якщо ви вважаєте, що вам не потрібен розділ, який уже згадувався вище, видаліть цей розділ і продовжуйте.
• Бути специфічним. Наприклад, коли ви вказуєте програмну систему як частину тестового середовища, тоді вкажіть версію програмного забезпечення замість лише назви.
• Уникайте довгих абзаців.
• По можливості використовуйте списки та таблиці.
• Оновлюйте план за потреби.
• Не використовуйте застарілий і невикористаний документ.

Важливість плану тестування

• План тестування дає напрямок нашим думкам. Це як звід правил, яких потрібно дотримуватися.
• План тестування допомагає визначити необхідні зусилля для перевірки якості програмного забезпечення, що тестується.
• План тестування допомагає цим людям зрозуміти деталі тестування, пов’язані ззовні, наприклад розробники, бізнес-менеджери, клієнти тощо.
• Такі важливі аспекти, як розклад тестування, стратегія тестування, обсяг тестування тощо, задокументовані в плані тестування, щоб команда менеджерів могла переглянути їх і повторно використати для інших подібних проектів.