Напишу некоторые свои мысли по поводу такого базового понятия в тестировании, как классы эквивалентности.

Теория.

Класс эквивалентности — это класс, в рамках которого все тесты являются эквивалентными.

Эквивалентные тесты — это тесты, которые приводят к одному и тому же результату.

То есть, если мы выполним два любых теста из одного класса эквивалентности — то получим один и тот же результат. Тут предполагается не результат «pass», а то, что мы идем по тем же самым шагам, используя другие данные и получаем аналогичный результат (с поправкой результата на эти самые другие данные, конечно).

Классы эквивалентности обычно тестируют на границах и их девиациях (+-1, например), потому что вероятность поймать ошибку на таких значениях выше из-за возможных ошибок на операциях сравнения.

Я бы разделил настоящий класс эквивалентности от предполагаемого. Дальше мои мысли.

Настоящий класс эквивалентности — это то, что описано выше. Это тот класс, в рамках которого все тесты являются эквивалентными. Для такого класса вероятность ошибки или успеха для каждого отдельного теста одинакова, а значит, тестировать такой класс на границах не имеет смысла, эти тесты дадут такую же вероятность ошибки, как и любые другие из данного класса. На то он и настоящий.

Парадокс 1: если класс эквивалентности настоящий (правильный), то тестировать его на границах нет смысла, можно выбрать любой тест и проверить только на нем. При этом можно утверждать, что все остальные тесты из данного класса также приведут к такому же результату (pass или fail).

Предполагаемый класс эквивалентности — это класс эквивалентности, в котором мы не уверены, но который определили как таковой на основании каких-то критериев (спецификации, кода, размышлений, убеждений, анализа и т.п.). Поскольку мы в нем не уверены (он не настоящий), то, соответственно, мы его тестируем на границах и около-граничных значениях. И это логично. НО: этого мало. У нас нет достаточной уверенности, что сам класс мы определили правильно и, теоретически, мы вполне можем пропустить ошибку где-то в середине этого класса, поскольку на самом деле это может оказаться не один класс, а несколько (просто мы об этом не знали), и вот в этих самых не найденных классах мы можем не запустить ни один тест и пропустить там ошибку.

Парадокс 2: тестировать предполагаемый класс эквивалентности на границах мало, вероятность пропустить ошибку все равно есть, поскольку нет уверенности в том, что мы правильно разбили тесты по классам эквивалентности.

Учитывая парадоксы 1 и 2, получается, что настоящий класс эквивалентности тестировать на границах нет смысла, а предполагаемый — не надежно. Зачем же тогда вообще нужны эти самые граничные значения? В разделе «практика» опишу свое видение.

Практика.

Классы эквивалентности придумывались тогда, когда был функциональный подход, не было никакой графики, не было фреймворков. И в таком случае деля тестов на эквивалентные и объединяя их в классы, можно было существенно сократить количество тестов, при этом с высокой долей вероятности уверяя в том, что ошибка не будет пропущена.

В настоящее время с этим есть проблемы:

• Многопоточные приложения. Мы можем потратить кучу времени и докопаться до почти настоящего класса эквивалентности, но другой поток с легкостью может внести суматоху в наш тест, и в итоге он окажется не эквивалентным другому. А значит, и не находится в нашем классе эквивалентности.
• Графика. Сейчас все больше приложений разрабатываются под тач-скрины. Естественно, что поля ввода заменяются на графические элементы, которые можно легко подвигать, переместить и т.п. Для графических элементов, на которых построен функционал, классы эквивалентности найти крайне тяжело. Если это и возможно — то не окупится…
• Фреймворки. Сейчас приложения настолько активно используют фреймворки, что большинство внутренней логики и базового кода находится именно внутри используемых фреймворков, что в корне ломает все планы по использованию классов эквивалентности (их невозможно найти, не зная реализации функций фреймворка). Тут мы либо доверяем фреймворку и принимаем риск того, что могут быть ошибки, либо не доверяем и тестируем сам фреймворк вместо тестирования приложения, написанного на его основе.

Получается, в теории классы эквивалентности — это хорошо. В современной практике — их грамотное использование крайне затруднительно и не окупается.

Что же делать?

Обычно не задаются вопросом поиска настоящего класса эквивалентности и даже хорошего предполагаемого класса. Берут очевидные данные (спецификацию, схемы, дизайн), и по ним находят простейшие классы. Дальше для этих классов проверяют на границах и околограничных значениях, и пару тестов добавляют из случайных значений внутри класса (очень примерного класса, по вышеуказанным причинам).

Как это работает?

Учитывая несколько случайных значений внутри класса, при достаточно большом числе повторения одного и того же теста мы имеем достаточно хорошее покрытие. Если взять лимит (вспоминаем математику) — то идеальное, полное покрытие для данного workflow. Учитывая то, что сейчас настроить регрессию на базе автоматизированных тестов не представляется большой проблемой, это вполне жизненный и реализуемый вариант, который позволяет минимальными усилиями добиться хорошего результата. Ну если, конечно, автоматизацию в принципе можно назвать минимальными усилиями 

P.S. Это мои краткие мысли. Еще можно долго рассуждать на тему того, какие есть критерии для эквивалентности тестов, как находить эквивалентность комлексных действий (а не банальных манипуляцийсо сферическим конем в вакууме с одиночным полем ввода) и т.п. Но я не хочу делать слишком большую заметку. Если интересно — опишу это позже.

http://testingforall.com/blog/?p=209