Чи потрібні нам дані випробувань чи ми можемо покластися на одиничні тести та ручне тестування?

Зараз ми працюємо над середнім / великим проектом PHP / MySQL. Ми проводимо тестування одиниць за допомогою PHPUnit & QUnit, і у нас є два штатні тестери, які тестують додаток вручну. Наші тестові (макетні) дані наразі створюються за допомогою SQL-скриптів.

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

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

Чи варто відмовитися від технічного обслуговування скриптів із тестовими даними та просто дозволити тестерам тестувати додаток без даних? Яка найкраща практика?

— Християнин П
джерело

Відповіді:

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

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

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

EDIT: Гаразд, я отримую те, що ви просите. Відповідь "так", оскільки завдання Tester - не генерувати тестові дані, а лише протестувати додаток. Потрібно створити свої сценарії таким чином, що дозволяє простіше у обслуговуванні та забезпечує введення дійсних даних. Без даних тесту тестеру нічого не доведеться тестувати. Однак, сказав, що якщо у вас є доступ до тестового середовища , я не бачу, чому ви не можете вставити тестові дані вручну, а не за допомогою скриптів.

— AJC
джерело

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

— Крістіан П

@ christian.p перевірити моє оновлення стосовно вашого уточнення питання.

— AJC

Тож ваше рішення полягає в тому, щоб відмовитися від скриптів і просто додати вручну тестові дані через інтерфейс користувача? Як щодо відповіді, яку надав P.Brian.Mackey та його відповіді на з'єднання даних із інтерфейсом користувача?

— Крістіан П

@ christian.p Ну, я погоджуюся, що ви повинні використовувати скрипти. АЛЕ немає ніякої формальності чи правила, яке говорить про те, ЩО ВАМ. Основною причиною використання скриптів для генерації макетних даних є швидкість (автоматизація) та доступ (до тестового середовища). Якщо у вас є доступ, і це швидше і простіше зробити це вручну, немає причини, що ви не можете цього зробити. (АЛЕ ведіть журнал перевірених вами даних).

— AJC

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

— Крістіан П

Так, найкраща практика - тестування одиниць та макет даних. Керівник проекту коректний. Оскільки виконання «простої» зміни тестових даних часто створює помилки, то це є сутністю проблеми.

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

Почніть робити рефактор. Тримайте покращення, щоб вони були керованими. Шукайте анти-шаблони, такі як заняття / методи Бога, не дотримуючись DRY, одноосібної відповідальності тощо ...

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

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

— П.Бріан.Маккі
джерело

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

— Крістіан П

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

— P.Brian.Mackey

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

— Крістіан П

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

— P.Brian.Mackey

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

— Крістіан П

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

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

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

— Отавіо Македо
джерело