ch_ip

Сложную тему Вы подняли. Во-первых, хочется уточнить, Вы хотите заниматься проектированием или тестированием?
Во-вторых, на мой взгляд дипломная работа должна быть посвящена какой-то одной отдельной проблеме, которая на текущий момент не решена. И соответственно, предлагать какие-то пути решения этой проблемы. Автоматизация функционального тестирования - обширнейшая тема. Года не хватит даже чтобы просто изучить все, что наработано по этой теме за последние лет эдак 30-40. Есть уже готовые инструменты функционального тестирования, которые продаются и за немаленькие деньги. Основная проблема в том, что нет хороших инструментов, которые были бы разработаны под цели и задачи тестирования. Не думаю, что писать свой инструмент с нуля - это хорошая идея. Год - слишком маленький срок для этого, тем более, что у Вас нет опыта автоматизации.
Что можно сделать: во-первых, познакомиться с существующей литературой по автоматизации, какие бываю виды автоматизированного тестирования, зачем применяются. Читать:
http://www.satisfy.com
http://www.developsence.com
http://automated-testing.info
http://www.protestin...functional.html
http://openquality.r.../automation.php
Книжки по автоматизации тестирования, например, Автоматизированное тестирование программного обеспечения. Элфрид Дастин, Джефф Рэшка, Джон Пол

Во-вторых, понять, чего не хватает существующим инструментам автоматизации, что тестировщики были счастливы. Не хватает на самом деле многого:
Подсказок, какие идентификаторы использовать стоит использовать,
Информации сразу по всем контролам на форме, сведенным в единую табличку, для анализа, какие свойства есть, на какие можно завязать
Подсказок, какие свойства не меняются от запуска к запуску
Отслеживания свойств между запусками
Автоматического отслеживания, сколько времени занимает выполнение того или иного действия
умного логирования и анализатора этих логов

В-третьих, можно взять исходный код AutoIT, он почти весь открыт, и попытаться дописать к нему какую-нибудь полезную вещь, решающую одну из вышеперечсиленных проблем или еще какую-нибудь, какую я забыл упомянуть.

С какой ошибкой падает?
Можно ли увидеть скрин с Object Spy
что будет, если вместо JavaToolbar прописать JavaList, как видит Object Spy и вызвать у него метод Select?

а как дерево само при этом выглядит?
Можете снять скрин с самого приложения в момент ошибки?
И еще интересно посмотреть на скрин объектного репозитория с выделенным в нем деревом

Просто мне так и не получилось заставить QuickTest распознавать элементы дерева с By Name.

То есть, он их записывает нормально, а потом по ним не переходит?
Можете привести пример кода + то, как идентифицируется само дерево + ошибку, которую выдает QTP, когда вы пытаетесь навигироваться по узлам через их имена?

А какую проблему призвано решить данное изменение?
Из подводных камней первое что приходит на ум –– это увеличение хрупкости тестов. Теперь добавление/перемещение/удаление узлов дерева приведет к тому, что Вы будете работать не с тем узлом, с каким планировали

1. Убрать items_count и другие динамические свойства из Object Identification. Оставить только те, которые не меняются от сессии к сессии.
2. Да, распознавание объекта идет по совокупности всех свойств, которые были запомнены для этого объекта. Mandatory свойства запоминаются всегда, Assistive только в случае, когда набора Mandatory свойств не хватает для однозначного определения объекта в момент записи
3. Никогда не надо включать Smart Identification при прогоне теста. При записи полезно, да. При запуске обычно только мешает. Гораздо правильнее подобрать набор свойств, который обеспечит вам стабильную идентификацию элемента
4. Судя по приведенному коду, у вас нормально распознаются все объекты. Dev name - не единственное свойство, которое можно использовать для распознавания объектов. Почитайте справку QTP про Object Identification, статью Михаила Давыдова в библиотеке S-T
5. Вы можете спокойно выбрать любой узел из дерева. Вам обязательно нужны, чтобы элементы дерева представлялись отдельными объектами? Если да, то зачем? Чисто теоретически это можно сделать с помощью Java Extensibility Toolkit. Вот только я не помню, начиная с какой версии он поставляется в составе QTP. Может быть в 9.5 его еще не было. нет машинки с 9.5 под рукой, чтобы проверить.

Что такое "упало" и "не упало", я до сих пор не совсем понимаю =)

Упало - это когда этим дальше нельзя пользоваться: программа зависла сама, повесила ОС или отожрала у нее всю память или самопроизвольно закрылась или исполняется бесконечно долго, не работают критично важные в программе функции.
Второй вариант "упало" - это когда адекватные действия привели к катастрофическим последствиям: потерялись данные пользователя, деньги ушли на другой счет, ракета полетела не в ту сторону.

Все остальное - это как правило серьезно, но не упало.

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