14

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

testing

— Стовп солі
джерело

1

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

— Кріс

11

Те, що повинно бути найправильнішим.

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

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

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

— Берін Лорич
джерело

1

Добре сказано, найкраща відповідь, яку я прочитав поки що.

— Кріс

5

Чорний

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

— Стівен А. Лоу
джерело

2

Якщо, звичайно, тести чорного поля пропустили тестування ключового фрагмента функціональності або конфігурації:}

— Алан

3

@Alan: той самий аргумент стосується і тестування у білій коробці, отже, застереження "покриття добре"

— Стівен А. Лоу

1

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

— Алан

1

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

— Саммі

1

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

— Док Браун

3

Чорна коробка.

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

— Вальтер
джерело

2

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

— Alan

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

— Кріс

2

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

— Енріке
джерело

2

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

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

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

— Джастін Етьє
джерело

1

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

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

— Алан
джерело

1

Я б сказав, що тестування Black Box спочатку просто тому, що як прихильник TDD, тести пишуться раніше, ніж код (або поле) існує в будь-якому випадку :)

Тестування White Box (наскільки я розумію) корисніше для налагодження мислення.

— Матьє М.
джерело

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

— Док Браун

1

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

— Матьє М.

1

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

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

— Етел Еванс
джерело

0

Ні. Я намагаюся писати хороші тести, використовуючи правильний BICEP , пам’ятаючи ПРАВИЛЬНІ граничні умови, незалежно від того, в якому порядку вони приходять на думку. Це обидва абревіатури, запропоновані в Тестуванні прагматичних одиниць .

Моя мета - зосередитись на написанні хороших тестів, а не того, який колір слід написати першим.

— Стівен Еверс
джерело

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

— Етел Еванс

@ Етел Еванс: За визначенням вони не є тестами білого поля. Переважна більшість одиничних тестів - це білі тести, але це не є вимогою. Будь-які тести, які відображають область входів на діапазон виходів функції, є одиничними тестами, але не потрібно знати деталі реалізації.

— Стівен Еверс

0

Спочатку робіть тестування білого поля .

По-друге, для тестування Black Box

> Тестування чорної скриньки

I. Тестер повинен перевірити функціональність програми, наприклад текстове поле, перемикач, список списків, кнопка команд, ... тощо. ,,

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

ІІІ. Тестер повинен перевірити весь потік програми.

Примітка. Щоб перевірити позитивні та негативні умови.

Тестування чорної скриньки чи білої коробки - що робити спочатку?

Чорний