Переосмислення класів еквівалентності, частина 1
Переклад: Ольга Алифанова
(Ні, я не буду редагувати цю статтю в вікіпедії. Я не вважаю кумедним або корисним пропонувати свій досвід в обмін на аргументи анонімних любителів. Вікіпедія дуже важлива, тому що служить загальної довідкою, якщо потрібно покритикувати популярне знання, але як і саме популярне знання , вона непоправна. Популярне завжди перемагає, а народ не особливо любить міркувати).
"Класи еквівалентності - це техніка тестування ПО, яка ділить дані, що вводяться на класи еквівалентних один одному значень, на базі яких створюються тест-кейси".
Не зовсім. Немає ніяких підстав вважати, що класи еквівалентності обмежуються "вводяться даними". Розумовий процес поділу на класи еквівалентності може застосовуватися до вихідних даних, версіями продукту, тестовим оточенням, або кейсів як таким. Класи еквівалентності застосовні до чого завгодно, де варіативність може вплинути на результат тесту.
Так, це техніка, але більш підходящим словом буде "евристика". Евристика - це ненадійний метод вирішення проблеми. Класи еквівалентності вкрай ненадійні, але між тим корисні.
"В принципі, тест-кейси пишуться так, щоб покрити кожен клас хоча б один раз. Ця техніка намагається визначити тест-кейси, що виявляють класи помилок, знижуючи тим самим загальну кількість необхідних для роботи тест-кейсів".
Цей текст досить непоганий. Відзначте вираз "в принципі" і використання слова "намагається". Це пом'якшувальні слова, і це важливо, тому що класи еквівалентності - евристика, а не алгоритм.
Говорити, між тим, про "кейсах, які необхідні для роботи" - це відводити розмову в сторону від тестування. Тестування - це не створення тест-кейсів, і це точно не про кількість тест-кейсів, які ви створюєте. Тестування - це проведення експериментів, а загальна кількість експериментів виходить далеко за рамки питань на кшталт "який тест-кейс мені написати далі?". Ця фраза повинна звучати як "знижуючи тестові зусилля".
"Перевага цього підходу - це скорочення часу, необхідного на тестування ПО завдяки меншій кількості тест-кейсів".
Вибачте але немає. Перевага класів еквівалентності зовсім не в зниженні кількості тест-кейсів. Це навіть не про зниження тестових зусиль як таких (хоча вірно, що ця техніка "намагається" знизити зусилля по тестуванню "). Класи еквівалентності - це просто спосіб систематично вгадувати, де, можливо, ховаються найбільші баги, і допомагає фокусувати ваші зусилля. класи еквівалентності - це техніка пріоритетності. Вона допомагає вам пояснювати свій вибір і захищати його. Краща приоритезация сама по собі не знижує зусилля по тестуванню, але її мета - наштовхнутися на великі баги раніше, а не пізніше. і ми хочемо наштовхнутися на них целе аправленно, а не випадково. І якщо ми добре зробили свою роботу, то так, ми витратимо менше зусиль на тестування. Зниження тестових зусиль - побічний ефект техніки класів еквівалентності.
"Класи еквівалентності зазвичай застосовуються до даних, які вводяться в тестовий компонент, але можуть застосовуватися і до вихідних даних в рідкісних випадках. Як правило, вони випливають з вимог або специфікації для введення даних, що впливають на обробку тестового об'єкта".
Класи еквівалентності - це процес, яким всі ми неформально займаємося, не тільки в тестуванні, але і в повсякденному житті. Коли ви відкриваєте двері - ви свідомо вирішуєте штовхнути саме цей квадратний сантиметр металевої дошки? Ні, зовсім ні. Ви знаєте, що для більшості дверей абсолютно не важливо, куди їх штовхають. Всі місця, які можна штовхнути, еквівалентні. Це клас еквівалентності! Ми застосовуємо класи еквівалентності до всього, з чим ми взаємодіємо.
Так, ми застосовуємо цю техніку до вихідних даних і так, ми можемо розглядати класи еквівалентності, засновані на специфікації, але ми також розглядаємо класи, засновані на тому, що ми вивчили про тестованому ПО. Ми застосовуємо класи еквівалентності, грунтуючись на всьому, що ми знаємо. Якщо те, що ми знаємо, невірно (наприклад, якщо в ПО є несподівані баги), то наші класи еквівалентності теж будуть невірні. І це нормально, якщо ви розумієте, що це евристика, а не золотий квиток в країну ідеального тестування.
"Фундаментальна концепція класів еквівалентності виходить із відносини еквівалентності. Програмна система - це, по суті, розрахункова функція, впроваджена як алгоритм на якомусь мові програмування. Якщо задані вхідні дані, деякі інструкції цього алгоритму покриваються (див." Покриття коду "), а деякі - немає ... "
Фундаментальна концепція класів еквівалентності не має нічого спільного з інформатикою або розрахунками. Вона про логіку. Логіка існувала задовго до комп'ютерів. Клас еквівалентності - це, грубо кажучи, набір. Це набір речей, які поділяють певну властивість. Цікаве з точки зору класу еквівалентності властивості - це корисність для дослідження специфічного ризику продукту. Іншими словами, тестування класів еквівалентності - це переконання, що кожен член певної групи речей буде з більш-менш однаковою ймовірністю знаходити певний вид бага, якщо його застосувати в певному виді тесту.
Якщо я визначу "тестові умови" як щось про продукт або його оточенні, що може бути досліджено при тестуванні, то я можу визначити класи еквівалентності приблизно так: Клас еквівалентності - це набір тестів або тестових умов, які еквівалентні по відношенню до певного продуктового ризику в певному контексті.
Це визначення має на увазі, що два види даних, які не еквівалентні для одного бага, можуть бути еквівалентні для пошуку іншого бага. Це також має на увазі, що якщо ми невірно змоделювали продукт, ми не дізнаємося правильні класи еквівалентності. В цілому, враховуючи, що баги бувають всіх розмірів і сортів, виділити ідеально вірні класи еквівалентності - це приблизно як заздалегідь, без тестування, знати, де знаходяться баги в продукті. Це пов'язано з тим, що класи еквівалентності засновані на припущеннях, які типи багів можуть зустрітися в продукті.
Основна проблема з більшістю рад з тестування