Регресійні види тестування (Regression testing)
Регресійне тестування (regression testing): Тестування вже протестованої програми, що проводиться після модифікації для впевненості в тому, що процес модифікації не вніс або не активізував помилки в областях, що не зазнавали змін. Проводиться після змін у коді програмного продукту або його оточенні. (ISTQB)
Регрес- Це протилежність прогресу. Будь-яке ПЗ у міру прогресу у функціоналі неминуче ускладнюється, збільшуються взаємозв'язки у функціях тощо, і щоб у тому, що у існуючої системі не починається регрес, корисно іноді проводити її повне тестування. І тим більше логічно перетестувати все, що можна, якщо в систему були внесені якісь суттєві зміни. Але цього не достатньо. По-суті, проблема набагато серйозніша – ми щоразу не знаємо, що принесе із собою нова функціональність у системі. Нам щоразу треба припустити/дізнатися/протестувати нові взаємодії в системі, а не тестувати лише нові функції в ізоляції від інших. Старий функціонал із новим якщо починають перетинатися - треба заново розчехляти аналітику, виявляти нові ситуації, які можуть виникнути, писати нові тест-кейси, які торкаються вже не так функціональні, як інтеграційні аспекти. Тому з'ясування "чи не настав регрес" (увага, не плутати з "чи не настала регресія") - постійне завдання, яке також необхідно вирішувати в контексті maintenance testing.
Регресійне тестування (Regression Testing) - збірна назва для всіх видів тестування програмного забезпечення, пов'язаних із змінами, спрямованими на виявлення помилок у вже протестованих ділянках вихідного коду, на перевірку того, що нова функціональність не заафектила (affect) стару. Такі помилки – коли після внесення змін до програми перестає працювати те, що мало продовжувати працювати, – називають регресійними помилками (regression bugs). Регресійні тести повинні бути частиною релізного циклу (Release Cycle) та враховуватися під час тестової оцінки (test estimation).
Під час коригування програми необхідно гарантувати збереження якості. Для цього використовується регресійне тестування - дорога, але необхідна діяльність в рамках maintenance testing, спрямована на повторну перевірку коректності зміненої програми. Відповідно до стандартного визначення, регресійне тестування - це вибіркове тестування, що дозволяє переконатися, що зміни не викликали небажаних побічних ефектів, або що змінена система, як і раніше, відповідає вимогам. Регресійне тестування зазвичай проводиться перед релізом нової версії програми. Це відбувається так: протягом якогось часу робляться якісь фічі та інші завдання, вони тестуються окремо і зливаються у загальну гілку (майстер/девелоп - найчастіше ця гілка називається залежно від процесів у проекті). Далі,
Головним завданням maintenance testing є реалізація систематичного процесу обробки змін у коді. Після кожної модифікації програми необхідно переконатися, що на функціональність програми не вплинув модифікований код. Якщо такий вплив виявлено, говорять про регресійний дефект. Для регресійного тестування функціональних можливостей, зміна яких не планувалося, використовуються раніше розроблені випробування. Одна з цілей регресійного тестування полягає в тому, щоб, відповідно до критерію покриття коду, що використовується (наприклад, критерієм покриття потоку операторів або потоку даних), гарантувати той же рівень покриття, що і при повному повторному тестуванні програми. Для цього необхідно запускати тести, що стосуються змінених областей коду або функціональних можливостей.
Інша мета регресійного тестування полягає в тому, щоб переконатися, що програма функціонує відповідно до своєї специфікації, та що зміни не призвели до внесення нових помилок до раніше протестованого коду. Ця мета завжди може бути досягнута повторним виконанням всіх тестів регресійного набору, але перспективніше відсіювати тести, на яких вихідні дані модифікованої та старої програми не можуть відрізнятися. Важливим завданням регресійного тестування є також зменшення вартості та скорочення часу виконання тестів.
Можна зробити висновок, що регресійне тестування виконується, щоб мінімізувати регресійні ризики. Тобто ризики того, що при черговій зміні продукт перестане виконувати свої функції. З регресійним тестуванням щільно пов'язана інша активність – імпакт аналіз (Impact Analysis, аналіз впливу змін). Підсумкова область регресії називається Regression Scope/Scope of Regression.
Класифікація регресійного тестування :
Перевірити все (Retest All): Як випливає з назви, всі тест-кейси в наборі тестів повторно виконуються, щоб гарантувати відсутність помилок, які виникли через зміну коду. Це дорогий метод, оскільки він потребує більше часу та ресурсів у порівнянні з іншими методами;
Мінімізація набору тестів (test suite minimization) прагне зменшити розмір тестового набору з допомогою усунення надлишкових тестових прикладів з тестового набору;
Завдання вибору тесту (test case selection) пов'язані з проблемою вибору підмножини тестів, які будуть використовуватися перевірки змінених частин програмного забезпечення. Для цього потрібно вибрати підмножину тестів із попередньої версії, які можуть виявляти несправності, ґрунтуючись на різних стратегіях. Більшість задокументованих методів регресійного тестування зосереджено саме на цій техніці. Звичайна стратегія у тому, щоб зосередити увагу на ототожнення модифікованих частин SUT (system under test) й у вибору тестових випадків, які стосуються ним. Наприклад, техніка повного повторного тестування (retest-all) - одне із наївних типів вибору регресійного тесту шляхом повторного виконання всіх видів тестів від попередньої версії нової. Вона часто використовується в промисловості через її простого та швидкого впровадження. Проте її здатність виявлення несправностей обмежена. Таким чином, значний обсяг робіт пов'язаний із розробкою ефективних та масштабованих селективних методів;
Завдання визначення пріоритетів тесту (test case prioritization). Її цілі полягають у виконанні замовлених тестів на основі будь-якого критерію. Наприклад, на основі історії, бази чи вимог, які, як очікується, призведуть до більш раннього виявлення несправностей або допоможуть максимізувати деякі інші корисні властивості;
Гібридний: Гібридний метод є комбінацією вибіркового та пріоритезації. Замість того, щоб вибирати весь набір тестів, виберіть ті тест-кейси, які повторно виконуються в залежності від їх пріоритету;
Типи регресії за Канером :
Регресія багів (Bug regression) – спроба довести, що виправлена помилка насправді не виправлена;
Регресія старих багів (Old bugs regression) - спроба довести, що зміна коду чи даних зламало виправлення старих помилок, тобто. старі баги почали знову відтворюватися;
Регресія побічного ефекту (Side effect regression) - спроба довести, що недавня зміна коду або даних зламала інші частини програми, що розробляється;
Регресія в Agile :
В Agile продукт розробляється в рамках короткої ітерації, яка називається спринтом, яка триває 2-4 тижні. У Agile існує кілька ітерацій, тому це тестування відіграє важливу роль, оскільки в ітераціях додається нова функціональність чи зміни коду. Набір регресійних тестів має бути підготовлений на початковому етапі та оновлюватися з кожним спринтом. У Agile перевірки регресії поділяються на дві категорії:
Регресія рівня спринту (Sprint Level Regression): виконується здебільшого нових функцій чи поліпшень, внесених у останній спринт. Тест-кейси з набору тестів вибираються відповідно до нових доданих функцій або зроблених поліпшень;
Наскрізна регресія (End to End Regression): включає всі тест-кейси, які повинні бути повторно виконані для наскрізного тестування всього продукту, охоплюючи всі основні функції;
Смоук тестування (Smoke testing)
Тест "на дим" (smoke test): Вибір із загальної кількості запланованих тестових сценаріїв, що покриває основну функціональність компонента або системи. Проводиться з метою переконатися, що базові функції програми загалом працюють коректно, без заглиблення у деталі. Щоденне складання та тест "на дим" є передовими практичними методами. Вхідний тест, тест верифікації складання. (ISTQB)
Тест верифікації складання (build verification test): Набір автоматичних тестів, що валідують цілісність кожної нової збірки та верифікують її ключову/базову функціональність, стабільність та тестування. Даний вид тестування використовується там, де є висока частота збірок (наприклад, проекти з використанням гнучких методологій розробки) і виконується для кожної нової збірки перед передачею її в тестування. також регресійне тестування, тест "на дим". (ISTQB)
Smoke testing, BVT - Build Verification Testing, BAT - Builds Acceptance Testing, Breath Testing, Shakeout/Shakedown Testing, Intake test, і навіть у російськомовних варіантах димове, дим, димне, тестування складання тощо. - це підмножина регресійного тестування, короткий цикл тестів, що виконується для кожної нової збірки для підтвердження того, що після внесених змін стартує і виконує основні функції без критичних і блокуючих дефектів. У разі відсутності таких дефектів Smoke testing оголошується пройденим, і команда QA може починати подальше тестування повного циклу, інакше, складання оголошується дефектною, що робить подальше тестування марною тратою часу та ресурсів. У такому разі складання повертається на доопрацювання та виправлення. Smoke testing зазвичай використовується для Integration,
Якщо ми говоримо про сайт інтернет-магазину, то сценарій може бути таким:
Сайт відкривається
Можна вибрати випадковий товар і додати його до кошика
Можна оформити та сплатити замовлення
Якщо ми говоримо про мобільний додаток, наприклад, messenger, то:
Додаток встановлюється та запускається
Можна авторизуватись
Можна написати повідомлення випадковому контакту
Невелика шпаргалка за ступенем важливості:
smoke – найважливіше. Тест-кейси грають дуже важливу роль цьому рівні тестування, тому межа метрик (metric limit) часто відповідає 100% чи приблизно 100%;
critical path – повсякденне. Тести критичного шляху запускаються для перевірки функціональності, що використовується типовими користувачами в їхній повсякденній діяльності. Є багато користувачів, які зазвичай використовують певну частину функціональності програми, яку необхідно перевірити, як тільки smoke етап буде успішно завершено. Тут ліміт метрик трохи нижче, ніж у smoke і відповідає 70-80-90% залежно від мети проекту;
extended – все. Виконується вивчення всієї функціональності, зазначеної у вимогах. Перевіряється навіть функціональність із низьким пріоритетом. При цьому в цьому тестуванні потрібно розуміти, який функціонал найцінніший, а який менш важливий. За умови, що ви маєте достатньо часу або інших ресурсів, тести на цьому рівні можна використовувати для вимог з низьким пріоритетом;
Саніті тестування (Sanity testing)
Тест працездатності (sanity test): Див. Тест "на дим". (ISTQB)
Інші джерела:
Sanity testing також є підмножиною регресійного тестування і виконується до або замість повної регресії, але після smoke. Ці два підвиди схожі, але в цілому Sanity використовується на стабільніших білдах для визначення працездатності певної частини програми після внесення змін.
Примітка. Санітарним це тестування в російськомовному середовищі назвалося з абсолютно незрозумілих причин, але гуглиться тільки так. Насправді ж дослівно перекладається як тестування на осудність/розумність/працездатність/узгодженість або за версією ISTQB “Тест працездатності”.
Підтвердне тестування: Тестування, при якому виконуються тестові сценарії, які були не пройдені при останньому запуску, з метою підтвердити успішність виправлень. (ISTQB)
Повторне тестування - це тип тестування, що виконується в новій збірці по проваленому на старій збірці тест-кейсу з тим самим оточенням та даними, для перевірки того, що цей дефект тепер усунений. Ре-тест виконується перед sanity-тестуванням, пріоритет ре-тесту вище регресійних перевірок, тому воно має виконуватися перед ними.
Тестування N+1 (N+1 testing)
Варіант регресійного тестування представлений N+1. У цьому методі тестування виконується в кілька циклів, у яких помилки, виявлені в тестовому циклі «N», усуваються та повторно тестуються у тестовому циклі N+1. Цикл повторюється, доки не буде знайдено жодної помилки.
Різниця між повторним та регресійним тестуванням:
Регресійне тестування проводиться для підтвердження того, що недавня зміна програми або коду не вплинула на існуючі функції. Повторне тестування проводиться для підтвердження того, що тест-кейси, які не пройшли, відбуваються після усунення дефектів;
Мета регресійного тестування – підтвердити, що нові зміни коду не повинні мати побічних ефектів для існуючих функцій. Повторне тестування проводиться на основі виправлень дефектів;
Перевірка дефектів перестав бути частиною регресійного тестування. Перевірка дефекту є частиною повторного тестування;
Залежно від проекту та наявності ресурсів, регресійне тестування може проводитись паралельно з повторним тестуванням. Пріоритет повторного тестування вищий за регресійне тестування, тому воно проводиться перед регресійним тестуванням;
Регресійне тестування називається загальним (generic) тестуванням. Повторне тестування – це планове (planned) тестування;
Регресійне тестування проводиться для пройдених Test Case. Повторне тестування проводиться лише невдалих тестів;
Регресійне тестування перевіряє наявність несподіваних побічних ефектів. Повторне тестування гарантує, що початкову помилку було виправлено;
Test case для регресійного тестування можна отримати з функціональної специфікації, user tutorials and manuals, і навіть defect reports щодо виправлених проблем. Test case для повторного тестування неможливо отримати до початку тестування;
Чи може бути ситуація, коли регресія проводиться не після зміни коду?
Так, у ситуаціях із зовнішніми факторами: зміни до БД, версії ОС тощо.
Джерела:
Додатковий матеріал:
Last updated