Чи гарна ідея вимірювати ефективність методу, використовуючи одиничний проміжок часу тесту?

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

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

Для цього чи корисна ідея:

• Щоб використовувати одиничні тести, щоб мати уявлення про витрачений час на виконання тієї ж дії² n разів,

• Використовувати тайм-аут за тест через [TestMethod, Timeout(200)]атрибут у C #?

Я очікую декілька проблем з таким підходом:

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

• Чи дійсно вимірюється час очікування випробувань у Visual Studio дійсно, що очікується для вимірювання, беручи до уваги, що ініціалізація та очищення відсутні для цих тестів або занадто короткі, щоб впливати на результати?

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

• Тестова розробка (TDD) неможлива для цих тестів. Як би це не вдалося, в першу чергу, перш ніж почати впроваджувати код?

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

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

Я помиляюся? Чи є інші проблеми, що робить цілком неприйнятним використання для цього тестів?

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

^{Ually Насправді очікується, що одиничні тести працюватимуть лише на ПК-розробниках, які мають порівняну продуктивність, що зменшує розрив між найшвидшими машинами, які ніколи не зможуть провалити тест на ефективність, і найповільнішими машинами, які ніколи не зможуть пройти його.}

^{² Під дією я маю на увазі досить короткий фрагмент коду, який витрачає на виконання кілька мілісекунд.}

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

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

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

Однак, ось деякі моменти ваших відповідних питань:

• концептуально: це правда, що це не те, що стосується одиничних тестів. Але поки всі усвідомлюють, що тест не повинен підтверджувати щось, що має робити QA, це добре.

• Visual Studio: про це нічого не можна сказати, оскільки ми не використовуємо блок тестування модулів від VS.

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

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

• Час виконання: Як було сказано, ми не проводимо ці тести на машинах розробників, а як частина системи складання у вигляді тесту на інтеграцію.

Я здебільшого наближений до вашого мислення. Просто викладаю міркування незалежним потоком.

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

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

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

Я не знаю про функціональність Visual studio, але, як правило, вам потрібен ширший інструмент для профілювання.

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

Деякі міркування в конкретному порядку, які можуть бути корисними:

• Тестування працездатності QA було трудомістким і склало власний графік (скажімо, один раз під час ітерації), тож натискання на контроль джерела не було проблемою.
• Наша система була великою та модульною, одиничні тести були надто детальними для наших потреб, і ми створили спеціальні «жирні» одиничні тести, ретельно розроблені, щоб викликати проблеми з ефективністю у конкретних сферах, що цікавлять (вони також були класифіковані, але це деталі реалізації).
• Звичайні обмеження для одиничних тестів все ще застосовуються: вони повинні бути невеликими, швидкими і точними.
• Щоб виключити вплив тестових рамок, вони працювали спеціальною обгорткою, тому ми точно знали , скільки часу займає дана операція.
• Їх можна записати до завершення фактичної реалізації (результати можуть бути неактуальними або корисними, залежно від процесу. Можливо, розробники все ще експериментують з реалізацією і хотіли б побачити, як йде в цілому).
• Вони працювали на сервері CI після кожної збірки, тому загальний час виконання слід тримати порівняно коротко (якщо це не так, точніше визначити точну зміну, що викликала проблему, стає значно складніше).
• Сервер CI був потужним і його фіксували апаратно, тому ми вважали це виділеною машиною (можна використовувати дійсно виділений сервер за допомогою віддаленого агента побудови).
• Тестова обгортка зібрала всю відповідну інформацію (технічні характеристики, назви тестів / категорії, завантаження системи, минулий час тощо) та експортувала її у вигляді звітів або до бази даних.
• У нас був пристосування для JIRA витягування цих звітів та малювання приємних діаграм за назвою / категорією / номером збірки з деякими елементами управління (накладання попереднього випуску на поточний тощо), тому розробники можуть швидко побачити їх вплив, а менеджери можуть отримати огляд (деякі червоні, всі зелені, знаєте, для них це важливо).
• Можна було проаналізувати, як проект проходить з часом, використовуючи зібрану статистику.

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

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

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