При   разработка тестовых примеров имеет основополагающее значение для обеспечения надежности и отказоустойчивости приложений. Методы разработки комбинаторных тестов, такие как k-стороннее тестирование и парное тестирование, направлены на проверку взаимодействия между различными входными переменными. Однако становится очевидным, что проблемы и подводные камни могут снизить эффективность выявления критических ошибок. тестировании программного обеспечения  Эта короткая статья посвящена конкретным проблемам, с которыми можно столкнуться при проектировании комбинаторных тестов, и исследует нюансы, требующие тщательного рассмотрения. Давайте углубимся в случаи неправильных входных значений, важность надежных оракулов, значение часто упускаемых из виду комбинаций переменных и важнейшее понимание того, как переменные взаимодействуют.    идентификация входных значений Неправильная  Набор тестов k-way включает все возможные комбинации значений k переменных. Например, применение алгоритма всех пар приводит к созданию двустороннего набора тестов, охватывающего все возможные комбинации пар значений переменных. Следовательно, k-сторонняя ошибка относится к ошибке, возникающей в результате взаимодействия значений k переменных. Проверка двух систем, SYS1 и SYS2, выявила ошибки после их производственных выпусков. Обе системы прошли k-стороннее тестирование со значениями k 2, 3, 4 и 5+.  В таблице показаны результаты k-way тестирования для двух систем.  Тип неисправности  СИС1  СИС2  2 пути  30  29  3-сторонний  4  12  4-сторонний  7  1  > 4-ходовой  7  3  Не найдено  34  43  Последовательные проверки проводились для каждого набора k-way. Рисунок 2.1 показывает, что ошибки, возникающие из-за взаимодействия двух или меньшего количества входных переменных, составили   и   . Ошибки от взаимодействия трех переменных составили   и   . Для взаимодействий с участием четырех переменных ошибки составляли   и   . Ошибки из-за взаимодействия с более чем четырьмя переменными составили   и   . Примечательно, что   ошибки не были обнаружены в SYS1, а   ошибки не были обнаружены в SYS2. 29 in SYS1 30 in SYS2 4*(30+4) in SYS2 12*(29+12) in SYS1 7*(30+4+7) in SYS2 1*(29+12+1) in SYS1 3*(29+12+1+3) in SYS1 7*(30+4+7+7) in SYS2 43 34  В этом примере наиболее существенные ошибки относились к категории   . Дальнейшие исследования показали, что большинство необнаруженных ошибок были односторонними, то есть определенное значение одной переменной приводило к ошибке независимо от значений других переменных. Попарное тестирование должно было обнаружить эти ошибки, но по каким-то причинам они остались необнаруженными. Эти ошибки   представляют собой в первую очередь односторонние ошибки, которые остались незамеченными, поскольку определенные входные значения либо не были выбраны, либо выбраны неправильно. «Не найдено» «Не найдено»    заключается в том, что любые ошибки, допущенные до применения алгоритма всех пар, сохранятся. Это означает, что если предыдущие методы разработки тестов применялись неправильно или входные значения были неверными, ошибки в приложении сохранятся независимо от использования алгоритма всех пар или тестирования ортогональных массивов. Суть проблемы   Слабость в определении ожидаемых результатов: неопределенность в результатах  В качестве примера рассмотрим модуль приложения с многочисленными опциями (примерно такой формы) и, как следствие, большим количеством комбинаций входных данных.  Допустим, в модуле имеется   возможных комбинаций. Здесь проблема не в выборе неправильных входных значений, поскольку все возможные значения переменных можно тщательно протестировать с помощью алгоритма Allpairs. Однако позволит ли это выявить все критические ошибки? Скорее всего, нет из-за проблем с ожидаемыми результатами. После манипулирования каждой комбинацией опций в таком программном модуле нужно будет некоторое время использовать систему, чтобы убедиться, что опции работают правильно и ничего больше не сломалось после применения выбранных опций. В этом случае нет никакой гарантии, что не возникнет какой-либо тонкой, неочевидной проблемы, которую легко пропустить. 2^12 * 3  После каждого теста может потребоваться тщательная оценка основных функций системы. Дело здесь в том, что серьезные дефекты часто оказываются не так очевидны, как хотелось бы, и учесть все в ожидаемых результатах становится практически невозможно.  Невнимание к наиболее вероятным комбинациям  Из комбинаций   (как мы предложили в примере выше), скорее всего, есть одна комбинация опций модуля, которая будет встречаться гораздо чаще, чем все остальные — настройка   . Если 95% людей никогда не изменят параметры этого модуля по сравнению с настройками по умолчанию, то должен быть хороший охват параметров,   . Тестирование всех вариантов с отклонением от конфигурации по умолчанию в одном варианте приведет к двузначному количеству тестов. Если протестировать все комбинации опций с возможным отклонением в двух настройках от значения по умолчанию, то это будет около сотни тестовых случаев. Тестирование с использованием этих тестовых примеров и тестовых случаев, состоящих из всех пар, может дать лучшие результаты, чем игнорирование существования опции по умолчанию. Однако алгоритм Allpairs заставляет тестировщика игнорировать наиболее вероятные и часто используемые комбинации переменных. 2^12 * 3 по умолчанию близких к настройкам по умолчанию  Взаимодействия неизвестных переменных  Ключевой фактор успеха или неудачи парного тестирования заключается в понимании того, как комбинация входных переменных влияет на выходные данные. Применение парного тестирования к двум различным тестируемым приложениям может дать существенно разные результаты. Некоторые приложения используют меньше входных данных для создания выходных данных, тогда как другие используют больше.   В качестве примера рассмотрим программу, имеющую три входные переменные (X, Y, Z) и три возможных выходных данных (1, 2, 3). Стрелки указывают, какие переменные должны взаимодействовать для получения конкретного результата. Чтобы получить результат 1, переменные Y и X должны взаимодействовать; чтобы получить результат 2, переменные Z и X должны взаимодействовать. Для этого приложения подходящим выбором будет применение парного тестирования, и вероятны положительные результаты. Однако в случаях, когда существуют сценарии, в которых выходные данные являются результатом взаимодействия более чем двух входных переменных, существует высокая вероятность того, что парное тестирование не сможет выявить ошибки. Простое применение парного тестирования увеличивает риск упустить из виду критические ошибки в тестируемом приложении.  Для специалиста по обеспечению качества важно понимать эти нюансы. Хотя в некоторых случаях эти идеи являются теоретическими, они подчеркивают необходимость целостного подхода к тестированию, который выходит за рамки поверхностного и обеспечивает надежность и надежность ваших приложений. Понимание сложности проектирования комбинаторных тестов позволяет специалистам по обеспечению качества эффективно тестировать сложную бизнес-логику приложений и предоставлять пользователям высококачественное программное обеспечение.

About Me

Read My Articles

Hire Me

Этот звук создан на языке оригинала истории!

Контроль качества программного обеспечения: решение проблем с помощью комбинаторного проектирования тестов

About Author

КОММЕНТАРИИ

БИРКИ

ЭТА СТАТЬЯ БЫЛА ПРЕДСТАВЛЕНА В

Related Stories

Цифровые кочевники слушают: что нужно знать о новой визе DTV в Таиланде

Как улучшить ваш рабочий процесс в 10 раз: 17 основных приложений

Valhalla Флоки станет ассоциированным спонсором индийского тура по Шри-Ланке

Невидимые слои: почему интервью с пользователями являются незаменимым активом

Цифровые кочевники слушают: что нужно знать о новой визе DTV в Таиланде

Как улучшить ваш рабочий процесс в 10 раз: 17 основных приложений

Valhalla Флоки станет ассоциированным спонсором индийского тура по Шри-Ланке

Невидимые слои: почему интервью с пользователями являются незаменимым активом

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps