Перейти к содержимому

Chrome DevTools: Инструменты тестировщика
онлайн, начало 4 июня
Docker: инструменты тестировщика
онлайн, начало 4 июня
Первый Онлайн ИНститут Тестировщиков
онлайн, начало 1 июня
Тестирование без требований: выявление и восстановление информации о продукте
онлайн, начало 1 июня
Фотография

Аспекты отличия Use Case от Test Case


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 29

#1 pavel_kravts

pavel_kravts

    Новый участник

  • Members
  • Pip
  • 16 сообщений
  • ФИО:Кравцов Павел
  • Город:Москва

Отправлено 02 апреля 2008 - 11:09

Господа, какие на Ваш взгляд можно выделить принципиальные отличия между такими проф определениями как Use Case и Test Case??
  • 0

#2 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 02 апреля 2008 - 11:37

Господа, какие на Ваш взгляд можно выделить принципиальные отличия между такими проф определениями как Use Case и Test Case??

На такие вопросы люблю отвечать просто переведя на русский язык определения...
Use Case - что-то вроде, случай использования
Test Case - что-то вроде, тестовый случай

Разница уже очевидна - это абсолютно разные документы.
Грубо говоря, в Use Case описываются правила/пути пользования определенного функционала, в Test Case - то как будет тестироваться функционал.

А вы сами что об этом думаете?
  • 0
Алексей Булат
Про Тестинг

#3 Vitekua

Vitekua

    Новый участник

  • Members
  • Pip
  • 45 сообщений
  • Город:Kharkov

Отправлено 02 апреля 2008 - 14:30

А вы сами что об этом думаете?


Зачем думать или читать, если на форуме спросить можно ;)
  • 0
Мастер на все руки

#4 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 02 апреля 2008 - 16:37

А вы сами что об этом думаете?


Зачем думать или читать, если на форуме спросить можно ;)

Сорри за флуд, но в форуме надо спрашивать, если нигде больше нет информации или есть очень разная...
  • 0
Алексей Булат
Про Тестинг

#5 pavel_kravts

pavel_kravts

    Новый участник

  • Members
  • Pip
  • 16 сообщений
  • ФИО:Кравцов Павел
  • Город:Москва

Отправлено 03 апреля 2008 - 07:35

Грубо говоря, в Use Case описываются правила/пути пользования определенного функционала, в Test Case - то как будет тестироваться функционал.
А вы сами что об этом думаете?


Таким образом получается что Test Cases включают в себя Use Cases + еще дополнительные моменты, которыми могут быть corrupt tests (тестовые данные, которые выходят за границы use cases). Я правильно Вас понимаю?
  • 0

#6 LeshaL

LeshaL

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 03 апреля 2008 - 09:10

Грубо говоря, в Use Case описываются правила/пути пользования определенного функционала, в Test Case - то как будет тестироваться функционал.
А вы сами что об этом думаете?


Таким образом получается что Test Cases включают в себя Use Cases + еще дополнительные моменты, которыми могут быть corrupt tests (тестовые данные, которые выходят за границы use cases). Я правильно Вас понимаю?

Я бы построил такую цепочку Product -> Product's Features -> Use Cases -> Test Cases. Т.е. продукт состоит из какого-то набора фич\функционала. Каждая фича имеет несколько вариантов использования.
Каждый вариант использования какого-либо фукнционала, порождает один или больше тесткейзов. В том числе и негативные тесты. (Не знаю, откуда появилось название corrupt test - обычно это negative test называется).
Пример.
Есть программа, простенький текстовый редактор я-ля notepad для txt файлов. Одна из фич - copy\paste. Один из вариантов использования - вставление (вставка, ну вообщем paste) скопированного текста из другого приложения. Один из тесткейзов - открыть другой текстовый редактор(word), скопировать в нем текст, вставить в тестируемый редактор -> убедиться, что все скопированное вставилось. Второй тесткейз: открыть графический редактор(paintbrash), скопировать картинку, попытаться вставить в тестируемое приложение -> убедиться, что... итд.
Другой вариант использования той же фичи - copy\paste внутри редактора
Третий - copy из нашего редактора\paste в другой аппликухе.
Итд.
  • 1
Regards,
Alexey

#7 idunin

idunin

    Активный участник

  • Members
  • PipPip
  • 115 сообщений
  • ФИО:Илья Владимирович
  • Город:Москва


Отправлено 03 апреля 2008 - 11:44

Таким образом получается что Test Cases включают в себя Use Cases + еще дополнительные моменты, которыми могут быть corrupt tests (тестовые данные, которые выходят за границы use cases). Я правильно Вас понимаю?

Почитайте книгу "Современные методы описания функциональных требований к системам" А. Коберн. Он как раз пишет про этот аспект и описывает, что из Use Case получаются отличные сценарии тестирования, надо только добавить конкретные значения (была бы под рукой, написал бы номер главы). :)

Про "corrupt tests". Сценарии использования пишутся как для верного, так и для неверного поведения системы/пользователя - "шаги расширения". Если придерживаться того же Коберна, то можно считать, что для тестирования функциональной области достаточно взять только сценарии использования с конкретными значениями.
  • 0

#8 EEV

EEV

    Новый участник

  • Members
  • Pip
  • 34 сообщений
  • ФИО:Екатерина Евстратенко


Отправлено 20 апреля 2008 - 19:45

:rtfm: сорри, собщение продублировалось
  • 0

#9 EEV

EEV

    Новый участник

  • Members
  • Pip
  • 34 сообщений
  • ФИО:Екатерина Евстратенко


Отправлено 20 апреля 2008 - 20:10

Почитайте книгу "Современные методы описания функциональных требований к системам" А. Коберн. Он как раз пишет про этот аспект и описывает, что из Use Case получаются отличные сценарии тестирования, надо только добавить конкретные значения (была бы под рукой, написал бы номер главы). :)

Про "corrupt tests". Сценарии использования пишутся как для верного, так и для неверного поведения системы/пользователя - "шаги расширения". Если придерживаться того же Коберна, то можно считать, что для тестирования функциональной области достаточно взять только сценарии использования с конкретными значениями.


Из Use Cases МОГУТ получиться отличные сценарии тестирования. А могут и нет. Зависит от
1. представления автора юзкейсов о том, как их надо писать. (Бывают такие юзкейсы, которые хочется сначала переписать, а потом из этого тест-кейсы сочинять. Наболело! :rtfm:) Ибо кто-то пишет юзкейсы не так, как их ожидают видеть заинтересованные лица, а так, как написано в умных книжках.
2. умения тест-дизайнера сочинить тесты (в каком бы виде ни были предъявлены требования)

Между UC и ТС есть одно важное общее место: и те, и другие описывают ожидаемое поведение системы. НО: с разных точек зрения и с разной степенью абстракции (это различия - к вопросу автора темы). Чем конкретнее написаны юз-кейсы, тем меньше работы по созданию ТС на их основе, и наоборот.
Hint: Поищите статьи о методах создания тест-кейсов на основе юзкейсов.

"можно считать, что для тестирования функциональной области достаточно взять только сценарии использования с конкретными значениями" --> IMHO, скорее (90%) нет, чем да. Сильно зависит от качества юзкейсов.
  • 0

#10 pavel_kravts

pavel_kravts

    Новый участник

  • Members
  • Pip
  • 16 сообщений
  • ФИО:Кравцов Павел
  • Город:Москва

Отправлено 23 мая 2008 - 08:22

В кратце подводя все вышеописанное можно сказать следующее:

UseCases - это созедательные сценарии, которые описывают непосредственно поведение, работу аппликации.

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

Не даром говорят, что программист - созедатель, а тестировщик - разрушитель..

Жду ваших мнений по этому поводу. Прав ли я?
  • 0

#11 SALar

SALar

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 274 сообщений
  • Город:Москва


Отправлено 23 мая 2008 - 09:17

Юзкейсы - это часть требований. Пусть будет треть.
Как проверять остальные будем?
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#12 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 24 мая 2008 - 22:33

Юзкейсы - это часть требований. Пусть будет треть.
Как проверять остальные будем?

Ну вообще-то есть есть еще куча всего, начиная от требований к интерфейсу, производительности, какими-то бизнес требованиями, ну и много другое...

На все это тоже должны писаться тест кейсы, которые должны быть пройдены в процессе тестирования.

Вообще хорошо было бы определить, какие именно требования должен включать Юзкейс? На моей истории я их видел не мало, поэтому интересно услышать вашу точку зрения...
  • 0
Алексей Булат
Про Тестинг

#13 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 26 мая 2008 - 11:02

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


- Чив ли я?
- Чив. Чив.
(Из букваря. Просто вспомнилось. :crazy: )

Use Case - это описание наиболее критичных функциональных путей программы (или, по простому, историй использования функциональности).
Test Case - это то, как мы эти пути будем проверять.
В идеальном случае - Use Case + Test Data = Test. В этом варианте экономится время на оформление Test Cases.
  • 0
Гринкевич Сергей

#14 ghost83

ghost83

    Новый участник

  • Members
  • Pip
  • 23 сообщений
  • ФИО:Жуковский А. М.

Отправлено 26 мая 2008 - 15:06

Use Case - это описание наиболее критичных функциональных путей программы (или, по простому, историй использования функциональности).
Test Case - это то, как мы эти пути будем проверять.
В идеальном случае - Use Case + Test Data = Test. В этом варианте экономится время на оформление Test Cases.


Не со всем согласен. Все таки, Use Case + TestData = Positive test (или здесь нужно было оговориться о том, что один Use Case покрывает набор Test-ов).
Но в общем и целом верно. Use Case - это успешный пользовательский сценарий использования. А Test Case - это сценарий проверки одного или нескольких Use Case-ов. Связь Use Case <-> Test Case - многие ко многим.
  • 0

#15 ghost83

ghost83

    Новый участник

  • Members
  • Pip
  • 23 сообщений
  • ФИО:Жуковский А. М.

Отправлено 26 мая 2008 - 15:33

Юзкейсы - это часть требований. Пусть будет треть.
Как проверять остальные будем?


В компании, в которой я работаю, функциональными требованиями являются варианты использования (т.е. Use Cases). Так что, насчет того, что это - треть, можно поспорить.
  • 0

#16 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 26 мая 2008 - 19:00


В идеальном случае - Use Case + Test Data = Test.


Не со всем согласен. Все таки, Use Case + TestData = Positive test


Используйте Negative Test Data + Use Case = Negative test.

Согласен - связь многие ко многим. Все зависит от детализации и методики написания use case-ов и test case-ов.
  • 0
Гринкевич Сергей

#17 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 26 мая 2008 - 20:09

Используйте Negative Test Data + Use Case = Negative test.

Согласен - связь многие ко многим. Все зависит от детализации и методики написания use case-ов и test case-ов.


Согласен, но что на счет уровней детализации?
А Кто определяет до какого уровня должны она уходить вглубь?
Являются ли Business Reqs и Functional Reqs частью UCs?

Пока лучшие UC, которые я видел (это было нечто среднее между общепринятым UC и технической спецификацией) включали в себя:
  • пути использования
  • диаграммы использования
  • бизнес требования
  • описание валидаций и валидационных сообщений
  • операции внутри БД
и много других мелочей...
  • 0
Алексей Булат
Про Тестинг

#18 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 27 мая 2008 - 06:16

Согласен, но что на счет уровней детализации?
А Кто определяет до какого уровня должны она уходить вглубь?


Мне никогда не приходилось видеть тех задание на разработку АС для ядерных реакторов. Но, думаю, у них бумаг будет побольше, чем в "простых" проектах.

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

А определяет всю эту "байду" менеджер проекта (ну, или тест менеджер, если ему даны такие полномочия).

Могу сказать только одно. Чем более подробна документация по проекту, тем лучше и качественнее получается продукт (при остальных равных условиях!).
  • 0
Гринкевич Сергей

#19 SALar

SALar

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 274 сообщений
  • Город:Москва


Отправлено 28 мая 2008 - 06:22

Юзкейсы - это часть требований. Пусть будет треть.
Как проверять остальные будем?


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

Хорошо, приведу пример из жизни.

Есть заказ на разработку некой системы.
Требования включают один! юзкейс. Один. Всего один. А вот остальная часть требований - это несколько сотен, может быть несколько тысяч страниц.
Действительно не треть.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#20 pavel_kravts

pavel_kravts

    Новый участник

  • Members
  • Pip
  • 16 сообщений
  • ФИО:Кравцов Павел
  • Город:Москва

Отправлено 28 мая 2008 - 06:45

[/quote]
Требования включают один! юзкейс. Один. Всего один. А вот остальная часть требований - это несколько сотен, может быть несколько тысяч страниц.
Действительно не треть.
[/quote]

И как же назвать эти остальные требования на несколько тысяч страниц?? Разве они не будут юзкейсами?
  • 0


Практикум по тест-дизайну 2.0
онлайн
Школа для начинающих тестировщиков
онлайн
Школа тест-аналитика
онлайн
Техники локализации плавающих дефектов
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале