Комп’ютерні тести, найкращі практики

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

Невеликий обхід через теорію

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

Чотири основні рівні тестування можна очистити:

Блокові тести: вони спрямовані на перевірку функціональності певного розділу коду, незалежно один від одного. Тому ми потенційно виявимо дефект у конкретному місці.
Інтеграційні тести: Після проведення модульних випробувань мова йде про тестування системи в цілому, тобто шляхом інтеграції всіх її компонентів. Можливі два варіанти, в компонентному режимі або в режимі "великого вибуху".
Системні тести: метою цього етапу є перевірка правильності роботи розробки в теорії, але також у контексті, заданому користувачем.
Приймальні випробування які прагнуть перевірити розвиток між різними командами проектів (MOE => MOA), а потім з користувачами.

У межах цих різних рівнів є різні типи тестів. Ми можемо навести найпоширеніші:

І на практиці, що це дає ?

Необхідність мати стратегію та план випробувань з фази розробки

В ідеалі, ми повинні будувати функціональні тестові приклади як за специфікаціями, так і коли. Це дозволяє, наприклад, підтвердити поведінку, яку очікує користувач розмірковуючи про численні можливі випадки. Тестові приклади також можна використовувати для ілюстрації специфікацій, надаючи приклади, корисні як для розробника, так і для користувача. Оскільки значна частина помилок спричинена непорозумінням (Користувачі/MOA або MOA/MOE), було б неправильно не сприяти хорошому спілкуванню з перших фаз.

A fortiori, використання кількісних тестів дозволяє виявити крайні або прикордонні випадки. Якщо для розрахунку потрібна, наприклад, ціна виконання, що робити, якщо вона від’ємна? Чи повинен я надати захисну огорожу, якщо вона смокче? Таким чином, ми уникаємо ризику задавати ці запитання на наступних етапах, де вартість виправлення помилок може бути вищою (особливо при керуванні V-циклом, менша у Agile).

У цьому сенсі так звані методи “безперервного тестування” (Test Driven Development, Behavioure Driven Development), які поєднують в собі як кодування, так і автоматичні тести в процесі побудови, забезпечують велику перевагу: негайне виявлення помилок шляхом одночасного тестування технічної та функціональної частин. Час економиться, а час - це гроші.

Важливість планування

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

Різні фази тесту перекриваються між собою, тому ми не можемо перейти до фази, не перевіривши попередню, що само собою зрозуміло. Не проводити наскрізних випробувань перед випробуваннями на дим, - скрикнув маршал Ла Паліс! Однак, більш конкретно, особливу увагу слід приділити послідовності цих тестів, а також їх тривалості. Наскільки складною є вправа, настільки складною є оцінка навантаження, характерна для кожного проекту. Непередбачена подія, яку ніколи не можна виключати, виявлення проблеми іноді може призвести до появи багатьох інших, більш численних і більш серйозних для виправлення. Потім маленький жучок раптово перетворюється на мурашник, де багато інших звіряток спокійно чекають, присідаючи в тіні, готові з’явитися, як тільки виявлять одного з них. Щоб уникнути будь-якого впливу на наступні фази та на дату виробництва, настійно рекомендується давати собі запас близько 10% від загального очікуваного навантаження, щоб бути комфортним, якщо трапиться несподіваний елемент.

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

Жодним тестом ви не будете нехтувати

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

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

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

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

Інші типи тестів трохи більш випадкові, але які засвідчать надійність розробки, тести, які іноді називають "руйнуванням" мають на меті імітувати непослідовну поведінку користувачів. Візьмемо приклад з «ціни» фінансових продуктів. Що станеться, якщо я вводжу текст у поле кількості? У мене є можливість, можливо, ввести інший термін дії опціону, ніж запропонований, але чи можу я надіслати, в режимі беркерка, запит на ціну, якщо обрана дата припадає на вихідні чи державні свята? Натомість я отримаю синій екран смерті або таку непослідовну ціну, яка загрожує дестабілізацією всієї світової банківської та фінансової системи? Історія вчить нас, що саме під час випробувальної фази цього типу Чорнобильська електростанція вибухнула, звичайно, вона має межі для цього режиму "деглінго".

Оптимізація, переробка та моніторинг тестів

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

Щоб проілюструвати можливу оптимізацію тестів, які потрібно виконати, розглянемо приклад наступної розробки:

Процес містить 3 кроки для досягнення трьох результатів: END, вихід 1 або вихід 2. Крок характеризується дією (наприклад: клацання) або конкретною умовою (напр .: Запитана ціна> x),
Якщо Крок 1 - ІСТИНА => Крок 2; Інакше END,
Крок 2 включає подвійну неконфігурувану умову (АБО не може бути змінена),
Якщо Крок 2.a або Крок 2.b має значення TRUE => Крок 3; Інші результати 1,
Крок 3 перевіряє лише одну умову одночасно (3.a, 3.b) або обидві одночасно, Можна встановити,
Якщо крок 3 має значення TRUE => Вихід 2; Інші результати 1.

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

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

Автор

Спираючись на значний досвід роботи в галузі ринкових фінансів, Крістоф був консультантом МОУ протягом 7 років. Майже два роки він зараз є керівником проекту з питань дотримання вимог.

Дізнайтеся про інші його статті

Новини та подібні події

Привіт світ: весняне завантаження та Ehcache !

Використання springboot з ehcache дозволяє легко та швидко реалізувати логіку кешу. І факт інтеграції його в наш додаток завдяки різним анотаціям дозволяє нам отримати користь від сили Весни ....

Розробка вимог до порятунку управління історією користувачів

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