Здравствуйте, Аноним, Вы писали:

А>Народ не дайте помереть дураком, объясните в чем фикус subj'а?
А>Читал инет, думал, так и не понял как их делать и что они (тесты) должны делать. Может я просто не могу понять концепцию?
А>Насколько я понимаю unit тесты в общем случае гарантируют (должны гарантировать?), что код выполняет заявленную функциональность.
А>Но, к примеру имеем функцию sqrt(unsigned x), для того, что бы что-либо гарантировать мы должны выполнить полное покрытие для всех значений х и при этом уже иметь готовый правильный результат. И так собственно для всех функций, разве нет? Учитывая, что количество вариантов стримится к бесконечности, явно имеется ввиду не то? Тогда что?

Есть такое понятие, как классы эквивалентности входных данных.
При составлении тестов надо плясать от них.
Потому для тестирования sqrt будет достаточно следующих входных данных
1) +5.0 — нормальное допустимое значение
2) -10.0 — недопустимое значение
3) 0.0 — граничное значение
4) -0.0000001 — близкое к граничному недопустиове значение
5) +0.0000001 — близкое к граничному допустиове значение

Варианты 4-5 можно и исключить.

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

> Это проходит только с тривиальными функциями, но даже в этом случае можно
> сильно пролететь. Известный пример с ракетой ариант-5. Да и как
> поступать, если речь идет не о данных, а о действиях?

мда... Тестирование очень и очень сложная наука.
И чем более качественно надо тестировать тем гораздо больше ресурсов для этого надо.

С уважением
Кочмин Александр

Здравствуйте, Other Sam, Вы писали:

OS>Что-то я не смог уловить, о чем идет разговор?

OS>Unit-тестирование по-русски называется "Модульное тестирование". То есть такой тест в котором учавствует отдельный модуль системы. В противовес "Интеграционное тестирование" — при котором проверяется взаимодействие модулей.
Интеграционное тестирование может быть произведено Unit-тестированием. Мы всего-лишь должны знать стандарты взаимодействия модулей. Возможен и такой вариант, когда мы проверяем один модуль, а он взаимодействует с другим, причем на ранних стадиях тестирования второй модуль подменяется mock-объектом.

OS>Проверить правильность реализации какой-бы то ни было функции не составляет труда. Если функция задана формально можно проверить с помощью математического пакета (прогнать ночью все варианты). Либо сделать две реализации (двумя разными програмистами). Одну рабочую реализацию, которая будет включена в систему. А одну реализацию с помощью наиболее удобного инструмента. Все несоответствия в их результатах проверять и исправлять. Либо с помошью высококвалифицированного программиста исследовать реализацию как "белый ящик".
Тут речь идет или о космических технологиях, либо ядерных, когда цена ошибки слишком высока. Обычно автоматизированное тестирование происходит более просто, т.к. никто не будет впустую тратить время и деньги на проекте. Производя подобное мы соглашаемся, что возможность возникновения ошибки в нашей системе будет несколько выше, чем в космических технологиях, но этот показатель будет значительно ниже, чем при постоянном ручном тестировании того же программиста или пользователя.

OS>Действительно трудно проверять то, что не задано формально. Так как в процессе реализации действия уточняются. Нельзя написать неполную программу. Даже если какие-то данные неясно как отрабатывать, программа выкинет исключение. То есть среагирует вполне определенно. После чего придется в спецификации описать эти условия и определить как "должна" работать программа (или отдельная функция) в данных условиях.

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

Народ не дайте помереть дураком, объясните в чем фикус subj'а?
Читал инет, думал, так и не понял как их делать и что они (тесты) должны делать. Может я просто не могу понять концепцию?
Насколько я понимаю unit тесты в общем случае гарантируют (должны гарантировать?), что код выполняет заявленную функциональность.
Но, к примеру имеем функцию sqrt(unsigned x), для того, что бы что-либо гарантировать мы должны выполнить полное покрытие для всех значений х и при этом уже иметь готовый правильный результат. И так собственно для всех функций, разве нет? Учитывая, что количество вариантов стримится к бесконечности, явно имеется ввиду не то? Тогда что? Или что должны делать тесты, если речь идет о внешних сущностях? Например пользователь должен подня трубку и куда-то позвонить, причем результат зависит от номера на который он позвонил, и в свою очередь зависит от настроек телефоной станции. Количество вариантов так же немерянно, если не бесконечно, а написание хоть сколько-нибудь адекватных тестов сродни написания самой системы, поскольку основано на тщательном анализе стандартов. Даже если это автоматизировать, то как учесть человеческие ошибки? Человек может уронить трубку, набрать не тот номер, и сделать еще массу неправильных вещей, которые, тем не менее, должны быть отработаны правильно. Это не тот случай или я что-то не понимаю? Если тесты покрывают все, то их количество бесконечно, если не все, то какой в них смысл? Как заменить человека роботом, возможно ли это вообще? Имеют ли смылс потуги на частичную замену, если все равно это не гарантирует ничего? Что вообще имеется ввиду под данным термином в XP? Может кто-нибудь объяснить?
Спасибо!

> Народ не дайте помереть дураком, объясните в чем фикус subj'а?
> Читал инет, думал, так и не понял как их делать и что они (тесты) должны
> делать. Может я просто не могу понять концепцию? Насколько я понимаю unit
> тесты в общем случае гарантируют (должны гарантировать?), что код
> выполняет заявленную функциональность. Но, к примеру имеем функцию
> sqrt(unsigned x), для того, что бы что-либо гарантировать мы должны
> выполнить полное покрытие для всех значений х и при этом уже иметь
> готовый правильный результат.

ты путаешь понятия unit тестирования, как инструмента для тестирования.
И понятия качества тестирования, методики тестирования покрытия функциональности тестами и прочее.
Это совершенно разные вещи.
И "unit тестирование" никак не отвечает на второе понятие, как и и втрое ничего не знает про unit тестирование.

С уважением
Кочмин Александр

Здравствуйте, kochmin_alexandr, Вы писали:

_>ты путаешь понятия unit тестирования, как инструмента для тестирования.
_>И понятия качества тестирования, методики тестирования покрытия функциональности тестами и прочее.
_>Это совершенно разные вещи.
_>И "unit тестирование" никак не отвечает на второе понятие, как и и втрое ничего не знает про unit тестирование.

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

Здравствуйте, bkat, Вы писали:

B>Есть такое понятие, как классы эквивалентности входных данных.

Это проходит только с тривиальными функциями, но даже в этом случае можно сильно пролететь.
Известный пример с ракетой ариант-5. Да и как поступать, если речь идет не о данных, а о действиях?

Здравствуйте, Аноним, Вы писали:

А>Не так, разницу, я конечно осознаю. Скорее задаюсь вопросом может ли unit тестирование обеспечить хоть какое-то качество и если может, то за счет чего.

На данный момент unit-тестирование наиболее активно применяется в технике, известной под названием Test Driven Development (TDD). При этом unit-тесты большинством авторов, пишущих о TDD, трактуются как safety net (то есть страховочная сетка, как у акробатов). Их задача -- проверять, что при реализации некоторой новой функциональности старая не нарушена, и если нарушена -- сообщить об этом как можно скорее. Вот главным обрабом за счёт этого "непорчения" уже реализованных частей системы и обеспечивается более высокое качество. Разумеется, при условии, ваша safety net не дырявая

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bkat, Вы писали:

B>>Есть такое понятие, как классы эквивалентности входных данных.

А>Это проходит только с тривиальными функциями, но даже в этом случае можно сильно пролететь.
А>Известный пример с ракетой ариант-5.

А какие альтернативы?
Полный перебор? Не подходит даже для тривиальных случаев.
Случайная выборка? Может применяться, но имеет смысл только в сочетании
с черным/белым/серым ящиком. Иначе пролететь можно еще сильнее.
Так что, разбиение входных данных на классы эквивалентности — это разумная
и универсальная методика. В сложных ситуациях искать классы эквивалентности
сложнее. Но, как верно подметил kochmin_alexandr,
тестирование — это сложно и в общем случае не легче разработки.

За достойное вознаграждение готов рассмотреть нетривиальные функции
и выдать на гора набор тестов

Кстати, даже идеальное тестирование, вылавливающее абсолютно все баги,
не может быть гарантией качества.
Так что тестирование (а тем более unit) — это только часть всей истории.

А>Да и как поступать, если речь идет не о данных, а о действиях?

Это я не понял. Что ты имел ввиду?
Все в итоге сводится к функциям.
У тебя есть входные данные, представленные произвольным образом.
Есть функция(действие), обрабатывающая входные данные.
И есть то, что ты ожидаешь.
Ожидаемый результат — это то, что определяется спецификациями.

Здравствуйте, bkat, Вы писали:

B>А какие альтернативы?

Гы, я собственно это и не оспаривал, я хочу разобраться что могут дать тест-юниты.
Пока мне представляется, что они дают не много ни мало, ложное чувство, что у нас все в порядке.
Поэтому и возникают вопросы, что хочется как можно больше автоматизировать, особенно в случае очень больших и сложных систем, а сдругой стороны думаешь а не выйдел ли это потом боком. Я вовсе не озадачен вопросом, является ли тестирование сложным делом, как некоторым могло показаться.

B>Так что тестирование (а тем более unit) — это только часть всей истории.

Часть то часть, но от это части хочется иметь определнный результат. А то получится, что — Ура товарищи все энит-тестуы у нас пройдены. — И че? — Ну... просто пройдены...

B>Это я не понял. Что ты имел ввиду?
B>Все в итоге сводится к функциям.

Но сводится к функция по разному, если функции вызываются от, скажем эээ внешних раздражителей, то может иметь значение и порядок их вызова(или не вызова) и даже время выполнения каждой их них.

B>У тебя есть входные данные, представленные произвольным образом.
B>Есть функция(действие), обрабатывающая входные данные.
B>И есть то, что ты ожидаешь.
B>Ожидаемый результат — это то, что определяется спецификациями.

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

Здравствуйте, bkat, Вы писали:

B>Полный перебор? Не подходит даже для тривиальных случаев.
B>Случайная выборка? Может применяться, но имеет смысл только в сочетании
B>с черным/белым/серым ящиком. Иначе пролететь можно еще сильнее.
B>Так что, разбиение входных данных на классы эквивалентности — это разумная
B>и универсальная методика. В сложных ситуациях искать классы эквивалентности
B>сложнее.
Согласен, а при обнаружении нестандартных ситуаций, не входящих в текущее описание черного/белого/серого ящика, класса эквивалентности заново пытаемся определить условия проверок с учетом полученного исключения. Это вполне реальная практика, когда при начальном условии проверок мы в дальнейшем дополняем эти условия, что позволяет обеспечить приемлемое качество.

B>Но, как верно подметил kochmin_alexandr,
B>тестирование — это сложно и в общем случае не легче разработки.
При хорошем предварительном анализе это и не так уж и сложно.

B>Кстати, даже идеальное тестирование, вылавливающее абсолютно все баги,
B>не может быть гарантией качества.
B>Так что тестирование (а тем более unit) — это только часть всей истории.
В TDD unit-тестирование используется так же для понимания, что то, что Вы написали, не сломало уже имеющийся функционал.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bkat, Вы писали:

B>>А какие альтернативы?

А>Гы, я собственно это и не оспаривал, я хочу разобраться что могут дать тест-юниты.
А>Пока мне представляется, что они дают не много ни мало, ложное чувство, что у нас все в порядке.
А>Поэтому и возникают вопросы, что хочется как можно больше автоматизировать, особенно в случае очень больших и сложных систем, а сдругой стороны думаешь а не выйдел ли это потом боком. Я вовсе не озадачен вопросом, является ли тестирование сложным делом, как некоторым могло показаться.

Зависит от качества юнит тестов.
У нас на проекте куча юнит тестов, которые прогоняются
автоматом каждый раз, когда строится система.
Пользы куда больше, чем затраты на создание/поддержание юнит тестов.
В общем стоит попробовать самому, чтобы оценить.

B>>Так что тестирование (а тем более unit) — это только часть всей истории.

А>Часть то часть, но от это части хочется иметь определнный результат. А то получится, что — Ура товарищи все энит-тестуы у нас пройдены. — И че? — Ну... просто пройдены...

Ну собственно да.
Каждый раз открывать бутылку шампанского из-за этого не стоит.

B>>Это я не понял. Что ты имел ввиду?
B>>Все в итоге сводится к функциям.

А>Но сводится к функция по разному, если функции вызываются от, скажем эээ внешних раздражителей, то может иметь значение и порядок их вызова(или не вызова) и даже время выполнения каждой их них.

Внешние раздражители — это тоже входные данные.
При проектировании тестов все едино.
Реализации тестов может быть нетривиальной.
Скажем для тестирования приема/посылки SMS надо будет посторить нехилую систему,
состоящую из дорогостоющего оборудования и сложных программ.

B>>У тебя есть входные данные, представленные произвольным образом.
B>>Есть функция(действие), обрабатывающая входные данные.
B>>И есть то, что ты ожидаешь.
B>>Ожидаемый результат — это то, что определяется спецификациями.

А>Тут я не согласен, это какой-то вырожденный случай. Как правило важен еще и некий сценарий последовательности событий. И именно в сценариях то вьют себе гнёзда самые зловредные баги.

А в чем проблема?
У меня куча тестов, которые проверяют именно сценарии.
Таких тестов даже больше, чем тех, которые тестируют единственный метод.
Можешь рассматривать последовательность событий, как суперпозицию элементарных действий.

Здравствуйте, stasukas, Вы писали:

B>>Но, как верно подметил kochmin_alexandr,
B>>тестирование — это сложно и в общем случае не легче разработки.
S>При хорошем предварительном анализе это и не так уж и сложно.

Анализ — это часть работы тестера.

По аналогии с разработкой есть этап проектирования и есть этап кодирования.
Кодирование при хорошем проекте проблем не представляет
С тестами все то же самое. Тесты надо проектировать,
кодировать и даже тестировать (тестировать тесты)

B>>Кстати, даже идеальное тестирование, вылавливающее абсолютно все баги,
B>>не может быть гарантией качества.
B>>Так что тестирование (а тем более unit) — это только часть всей истории.
S>В TDD unit-тестирование используется так же для понимания, что то, что Вы написали, не сломало уже имеющийся функционал.

Так и есть.
Убеждаемся, что старые, не выявленные баги никуда не делись

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, stasukas, Вы писали:

B>>>Но, как верно подметил kochmin_alexandr,
B>>>тестирование — это сложно и в общем случае не легче разработки.
S>>При хорошем предварительном анализе это и не так уж и сложно.

B>Анализ — это часть работы тестера.
Нет, этот анализ делается бизнес-аналитиком (большая его часть), ведь при описании области автоматизации намного легче получить данные о правильном поведении от людей, которые описывают поведение будущей системы (они должны явно говорить, какие данные на входе некоторого UC допустимы, а какие нет).
Если речь идет о проверке взаимодействия компонентов системы, то здесь анализом занимается архитектор.

B>По аналогии с разработкой есть этап проектирования и есть этап кодирования.
В итоге тест-менеджер основываясь на 2-х вышеуказанных результатах составляет план тестирования и пишет описания к тестам, которые в дальнейшем реализуются кодерами.

B>Кодирование при хорошем проекте проблем не представляет
B>С тестами все то же самое. Тесты надо проектировать,
B>кодировать и даже тестировать (тестировать тесты)
Согласен.

B>>>Кстати, даже идеальное тестирование, вылавливающее абсолютно все баги,
B>>>не может быть гарантией качества.
B>>>Так что тестирование (а тем более unit) — это только часть всей истории.
S>>В TDD unit-тестирование используется так же для понимания, что то, что Вы написали, не сломало уже имеющийся функционал.

B>Так и есть.
B>Убеждаемся, что старые, не выявленные баги никуда не делись
Правильно, как описать то, что еще неизвестно Но это (неполное описание области тестирования) всего-лишь человеческий фактор при описании системы тестов (или лень правильно описать, или недальновидность при анализе/описании тестов, или договоренность об облегчении системы тестов).

Здравствуйте, stasukas, Вы писали:

S>Здравствуйте, bkat, Вы писали:

B>>Здравствуйте, stasukas, Вы писали:

B>>>>Но, как верно подметил kochmin_alexandr,
B>>>>тестирование — это сложно и в общем случае не легче разработки.
S>>>При хорошем предварительном анализе это и не так уж и сложно.

B>>Анализ — это часть работы тестера.
S>Нет, этот анализ делается бизнес-аналитиком (большая его часть), ведь при описании области автоматизации намного легче получить данные о правильном поведении от людей, которые описывают поведение будущей системы (они должны явно говорить, какие данные на входе некоторого UC допустимы, а какие нет).
S>Если речь идет о проверке взаимодействия компонентов системы, то здесь анализом занимается архитектор.

Я имею ввиду анализ спецификаций требований с целями
установить тестируемость/нетестируемость и спроектировать набор тестов.
Бизнес-аналитик этим заниматься не будет.
Это все же задача тестеров (не вдаваясь в иерархию среди самих тестеров).

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

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, stasukas, Вы писали:

S>>Здравствуйте, bkat, Вы писали:

B>>>Здравствуйте, stasukas, Вы писали:

B>>>>>Но, как верно подметил kochmin_alexandr,
B>>>>>тестирование — это сложно и в общем случае не легче разработки.
S>>>>При хорошем предварительном анализе это и не так уж и сложно.

B>>>Анализ — это часть работы тестера.
S>>Нет, этот анализ делается бизнес-аналитиком (большая его часть), ведь при описании области автоматизации намного легче получить данные о правильном поведении от людей, которые описывают поведение будущей системы (они должны явно говорить, какие данные на входе некоторого UC допустимы, а какие нет).
S>>Если речь идет о проверке взаимодействия компонентов системы, то здесь анализом занимается архитектор.

B>Я имею ввиду анализ спецификаций требований с целями
B>установить тестируемость/нетестируемость и спроектировать набор тестов.
B>Бизнес-аналитик этим заниматься не будет.
B>Это все же задача тестеров (не вдаваясь в иерархию среди самих тестеров).

B>Бизнес-аналитик пусть анализирует область и формулирует требования.
B>Этого достаточно, чтобы загрузить работой по уши любого бизнес-аналитика.
Вот в эти требования и должны входить условия тестирования в изложении пользователей. Меня ни за что не застявят дать задание тест-менеджеру на общение с "пользователями" — это привелегия бизнес-аналитика и он должен уметь вытягивать всю необходимую информацию от "пользователя". Тест-менеджер может потребовать уточнения у бизнес-аналитика, но не более.

Здравствуйте, Alexei Barantsev, Вы писали:

AB>Здравствуйте, Аноним, Вы писали:

А>>Не так, разницу, я конечно осознаю. Скорее задаюсь вопросом может ли unit тестирование обеспечить хоть какое-то качество и если может, то за счет чего.

AB>На данный момент unit-тестирование наиболее активно применяется в технике, известной под названием Test Driven Development (TDD). При этом unit-тесты большинством авторов, пишущих о TDD, трактуются как safety net (то есть страховочная сетка, как у акробатов). Их задача -- проверять, что при реализации некоторой новой функциональности старая не нарушена, и если нарушена -- сообщить об этом как можно скорее. Вот главным обрабом за счёт этого "непорчения" уже реализованных частей системы и обеспечивается более высокое качество. Разумеется, при условии, ваша safety net не дырявая

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

Что-то я не смог уловить, о чем идет разговор?

Unit-тестирование по-русски называется "Модульное тестирование". То есть такой тест в котором учавствует отдельный модуль системы. В противовес "Интеграционное тестирование" — при котором проверяется взаимодействие модулей.

Проверить правильность реализации какой-бы то ни было функции не составляет труда. Если функция задана формально можно проверить с помощью математического пакета (прогнать ночью все варианты). Либо сделать две реализации (двумя разными програмистами). Одну рабочую реализацию, которая будет включена в систему. А одну реализацию с помощью наиболее удобного инструмента. Все несоответствия в их результатах проверять и исправлять. Либо с помошью высококвалифицированного программиста исследовать реализацию как "белый ящик".

Действительно трудно проверять то, что не задано формально. Так как в процессе реализации действия уточняются. Нельзя написать неполную программу. Даже если какие-то данные неясно как отрабатывать, программа выкинет исключение. То есть среагирует вполне определенно. После чего придется в спецификации описать эти условия и определить как "должна" работать программа (или отдельная функция) в данных условиях.

В общем, реально говорить о проверке можно только если есть формальное описание функций или программы или модуля и т. д.