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