Які типи програмного тестування ви знаєте? Я чув про тестові розробки, одиничні тести тощо, але не можу зрозуміти їх важливість та різницю. Наприклад, чому ми використовуємо тести регресії або тести прийняття. Яку перевагу вони надають?
Які типи програмного тестування ви знаєте? Я чув про тестові розробки, одиничні тести тощо, але не можу зрозуміти їх важливість та різницю. Наприклад, чому ми використовуємо тести регресії або тести прийняття. Яку перевагу вони надають?
Відповіді:
На мою думку, широкими категоріями будуть:
Тестування чорної скриньки . Ви не можете побачити код і просто прослідковуєте сліпо певною мірою, оскільки те, що є в додатку чи системі, приховано від вас. Таким чином, у цьому випадку люди не знають усіх випадків помилок і повинні вгадувати з різними граничними умовами, які можуть чи не можуть бути очевидними, щоб знайти всі випадки.
Тестування білого ящика . Ви можете побачити код і зможете перевірити, які шляхи коду використовуються, щоб покриття коду могло бути використане як метрику для забезпечення використання всієї логіки в системі. Ідея тут полягає в тому, щоб знати, як виглядає код, щоб допомогти керувати тестами, щоб він був не настільки загадковий, як тестування чорної скриньки.
Тестування сірого ящика - це гібрид попередніх двох.
Прикордонні випадки, як правило, є те, що можна побачити в тестуванні білого поля, оскільки в коді є різні умови, щоб виписувати тести, щоб потрапити, наприклад, якщо у вас була програма, яка запитує номер, а хтось вводить X, як це обробляється слід бачити десь у коді.
Загальними класифікаціями тестування були б:
Одиничні тести . Це, як правило, найменші тести, які перевіряють щось досить специфічне, наприклад, чи обробляє цей метод цей граничний випадок? Зауважте, що тут може бути використана ін'єкційна залежність у випадках, коли за допомогою макетних об'єктів зменшуються залежності для тестів.
Інтеграційні тести . Це тести, в яких підключено пару компонентів і виконуються тести, щоб гарантувати, що компоненти добре працюють разом. Зауважте, що хоч одиничні тести можуть працювати незалежно, саме тут проводиться тест на те, наскільки добре складаються речі, оскільки може виникнути невдала комунікація між шарами, що спричиняє корисність цих тестів для лову різних хатчей. Термін « Кінцеві тести» використовується для інтеграційних тестів, коли повний ланцюжок компонентів тестується від «однієї кінцевої точки програми до іншої» (що б це не означало).
Регресійні тести . Це були тести, зроблені в минулому, які робляться знову, щоб гарантувати, що те, що було виправлено, залишається виправленим і помилки не повторно вводяться в код.
Тести на придатність . Це будуть тести, зроблені для того, щоб побачити, наскільки добре кінцеві користувачі можуть працювати з програмним забезпеченням для виконання різних завдань. Де щось можна автоматизувати, щоб зробити щось швидше або налаштувати інтерфейс користувача, щоб щось було простіше у використанні.
Тести прийняття користувача . Це були б тести, зроблені кінцевими користувачами, щоб вони з перших рук побачили, як щось працює, і погодилися, що програмне забезпечення задовольняє бізнес-потреби, які вимагали цього.
Функціональні тести - це всі види тестів, засновані на функціональній специфікації тестуваного програмного забезпечення. Це завжди чорні тести.
Тести на продуктивність. Це були б тести, зроблені для того, щоб система могла впоратися з певним навантаженням, не надто повільно. Наприклад, тестування нової веб-ферми серверів може одночасно обробляти 100 користувачів, які потрапляють на сайт, було б прикладом тесту на ефективність. Вони також можуть називатися "навантажувальними тестами" або "стрес-тестами", оскільки загалом ідея полягає в тому, щоб або підштовхнути систему до її межі, або перевірити, чи може система обробляти якусь проекцію з іншого відділу. Обґрунтуванням цих тестів є те, що часто є численні параметри конфігурації для оптимізації, які можуть зайняти більше ніж трохи роботи, щоб виявити вузькі місця та вирішити проблеми. Вузьким місцем цього можуть бути пам'ять, введення / виведення, процесор або пропускна здатність мережі, що спричиняє не так сприйнятливість системи, як очікувалося.
Тест-керована розробка - це методологія, яка не стосується конкретного виду тестування, а скоріше тести записуються перед кодом, щоб тести були тим, що рухає розробкою, а не поведінкою , доменом чи характеристикою, які є іншими прикладами з точки зору процес.
Безперервна інтеграція - це практика регулярно виконувати деякі тести, такі як одиничні, інтеграційні та регресійні тести, щоб, якщо зміна порушила тест, це буде спіймано якомога раніше.
Регресійне тестування проводиться для того, щоб нові зміни в системі не порушили жодної існуючої функціональності, на яку не повинно впливати зміни.
Тестування прийняття зазвичай проводиться замовником / клієнтом / бізнес-користувачами, воно часто є більш високим рівнем, ніж інші форми тестування, і воно проводиться так, щоб люди, які запитували зміни, були задоволені ними та дозволили просувати зміни у ваші виробнича система.