Существуют ли эффективные методы тестирования черного ящика, позволяющие избежать избыточности?

Я проводил тестирование «черного ящика» для программного обеспечения, которое выполняет инженерный анализ различных типов моделей концентрированной солнечной энергии (CSP).

Тестирование обеспечения качества, которое я проводил, включало изменение только одного параметра модели по умолчанию за раз. Это было очень просто, когда я просто проверял, соответствует ли вывод ожидаемому результату.

Однако теперь я хочу приступить к изучению комбинаций конфигураций, которые отличаются от настроек по умолчанию, чтобы выяснить, приведет ли какая-либо из этих комбинаций к неверному значению или даже к сбою пользовательского интерфейса (UI).

В первом экземпляре, с которым я работаю, пользовательский интерфейс имеет (6) различных типов параметров, которые я должен изучить в отношении конфигурации по умолчанию. Кроме того, я хочу изучить комбинации (6) параметров конфигурации, изменяя их путем увеличения (+) или уменьшения (-) по отношению к конфигурации по умолчанию.

Как вы понимаете, желая изучить эти (6) параметров в комбинациях (+) и (-), я легко создам МНОГИЕ различные типы тестов черного ящика.

Есть ли какие-либо предложения о том, как более эффективно проводить эти тесты черного ящика? Я стараюсь избегать выполнения всех различных типов конфигураций, в то же время исследуя вычислительный код во всех аспектах.


person finnahuss    schedule 15.07.2019    source источник
comment
Как вы можете изучить вычислительный код во всех аспектах, не выполняя всевозможные настройки? Похоже, вы просите протестировать, скажем, компилятор, не давая ему всяких программ. ИМХО, вы должны использовать ГСЧ для генерации входных конфигураций.   -  person Walter    schedule 16.07.2019
comment
Это реальная проблема, которую я пытаюсь обойти. Я просто не уверен, что это реальное желание решить эту проблему. Сначала я изучал факторные планы... Я не хочу вдаваться в подробности, но, поскольку существует (6) факторов, различающихся (3) разными способами (+, - и настройка по умолчанию) для каждого параметра, я, по сути, глядя на сценарий модульного тестирования, тестирующий 3 ^ 6 конфигураций. Я не думаю, что факториальные планы - это ответ. Не могли бы вы уточнить, что вы имеете в виду под ГСЧ?   -  person finnahuss    schedule 16.07.2019
comment
Я думал о непрерывном, а не о дискретном вводе, как в вашем случае (это не было ясно из исходного вопроса). ГСЧ = генератор случайных чисел. Ну, вы должны протестировать все 3^6=729 конфигураций - в конце концов, их немного.   -  person Walter    schedule 16.07.2019
comment
@Walter, как начинающий программист на C ++, я не могу сказать, серьезно ли вы относитесь к тому, является ли 729 модульных тестов разумным объемом тестирования, которое нужно выполнить ... вручную. Для справки, я использую Google Test Framework. До этой попытки, когда я менял один параметр относительно конфигурации по умолчанию, это обеспечивало приличное количество ручного ввода с моей стороны.   -  person finnahuss    schedule 16.07.2019
comment
Если вам действительно нужен полный охват всех комбинаций параметров, я бы посоветовал написать небольшую программу на любом языке, который вам удобен, которая генерирует код для этих модульных тестов.   -  person paddy    schedule 16.07.2019
comment
Вы тестируете всю программу или тестируете небольшие фрагменты кода, например, отдельные функции или методы? В первом случае вы не выполняете модульное тестирование.   -  person Dirk Herrmann    schedule 19.07.2019
comment
Оказывается, решение для моего ответа называется «комбинаторное тестирование». По сути, это все еще метод модульного тестирования черного ящика, который сокращает общее количество модульных тестов, сохраняя при этом весь спектр проверяемых параметров. Отличительной чертой комбинаторного тестирования является то, что оно специально используется для обеспечения качества программного обеспечения, где оно помогает пользователю обнаруживать неясные ошибки программного обеспечения посредством взаимодействия комбинаций параметров, просто не требуя от пользователя выполнения сценария исчерпывающего тестирования.   -  person finnahuss    schedule 20.07.2019