До этого мы разобрали 4 техники тест дизайна:
* Decision Table Testing
* Boundary Value Testing
* Equivalence Class Testing
* State-Transition Testing
Вступление
Рассмотрим следующие ситуации:
1. Сайт должен работать в 8 браузерах - Internet Explorer 6, 7, и 8, Netscape 6.0 и 7.0, Mozilla 2 и 3, и Opera 9; используя плагины - RealPlayer, MediaPlayer, без плагинов; на ОС - Windows NT, 2003, XP, vista, 2008 и seven; на разных веб серверах - IIS, Apache, и WebLogic; запущенных на сервере с разными ОС - Windows 2003, 2008 и Linux.
* 8 бразуеров
* 3 плагина
* 6 ОС клиента
* 3 веб сервера
* 3 ОС сервера
Итого: 1,296 возможных комбинаций.
2. Банк создал новую систему обработки данных. У этого банка есть разные клиенты - очень важные клиенты, юр. лица и физ. лица; различные виды счетов - сберегательные, ипотечные кредиты, потребительские кредиты, и коммерческие кредиты; плюс отделения банка работают в разных штатах, с разной спецификой проведения фин. операций - Калифорния, Невада, Юта, Айдахо, Аризона и Нью-Мехико.
* 4 типа клиентов
* 5 типов аккаунтов
* 6 штатов
Итого: 120 комбинаций.
3. В ООП приложении, объект класса "А" может передать параметром объект класса "P", объекту класса "X". Классы B,C,и D унаследованы от класса A, и тоже могут передавать данные. Классы Q, R, S и T унаследованы от класса P и могут быть переданы как данные. Классы Y и Z унаследованы от класса X и могут получать данные.
* 4 классов отправителя
* 5 классов данных
* 3 класса приемника.
Итого: 60 комбинаций.
Что общего у этих примеров? В каждом случае мы имеем большое количество комбинаций, которые необходимо протестировать, причем не тестировать какие то комбинации выглядит рискованно. Но количество комбинаций настолько велико, что скорее всего у нас не хватит ресурсов, чтобы спроектировать и пройти тест кейсы. Поэтому, учитывая наши ограниченные ресурсы, каким то магическим образом, мы должны отобрать только часть комбинаций. Pairwise testing и есть этот магический способ.
В чём заключается магия выбора комбинаций Pairwise testing? Не следует пытаться проверить все комбинации значений для всех переменных, а проверять комбинации пар значений переменных(пока наверно не сильно понятно, но это ничего :)). Эта техника существенно уменьшает количество комбинаций для тестирования.
Например:
* Если приложение имеет 4 разных входных параметра, и каждый из этих параметров может принимать 3 различных значения, то количество комбинаций будет 3 в 4 степени, а т.е. 81 комбинация. Попарно (pairwise), можно покрыть все входные значения за 8 тест кейсов.
* Если приложение имеет 13 разных входных параметров, и каждый из этих параметров может принимать 3 различных значения, то количество комбинаций будет 3 в 13 степени, а т.е. 1 594 323 комбинаций. Попарно, можно покрыть все входные значения за 15 тест кейсов.
* Если приложение имеет 20 разных входных параметров, и каждый из этих параметров может принимать 10 различных значения, то количество комбинаций будет 20 в 10 степени. Попарно, можно покрыть все входные значения за 180 тест кейсов.
Несколько исследований о pairwise testing:
* Исследование, опубликованное Brownlie of AT&T в отношении тестирования local-area network-based electronic mail system гласит, что применение pairwise testing обнаружило на 28% дефектов больше, чем их оригинальный план разработки и выполнения 1 500 тест кейсов (позже количество тест кейсов было сокращено до 1 000 из-за временных ограничений), и заняло на 50% меньше ресурсов.
* Kuhn и Reilly проанализированы недостатки, записанные в базе данных браузера Mozilla. Они определили, что pairwise testing обнаружили бы 76% найденных ошибок.
* Wallace и Kuhn опубликовали исследование, проведенное Национальным институтом стандартов и технологий над ошибками ПО в отозванных мед. устройствах, собиравшимися на протяжении 15 лет. Они пришли к выводу, что 98% дефектов могли быть обнаружены с помощью pairwise testing. Т.е., по этой статистике, 98% ошибок возникают при конфликте ПАР входных данных или неверной интерпретацией 1 входного параметра системой, что pairwise testing покрывает. Еще раз, ошибки источником которых является комбинация 3х конкретных входных параметров составляет 2%.
Почему pairwise testing так хорошо работает? Неизвестно. В любом случае, успех применения этой техники на многих проектах является отличной мотивацией для ее использования.
Pairwise testing основывается на orthogonal arrays или the Allpairs algorithm. В этом посте будем рассматривать pairwise testing на основе orthogonal arrays.
* Decision Table Testing
* Boundary Value Testing
* Equivalence Class Testing
* State-Transition Testing
Вступление
Рассмотрим следующие ситуации:
1. Сайт должен работать в 8 браузерах - Internet Explorer 6, 7, и 8, Netscape 6.0 и 7.0, Mozilla 2 и 3, и Opera 9; используя плагины - RealPlayer, MediaPlayer, без плагинов; на ОС - Windows NT, 2003, XP, vista, 2008 и seven; на разных веб серверах - IIS, Apache, и WebLogic; запущенных на сервере с разными ОС - Windows 2003, 2008 и Linux.
* 8 бразуеров
* 3 плагина
* 6 ОС клиента
* 3 веб сервера
* 3 ОС сервера
Итого: 1,296 возможных комбинаций.
2. Банк создал новую систему обработки данных. У этого банка есть разные клиенты - очень важные клиенты, юр. лица и физ. лица; различные виды счетов - сберегательные, ипотечные кредиты, потребительские кредиты, и коммерческие кредиты; плюс отделения банка работают в разных штатах, с разной спецификой проведения фин. операций - Калифорния, Невада, Юта, Айдахо, Аризона и Нью-Мехико.
* 4 типа клиентов
* 5 типов аккаунтов
* 6 штатов
Итого: 120 комбинаций.
3. В ООП приложении, объект класса "А" может передать параметром объект класса "P", объекту класса "X". Классы B,C,и D унаследованы от класса A, и тоже могут передавать данные. Классы Q, R, S и T унаследованы от класса P и могут быть переданы как данные. Классы Y и Z унаследованы от класса X и могут получать данные.
* 4 классов отправителя
* 5 классов данных
* 3 класса приемника.
Итого: 60 комбинаций.
Что общего у этих примеров? В каждом случае мы имеем большое количество комбинаций, которые необходимо протестировать, причем не тестировать какие то комбинации выглядит рискованно. Но количество комбинаций настолько велико, что скорее всего у нас не хватит ресурсов, чтобы спроектировать и пройти тест кейсы. Поэтому, учитывая наши ограниченные ресурсы, каким то магическим образом, мы должны отобрать только часть комбинаций. Pairwise testing и есть этот магический способ.
В чём заключается магия выбора комбинаций Pairwise testing? Не следует пытаться проверить все комбинации значений для всех переменных, а проверять комбинации пар значений переменных(пока наверно не сильно понятно, но это ничего :)). Эта техника существенно уменьшает количество комбинаций для тестирования.
Например:
* Если приложение имеет 4 разных входных параметра, и каждый из этих параметров может принимать 3 различных значения, то количество комбинаций будет 3 в 4 степени, а т.е. 81 комбинация. Попарно (pairwise), можно покрыть все входные значения за 8 тест кейсов.
* Если приложение имеет 13 разных входных параметров, и каждый из этих параметров может принимать 3 различных значения, то количество комбинаций будет 3 в 13 степени, а т.е. 1 594 323 комбинаций. Попарно, можно покрыть все входные значения за 15 тест кейсов.
* Если приложение имеет 20 разных входных параметров, и каждый из этих параметров может принимать 10 различных значения, то количество комбинаций будет 20 в 10 степени. Попарно, можно покрыть все входные значения за 180 тест кейсов.
Несколько исследований о pairwise testing:
* Исследование, опубликованное Brownlie of AT&T в отношении тестирования local-area network-based electronic mail system гласит, что применение pairwise testing обнаружило на 28% дефектов больше, чем их оригинальный план разработки и выполнения 1 500 тест кейсов (позже количество тест кейсов было сокращено до 1 000 из-за временных ограничений), и заняло на 50% меньше ресурсов.
* Kuhn и Reilly проанализированы недостатки, записанные в базе данных браузера Mozilla. Они определили, что pairwise testing обнаружили бы 76% найденных ошибок.
* Wallace и Kuhn опубликовали исследование, проведенное Национальным институтом стандартов и технологий над ошибками ПО в отозванных мед. устройствах, собиравшимися на протяжении 15 лет. Они пришли к выводу, что 98% дефектов могли быть обнаружены с помощью pairwise testing. Т.е., по этой статистике, 98% ошибок возникают при конфликте ПАР входных данных или неверной интерпретацией 1 входного параметра системой, что pairwise testing покрывает. Еще раз, ошибки источником которых является комбинация 3х конкретных входных параметров составляет 2%.
Почему pairwise testing так хорошо работает? Неизвестно. В любом случае, успех применения этой техники на многих проектах является отличной мотивацией для ее использования.
Pairwise testing основывается на orthogonal arrays или the Allpairs algorithm. В этом посте будем рассматривать pairwise testing на основе orthogonal arrays.
