Меню

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

software test estimation techniques

Спробуйте Наш Інструмент Для Усунення Проблем

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

Досвід відіграє важливу роль в оцінці “Зусиль щодо тестування програмного забезпечення”. Робота над різноманітними проектами допомагає підготувати точну оцінку циклу випробувань. Очевидно, що не можна просто наосліп поставити якусь кількість днів для будь-якого тестового завдання. Оцінка тесту повинна бути реалістичною та точною.

Методи оцінки програмного тесту

У цій статті я намагаюсь дуже просто викласти деякі моменти, які допоможуть підготувати точну оцінку тесту.

Що ви дізнаєтесь:

Короткий опис процесу оцінки тесту

'Оцінка - це процес пошуку оцінки або апроксимації, яка є корисною для певних цілей, навіть якщо вхідні дані можуть бути неповними, невизначеними або нестабільними'. (Довідка: Вікіпедія )

Ми всі стикаємось із різними завданнями та обов’язками та строками впродовж нашого життя як професіонали, зараз існує два підходи до пошуку рішення проблеми.

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

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

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

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

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

Практику оцінки можна визначити тоді більш формально як приблизний розрахунок ймовірної вартості певної роботи.

Також читайте=> 7 факторів, що впливають на тестову оцінку проекту автоматизації селену

Основні передумови процесу оцінки тесту

# 1) Статистичні дані, отримані в результаті роботи з минулим досвідом : Завжди є гарною практикою витратити якийсь час, згадуючи минулі проекти, які ставили проблеми, подібні до нинішніх зусиль.

# 2) Доступні документи або артефакти: входять інструменти репозиторію управління тестами зручні в таких типах сценаріїв, оскільки вони зберігають документи щодо вимог та роз’яснень. На ці документи може посилатися команда випробувачів, щоб чітко визначити обсяг проекту.

# 3) Припущення про тип роботи: Минулий досвід роботи допомагає скласти припущення щодо проекту. Тут найважливіше наймати досвідчених фахівців.

Керівники тестувань можуть підібрати мізки цих людей для досягнення бажаних результатів.

# 4) Розрахунок потенційних ризиків та загроз: Команда тестування також повинна візуалізувати потенційні ризики та загрози та підводні камені, які можуть лягти для команди в майбутньому.

# 5) Визначення того, чи були документи базовими: Команда випробувань також повинна визначити, чи були вимоги базовими чи ні. Якщо документи не є базовими, тоді важливо визначити частоту змін.

# 6) Усі обов'язки та залежності повинні бути чіткими: Організація повинна чітко визначити ролі та обов'язки всіх осіб, які виконуватимуть процес оцінки.

# 7) Документація та відстеження записів оцінок: Вся відповідна інформація для процесу оцінки повинна бути задокументована.

№8) Діяльність, яку потрібно виконати в процесі оцінки тесту

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

Найвидатніші методи оцінки тестів

Деякі з найважливіших методів оцінки тестів:

  • Оцінка контрольної точки
  • Оцінка на основі робочої фази
  • Оцінка точки використання випадку

Як і де ми використовуємо ці методи:

# 1) Оцінка тестових балів - це проста та зрозуміла техніка оцінки, яка широко використовується у всьому спектрі тестування програмного забезпечення. Ітераційні етапи та простота - найважливіші особливості цієї конкретної техніки.

вводити та виводити програмне забезпечення безкоштовно

# 2) Оцінка на основі робочої фази - це метод оцінки, який використовується, коли оцінка здогадок проводиться на певній фазі (як правило, найкоротшій і найпростішій з фаз), а потім команда тестування поступово додає інші етапи до початкової оцінки і, нарешті, випускає відповідну оцінку.

# 3) Методика оцінки точки використання - це оцінка випадків використання, коли невідрегульовані ваги актора та некореговані ваги випадків використання використовуються для визначення оцінки тестування програмного забезпечення.

Детальна інформація про методику оцінки контрольної точки

Методика оцінки точки випробування виконується, виконуючи перелічені кроки: -

техніка оцінки тестових балів

(Наступні ваги, які можуть відрізнятися від проекту до проекту, можуть розглядатися за цією парадигмою - Деякі з цих ваг є вагою мови програмування на основі складності коду, вагою програми на основі типу програми та вагами тесту, які призначені на основі різних фаз тестування програмного забезпечення.)

Неопрацьовані тестові бали множаться на CWF, щоб отримати розмір тестування у розмірі тестового пункту.

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

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

Для обчислення техніки оцінки контрольної точки ми враховуємо наступні змінні.

  • Складність вимоги до тесту

Складність вимоги до тесту

  • Інтерфейс з іншими вимогами

Інтерфейс з іншими вимогами

  • Загальна кількість пунктів перевірки

Загальна кількість пунктів перевірки

  • Дані базового тесту

Дані базового тесту

Потім нам потрібно розглянути весові вектори для кожної зі змінних даних та впорядкувати їх наступним чином.

вагові вектори для змінних даних

Коефіцієнт коригування = Середнє значення (добуток складності ваги та коефіцієнта ваги) / 30

Тестова точка налаштування для проектування тестового випадку = Загальна контрольна точка X (1 + коефіцієнт коригування для дизайну тест-кейсу)

селен із запитаннями на співбесіду c #

Скоригована точка тесту для виконання тесту = Загальна точка тесту X (1 + коефіцієнт коригування для тестування)

Загальний бал тесту (нормалізований) X (1 + коефіцієнт коригування для проектування / виконання тестового кейсу) = скоригований тестовий бал для проектування / виконання тестового кейсу

Загальні зусилля в годинах роботи на людину (PH) = Кількість нормованих тестових балів / Продуктивність (у Нормованих тестових балах на годинні години)

Приклади оцінки тестів

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

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

Тепер скажімо, сценарій тесту 1 отримав 5 очікуваних результатів тесту, сценарій тесту 2 6 очікуваних результатів тесту, сценарій тесту 3 лише 2 очікувані результати тесту, сценарій тесту 4 9 очікуваних результатів тесту, сценарій тесту 5 також 9 очікуваних результатів тесту.

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

Складні класи матимуть більше 7 очікуваних результатів, тоді як прості складатимуться з менш ніж 5 очікуваних результатів, а помірні сценарії складатимуться від 4 до 7 очікуваних результатів.

Таким чином, ми класифікуємо тестовий сценарій 1 і тестовий сценарій 2 як помірні сценарії, сценарій 5 та сценарій 6 як складні, а тестовий сценарій 3 - як прості.

Тепер ми застосуємо тестові точки до всіх цих сценаріїв. Ми застосовуємо 5 тестових балів для складних класів, 3 для помірних та 2 для простих сценаріїв.

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

Сценарій 1: 3 тестові бали * 5 очікуваних результатів тесту = скориговані тестові бали = 25
Сценарій 2: 3 тестові бали * 6 очікуваних результатів тесту = скориговані тестові бали = 30
Сценарій 3: 2 тестові бали * 2 очікувані результати тесту = скориговані тестові бали = 4
Сценарій 4: 5 тестових балів * 9 очікуваних результатів тесту = скориговані тестові бали = 45
Сценарій 5: 5 тестових балів * 9 очікуваних результатів тесту = скориговані тестові бали = 45

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

Сценарій тесту 1: 25 скоригованих тестових балів * 5 годин на людину = 125 годин на людину
Сценарій тесту 2: 30 скоригованих тестових балів * 5 годин на людину = 150 годин на людину
Сценарій тесту 3: 4 скориговані точки тесту * 5 годин на людину = 20 годин на людину
Сценарій тесту 4: 45 скоригованих тестових балів * 5 годин на людину = 225 годин на людину
Сценарій тесту 5: 45 скоригованих тестових балів * 5 годин на людину = 225 годин на людину

Отже, загальна приблизна кількість людських годин становить: 745 годин на людину

Використовуйте метод оцінки точки використання

Метод Use-Case Point базується на випадках використання, коли ми розраховуємо загальні зусилля щодо оцінки тесту на основі випадків використання або вимог.

Ось детальний процес методу оцінки точки використання:

Використовуйте метод оцінки точки випадку

Прикладом того ж є те, що в певній вимозі ми маємо 5 випадків використання, варіант використання 1, варіант використання 2,…, варіант використання 5 відповідно. Тепер давайте розглянемо, що варіант використання 1 складається з 6 учасників, варіант використання 2 складається з 15 учасників, випадки використання 3, 4 та 5, 3, 4 та 5 учасників відповідно.

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

Ми вирішили присвоїти 2 бали винятковим випадкам використання, 1 позитивним і -1 - негативним.

Таким чином, ми класифікуємо випадки використання 1 і 5 як позитивні, випадок використання 2 як винятковий, а випадки використання 3, 4 як негативні відповідно на основі наших вищезазначених припущень.

Отже, необроблені ваги акторів = Варіант використання 1 = (загальна кількість акторів) 5 * 1 (призначена точка) = 5. Аналогічно

Приклад використання 2 = 15 * 2 = 30.

Повторюючи процес для решти випадків використання, ми отримуємо Неперероблені ваги актора = 33

Вага неопрацьованого випадку використання = загальний номер. випадків використання = 5

Неопрацьована точка використання = Некориговані ваги акторів + Некоригована вага випадку = 33 + 5 = 38

Точка обробленого випадку використання = 38 * (0,65+ (0,01 * 50) = 26,7 або 28 годин на людину приблизно

Техніка розподілу робочої фази

Техніка розподілу робочої фази може бути описана на наступних етапах.

  • Розбийте загальну роботу на етапи.
  • Почніть з найпростішої фази та призначте для неї приблизне значення оцінки.
  • Потім перейдіть до визначення наступної можливої ​​фази, яка могла б розпочатися після завершення цієї фази.
  • Виведіть можливий набір значень наближення, які можна застосувати до цієї фази, і виберіть максимальне значення серед усіх отриманих значень наближення.
  • Підсумуйте приблизне значення оцінки, додавши значення оцінки поточного фазового зусилля до вже існуючого значення.
  • Продовжуйте кроки 3 - 5, поки не будуть вичерпані всі фази, визначені на першому кроці.
  • Прийміть остаточне приблизне значення оцінки як остаточне.

Припустимо, у вимозі є 5 обов’язкових фаз. Отже, на початковій фазі 1 ми припускаємо, що загальні зусилля, що потрібні, складають 35 людино-годин, а потім ми розпочинаємо наступну фазу 2, для якої ми маємо 4 порівняльних припущення 35, 45, 55 та 65 відповідно.

Отже, ми враховуємо 65 людино-годин, що є максимальним значенням тут. На фазі 3, 4, 5 ми отримуємо оцінки (12, 33, 43, 54), (15, 10, 7, 8) та (2, 16, 5, 13) відповідно. Застосовуючи згаданий принцип, ми отримуємо 185 годин роботи відповідно.

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

9 загальних порад щодо того, як точно оцінити час тестування

Фактори, що впливають на оцінку тестування програмного забезпечення, та загальні поради щодо точної оцінки:

# 1) Подумайте про деякий час буфера
Оцінка повинна включати певний буфер. Але не додайте буфер, що нереально. Наявність буфера в оцінці дозволяє впоратися з будь-якими затримками, які можуть виникнути. Наявність буфера також допомагає забезпечити максимальне покриття тесту.

# 2) Розглянемо цикл помилок
Оцінка тесту також включає цикл помилок. Фактичний цикл тестування може зайняти більше днів, ніж передбачалося. Щоб уникнути цього, слід врахувати той факт, що цикл випробувань залежить від стабільності збірки. Якщо збірка не є стабільною, тоді розробникам може знадобитися більше часу на виправлення, і очевидно, що цикл тестування автоматично розширюється.

Як додати Maven в затемнення

# 3) Наявність усіх ресурсів за розрахунковий період
Оцінка тесту повинна враховувати всі відпустки, заплановані членами групи (як правило, довгі відпустки) на найближчі кілька тижнів або наступні кілька місяців. Це забезпечить реальність оцінок.

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

# 4) Чи можемо ми проводити паралельне тестування?
У вас є кілька попередніх версій того самого продукту, щоб ви могли порівняти результати? Якщо так, тоді це може трохи полегшити ваше тестування. Вам слід подумати про оцінку на основі вашої версії продукту.

№5) Оцінки можуть піти неправильно - тому часто відвідуйте оцінки на початкових етапах, перш ніж це робити.
На ранніх стадіях нам слід часто повторно відвідувати оцінки тестів і за потреби вносити зміни. Ми не повинні продовжувати оцінку, коли її заморожуємо, якщо не відбудуться серйозні зміни у вимогах.

# 6) Подумайте про свій минулий досвід, щоб судити!
Досвід минулих проектів відіграє життєво важливу роль при підготовці оцінок часу. Ми можемо спробувати уникнути всіх труднощів або проблем, з якими стикалися в минулих проектах. Ми можемо проаналізувати, як склались попередні оцінки і наскільки вони допомогли вчасно доставити товар.

№7) Розглянемо сферу проекту
Знайте, яка кінцева мета проекту та перелік усіх кінцевих результатів. Фактори, які слід враховувати для малих та великих проектів, дуже різняться.

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

№8) Ви збираєтеся проводити випробування на навантаження?
Якщо вам потрібно витратити значний час на тестування продуктивності, тоді оцініть відповідно. Оцінки проектів, які передбачають випробування на навантаження, слід розглядати по-різному.

# 9) Чи знаєте ви свою команду?
Якщо ви знаєте сильні та слабкі сторони людей, які працюють у вашій команді, тоді ви можете більш точно оцінити завдання тестування. Оцінюючи, слід враховувати той факт, що всі ресурси можуть не давати однакового рівня продуктивності. Деякі люди можуть виконувати швидше порівняно з іншими. Хоча це не є головним фактором, це додає до загальної затримки результатів.

Висновок

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

Це також важливо для прийняття відкритої думки для налаштування необхідних процесів. Успішна реалізація цих процесів призводить до загального вдосконалення процесу тестування.

Це гостьова стаття автора “Н. Сандх'я Рані ”.

Рекомендована література

^