Меню

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

test coverage software testing

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

Повне керівництво тестуванням програмного забезпечення для тестування: Як перевірити більше, заощадити час та досягти кращих результатів тестування:

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

найкраще програмне забезпечення для Windows 10

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

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

Що таке покриття тесту?

Простіше кажучи, висвітлення: 'Що ми тестуємо та скільки тестуємо?'

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

покриття тесту

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

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

Тестове покриття та покриття коду

Висвітлення тестів часто плутають із покриттям коду. Хоча основні принципи однакові, це дві різні речі.

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

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

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

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

  • Якщо створено 10 вимог і 100 тестів - коли ці 100 тестів націлені на всі 10 вимог і не залишають жодної, ми називаємо це адекватним охопленням тестуванням на рівні проектування.
  • Коли виконується лише 80 із створених тестів і націлюється лише на 6 вимог. Ми говоримо, що 4 вимоги не покриваються, хоча 80% тестування виконано. Це статистика охоплення на рівні виконання.
  • Коли лише 90 тестів, що стосуються 8 вимог, призначили тестерів, а решта - ні, ми вважаємо, що охоплення тестовим завданням становить 80% (8 з 10 вимог).

Також важливо, коли потрібно розрахувати покриття.

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

Також читайте => Процес управління випуском та розгортанням

Мій досвід

Сцена 8 років тому: Коли я мав 2 роки досвіду в галузі тестування програмного забезпечення, я думав, що це добре, якщо я не знаю деяких основ тестування програмного забезпечення, тому що я можу навчитися з досвідом, і я це теж зроблю.

Я мав рацію - і теж не так.

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

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

Максимізуйте покриття тестуванням за менший час

Ось мій досвід одного з тогочасних інтерв’ю:

Як ви переконаєтесь, що охоплення тестом є повним або максимальним? Мене запитали.

Ммммм ... Я переконуюсь, що перевіряю всі функції , Я сказав.

S o Ви говорите, що як тільки ви протестуєте всі функціональні можливості, ви відчуваєте, що охопили максимум програми / продукту з точки зору тестування , інтерв'юер зазнав невдачі.

Мммм ... ну ... .мммм ... так, адже, протестуючи всі функціональні можливості, ви впевнені у поведінці програми / продукту, Я підтримав свою відповідь .

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

Зараз я ставав нетерплячим, невідомим про те, що збирався вивчити одну з найважливіших тем про тестування програмного забезпечення - ' Покриття тесту ” .

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

Значення охоплення тесту

Покриття тестування може мати різний зміст у різному контексті. Давайте відкриємо ці контексти один за одним:

Покриття товару - Які аспекти товару ви розглядали?

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

Приклад №1:

Якщо «ніж» - це продукт, ви тестуєте; просто не концентруйтеся на перевірці, чи правильно він ріже овочі / фрукти. Є й інші аспекти, на які слід звернути увагу, наприклад - користувач повинен мати можливість комфортно з цим поводитися.

Приклад №2:

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

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

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

Покриття ризиків - на які ризики ви протестували?

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

Приклад №1:

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

Ну, ось що означає покриття ризику. Виявлення ризику за заявкою / продуктом та ретельне тестування - це завжди хороша практика.

Приклад №2:

Під час тестування сайту електронної комерції тестер врахував усі ефективні фактори, але не врахував ризик того, що кількість користувачів одночасно і в день Супер ПРОПОЗИЦІЇ завітають на веб-сайт, не врахований ризик виявився величезною помилкою.

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

Покриття вимог - Які вимоги ви перевірили?

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

Приклад №1:

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

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

Приклад №2:

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

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

Також читати => Як створити матрицю простежуваності вимог

Як застосувати належний метод випробування?

Поінформованість - це все:

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

=> Ознайомтесь із цією статтею, щоб дізнатися більше про це та як ним користуватися: Як створити матрицю простежуваності вимог - точний процес за зразком шаблону

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

Таблиця, наведена нижче, може бути корисною:

Тип тестуЗагальна кількість справВиконані справиСтатусКоментарі
Функціональний1008050 пас, 30 невдача
Сумісність100п'ятдесят45 пас, 5 невдача
Юзабіліті10010098 пас, 2 невдачі
Остаточна регресія10010099 пас, 1 невдача

Як переконатися, що все перевірено?

  • Кожен випробувач повинен знати вимоги та методи випробувань
  • Розставте пріоритетні вимоги та зосередьте свою енергію там, де це найбільш потрібно
  • Будьте проінформовані про те, чим певний випуск відрізняється від попереднього, щоб ви могли точніше визначити критичні вимоги та зосередитись на максимально позитивному висвітленні
  • Адаптувати автоматизацію тестів
  • Використовуйте інструменти управління тестами завжди бути в курсі подій
  • Розумне робоче завдання - спрямовуйте свої найкращі ресурси на вирішення важливих завдань, і дозвольте новим тестувальникам досліджувати більше для нової перспективи
  • Ведення a контрольний список для всіх завдань та різноманітна діяльність
  • Більше взаємодійте зі своїми командами розробників / Scrum / BA, щоб отримати уявлення про поведінку програми
  • Відстежуйте всі свої цикли побудови та виправлення
  • Визначте найбільш вражаючі проблеми в самій початковій збірці (коли це можливо), щоб пізніші могли працювати для кращої стабільності та дістатись до тих областей, заблокованих попередніми проблемами

Критичні сфери та методи ефективного тестування

ефективне тестування

# 1)Переміщення ресурсу: Обмінюйтесь завданнями між членами вашої команди. Це допомагає покращити взаємодію та запобігти концентрації знань.

# два)Покриття сумісності: Переконайтеся, що ви обізнані та включаєте різні браузери і платформи щоб протестувати свою заявку.

# 3)Право власності: Зробіть тестерів підзвітними та дайте їм можливість (з моніторингом та підтримкою, звичайно) для модуля / завдання, над яким вони працюють. Це допомагає формувати відповідальність і дозволяє їм пробувати творчі шляхи, а не йти за побитими.

# 4)Терміни: Знання термінів випуску до початку фази тестування допомагає ефективно планувати

# 5)Спілкування : Залишайтеся на зв'язку з розробником та іншими командами між циклами випуску, щоб знати, що відбувається.

# 6)Ведіть RTM: Діє як хороша похідна на Зацікавлені сторони або клієнти , на основі якого графік випуску може бути підтверджений

Переваги тестування рівня обізнаності тестувальника:

Висновок

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

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

Завдяки більш структурованому підходу, спрямованому на 100% покриття вимог та ефективні методи тестування, ви не підете на компроміс щодо якості.

Ми сподіваємось, методи, викладені в цій статті, дадуть вам підказки.

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

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

^