Регресійне тестування

Методика регресійного тестування

Методика призначена для ефективного розв'язання задачі вибіркового повторного тестування. Її вихідними даними є: програма P та її модифікована версія P′, критерій тестування C, безліч (набір) тестів T, які раніше використовувалися для тестування P, інформація про покриття елементів P (M(P,C)) тестами з T. Необхідно реалізувати ефективний спосіб, що гарантує достатній ступінь впевненості в правильності P ', використовуючи тести з T .

Методика будується на основі поєднання процедур звичайного та регресійного тестування

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

  1. Визначити необхідні функціональні можливості програми з використанням, наприклад, методу розбиття на класи еквівалентності.
  2. Створити тести для функціональних можливостей.
  3. Виконати випробування.
  4. У разі необхідності - створити і виконати додаткові тести для покриття структурних елементів, що залишилися (ще не покритих) (попередньо встановивши їх відповідність функціональним вимогам).
  5. Створити базу даних тестів програми.

За аналогією зі звичайним тестуванням, процедура регресійного тестування у процесі супроводу складається з наступних етапів:

  1. Використання функції передбачення доцільності. Якщо прогнозована кількість вибраних тестів більша, ніж поріг доцільності, провести повторний прогін усіх тестів. В іншому випадку перейти до кроку 2.
  2. Ідентифікація змін ΔP у програмі P′ (і множини ΔМ змінених елементів, що покриваються) і встановлення взаємно однозначної відповідності між покриваються елементами М(P, C) і М(P′, C) відповідно до змін: ΔM = (M(P, C ) M(P′, C))(M(P′, C) M(P, C))
  3. Вибір T′⊆T - підмножини вихідних тестів, потенційно здатних виявити пов'язані зі змінами помилки в P′ для повторного виконання на P′ з використанням результатів, отриманих у пункті 2. Це підмножина можна впорядкувати, а також вказати кількість тестів, виконання яких достатньо для відповідності будь-якому критерію мінімізації. Для безпечних методів відбору тестів безліч T′ задовольняє наступним обмеженням: tiT, tiT′ P(ti)P′(ti)
  4. Застосування підмножини T′ для регресійного тестування зміненої програми P′ з метою перевірки результатів та встановлення факту коректності P′ стосовно T′ (відповідно до зміненого технічного завдання), а також оновлення інформації про проходження тестів із T′ на P′.
  5. У разі потреби – створення додаткових тестів для доповнення набору регресійних тестів. Це можуть бути нові функціональні тести, необхідні для тестування змін у технічному завданні або нових функціональних можливостей зміненої програми; нові структурні тести для активізації решти (непокритих) структурних елементів (попередньо встановивши їх відповідність функціональним вимогам, що перевіряються).
  6. Створення T'' - нового набору тестів для P', застосування його для тестування зміненої програми, перевірка результатів і встановлення факту коректності P' стосовно T'', оновлення інформації про хід виконання тесту та створення бази даних тестів зміненої програми для зберігання цієї інформації та вихідних даних тестів.Видалення застарілих тестів. T′′ формується за таким правилом: T′′ = (TTнові) Tустарілі

Система підтримки регресійного тестування

Структура системи підтримки регресійного тестування представлена ​​рис. 14.1. Вихідний код обох версій програми, що тестується, зберігається під управлінням системи контролю версій. Для відбору тестів методом покриття точок використання невиконуваних визначень засобами системи контролю версій створюється файл відмінностей, виходячи з якого обчислюється список доданих, змінених і віддалених рядків вихідного коду, який є зручною формою представлення безлічі ΔP . Потім провадиться перебір цього списку. Якщо який-небудь рядок списку є макровизначенням, здійснюється пошук рядків коду, що містять використання цього макровизначення по всьому тексту програми, що тестується; знайдені рядки приєднуються до множини ΔP . Розширена множина ΔP зіставляється з результатами прогону тестів з множини T на попередній версії програми. Якщо в ході виконання будь-якого тесту ti отримувала управління хоча б один рядок, що входить до множини ΔP тест ti відбирається для повторного запуску.

При створенні нових тестів за методом "підозрілих" станів функція програми, що тестується, що містить цикл обробки подій, доповнюється операторами виведення значень глобальних і видимих ​​локальних змінних. Запуск тестів з множини T′ на профільованій версії програми дозволяє отримати список її станів. Цей список аналізується, і для кожного раніше не спостерігається стану обчислюється список змінних, що змінилися порівняно з відомим станом. Безліч ΔP доповнюється рядками коду, де використовуються змінні цього списку. Для кожного станузазначаються тести, запуск яких необхідний. Нарешті створюється список рекомендованих нових тестів у формі, зручній для сприйняття людиною.

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

Типовий сценарій проведення регресійного тестування програм, написаних мовою C, із застосуванням описаної вище системи складається з наступних етапів:

  1. Обчислюється безліч Р рядків вихідного коду, доданих, віддалених або змінених порівняно з попередньою версією.
  2. Безліч ΔP доповнюється рядками, які безпосередньо не змінювалися, але містять посилання на змінені макровизначення
  3. Обчислюється впорядкована множина регресійних тестів T' , для яких ∀iT′ Ti, j - 1∩ΔP, де Ti, j-1 - безліч рядків вихідного коду продукту, що отримують управління в ході виконання тесту i на версії системи j-1 . Тести впорядковуються щодо зменшення кількості змінених рядків у шляху їх виконання.
  4. Обчислюється список глобальних та локальних змінних, що визначають стан програми s . Вихідний код програми, що тестується, модифікується так, що інформація про стан s (значення глобальних, статичних і локальних змінних) виводиться у зовнішній файл перед запуском тесту і після його закінчення.
  5. Нові тести та тести з безлічі T′ (регресійні тести)виконуються на поточній версії продукту j.
  6. Тести, перевіряють нештатні режими роботи товару, тобто. створюють стану, у яких подальша робота продукту неможлива відповідно до специфікації вимог, виключаються з розгляду. Якщо відомо, що жоден тест не призводить до виникнення нештатних станів, цей етап може бути опущений
  7. Для кожного тесту i обчислюється безліч Tij.
  8. Обробляються результати виконання тестів, і створюється безліч Sj, що складається з початкового стану s0 і всіх кінцевих станів, що спостерігалися. Обчислюється безліч Nj= SjSj-1 всіх нових проти попередніми версіями станів, що є " підозрілим " з погляду наявності помилок, і вектора їх відмінностей від вихідного стану s0 , тобто. змінні, змінені проти s0 .
  9. Багато змінених рядків вихідного коду ΔP доповнюються номерами рядків, де використовуються задані змінні.
  10. Якщо Nj = цикл роботи завершується. Якщо Nj, слід перейти до кроку 4 або, якщо лічильник кількості ітерацій роботи системи перевищує певне граничне значення, повідомити про це користувача. Користувач може прийняти рішення про припинення тестування або пропуск деякої кількості циклів.

програми
Мал. 14.1.Структура системи підтримки регресійного тестування.

Якщо етап 6 виконується автоматично, а етап 7 можна опустити, можлива повна автоматизація регресійного тестування.