Здравствуйте, господа.
Условия: есть тест-кейсы, тест-скрипты, которые были разработаны из use-case-ов таким образом, чтобы они отображали единицу функциональности - по сути получается "конструктор" функциональности. То есть можно построить "граф" взаимодействия единиц функциональности, который покажет все возможные пути прохождения тестирования.
Вопрос: как практически составляется такой граф или иная "картинка" возможных путей исполнения софта? Как здесь можно задействовать автоматизацию, и какой инструмент имеет такие возможности?
Пути Тестирования Неисповедимы...
Автор Levix, 18 ноя 2003 10:12
Сообщений в теме: 4
#1
Отправлено 18 ноября 2003 - 10:12
#2
Отправлено 20 ноября 2003 - 08:13
Здравствуйте. Если я правильно поняла проблему, то в TestDirector (от Mercury) есть модуль TestLab, в котором можно строить граф, задавать условия.
#3
Отправлено 21 ноября 2003 - 14:06
Добрый день.
По поводу составления графа путей тестирования - этот граф называется тест моделью.
Построение тест модели - дело творческое и относится к разделу планирования тестирования, автоматизация тут, в моем понимании, не привинчивается - если иметь в виду не тестирование модулей.
Для тестирования модулей есть утилиты, которые анализируют код и строят граф всех возможных путей извлечения кода, только я не занимаюсь тестированием модулей и не знаю конкретных утилит, но они есть ... Могу только поделиться опытом постоения тест модели для тестирования всей системы целиком (для black box - тестирования).
Тест модель может быть составлена, например в Rational Rose внутри use case-диаграммы. Тогда каждый use case (или test case) - это эллипс, пути выполнения - ассоциации, связывающие use cases. Из сообщения Levix не следует, в каком виде имеются use cases и test cases (текстовом или описанные с помощью UML-диаграмм), как они хранятся (в виде документов Word на диске или спланированы в специализированной системе типа TestManager от Rational, или еще где-нибудь), поэтому рассмотрим случай документов Word - когда есть текстовые описания test cases (или use cases, когда тестирование проводится по ним).
К каждому эллипсу в Rational Rose можно приаттачить документ Word (или в другом текстовом формате).
Имея на диаграмме эллипсы с прикрепленными описаниями можно их выстроить любым образом, связать ассоцациями, ввести линии синхронизации и другие объекты, в общем, далее все зависит от фантазии :)
По поводу составления графа путей тестирования - этот граф называется тест моделью.
Построение тест модели - дело творческое и относится к разделу планирования тестирования, автоматизация тут, в моем понимании, не привинчивается - если иметь в виду не тестирование модулей.
Для тестирования модулей есть утилиты, которые анализируют код и строят граф всех возможных путей извлечения кода, только я не занимаюсь тестированием модулей и не знаю конкретных утилит, но они есть ... Могу только поделиться опытом постоения тест модели для тестирования всей системы целиком (для black box - тестирования).
Тест модель может быть составлена, например в Rational Rose внутри use case-диаграммы. Тогда каждый use case (или test case) - это эллипс, пути выполнения - ассоциации, связывающие use cases. Из сообщения Levix не следует, в каком виде имеются use cases и test cases (текстовом или описанные с помощью UML-диаграмм), как они хранятся (в виде документов Word на диске или спланированы в специализированной системе типа TestManager от Rational, или еще где-нибудь), поэтому рассмотрим случай документов Word - когда есть текстовые описания test cases (или use cases, когда тестирование проводится по ним).
К каждому эллипсу в Rational Rose можно приаттачить документ Word (или в другом текстовом формате).
Имея на диаграмме эллипсы с прикрепленными описаниями можно их выстроить любым образом, связать ассоцациями, ввести линии синхронизации и другие объекты, в общем, далее все зависит от фантазии :)
#4
Отправлено 21 ноября 2003 - 14:25
Здравствуйте.
Большое спасибо за ответ.
Yarilo, очень интересуюсь Вашим подходом. Есть в наличии архитектура созданная в Rational Rose, есть в наличии Test Manager, в котором мы формируем тест-кейсы. Но поскольку мы только обучаемся делу тестирования, то пока пробуем определить подход к составлению модели тестирования.
Очень интересует связка Rose - Robot.
Скажите, а их можно между собой связать для отслеживания путей выполнения или нет?
И еще, Rose рассчитан на постороение таких моделей тестирования или Вы сами разработали такой подход с использованием стандартных средств инструмента?
Заранее благодарен за ответы.
Большое спасибо за ответ.
Yarilo, очень интересуюсь Вашим подходом. Есть в наличии архитектура созданная в Rational Rose, есть в наличии Test Manager, в котором мы формируем тест-кейсы. Но поскольку мы только обучаемся делу тестирования, то пока пробуем определить подход к составлению модели тестирования.
Очень интересует связка Rose - Robot.
Скажите, а их можно между собой связать для отслеживания путей выполнения или нет?
И еще, Rose рассчитан на постороение таких моделей тестирования или Вы сами разработали такой подход с использованием стандартных средств инструмента?
Заранее благодарен за ответы.
#5
Отправлено 09 декабря 2003 - 13:46
Добрый день, Levix.
По поводу Rational Rose. Это инструмент для моделирования систем в нотации языка UML, а нотация UML — набор приемов и артефактов для анализа и проектирования системы. UML предназначен для построения модели изучаемого явления (системы), тест модель — это тоже модель (собственно, название говорит само за себя ), поэтому возможно построить тест модель в Rational Rose. Это было основанием для построения тест модели в Rational Rose.
Объясню условия, в которых тест модель разрабатывалась в Rational Rose. В том проекте, для которого тест модель разрабатывалась в Rational Rose, были только use cases без test cases (из-за отсутствия времени на их разработку). Каждый use case был спланирован в Rational Rose (внутри use-case диаграммы) и имел прикрепленное текстовое описание в документе Word (следуя методологии RUP это текстовое описание называется Flow of Events).
Составленная тест модель представляет собой use-case диаграмму, содержащую use cases, скопированные из других use case диаграмм. Каждый use case в тест модели может встречаться несколько раз, конкретный поток событий, который нужно проверить в рассматриваемой ветке модели (т.к. модель представляет собой граф) уточняется в названии и описании ассоциации, которая соединяет данный use case с предыдущим use case (или с линией синхронизации — я изображаю ее в виде эллипса со стереотипом use case realization и именем <Sync Lin N>).
Про Test Manager и Robot. В Robot-е можно реализовать тест скрипты для каждого спланированного в TestManager-е test case. Потом в TestManagere можно к каждому test case приаттачить тест скрипт, разработанный в Robot-е. Далее можно объединить несколько test cases с приаттаченными скриптами (можно и без) в наборы (Suits) — эти наборы строятся для представления одной ветки тест модели, на мой взгляд, это не наглядно, и мы этим не пользуемся, но у всех свое мнение. Вообще, поработав с линейкой продуктов Rational, я сделала вывод, что это глючные продукты. Возможно, это связано с конфигурацией software, но глюки проявлялись не только на моей машине....
Про связь Robot и Rose — мне о ней известно только то, что если она и существует, то только посредством TestManager-а. В TestManager-е можно приаттачить к use case диаграмму из Rational Rose в качестве test input.
По поводу Rational Rose. Это инструмент для моделирования систем в нотации языка UML, а нотация UML — набор приемов и артефактов для анализа и проектирования системы. UML предназначен для построения модели изучаемого явления (системы), тест модель — это тоже модель (собственно, название говорит само за себя ), поэтому возможно построить тест модель в Rational Rose. Это было основанием для построения тест модели в Rational Rose.
Объясню условия, в которых тест модель разрабатывалась в Rational Rose. В том проекте, для которого тест модель разрабатывалась в Rational Rose, были только use cases без test cases (из-за отсутствия времени на их разработку). Каждый use case был спланирован в Rational Rose (внутри use-case диаграммы) и имел прикрепленное текстовое описание в документе Word (следуя методологии RUP это текстовое описание называется Flow of Events).
Составленная тест модель представляет собой use-case диаграмму, содержащую use cases, скопированные из других use case диаграмм. Каждый use case в тест модели может встречаться несколько раз, конкретный поток событий, который нужно проверить в рассматриваемой ветке модели (т.к. модель представляет собой граф) уточняется в названии и описании ассоциации, которая соединяет данный use case с предыдущим use case (или с линией синхронизации — я изображаю ее в виде эллипса со стереотипом use case realization и именем <Sync Lin N>).
Про Test Manager и Robot. В Robot-е можно реализовать тест скрипты для каждого спланированного в TestManager-е test case. Потом в TestManagere можно к каждому test case приаттачить тест скрипт, разработанный в Robot-е. Далее можно объединить несколько test cases с приаттаченными скриптами (можно и без) в наборы (Suits) — эти наборы строятся для представления одной ветки тест модели, на мой взгляд, это не наглядно, и мы этим не пользуемся, но у всех свое мнение. Вообще, поработав с линейкой продуктов Rational, я сделала вывод, что это глючные продукты. Возможно, это связано с конфигурацией software, но глюки проявлялись не только на моей машине....
Про связь Robot и Rose — мне о ней известно только то, что если она и существует, то только посредством TestManager-а. В TestManager-е можно приаттачить к use case диаграмму из Rational Rose в качестве test input.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных