Особливості вимог програмного забезпечення. Методи тестування. Фази тестування. Класи еквівалентності.

Вимоги (Requirements) до програмного забезпечення – сукупність тверджень щодо атрибутів, властивостей, або якостей програмної системи, що підлягає реалізації:

  • Одиничність – Вимога описує одну і тільки одну річ.
  • Завершеність – Вимога повністю визначена в одному місці і вся необхідна інформація присутня.
  • Послідовність – Вимога не суперечить іншим вимогам і повністю відповідає зовнішній документації.
  • Атомарність – Вимога не може бути розбита на ряд більш детальних вимог без втрати завершеності.
  • Відстежування – Вимога повністю або частково відповідає діловим потребам як заявлено зацікавленими особами і задокументовано.
  • Актуальність – Вимога не стала застарілою з часом.
  • Здійснимість – Вимога може бути реалізовано в межах проекту.
  • Недвозначність – Вимога коротко визначена без звернення до технічного жаргону та інших прихованих формулювань. Вона виражає об’єктивні факти, можлива одна і тільки одна інтерпретація. Визначення не містить нечітких фраз. Використання негативних тверджень заборонено.
  • Обов’язковість – Вимога представляє певну характеристику, відсутність якої призведе до неповноцінності рішення, яка не може бути проігнорована.
  • Верифікованість – Реалізованість вимоги може бути визначена через один з чотирьох можливих методів: огляд, демонстрація, тест чи аналіз.

Методи тестування:

  1. Білий ящик (WhiteBox) – цей метод заснований на тому, що розробник тесту має доступ до коду програм і може писати код, який пов’язаний з бібліотеками ПЗ, що тестується.
  2. Чорний ящик (Black Box) – цей метод заснований на тому, що тестувальник має доступ до ПЗ тільки через ті ж інтерфейси, що і замовник або користувач, або зовнішні інтерфейси, що дозволяють іншому комп’ютеру або іншому процесу підключитися до системи для тестування.
  3. Сірий ящик (Grey Box) – поєднує елементи двох попередніх підходів.

Фази тестування:

  1. Створення тестового набору (Test Suit) для конкретного середовища тестування (Testing Environment)
  2. Прогон програми на тестах з отриманням протоколу результатів тестування (Test Log)
  3. Оцінка результатів виконання програми на наборі тестів з метою прийняття рішення про продовження або зупинку тестування.

Класи еквівалентності (Equivalence class):
Підхід полягає в наступному: вхідні / вихідні дані розбиваються на класи еквівалентності, за принципом, що програма веде себе однаково з кожним представником окремого класу. Таким чином, немає необхідності тестувати всі можливі вхідні дані, необхідно перевірити по окремо взятому представнику класу.
Клас еквівалентності – це набір значень змінної, який вважається еквівалентним.

Тестові сценарії еквівалентні, якщо:

  • Вони тестують одне і те ж;
  • Якщо один з них знаходить помилку, то й інші виявлять її;
  • Якщо один з них не знаходить помилку, то й інші не виявлять її.

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

Розбиття

Приклад:
Припустимо, ми тестуємо Інтернет-магазин, який продає олівці. У замовленні необхідно вказати кількість олівців (максимум для замовлення – 1000 штук). Залежно від замовленої кількості олівців змінюється вартість:
1 – 100 – 10 грн. за олівець;
101 – 200 – 9 грн. за олівець;
201 – 300 – 8 грн. за олівець і т.д.
З кожною новою сотнею, ціна зменшується на гривню.

Якщо тестувати «в лоб», то, щоб перевірити всі можливі варіанти обробки замовленої кількості олівців, потрібно написати дуже багато тестів (згадуємо, що можна замовити аж 1000 штук), а потім ще все це і протестувати. Спробуємо застосувати розбиття на класи еквівалентності. Очевидно, що наші вхідні дані можна розділити на наступні класи еквівалентності:
Невалідне значення:> 1000 штук;
Невалідне значення: <= 0; Валідне значення: від 1 до 100; Валідне значення: від 101 до 200; Валідне значення: від 201 до 300; Валідне значення: від 301 до 400; Валідне значення: від 401 до 500; Валідне значення: від 501 до 600; Валідне значення: від 601 до 700; Валідне значення: від 701 до 800; Валідне значення: від 801 до 900; Валідне значення: від 901 до 1000. На основі цих класів ми і складемо тестові сценарії. Отже, якщо взяти по одному представнику з кожного класу, то отримуємо 12 тестів. Наступна лекція

  1 коментар до “Особливості вимог програмного забезпечення. Методи тестування. Фази тестування. Класи еквівалентності.

  1. qalearning
    9 Червня, 2015 at 11:12

    Зміст:

    1. Введення в тестування програмного забезпечення
    2. Особливості вимог програмного забезпечення. Методи тестування. Фази тестування. Класи еквівалентності.
    3. Види Тест Кейсiв. Стани Тест Кейсiв. Багтрекінгові системи. Серйозність і пріоритет дефекту. Життєвий цикл дефекту.
    4. Рівні тестування
    5. Види тестування ПО. Функціональне тестування (Functional Testing). Тестування безпеки (Security and Access Control Testing). Тестування взаємодії (Interoperability Testing)
    6. Нефункціональне тестування ПЗ
    7. Види тестування, пов’язані зі змінами. Кросбраузерність.
    8. Agile (Гнучка модель). Scrum. Selenium

We #StandWithUkraine.
Learn how you can help too!

#Stand­With­Ukraine

We don't know how long the war will last. But what we do know is that we can't stand aside and watch.

The fastest way you can help too is to support Ukraine financially. The National Bank of Ukraine (NBU) has opened a multi-currency account for that purpose. Learn more

This account accepts donations in US, Canadian and Australian dollars, euros, British pounds, Swiss francs, yuan and yen.

UA823000010000032302338301027

Also accepting cryptocurrency donations – the fastest way to help. Learn more

BTC – 357a3So9CbsNfBBgFYACGvxxS6tMaDoa1P

ETH, USDT (ERC-20) – 0x165CD37b4C644C2921454429E7F9358d18A45e14

Spread the word!