Різниця між тестом прийняття та функціональним тестом?


147

Яка реальна різниця між приймальними тестами та функціональними тестами?

Які основні моменти або цілі кожного? Де б я не читав, вони неоднозначно схожі.

Відповіді:


172

У моєму світі ми використовуємо такі терміни:

функціональне тестування : це перевірочна діяльність; ми створили правильно працюючий продукт? Чи відповідає програмне забезпечення бізнес-вимогам?

Для цього типу тестування у нас є тестові випадки, які охоплюють усі можливі сценарії, про які ми можемо придумати, навіть якщо цей сценарій навряд чи існує "в реальному світі". Роблячи цей тип тестування, ми прагнемо максимально охопити кодом. Ми використовуємо будь-яке тестове середовище, яке ми можемо використати в той час, воно не повинно бути «виробничим» калібром, доки воно є корисним.

тестування приймання : це діяльність з перевірки ; ми правильно побудували? Це те, що клієнту дійсно потрібно?

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

  • Надійність, доступність : перевірено стрес-тестом.

  • Масштабованість : перевірено навантаженням.

  • Корисність : перевіряється за допомогою перевірки та демонстрації замовнику. Чи налаштований інтерфейс користувача на свій смак? Ми розмістили брендинг клієнтів у всіх потрібних місцях? Чи є у нас усі поля / екрани, про які вони просили?

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

  • Ремонтопридатність : перевірено шляхом демонстрації того, як ми доставлятимемо оновлення / виправлення програмного забезпечення.

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

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


плюс 1 за приємну відповідь і "ака, безпека, просто підходити" :). Смішно :) Так команда не врахувала той факт, що в реальному світі хтось може замінити знак + справжнім словом, як я. Тому вони не дозволяють вводити +1 як перше слово в коментарі, але вони дозволяють "плюс 1" :). Тож функціонально вони не змогли перевірити це належним чином :). Myabe вони просто спробували прийняти тести :)
Geo C.

71

Мені подобається відповідь Патріка Каффа. Що я хотів би додати - це відмінність між рівнем тесту та типом тесту, який був для мене відкривачем очей.

рівні тесту

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

  1. Тестування компонентів / одиниць => перевірка детальної конструкції
  2. інтеграція компонентів / одиниць тестування => перевірка глобального дизайну
  3. тестування системи => перевірка системних вимог
  4. тестування системної інтеграції => перевірка системних вимог
  5. тестування прийняття => перевірка вимог користувача

типи випробувань

Випробування типу є характеристиками, вона фокусується на конкретний тест мети. Види тестів підкреслюють ваші аспекти якості, також відомі як технічні або нефункціональні аспекти. Типи тестів можуть бути виконані на будь-якому рівні тесту . Мені подобається використовувати в якості тестових характеристик якісні характеристики, згадані в ISO / IEC 25010: 2011.

  1. функціональне тестування
  2. тестування на надійність
  3. тестування працездатності
  4. тестування на працездатність
  5. тестування безпеки
  6. тестування на сумісність
  7. тестування на ремонтопридатність
  8. тестування на переносимість

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


2
Це найкраща відповідь на це питання, і "відмінність рівня тесту від типу тесту" - це те, що більшість відповідей тут пропущено, і ви маєте рацію, це "відкривачка для очей"
zmilan

23

Різниця полягає в тестуванні проблеми та вирішенні. Програмне забезпечення - це вирішення проблеми, і те, і інше можна перевірити.

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

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

Функціональне тестування - протестуйте продукт, переконавшись, що він має такі якості, які ви створили або побудували (функції, швидкість, помилки, послідовність тощо)

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


9

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

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

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

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


Мені подобається ця відповідь :) Вони майже однакове.
анбан

1
UAT так, в кінцевому рахунку робиться клієнтом, який «платить». Однак більшість часу вперше робиться особою із забезпечення якості, яка "добре" тестує і "намагається" зламати систему та шукати всі "дрібниці", перш ніж "платячий" клієнт переходить на це. Автоматизація селену для повторення виснажливих речей також може використовуватися разом із справжнім тестуванням UAT тестером QA, але ніколи не повторювати справжнє тестування, щоб перевірити всю функціональність, яку очікують у всіх очікуваних браузерах. UAT досить пояснює себе. Я думаю, що більшість описів функціональних тестувань здаються робототехнічними та словниковими.
Том Стікель

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

Це добре. Коли я помітив це розпливчасте визначення ... мені просто довелося прокоментувати "функціональне тестування: прийміть ділові вимоги та протестуйте все це з точки зору функціональності".
Том Стікель

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

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

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

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


2

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

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


1

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

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

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


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

1

Тестування на прийняття :

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

Хоча це продовжує говорити:

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

з позначкою "потрібне цитування".

Функціональне тестування (яке фактично переспрямовує на Тестування системи):

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

Тож із цього визначення вони майже те саме.

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


0

Зв'язок між ними: Тест на прийняття зазвичай включає функціональне тестування, але він може включати додаткові тести. Наприклад, перевірка вимог до маркування / документації.

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

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

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


0

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

  • Функціональне тестування: "ця кнопка не працює"
  • Нефункціональне тестування: "ця сторінка працює, але занадто повільна"

Щодо функціонального тестування порівняно з нефункціональним тестуванням (їх підтипи) - дивіться мою відповідь на це запитання .


-1

Вони те саме.

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

Ви можете зробити тестування приймання в автоматизованому порядку або вручну.


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