21 января 2011 г.

Эффективное применение комбинаторных техник тест дизайна.

Долго не получалось добраться до блога, но вот я опять вещаю :). Сначала хочу напомнить, что мы уже разобрали 6 техник тест дизайна:
 * Allpairs Algorithm testing
 * Orthogonal Arrays Testing
 * State-Transition Testing
 * Decision Table Testing
 * Boundary Value Testing
 * Equivalence Class Testing

И перед тем как приступить к разбору новых техник тест-дизайна хотелось бы написать статью об использовании комбинаторных техник (например Orthogonal Arrays Testing или Allpairs Algorithm testing). Точнее о разумном использовании комбинаторных техник. На написание этой статьи меня натолкнула статья Баха и Шредера "Pairwise Testing: A Best Practice That Isn’t". Они в ней рассматривают проблемы конкретно allpairs algorithm testing, но как по мне, то все их замечания можно применить к любым комбинаторным техникам.

Статья их появилась из-за того, что многие стали относить allpairs algorithm testing к best practices заочно, считая его панацеей в тестировании. Мол применил технику и все ненужные тестовые данные исчезли, а остались исключительно отличные тестовые данные, которые обеспечивают идеальное тестовое покрытие. Ну и до поры до времени тестировщики чувствуют себя спокойно и уверенно, пока баги на удивление таки не начинают выползать. Почему такое может происходить мы попробуем рассмотреть в этой статье.

Где нас ждет провал?
Allpairs algorithm достаточно деликатная техника, ее нужно использовать с умом. Бах и Шредер приводят следующие случаи, когда вас может поджидать провал в использовании попарного тестирования:
 1. Вы определили неверные значения переменных/входные значения.
 2. Вы определили не достаточно хорошие оракулы.
 3. Вы не уделили внимание наиболее возможным комбинациям переменных.
 4. Вы не знаете как переменные взаимодействуют.

Будем разбирать наглядно что это значит.


 1. Вы определили неверные значения переменным/входные значения.

Перед тем как разбирать пример стоит сначала упомянуть что такое n-way тестовые наборы. n-way тестовый набор - это такой набор, в котором встречаются все возможные комбинации значений n переменных. Т.е. при применении техники allpairs alghoritm мы получаем 2-way тестовый набор данных, т.к. в тестовом наборе существуют только все возможные комбинации ПАР значений переменных.
Ну и соответственно n-way fault - это ошибка, к которой приводит взаимодействие значений n переменных.

Так вот. Шредер(Schroeder) провел исследование над 2мя системами (the Loan Arranger System (LAS) и Data Management and Analysis System (DMAS)), которые вышли в продакшен с ошибками. До релиза каждая из систем была протестирована n-way тестовыми наборами, где n было равно 2, 3, 4 и 5+. Вот сколько ошибок было найдено:



Проверки каждым n-way набором проводились последовательно. Таблица показывает, что ошибки, к которым приводило взаимодействие 2х и менее входных переменных было 30 штук в LAS и 29 штук в DMAS. Ошибки, к которым приводило взаимодействие 3х переменных - дополнительно 4(30+4) штуки в LAS и 12(29+12) штук в DMAS. Ошибки, к которым приводило взаимодействие 4х переменных - 7(30+4+7) штук в LAS и 1(29+12+1) штука в DMAS. Ну и ошибки, к которым приводило взаимодействие более 4х переменных - 7(30+4+7+7) штук в LAS и 3(29+12+1+3) штуки в DMAS. А было не обнаружено 34 ошибки в LAS и 43 ошибки в DMAS.

В этом примере самые интересные ошибки категории "Not Found". Дополнительные исследования показали, что большинство не найденных ошибок были 1-way faults! Т.е. к ошибке приводило конкретное значение 1ой переменной, независимо от значений других. Pairwise testing должно было обнаружить эти ошибки, но почему они не были найдены?

На самом деле, эти ошибки не были бы найдены не только pairwise тестами, но и любыми n-way тестовыми наборами. Да и при тестировании на всех возможных комбинациях всех выбранных значений переменных тестировщики  LAS и DMAS эти дефекты не нашли. А всё потому что были выбраны такие тестовые данные, которые были не способны обнаружить эти дефекты. Проще говоря, "Not Found" группа это в большинстве случаев 1-way ошибки, которые не были обнаружены потому что некоторые значения входных данных были не выбраны или были выбраны не верно.

Суть в том, что все ошибки, которые вы сделали перед применением allpairs algorithm только будут усугубляться. Это значит что если не верно применили предыдущие техники тест дизайна (допустим вы до этого применяли Boundary Value Testing, Equivalence Class Testing, Domain Analysis Testing или что-то еще) или придумали значения входных данных неверно, то хоть применяй allpairs algorithm, хоть orthogonal array testing - ошибки в программе останутся.


  2. Вы определили не достаточно хорошие оракулы.

Будем разбираться на примере диалога MS Word'а.


Мы тут имеем всего 12,288 возможных комбинаций (212 умножить на 3). Тут проблема выбора неверных значений входных данных не стоит. Мы можем перебрать все возможные значения переменных при применении Allpairs alghoritm. Найдем ли мы все важные критические дефекты? Скорее всего нет, из-за проблемы оракулов(ожидаемых результатов). После того как мы будем менять каждую комбинацию опций в диалооге Word'a нам прийдется поюзать Word какое то время, чтобы проверить что не только опции правильно отработали, но и что что то другое не отвалилось после применения выбранных опций. Да и у нас нет 100% гарантий, что нет какой то малозаметной проблемы, не явной, которую мы пропустили, скажем, повреждения внутренней структуры документа.

Скорее всего, после каждого теста, мы будем шустро пробегать по основным функция Word'a, и будем надеяться на лучшее :) И суть в том, что часто серьезные сбои могут быть не так очевидны как нам хотелось бы. И учесть все в оракулах невозможно.


  3. Вы не уделили внимание наиболее возможным комбинациям переменных.

Возьмем опять пример диалога MS Word'а. Очевидно, что из 12,288 комбинаций есть одна комбинация опций этого диалога, которая будет возникать гораздо чаще остальных - настройка по умолчанию/дефолтная комбинация опций. Если процент людей, которые никогда не будут менять настройки опций по умолчанию этого диалога 95%, то должно быть хорошее покрытие из "околодефолтных" опций. Возможно даже будет разумнее протестировать "околодефолтные" настройки вместо применения попарного тестирования. Если мы протестируем все варианты с отклонением от дефолтной конфигурации в одну опцию - это будет 14 тест кейсов. Если будем брать для тестирования все комбинации опций с возможным отклонением 2 опции от дефолтной - это выйдет около 100 тест кейсов. И результаты тестирования этими тест кейсами возможно будут лучше, чем игнорирование существования дефолтной комбинации опций. Мы конечно можем провести и эти тест кейсы и allpairs тест кейсы, но суть останется той же - allpairs algorithm заставляет нас игнорировать наиболее вероятные комбинации переменных.


  4. Вы не знаете как переменные взаимодействуют.

Ключевым фактором успеха или провала применения pairwise testing - это понимание того как комбинирование входных переменных влияет на выходные данные. Можно применить pairwise testing к двум разным тестируемым приложениям и получить ощутимо разные результаты. Некоторые приложения используют меньше входных переменных для получения выходных данных, некоторые больше.

Например, на рисунке ниже представлена программа, которая имеет 3 входных переменных (X,Y,Z) и 3 возможных выходных данных (1,2,3). Стрелки на рисунке показывают какие переменные должны взаимодействовать для получения какого результата - чтобы получить в результате 1 должны взаимодействовать переменные X и Y, для получения результата 2 должны взаимодействовать переменные X и Z. Для этой программы применение pairwise будет подходящим выбором, и мы скорее всего получим достаточно позитивные результаты от его применения.
Но что если для создания выходных данных требуется более 2 водных переменных? Pairwise testing всё еще будет подходящим выбором?


А на этом рисунке видно, что у DMAS есть много выходных данных, к которым приводит взаимосвязь более чем 2х переменных. Даже можно сказать, что 20ть вариантов из выходных данных создаются при взаимодействии 9 или более входных переменных. А когда существуют варианты, при которых выходные данные являются результатом взаимодействия более 2х входных переменных, это автоматически означает, что могут быть ошибки, которые pairwise testing не определит. Т.е. слепо применяя pairwise testing, у вас есть достаточно большые шансы оставить критические дефекты в тестируемом приложении.


Заключение

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

Этот пост является вольным переводом статьи Баха и Шредера "Pairwise Testing: A Best Practice That Isn’t".

Ну и напомню, что дальше нас ждет разбор таких техник тест дизайна:
 * Domain Analysis Testing
 * Use Case Testing

11 комментариев:

  1. Жаль, что дальнейший перевод застопорился. Будем искать оригинальные источники.

    ОтветитьУдалить
  2. Та ленюсь всё :) Допишу-допишу ;)

    ОтветитьУдалить
    Ответы
    1. давай-давай, занимательное чтиво ! :)

      Удалить
  3. Да, Паша, давай пиши...

    ОтветитьУдалить
  4. А я раньше думал что Бах - это звук при ударе. Ну или композитор...

    ОтветитьУдалить
  5. Все мы так в возрасте 5 лет думали ;)

    ОтветитьУдалить
  6. Паша, допишите, пожалуйста. Так понятно получается :)

    ОтветитьУдалить
  7. * Domain Analysis Testing
    * Use Case Testing это когда будет расматриваться?

    ОтветитьУдалить
  8. Спасибо. Хотелось что бы дописал:
    * Domain Analysis Testing
    * Use Case

    ОтветитьУдалить
  9. Мы все еще ждем и надеемся на продолжение...

    ОтветитьУдалить