База знань

Регресійне тестування (Regression testing)

Регресійне тестування (Regression testing) є одним з важливих моментів якісного тестування програмного забезпечення, його невід’ємною частиною. Мета регресійного тестування – переконатися, що нові зміни в коді не вплинули негативно на існуючий функціонал. Проведення даного виду тестування гарантує, що старий код все ще працює в той час як зроблені нові зміни в коді в тому числі ті, які спрямовані на усунення раніше виявлених багів.

regr_test

Регресійне тестування необхідно в наступних випадках

1)зміни у вимогах і зміна в коді згідно нових вимог;

2) додавання нового функціоналу;

3)виправлення функціонального дефекту, наприклад щодо таких аспектів, що розробляється, як:

  • бізнес правила (Business Rules);
  • корекція, узгодження і відкат транзакцій (Transaction corrections, adjustments and cancellations);
  • адміністративні функції (Administrative functions)
  • аутентифікація (Authentication);
  • рівні авторизації (Authorization levels);
  • відстеження документів і звітності (Audit Tracking);
  • зовнішній інтерфейс (External Interfaces);
  • сертифікація вимог (Certification Requirements);
  • вимоги до звітності (Reporting Requirements);
  • архівні дані (Historical Data);
  • юридичні або регуляторні вимоги (Legal or Regulatory Requirements);

4)виправлення нефункціонального дефекту, щодо таких аспектів як:

      • продуктивність (Performance): час відгуку системи, пропускна здатність і т.п .;
      • масштабованість (Scalability);
      • максимальна кількість одночасно працюючих користувачів (Capacity);
      • доступність (Availability);
      • надійність (Reliability);
      • відновлюваність (Recoverability);
      • наскільки просто вносити зміни (Maintainability);
      • наскільки просто підтримувати продукт в робочому стані (Serviceability)
      • безпека (Security);
      • керованість (Regulatory / Manageability);
      • взаємодія з навколишнім ПО (Environmental);
      • забезпечення цілісності даних (Data Integrity);
      • ергономіка, зручність використання кінцевим користувачем (Usability);
      • сумісність (Interoperability).

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

Доцільно виділити ряд складнощів з якими стикається QA в процесі регресійного тестування:

      1. Згодом набори регресійних тестів (test suits) стають досить великими. Повне їх виконання вимагає великих витрат часу і коштів.
      2. Стає складно зменшувати тестові набори з метою досягнення максимального покриття коду.
      3. Визначення частоти проведення тестів регресії. Наприклад, при кожній зміні або кожен новий білд, або коли пофіксили ряд багів.

Регресійне тестування може проводиться з використанням наступних технік:

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

відбір тест кейсів для регресійного тестування.

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

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

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

Автоматизація

Якщо продукт піддається частим змінам, витрати на регресійне тестування збільшуються. Ручне виконання тест кейсів вимагає великих витрат часу і ресурсів. Тому в більшості випадків вдаються до автоматизації регресійного тестування. Для автоматизації тестування використовують різні інструменти. Одним з найбільш популярних є Selenium. Також використовується: Quick Test Professional, Rational Functional Tester, Microsoft Visual Studio for Testers.

Управління версіями вихідного коду

У процесі розробки ПЗ, код постійно модифікується, частота релізів / ітерацій безпосередньо впливає на кількість тестування. «Гнучкі» методології (Agile: Scrum, XP, Kanban, Lean) розробки ПЗ пропагують короткі ітерації (так звані «спринти» в термінології Scrum’а), відповідно істотно збільшується кількість необхідного регресійного тестування. Щоб гарантувати ефективне регресійне тестування потрібно дотримуватися певних правил:

– код, який піддається регресійному тестуванню, повинен бути під контролем так званого інструменту управління конфігураціями (Configuration Management Tool). Це потрібно для того, щоб відстежувати зміни в коді;

– неприпустимо вносити зміни в код в процесі регресійного тестування;

– база даних, яка використовується для регресійного тестування, повинна бути ізольована. Неприпустимою є зміна бази даних.
Є кілька видів регресійних тестів:

1) Верифікаційні тести (Verification Tests), які можна розділити на:

      • Санітарне тестування (Sanity testing) – проводиться для того, щоб переконатися в виправленні бага виявленого в попередньому білді, а також що  внесений дефект не пошкодив суміжний функціонал.
      • Димове тестування (Smoke testing or Build Verification testing), яке представляє собою набір тестів, мета яких – переконатися, що в новому білді основна функціональність програми не порушена. Іншими словами – це коротке тестування всіх основних функцій виготовленого ПЗ.

2) Безпосередньо саме регресійне тестування – повторне виконання тестів, які були написані і проведені в попередніх білдах і не виявили багів.

3) Тести які проводилися в попередніх білдах і виявили баги. Надалі баги були виправлені і закриті. Але якщо в ході розробки ділянки коду, де був раніше виявлений дефект змінився, то швидше за все баг проявиться знову. Щоб цього не допустити необхідно час від часу проводити тести, які раніше виявили баги.

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

Нижче представлені деякі положення щодо того, як проводити регресійне тестування:

      1. Повний регресійне тестування проводитиметься досить рідко – раз в реліз. А іноді, якщо релізи досить часті – раз на найбільш значні релізи.
      2. Починати потрібно з димового тестування. Якщо хоча б один тест призводить до дефекту, то більш детальне тестування вважається недоречним. Білд повертається на доопрацювання.
      3. Якщо димове тестування пройшло успішно, то проводиться санітарний тестування.
      4. З регресійних тестів, які раніше не виявили баги, відбираються ті, які тим чи іншим способом «стикаються» зі змінами в білді.
      5. Аналогічним чином (як в пункті 4) відбираються тести для регресійного тестування раніше виявлених багів;
      6. Регресивні тести, які успішно виконувалися і не приводили до помилки протягом декількох білдів, вважаються закритими. Далі їх використовують так, як описано в пункті 4.
      7. Для тестів регресії, які передбачається проводити більше 3-5 разів рекомендується писати скрипти для автоматизації процесу. Це відноситься до всіх груп тестів регресії.

Відбір тестів для Фінального регресійного тестування здійснюється за такими принципами:

      • В першу чергу відбирають тести забраковані (failed) два і більше разів. У тому числі й ті, які виявляли баги, що вимагають доопрацювання (re-do).
      • У другу чергу відбираються тести забраковані один раз, і успішно пройдені повторно.
      • Далі відбираються всі тести, які були пройдені успішно (pass), але проводилися тільки один раз.
      • Потім проводяться всі інші тести, в залежності від поставленого завдання.

Для наочності при проведенні регресійного тестування можна використовувати наступну таблицю:

№ тесту № версії № бага № версії № бага

Кількість стовпців відповідає кількості версій.

Набагато більше інформації на курсі базовий модуль тестування