OberonCore

Допустим, используется ручное тестирование и есть порядка 100 разных тестов. При создании тестов, программист создавал их по какому-то принципу, допустим, если данный параметр TRUE, то нужно проверить такие-то такие-то вещи, если он FALSE, то проверяем другие вещи. Иногда может быть комбинация их нескольких параметров, если 2 параметра, то получается 4 варианта. Также тесты можно разделить по тому, что они тестируют, допустим, одни тесты функционал проверяют другие представление и так далее. И из комбинации этих вариантов может получится 100+ разных тестов.
По прошествии какого-то времени (допустим, через год), тот же самый программист уже не помнит по какому принципу он составлял эти тесты, а просто видит 100+ разных тестов, записанных подряд (они могут быть записаны в каком-то документе, но данная проблема может распространятся и на автоматизированное тестирование, когда есть куча разных тестов, которые выполняются друг за другом, но уже не понятно по какому принципу они составлялись, все ли варианты там учтены).
Думаю, что можно было бы представлять тесты в виде дерева, где в каждой вершине происходит разделение на два или несколько вариантов, тогда взглянув на дерево можно было бы легче вспомнить как составлялись тесты.
Используется ли где-нибудь подобное древовидное представление? Встречался ли кто-нибудь с чем-нибудь подобным?

Если, я правильно понял, то в Boost Test есть такое, например. Там дерево тестов (test tree) состоит из наборов тестов (test suites) и собственно тестов (test cases). Вторые считаются концевыми вершинами дерева, первые - нет. Набор тестов кроме собственно тестов может так же включать и другие наборы. Можно запускать как отдельные тесты, так и их наборы. Всё это можно делать ручками из командной строки, а можно в исходниках тестов и их наборов использовать всякие проверки как во время компиляции, так и во время исполнения, чтобы определить, надо ли прогонять тест или набор. Это то, что Вам нужно?

Частично это может быть и то. Насколько я понимаю, там основной акцент сделан на то, что какие-то тесты не надо прогонять при каких-то условиях. А меня больше интересует древовидность критериев по которым составляется тест для того, чтобы в дальнейшем можно было проследить все ли основные категории тестов проверены.

Интересная мысль, Rifat.
Подумай её дальше )

Только, думаю, это будет лучше всего катить при тестировании "белого ящика", а не "чёрного".

На ум пришли таблица решений и дерево решений.

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

Глава 10. Таблицы решений и графы переходов

Хм... Я правильно понимаю, что Вам нужна какая-то особая техника покрытия кода (code coverage), в которой Вы ручками прописываете, какой тест что конкретно покрывает, а не (как обычно) утилита автоматически делает это, анализируя исходный код и код тестов? Тогда нет, такого я что-то не припомню, и поверхностное гугление тоже никуда не привело.

Сейчас это есть в любой xUnit-системе
Мы для С++ используем Catch - это вообще 1 инклуд.
https://github.com/catchorg/Catch2