Як знати, коли припинити тестування?


23

Я знаю, це дуже принципове питання. Для деяких програмних програм існує велика майже нескінченно велика кількість тестових випадків для програми. Перевіряти всі ці тестові справи не практично. Як ми вирішуємо, коли припинити тестування? (крім "коли гроші закінчуються").


3
коли це не вдається ..
Хав'єр

Я думаю, ви знайдете повідомлення в блозі Майкла Болтона про зупинку евристики для тестування корисним для читання: http://www.developsense.com/blog/2009/09/when-do-we-stop-test/ Ви можете впізнати деякі з люди евристики запропонували в цій темі.
testerab

На мій досвід, цього було досить, застосовуючи принцип Парето .
Амір Резай

Відповіді:


3

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

Помилки, як правило, «кластеризуються» в певних модулях та певних функціях: Щойно ви знайдете помилку в одному, ви знаєте, що вам слід шукати в ньому додатково більше помилок. Для пошуку помилок можна скористатися методами тестування в чорному ящику, тестуванням на білій скриньці та мутаційним тестуванням. Поки ви виявляєте помилки, ви знаєте, що ваш процес тестування працює!

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

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


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

14

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

Це справді питання для хорошого тестера системи (і я не один), але я дам йому постріл.

Ваша основна міра буде тестовим покриттям: яка частина програми була фактично протестована (як одиничним тестом, так і функціонально).

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

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

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

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

(Я думаю, що це називається смугастим, але не цитуйте мене з цього приводу.)

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


4

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


7
Ну ось це проблема проблеми, просто перефразоване, чи не так?
Мартін Вікман

@Martin: мабуть, ні. Замість того, щоб починати з тестового випадку 1 і закінчувати тестовим випадком ∞, ця відповідь повинна змусити запитувача почати з найважливішого тестового випадку і закінчити, коли вони більше не додають значення.

1
Хоча по-філософськи коректно (і продумано), я думаю, що ОП шукає щось трохи зручніше.
Мартін Вікман

"прийнятний" можна визначити заздалегідь. Це дуже допомагає.

@ Thorbjørn: "Можна визначити". Так, але як? Саме це і шукає ОП.
Мартін Вікман

3

"Тестування програми можна використовувати, щоб показати наявність помилок, але ніколи не показувати їх відсутність!" --Edsger Dijkstra

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

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

По суті, ви хочете, щоб вас охопили два великих місця:

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

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


2

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


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

2

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

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

Ось чудовий приклад.


2

Статистики також розглядали це питання - фактично ще в 1970-80-х роках. Враховуючи відповідні припущення щодо виявлення помилок, вони намагаються оцінити кількість помилок за даними тестування. Потім це використовується, щоб визначити, коли зупинити, на основі оптимізації функції втрат. Ознайомтеся з прикладом https://rpubs.com/hoehle/17920 ... для короткого опрацювання однієї з робіт з цього питання, включаючи код R про те, як це зробити на практиці.

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


1

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


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

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

Як системний тестер, я рідко опинився в положенні, коли дата випуску затрималася для проведення додаткових тестів. Я знаю, що ніколи нічого не випробовую повністю - те, що я намагаюся зробити, - це визначити пріоритет. Очевидно, якість дзвінків, які я роблю, про те, які області спробувати в першу чергу, залежать від інформації, яку я отримую про технічний ризик та важливість бізнесу. Найголовніше - це ЗАВЖДИ це бізнес-рішення, а не рішення / тестування щодо того, який рівень ризику компанія готова взяти на себе. Ми можемо порадити, але саме бізнес повинен вирішити.
тестераб

Хоча я повністю погоджуюся: це не робиться, поки його не перевірять. (Я схильний погоджуватися з думкою про те, що нам краще використовувати термін "фіксуюча фаза", ніж тестовий етап.) Моя незгода полягає лише в тому, що я думаю, що тестування за своєю суттю є відкритим - ви ніколи не можете прорисувати лінію і говорити "більше немає тестів, які ми могли б зробити зараз", просто "немає більше тестів, які, на нашу думку, варто зробити зараз".
testerab

1

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


1

Все це зводиться до питання впевненості. Ви впевнені, що система достатньо перевірена?

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

Ось кілька тестів, пов’язаних із "Готовими показниками":

  • Ваша збірка та установка повністю автоматизована і всі тести (блок, gui, інтеграція) виконуються автоматично?
  • Ви пишете свої тести під час (або бажано раніше) написання коду, а не після?
  • Чи відчуваєте ви себе в безпеці, щоб зробити великий рефакторинг коду, не вводячи помилок?
  • Чи достатньо високий рівень охоплення кодом?
  • Чи є у вас команда спеціалізованого тестера? Чи щодня він / вона беруть участь у всьому розвитку, а не лише наприкінці?
  • Ваш тестер вручну (розвідувальний) намагався зламати його без успіху?

Якщо ви можете перевірити ці моменти, то, напевно, ви можете сказати, що ви достатньо протестували.


1

Ніколи, я думаю, ви ніколи не закінчите тестування в системі .. Є так багато змінних, якими ви не можете керувати.

Але, як ми знаємо, ви не можете перевірити "навіки", тому я думаю, що межа в основному залежить від:

  • Коли ризик, пов'язаний із використанням програмного забезпечення, знижується до прийнятного рівня. (як говорить @Graham Lee)
  • Хто користувач системи? це може бути ви чи президент Сполучених Штатів. У першому випадку ви мало хвилюєтесь, якщо з’являється помилка, оскільки ви вирішите її та її зробили. У другому випадку ви не хочете, щоб з’явилася БУДЬ-яка помилка.
  • Які у вас стосунки з клієнтом? Можливо, клієнтом є ваш тато, тож це не так страшно, а може, це велика компанія.
  • Наскільки серйозний помилок для користувачів системи? Чи це спричинить третю світову війну чи просто потворне повідомлення?

0

Коли люди, які мають вийти на розгортання, задоволені.

або в деяких випадках більшість відповідальних сторін задоволені.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.