Аспекты отличия Use Case от Test Case
#1
Отправлено 02 апреля 2008 - 11:09
#2
Отправлено 02 апреля 2008 - 11:37
На такие вопросы люблю отвечать просто переведя на русский язык определения...Господа, какие на Ваш взгляд можно выделить принципиальные отличия между такими проф определениями как Use Case и Test Case??
Use Case - что-то вроде, случай использования
Test Case - что-то вроде, тестовый случай
Разница уже очевидна - это абсолютно разные документы.
Грубо говоря, в Use Case описываются правила/пути пользования определенного функционала, в Test Case - то как будет тестироваться функционал.
А вы сами что об этом думаете?
Про Тестинг
#3
Отправлено 02 апреля 2008 - 14:30
А вы сами что об этом думаете?
Зачем думать или читать, если на форуме спросить можно ;)
#4
Отправлено 02 апреля 2008 - 16:37
Сорри за флуд, но в форуме надо спрашивать, если нигде больше нет информации или есть очень разная...А вы сами что об этом думаете?
Зачем думать или читать, если на форуме спросить можно ;)
Про Тестинг
#5
Отправлено 03 апреля 2008 - 07:35
Грубо говоря, в Use Case описываются правила/пути пользования определенного функционала, в Test Case - то как будет тестироваться функционал.
А вы сами что об этом думаете?
Таким образом получается что Test Cases включают в себя Use Cases + еще дополнительные моменты, которыми могут быть corrupt tests (тестовые данные, которые выходят за границы use cases). Я правильно Вас понимаю?
#6
Отправлено 03 апреля 2008 - 09:10
Я бы построил такую цепочку Product -> Product's Features -> Use Cases -> Test Cases. Т.е. продукт состоит из какого-то набора фич\функционала. Каждая фича имеет несколько вариантов использования.Грубо говоря, в Use Case описываются правила/пути пользования определенного функционала, в Test Case - то как будет тестироваться функционал.
А вы сами что об этом думаете?
Таким образом получается что Test Cases включают в себя Use Cases + еще дополнительные моменты, которыми могут быть corrupt tests (тестовые данные, которые выходят за границы use cases). Я правильно Вас понимаю?
Каждый вариант использования какого-либо фукнционала, порождает один или больше тесткейзов. В том числе и негативные тесты. (Не знаю, откуда появилось название corrupt test - обычно это negative test называется).
Пример.
Есть программа, простенький текстовый редактор я-ля notepad для txt файлов. Одна из фич - copy\paste. Один из вариантов использования - вставление (вставка, ну вообщем paste) скопированного текста из другого приложения. Один из тесткейзов - открыть другой текстовый редактор(word), скопировать в нем текст, вставить в тестируемый редактор -> убедиться, что все скопированное вставилось. Второй тесткейз: открыть графический редактор(paintbrash), скопировать картинку, попытаться вставить в тестируемое приложение -> убедиться, что... итд.
Другой вариант использования той же фичи - copy\paste внутри редактора
Третий - copy из нашего редактора\paste в другой аппликухе.
Итд.
Alexey
#7
Отправлено 03 апреля 2008 - 11:44
Почитайте книгу "Современные методы описания функциональных требований к системам" А. Коберн. Он как раз пишет про этот аспект и описывает, что из Use Case получаются отличные сценарии тестирования, надо только добавить конкретные значения (была бы под рукой, написал бы номер главы). :)Таким образом получается что Test Cases включают в себя Use Cases + еще дополнительные моменты, которыми могут быть corrupt tests (тестовые данные, которые выходят за границы use cases). Я правильно Вас понимаю?
Про "corrupt tests". Сценарии использования пишутся как для верного, так и для неверного поведения системы/пользователя - "шаги расширения". Если придерживаться того же Коберна, то можно считать, что для тестирования функциональной области достаточно взять только сценарии использования с конкретными значениями.
#8
Отправлено 20 апреля 2008 - 19:45
#9
Отправлено 20 апреля 2008 - 20:10
Почитайте книгу "Современные методы описания функциональных требований к системам" А. Коберн. Он как раз пишет про этот аспект и описывает, что из Use Case получаются отличные сценарии тестирования, надо только добавить конкретные значения (была бы под рукой, написал бы номер главы). :)
Про "corrupt tests". Сценарии использования пишутся как для верного, так и для неверного поведения системы/пользователя - "шаги расширения". Если придерживаться того же Коберна, то можно считать, что для тестирования функциональной области достаточно взять только сценарии использования с конкретными значениями.
Из Use Cases МОГУТ получиться отличные сценарии тестирования. А могут и нет. Зависит от
1. представления автора юзкейсов о том, как их надо писать. (Бывают такие юзкейсы, которые хочется сначала переписать, а потом из этого тест-кейсы сочинять. Наболело! ) Ибо кто-то пишет юзкейсы не так, как их ожидают видеть заинтересованные лица, а так, как написано в умных книжках.
2. умения тест-дизайнера сочинить тесты (в каком бы виде ни были предъявлены требования)
Между UC и ТС есть одно важное общее место: и те, и другие описывают ожидаемое поведение системы. НО: с разных точек зрения и с разной степенью абстракции (это различия - к вопросу автора темы). Чем конкретнее написаны юз-кейсы, тем меньше работы по созданию ТС на их основе, и наоборот.
Hint: Поищите статьи о методах создания тест-кейсов на основе юзкейсов.
"можно считать, что для тестирования функциональной области достаточно взять только сценарии использования с конкретными значениями" --> IMHO, скорее (90%) нет, чем да. Сильно зависит от качества юзкейсов.
#10
Отправлено 23 мая 2008 - 08:22
UseCases - это созедательные сценарии, которые описывают непосредственно поведение, работу аппликации.
В то же время TestCases включают в себя UseCases, в некоторой степени возможно переписанные (зависит от мышления дизайнера тестов) и дополненные другими сценариями. TestCases включают помимо созедательных сценариев сценарии разрушения.
Не даром говорят, что программист - созедатель, а тестировщик - разрушитель..
Жду ваших мнений по этому поводу. Прав ли я?
#11
Отправлено 23 мая 2008 - 09:17
Как проверять остальные будем?
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#12
Отправлено 24 мая 2008 - 22:33
Ну вообще-то есть есть еще куча всего, начиная от требований к интерфейсу, производительности, какими-то бизнес требованиями, ну и много другое...Юзкейсы - это часть требований. Пусть будет треть.
Как проверять остальные будем?
На все это тоже должны писаться тест кейсы, которые должны быть пройдены в процессе тестирования.
Вообще хорошо было бы определить, какие именно требования должен включать Юзкейс? На моей истории я их видел не мало, поэтому интересно услышать вашу точку зрения...
Про Тестинг
#13
Отправлено 26 мая 2008 - 11:02
UseCases - это созедательные сценарии, которые описывают непосредственно поведение, работу аппликации.
В то же время TestCases включают в себя UseCases, в некоторой степени возможно переписанные (зависит от мышления дизайнера тестов) и дополненные другими сценариями. TestCases включают помимо созедательных сценариев сценарии разрушения.
... Прав ли я?
- Чив ли я?
- Чив. Чив.
(Из букваря. Просто вспомнилось. )
Use Case - это описание наиболее критичных функциональных путей программы (или, по простому, историй использования функциональности).
Test Case - это то, как мы эти пути будем проверять.
В идеальном случае - Use Case + Test Data = Test. В этом варианте экономится время на оформление Test Cases.
#14
Отправлено 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 - многие ко многим.
#15
Отправлено 26 мая 2008 - 15:33
Юзкейсы - это часть требований. Пусть будет треть.
Как проверять остальные будем?
В компании, в которой я работаю, функциональными требованиями являются варианты использования (т.е. Use Cases). Так что, насчет того, что это - треть, можно поспорить.
#16
Отправлено 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-ов.
#17
Отправлено 26 мая 2008 - 20:09
Используйте Negative Test Data + Use Case = Negative test.
Согласен - связь многие ко многим. Все зависит от детализации и методики написания use case-ов и test case-ов.
Согласен, но что на счет уровней детализации?
А Кто определяет до какого уровня должны она уходить вглубь?
Являются ли Business Reqs и Functional Reqs частью UCs?
Пока лучшие UC, которые я видел (это было нечто среднее между общепринятым UC и технической спецификацией) включали в себя:
- пути использования
- диаграммы использования
- бизнес требования
- описание валидаций и валидационных сообщений
- операции внутри БД
Про Тестинг
#18
Отправлено 27 мая 2008 - 06:16
Согласен, но что на счет уровней детализации?
А Кто определяет до какого уровня должны она уходить вглубь?
Мне никогда не приходилось видеть тех задание на разработку АС для ядерных реакторов. Но, думаю, у них бумаг будет побольше, чем в "простых" проектах.
Уровень детализации - это компромисс между наличием времени на эту работу, уровнем квалификации сотрудника и корпоративными методиками по разработке. Могут еще добавляться требования заказчика, если он опускается до уровня артефактов по тестированию.
А определяет всю эту "байду" менеджер проекта (ну, или тест менеджер, если ему даны такие полномочия).
Могу сказать только одно. Чем более подробна документация по проекту, тем лучше и качественнее получается продукт (при остальных равных условиях!).
#19
Отправлено 28 мая 2008 - 06:22
Хорошо, приведу пример из жизни.Юзкейсы - это часть требований. Пусть будет треть.
Как проверять остальные будем?
В компании, в которой я работаю, функциональными требованиями являются варианты использования (т.е. Use Cases). Так что, насчет того, что это - треть, можно поспорить.
Есть заказ на разработку некой системы.
Требования включают один! юзкейс. Один. Всего один. А вот остальная часть требований - это несколько сотен, может быть несколько тысяч страниц.
Действительно не треть.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#20
Отправлено 28 мая 2008 - 06:45
Требования включают один! юзкейс. Один. Всего один. А вот остальная часть требований - это несколько сотен, может быть несколько тысяч страниц.
Действительно не треть.
[/quote]
И как же назвать эти остальные требования на несколько тысяч страниц?? Разве они не будут юзкейсами?
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных