Подозреваю что вы говорите о генерации наборов тестов, а не о тест плане - верно?
В том числе и о наборе тестов.
Тогда мы говорим о разных документах, только и всего. В тест плане тестов нет.
А дальше пошёл скорее ряд предположений, чем алгоритм генерации тест плана, в часности стратегии тестирования.
Во-первых, некоторые части тестплана (как Введение, Описание системы), сами по себе имеют достаточно шаблонный вид, в котором множество варьируемых параметров можно ограничить (например, тип тестируемого приложения).
И что это даёт? Как по
описанию приложения обычными словами автоматически понять какому типу принадлежит приложение? Средства EntityExtraction в целом кое-как справляются с базовыми задачами распознавания Person, Location и ещё некоторых более продвинутых вещей типа Fact - но не более. Вы говорите об автоматическом
чтении документа
решением генерации тест плана. Я повторюсь, хочу сказать что автоматически генерировать его нереально, ибо нет решений понимающих текст.
Тот же перечень тестируемых и нетестируемых модулей (Test Coverage/Scope) можно получить по следующему принципу. В тесткейсах где-то в заголовке завести (если не было) поле вроде Component, которое описывает ту часть приложения, которая затрагивается данным тесткейсом. На генератор ставится фильтр по компонентам. Соответственно, компоненты, которые по фильтру проходят в план, ставятся в перечень тестируемых компонентов, остальные - в перечень нетестируемых.
Всё бы хорошо, но вы предлагаете по имеющимся тестам генери ровать статистику и просто показать что не покрыто тестами. То есть
после того как тесты были написаны. А к пониманию тестируемых и нетестируемых требований это отношения не имеет, потом что выделить нетестируемые требования надо
до того как мы начали писать тесты.
Далее, если брать приведенную вами ссылку на эссе Алексея Баранцева (а я иду сейчас по данной работе), то там следует пункт "Подход к тестированию". Тип тестирования можно либо зафиксировать, либо отразить определенной структурой каталогов (например, в отдельной папке хранить системные тесты, отдельно юнит, интеграционные и т.д.). Задав фильтр, мы можем определить, какие тесткейсы попали в тестплан. На основании этих данных можно все тесткейсы сгруппировать по типу тестирования.
Погодите, коллега. :)
Вы приводите техническое описание системы контроля процесса тестирования и описываете тест план просто как один из отчётов, который по тому что есть в системе просто покажет что есть и чего нет. Папки надо создать, чтобы их создать надо понять какие типы тестов будут - это и есть та часть работы которая в данный момент неавтоматизируема - то есть никто кроме человека её не сделает.
Загвоздка только в том, что тест план пишется
до того как созданы тесты, как созданы папки отвечающие типам тестом - пишется ровно для того, чтобы всё это и понять и зафиксировать.
Дальше вы приводите техническое описание системы управления процессом тестирования, которая позволяет создавая элемекнты системы (по сути и планируя тестирования) получить потом документ, который можно назвать тест планом. Подход скажу честно интересный - для меня наверное, даже неочевидный и заставляющий подумать-покопаться, но вопрос лежит уровнем выше.
Мой поинт прост:
Планирование тестирования как активность по выявлению подходов к тестированию на основе понимания и анализа существующих проектных артефактов - суть задача выполняемая только человеком, всё остальное вторично и может быть автоматизировано. Решение принимается человеком, фиксируется инструментом - тут и спорить нечего.
