Які недоліки автоматизованого тестування?

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

Ось декілька, які я придумав:

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

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

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

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

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

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

• Інструментальні потреби: ви там на місці. Не так багато додати до цього.

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

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

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

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

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

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

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

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

• Час, необхідний для встановлення тесту у складному додатку для підприємства.
• Поводження зі старими тестами, які виходять з ладу неправильно, інакше кажучи, система розвинулася і тепер тести неправильні.
• Помилкова впевненість у виправленому або невідомому покритті тесту.

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

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

Звичайно, моя думка - це програма, яка є старшою, ніж її одиничні тести.

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

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

Хоча тестування автоматизації має багато переваг, у нього є і свої недоліки. Деякі з недоліків:

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

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

Нещодавно я задав питання про тести на розробку ігор - це BTW, як я знав про це. Відповіді там вказали на деякі цікаві, конкретні недоліки:

1. Це дорого робити, коли ваш код повинен бути сильно пов'язаний .
2. Це важко зробити, коли потрібно знати про різні апаратні платформи, коли ти повинен аналізувати вихід для користувача, а результат коду має сенс лише в більш широкому контексті .
3. Тестування UI та UX дуже важко .
4. І, зокрема, автоматизовані тести можуть бути дорожчими та менш ефективними, ніж купа дуже дешевих (або безкоштовних) бета-тестерів .

4-й пункт змушує мене згадати певний досвід. Я працював над дуже худорлявою, орієнтованою на XP, компанією Scrum, в якій настійно рекомендувались тестові одиниці. Однак на шляху до більш тонкого, менш бюрократичного стилю компанія просто нехтувала побудовою команди з контролю якості - у нас не було тестерів. Так часто клієнти виявляють банальні помилки, використовуючи деякі системи, навіть із покриттям тесту> 95%. Тож я додам ще один момент:

• Автоматичні тести можуть відчути, що якість та тестування не є важливими.

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

Нарешті, я часто зустрічаю проблему: автоматичне тестування може залежати від інструментів, і ці інструменти можуть бути погано написані. Я запустив проект за допомогою XUL деякий час тому, і, людино, просто боляче писати одиничні тести для такої платформи. Я запустив ще одну програму, використовуючи Objective-C, Cocoa та Xcode 3, і модель тестування на ній була в основному купою обхідних шляхів.

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

Два, які не згадуються:

• Тривалість годинного годинника може знадобитися для запуску великого тестового набору

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

• Неможливість деяких методів написання тесту

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

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

Хочу додати ще одне, помилкове почуття безпеки.

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

Важко переконати управління / венчурного капіталіста

• testautomation збільшує авансові витрати.
• testautomation збільшує час виходу на ринок.
• користь від теставтомації припадає на середину та термін. жорстока конкуренція зосереджується більше на короткотермінових вигодах.

Докладніше див. Тестування керованого ринку .

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