Comments 10
Такие тесты это первый кандидат на автоматизацию. Я для такого случая использовал allpairspy в связке с pytest.
Кому интересно, эти 98 или 97 процентов, по всей видимости, взялись из исследования Долорес Уоллес и Ричарда Куна под названием "Failure modes in medical device software: an analysis of 15 years of recall data" 2001 года, на которую также ссылаются сами авторы в своей более поздней работе в соавторстве с Альбертом Галло: "Software Fault Interactions and Implications for Software Testing" опубликованой в 2004 году.
В исследовании 2001 года, они проанализировали выявленные ошибки в медицинских устройствах, так сказать пост-мортем. Причем им были не были доступны детали технического анализа ошибки, а только их описания. В результате чего они рассматривали 342 ошибки в своей работе. Из них только 109 случаев имели достаточно информации, чтобы определить необходимый уровень тестирования для выявления ошибки.
Например, в одном из отчетов говорилось "Если использовать устройство со старыми электродами, то появляется сообщение об ошибке, вместо предупредительного сигнала об оснастке оборудования". В таком случае тестирование устройства со старыми электродами выявило бы ошибку.
В другом отчете говорилось, что "возможно установление значения CO2 вручную, выше максимального значения, без предупредительного сигнала". Тут опять же один тест со значением превосходящим норму выявил бы ошибку.Другие ошибки было выявить не так просто, например в одном отчете значилось: "Если инъекция происходит в тот момент когда насосы работают в режиме массы тела, средний дисплей не обновляет данные". В этом случае обнаружение потребовало теста с комбинацией условий: инъекция в режиме массы тела
В одном из отчетов другого производителя значилось такое описание дефекта с комбинацией условий: "вентилятор может перестать работать, когда регулятор компенсации атмосферного давления выставлен на 0 метров и проточный объем выставлен на значение менее чем 2.2 литра в минуту.
Только 3 из 109 ошибок требовали более двух условий для их проявления.
Вот и делайте сами выводы, насколько такое исследование годится чтобы 97% вытесали на каменных скрижалях комбинаторного тестирования.
Как мне кажется такое пост-мортем исследование не верно в том плане той причине, что рассматриваются только входные данные. Про выходные параметры ничего не говорится. Если нам повезет то мы будем смотреть на "правильный" выходной параметр, как во втором примере - значение на дисплее. Но этот выходной параметр, может быть весьма опосредованно связано с входными параметрами. В требованиях может быть записано что-то типа: "значение Х на дисплее обновляется каждые 500 мс" и все. И исходя из этих рассуждений нужно пары входных параметров тестировать с парами выходных параметров, не связаных либо слабо связаных с входными параметрами.
И это то что мы наблюдаем в жизни, ломается в неочевидных местах. Поэтому, например, многие программы неадекватно реагируют на прерывание интернет соединения. Никакой pairwise тут не поможет, потому что нам просто не придет в голову, взять наличие/отсутствие интернет-соединения за входной параметр функции.
А комбинаторное тестирование формуляров из 100500 опций, да конечно это снижает затраты на дизайн и выбор тестов. Но с другой стороны, откуда мы знаем связаны ли между собой эти параметры или нет. Ведь в исследовании проявлялись комбинации из разных ступеней. Т.е. это может быть пользовательская настройка в комбинации с полем формуляра, а может быть только комбинация полей формуляра.
Поэтому я рекомендую всем, еще почитать статью "Pairwise Testing: A Best Practice That Isn’t" (Bach, Schroeder, 2006)
Шаг 3: Но согласитесь, в реальных кейсах не бывает такого, что бы не было бизнес логики.
По идее это должно было быть шагом 1, разве не так?
Сначала посмотреть, какие значения допустимы, а потом уже на основе ограничений применять технику попарного тестирования?
Еще меня интересует, почему эти знания о бизнес логике не использовались в момент разбиения данных на классы эквивалентности? Тут же явно видно, что по количеству страниц есть особенные значения 100, 200 и 500. А в вашем наборе вы сразу выкинули 100 и 200
Количество страниц
Применяем наши любимые классы эквивалентности и граничные условия: 30, 50, 500, 1000;
Это выглядит грубыми ошибками тест-дизайна. А может быть даже полным непониманием смысла техник тест-дизайна.
Полностью с вами согласен по обоим пунктам.
Безусловно, при реальном тестировании, мы должны изначально опираться на бизнес логику. А вторая ошибка, что я сразу выкинул особые значения 100 и 200, это как раз следствие того, что бизнес логику я навешал уже после.
Но, в первом случае, задача была показать, на сколько изначально велико кол-во кейсов, и лишь потом приступать к их сокращению. Тут больше визуальный прием, чем реальная практика - я думал, всем понятно что мы никогда не будем так делать в реальности.
А вот особые значения страниц я упустил..это да. Но опять же, задача была показать саму необходимость применить классы эквивалентности на данном этапе.
Но, в первом случае, задача была показать, на сколько изначально велико кол-во кейсов, и лишь потом приступать к их сокращению. Тут больше визуальный прием, чем реальная практика - я думал, всем понятно что мы никогда не будем так делать в реальности.
Понимаете, в чем проблема с моей точки зрения? Это количество кейсов велико при "неграмотном" подходе. Если подойти грамотно, то количество кейсов и трудозатраты на тест-дизайн будут меньше даже без применения техники попарного тестирования.
Пусть при этом польза от применения техники попарного тестирования будет не так очевидна, зато это будет объективное сравнение. А не то, что получилось у вас: сравнение количества кейсов при откровенной халтуре, и при хорошем подходе. Возникает вопрос: а точно ли при хорошем подходе ключевую роль в сокращении кейсов играет именно техника попарного тестирования? Или тут больше влияет хороший подход к тест-дизайну?
А, я понял вашу мысль. Но,опять же повторюсь, что это больше визуальный прием для статьи. Я не использовал вдумчивый тест дизайн. Это статья не про цели тест дизайна ,а про последовательность действий и про то что пейрвайс может помочь в каких то случаях. Попарное тестирование,это далеко не панацея, и конечно неправильно рассматривать его как решение для всего этапа тестдизайна. Но вполне можно рассмотреть,как отдельную технику ,опуская все остальное.
Мы не рассуждаем о сокращении числа тестов впринципе, мы рассуждаем об инструменте для потенциального сокращения. Вы говорите о "сравнении числа тестов при хорошем подходе" ,но при хорошем подходе к чему? Если к применению конкретной технике попарного тестирования ,то ок,но если к этапу тест дизайна, то конечно же это не "хороший подход". Он скорее неправильный в реальной работе: как вы правильно заметили, нельзя на отвали применить одни техники и применив пейрвайс ,сказать что сократили кучу тестов, в реальной работе мы анализируем , фиксируем зависимые и независимые параметры , оцениваем какие-то риски , применяя весь набор техник тест дизайна комплексно и вдумчиво для соответствующих наборов данных, в конечном "идеальном" итоге получая минимальный набор тестов без потери эффективности тестового покрытия.
Я пишу сейчас это всё не конкретно для вас (не уверен что смогу тягаться с вами в продвинутом тест дизайне), а чтобы пояснить читающим на что стоит обратить внимание при чтении статьи.
Сокращаем плотность бумаги, потому-что нужно это прочитать
Спасибо большое, не слышал раньше про подобное. Очень поможет в работе.
pict есть в brew:
brew install pict
Добавляем pairwise (попарное тестирование) в свой арсенал QA инженера