Методи або категорії тестування програмного забезпечення [закрито]


16

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


8
Яка частина цього була заплутаною чи неповною? en.wikipedia.org/wiki/Software_testing
S.Lott

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

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

Відповіді:


38

На мою думку, широкими категоріями будуть:

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

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

Тестування сірого ящика - це гібрид попередніх двох.

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

Загальними класифікаціями тестування були б:

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

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

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

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

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

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

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

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

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


5
+1 ... і, на жаль, все ще є ручні тести навіть після всього цього.
Стівен Еверс

2
і тест на Стрес - всі можливі сеанси тестування тієї самої маски в той же час і безперервно сценарій тестування, десь включений як частина UAT, btw +1
mKorbel

1
Ви не пропускаєте тестування покриття / покриття галузей? Крім того, працює під якоюсь системою перегляду пам’яті, на кшталт «Електричної огорожі», або Valgrind?
Брюс Едігер

1
@Bruce Ediger: покриття - це статистика для тестування білого поля, а не метод тестування, а інструменти, які ви описуєте, призначені для тестування перф.
Стівен Еверс

Мені доводиться відрізнятись від "інструментів ... для тестування перф". У деяких мовах (C або C ++), виконуючи цілу партію одиничних тестів у valgrind, ви знайдете помилки, яких не знайде жоден з інших перелічених вище випробувань. Valgrind - це, безумовно, інструмент налагодження, але запускати тести у програмі, що працює на вашій увазі, дуже потрібно.
Брюс Едігер

4

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

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


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