Сообщений в теме: 25

[addnr]

почитал про этапы тестирования (модульное->интеграционное->системное).
разобрался с модульным, написал юнит тесты. частично разобрался с системным, проводил не сложные автоматические тесты при помощи SilkTest.
а вот про интеграционное почитал в теории все понятно, но как его делать на практике ума не прилажу. делается на подобие юнит тестов только более укрупненных или как с системном тестируется GUI только считается что разрабатываемое ПО пока не все может?

объясните кто разберается в интеграционном тестировании , как его на практике делать?

[DrVal]

При интеграционном тестировании проверяется взаимодействие 2-х или более модулей.
И упор делается именно на проверку взаимодействия.

Можно использовать и юнит-тесты, но вызовы пойдут не в стаб, а во второй модуль.

Более конкретно ответить сложно, без понимания о каких модулях речь.

почитал про этапы тестирования (модульное->интеграционное->системное).
разобрался с модульным, написал юнит тесты. частично разобрался с системным, проводил не сложные автоматические тесты при помощи SilkTest.
а вот про интеграционное почитал в теории все понятно, но как его делать на практике ума не прилажу. делается на подобие юнит тестов только более укрупненных или как с системном тестируется GUI только считается что разрабатываемое ПО пока не все может?

объясните кто разберается в интеграционном тестировании , как его на практике делать?

[the_norn]

Опять же все зависит от контекста, но я при проведении Интеграционного тестирования делал упор именно на проверку взаимодействия различных модулей (тех же Units) Юниты объединяются в группы и над ними выполняются тесты. Данный вид тестирование является промежуточным между модульным и системным, подробнее можно тут глянуть http://www.protestin...ntegration.html

[addnr]

напишу пример, правильно ли я все понял:
есть система которая состоит из модулей(бизнес логика), каждый модуль состоит из нескольких классов. модули слабо связаны между собой.
система написана на C# + WPF.

порядок проведения тестирования:
1) написание юнит тестов для каждого не тривиального класса.
2) написание интеграционного теста (наподобие юнит теста) для каждого модуля (заглушки используются только на выходе из модуля, если нужны)
3) создание сборки с полноценным работающим продуктом, проведение тестирования GUI при помощи SilkTest.
4) ручное тестирование GUI, то что не покрыли используя SilkTest.

правильно ли я написал порядок и методы проведения тестирования? если нет то можно поподробнее почему)
на данный момент больше всего интересует этап интеграционного тестирования

[DrVal]

Если модули между собой не связаны, а завязаны на один общий GUI (т.е. архитектура 2-х уровневая), то интеграционного тестирования скорее всего и не нужно.
Т.к. в данном случае оно является частью системного, специальных тестов не требуется, просто проверяется часть функционала, которая в данный момент реализована.

[addnr]

более конкретный пример по вопросу как проводить интеграционное тестирование в этом конкретном случае. пример - вопрос, если быть точным)

есть 2 программных модуля (М1 и М2)(модули бизнес логики), каждый из которых состоит из двух классов, модуль М1 состоит из классов М1к1 и М1к2. модуль М2 состоит классов М2к1 и М2к2. Модули слабо связаны между собой.

порядок проведения тестирования:
1) модульное тестирование. Написание юнит тестов для классов (М1к1, М1к2, М2к1 и М2к2).
2) интеграционное тестирование.
а) Написание юнит тестов тестирующих совокупность классов М1к1 и М1к2 (модуль М1).
б) Написание юнит тестов тестирующих совокупность классов М2к1 и М2к2(модуль М2).
в) Написание юнит тестов тестирующих совокупность классов М1к1, М1к2, М2к1 и М2к2 (взаимодействие модулей М1 и М2).



правильная последовательность и способ тестирования, если нет то можно пожалуйста поподробнее почему и как лучше

[addnr]

DrVal
тоесть можно сделать следующие выводы:
на этапе интеграционного тестирования проверяется взаимодействие сильно связанных между собой классов, при помощи юнит тестов (если классы часть бизнес логики).

связи между слабо связанными модулями тестируются на этапе системного тестирования через GUI

[DrVal]

Взаимодействие классов внутри модуля - это модульное тестирование, а не интеграционное.

И покрываться должно юнит-тестами.

Тесты 2.в имеею смысл, когда в архитектуре более 2-х уровней.

Например, есть общий модуль обработки ошибок M3.
Нужно проверить, что коды ошибок/сообщения из M1 и M2 не теряются при обработке в M3.

А системный тест в этом случае - при возникновеии ошибки в M1, пользователь получает внятное сообщение в GUI.

более конкретный пример по вопросу как проводить интеграционное тестирование в этом конкретном случае. пример - вопрос, если быть точным)

есть 2 программных модуля (М1 и М2)(модули бизнес логики), каждый из которых состоит из двух классов, модуль М1 состоит из классов М1к1 и М1к2. модуль М2 состоит классов М2к1 и М2к2. Модули слабо связаны между собой.

порядок проведения тестирования:
1) модульное тестирование. Написание юнит тестов для классов (М1к1, М1к2, М2к1 и М2к2).
2) интеграционное тестирование.
а) Написание юнит тестов тестирующих совокупность классов М1к1 и М1к2 (модуль М1).
б) Написание юнит тестов тестирующих совокупность классов М2к1 и М2к2(модуль М2).
в) Написание юнит тестов тестирующих совокупность классов М1к1, М1к2, М2к1 и М2к2 (взаимодействие модулей М1 и М2).



правильная последовательность и способ тестирования, если нет то можно пожалуйста поподробнее почему и как лучше

[innovator]

Неплохо в общих чертах написано у Канера и Ко "Тестирование программного обеспечения". Смотри с.74-76 если издание 2001 года "ДиаСофта"
Там еще рассматривается разные направления: bottom-up и top-down

[neono]

Итеграционное тестирование, как вид тестирование, проверяет взаимодействие модулей системы.
Тут именно бизнес модули имеются ввиду, а не модули архитектуры приложения.
Не нужно зацикливаться на модульных тестах.
Может быть интеграционное нагрузочное тестирование, и как вы понимаете оно с юнит тестами никак не связано

Взаимодействие классов внутри модуля - это модульное тестирование, а не интеграционное. - правильно DrVal говорит.
Хотя тут тоже можно придраться, что модульное =! юнит. Модуль = компонентное тестирование. Но эта за рамки дискуссии вылезает )))

[Alfa]

Хотя тут тоже можно придраться, что модульное =! юнит.

Ну расскажите, чем же модульное тестирование отличается от юнит тестирования. С интересом послушаю.

[SALar]

Проблема как всегда в терминологии.
Уважаемый Стив Макконнелл в книге "Остаться в живых" приводит следующее определение интеграционного тестирования:

Тестирование интеграции представляет собой проверку нового кода в сочетании с кодом, уже интегрированным в систему. Этот тип тестирования выполняется неформально разработчиком, создавшим новый код.

RUP предлагает следующую иерархию: Unit -> Integration -> System -> Acceptance

Моя иерархия тестов ближе к классификации RUP.
* Юнит тестирование - тестирование классов (или группы классов) и/или функций. Это как правило тестрование мельчайшей неделимой логически цельной единицы кода.
* Компонентное тестирование - тестирование компоненета имеющего оформленное API. Разумно применять в архитектуре:

|  Уровень	   | Уровень | Уровень 
		|  представления | логики  | данных
		|				|		 |
тонкий  |  сервер		| сервер  | сервер
клиент  |  представления | логики  | данных
		|				|		 |
	Толстый клиент	   |		 |
		|				|		 |
		|				|		 |
	Компонентные тесты   |		 |

Также, компонентные тесты идеальны для тестирования выделенных расчетных модулей (например, биллинга или математических библиотек).
* Системное тестирование - тестирование разрабатываемой системы с точки зрения конечного потребителя. Вполне может быть, что конечный потребитель - это сторонняя программа. В этом случае будет мало отличаться от компонентного тестирования.

А вот выражению Модульное тестирование особенно не повезло. И здесь я полагаю "огромная заслуга" переводчиков. Дело в том, что юнит тестирование не очень благозвучно для русского уха. В результате модульным тестированием именуют в зависимости от ситуации и юнит тестирование и компонентное тестирование.

Еще больше не повезло термину performance testing. Переводчики с упорством, достойным лучшего применения переводили его как нагрузочное тестирование и так в этом преуспели, что этот перевод едва не стал стандартом дефакто.

[neono]

Хотя тут тоже можно придраться, что модульное =! юнит.

Ну расскажите, чем же модульное тестирование отличается от юнит тестирования. С интересом послушаю.

все дело в определениях.
Открываем Силлабус ISTQB Foundation и читаем:

The four levels used in this syllabus are:
o component (unit) testing;
o integration testing;
o system testing;
o acceptance testing.

Дальше что такое Component Testing.

Component testing searches for defects in, and verifies the functioning of, software (e.g. modules,
programs, objects, classes, etc.) that are separately testable. It may be done in isolation from the
rest of the system, depending on the context of the development life cycle and the system. Stubs,
drivers and simulators may be used.

Component testing may include testing of functionality and specific non-functional characteristics,
such as resource-behaviour (e.g. memory leaks) or robustness testing, as well as structural testing
(e.g. branch coverage). Test cases are derived from work products such as a specification of the
component, the software design or the data model.

Можно придираться к словам что здесь имеется ввиду компонетное а не модульное, но все это трудности перевода.

SALar прав,
Юнит тестирование - тестирование классов
Компонентное тестирование - тестирование компоненета имеющего оформленное API.

Я надеюсь развеял ваши сомнения и вы с "интересом послушали".

[Alfa]

Уважаемый Стив Макконнелл в книге "Остаться в живых" приводит следующее определение интеграционного тестирования:

Уважаемый неправ, что поделать.

Моя иерархия тестов ближе к классификации RUP.
* Юнит тестирование - тестирование классов (или группы классов) и/или функций. Это как правило тестрование мельчайшей неделимой логически цельной единицы кода.
* Компонентное тестирование - тестирование компоненета имеющего оформленное API.

Публичные методы класса это оформленное API? По-моему — да. В этом случае мало отличается от юнит тестирования.

* Системное тестирование - тестирование разрабатываемой системы с точки зрения конечного потребителя. Вполне может быть, что конечный потребитель - это сторонняя программа.

Конечным потребителем класса может являться другой класс? По-моему — да. В этом случае мало отличается от юнит тестирования.

А вот выражению Модульное тестирование особенно не повезло. И здесь я полагаю "огромная заслуга" переводчиков. Дело в том, что юнит тестирование не очень благозвучно для русского уха. В результате модульным тестированием именуют в зависимости от ситуации и юнит тестирование и компонентное тестирование.

Что согласно Вашим определениям одно и тоже, и еще совпадает с интеграционным тестированием.

Есть другие варианты ответа на мой вопрос?

[Alfa]

Я надеюсь развеял ваши сомнения и вы с "интересом послушали".

Я с интересом почитал нерелевантные цитаты из Syllabus ISTQB. Можно теперь что-то касательно моего вопроса?

[neono]

Я надеюсь развеял ваши сомнения и вы с "интересом послушали".

Я с интересом почитал нерелевантные цитаты из Syllabus ISTQB. Можно теперь что-то касательно моего вопроса?

Если вы перестанете цепляться к словам и перечитаете еще раз то увидите что вся загвоздка именно в понятиях.
Модульное = компонентное, юнит - из другой оперы.
Я это попытался до вас донести.

А то получается что Стив Макконнелл неправ, Силлабус не прав ))
Кто прав-то? Вы? Тогда обоснуйте ваши доводы.
Пока получается что я привел какие-то аргументы, процитировав нелюбимый вами силабусс, а вы только отмахиваетесь.
К сожалению, очень тяжело так вести диалог.

[Alfa]

Если вы перестанете цепляться к словам и перечитаете еще раз то увидите что вся загвоздка именно в понятиях.

Я перечитал. И знаете заметил, что SALar считает вашу трактовку модульное vs юнит ошибкой переводчиков. Я таких переводов не встречал, но если это так, то это ошибка перевода.

Модульное = компонентное, юнит - из другой оперы.

The four levels used in this syllabus are:
o component (unit) testing;

Одно с другим как-то не вяжется.

А то получается что Стив Макконнелл неправ, Силлабус не прав ))

Я не говорил, что syllabus неверен.

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

Я пока особо ничего не утверждал, чтобы быть правым или неправым. А всего-то спросил в чем разница между модульным и юнит тестированием. Вы привели цитату из syllabus ISTQB, в которой говорилось про unit, component, integration, system, acceptance тестирование, но ничего про модульное и юнит тестирование.
Давайте далее вести диалог на русском языке. А то у меня складывается впечатление, что вы переводите apple как картошка и пытаетесь меня убедить, что яблоки родятся в земле.

[neono]

Alfa, я попытался объяснить следующее:

В силлабусе говорится что Компонентное (Юнит) тестирование ищет дефекты в изоляции от всей системы.
Здесь главное что слово юнит - элемент системы. И Юнит тестирование по этому силлабусу ничто иное как тестирование части системы.
Или компонент, или модуль, как хотите так и переводите на русский. И здесь речь идет о black box.

В головах наших отложилась другое представление юнит тестирования. Это вообще часть работы разработчика скорее, нежели тестировщика - написание юнит-тестов. То есть white box.

Мне кажется, что вся проблема именно в переводе.
Поправьте меня, если я не прав.

[Alfa]

В силлабусе говорится

Может хватит цитировать/ссылаться на syllabus не в тему? Вы либо ответьте на мой вопрос: чем модульное тестирование отличается от юнит тестирования?
Либо так и скажите: отстань-мол со своими вопросами, я и отстану. А то уже неинтересно становится.

[Sezam]

То же стало интересно в чем разница.
Всю жизнь воспринимал как одно и то же:
Юнит, модульное и компонентное тестирование.
Правда - я не пытался перенести понятия именно на код и кодозависимые части разрабатываемой системы.
Для меня эти все три понятия - как одно - тестирование наименьшей абстрактной единицы, которую можно выделить из системы, без потери уникальности и логического смысла обособляемой части.

А чем уж будет определ критерий достаточности обособления это "единицы", который вы примените на текущем проекте - это уже depends on..
Это может быть и метод, а может быть и целый пакет классов, смотря на какой уровень детализации у нас есть спеки, смотря как у нас поставлены процессы в компании.