Главная » 2012 » Март » 3 » Классы эквивалентности: advanced
19:06
Классы эквивалентности: advanced

Классы эквивалентности: advanced

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

Теория.

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

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

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

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

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

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

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

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

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

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

Практика.

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

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

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

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

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

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

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

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

 

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

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

Просмотров: 766 | Добавил: admin | Рейтинг: 0.0/0
Всего комментариев: 0
Имя *:
Email *:
Код *: