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

[Spy]

И любая система, нарушающая этот принцип "равновероятности" будет тем самым "контрпримером", который Вы хотите привести. Чтобы бороться с этим, нужно либо уточнять требования, внося в них все эти "особенности", либо смириться с тем, что тесты имею право пропускать такие ошибки.

А как хотя бы приблизительно оценить ту неопределённость, связанную с тем что мы позволяем себе пропускать ошибки? Или оценить тот объём тестов, которые мы умышленно/неумышленно пропускаем, а он в целом имеет значение для правильности.

Как в случае сравнения двух тестовых наборов для разных проектов. Какой протестирован лучше? В одном 1 000 тестов, в другом 1 000 000. А толку? Всё равно и там и там что-то неучли. Но в одном проекте этот неучёт будет одну сумму стоить, а в другом другую.

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

Разрешается тыкнуть меня мордочкой в какой-нить толстый бук

[Green]

SPY,
Ваш крик души услышан!

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

Если есть 1000 требований, для них написано 10000 тест кейсов из них 2000 выполнено, то легко вычислить покрытие. Если же один из пораметров неизвестен, то получить точное значение покрития невозможно.

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

Покрытие можно гарантировать только в заранее определенных величинах. Если в приложении есть 100 функций, из них только 80 описаны в документации в виде требований и только для 50 из них (требований) написаны тест кейсы, то возможно ГАРАНТИРОВАТЬ что в итоге будет протестировано только 50% функциональности (те 50 требований, для которых подготовлены тест кейсы).

Если для нашего примера протестировано только 40 требований, это означает, что план по тестированию выполнен на 80%, но при этом реально протестировано 40% функциональности.

Отследить тестирование не описанных в тест кейсах оставшиеся 30 требований невозможно, так как не известно, сколько тестов должно быть выполнено для их проверки.

Что касается 20 "неучтенных" функций системы, то они могут быть протестированы только случайным образом, так как тестировщик может и не подозревать об их существовании.

[Spy]

Софтина отослала ценную информацию на адрес А. После этого с адреса Б пришёл пакет "не понял - повтори". Софтина, не долго думая, отсылает сообщение повторно по адресу Б.

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

Производитель: "ну да, фигня случается -- забыли это протестировать".



А мы им: "А теперь, ребята, по-подробнее, что ещё вы забыли протестировать?".

----------------
В общем, меня интересует проблема построения плана тестирования, проблема обеспечения качества софта (его правильности, надёжности, безопасности и т.д. см. ISO 9126 "Software engineering - Product quality") в аспекте всех угроз и рисков, которые мешают моей софтине быть качественной.

Фигня, что план тестирования был покрыт полностью - может план был галимый?

Можно пытаться построить план на базе стандартов, учитывая все их рекомендации. Но:
1. Как проверить, что действительно все рекомендации учтены и учтены в полной мере?
2. Кто сказал, что в стандартах перечислены все характеристики?
Был ISO/IEC 9126 в 1999, а в 2004 году его переписали, потому что галимый был. Это окончательная версия? Сомневаюсь.

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

I need f-n book

[Spy]

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

Т.е. понятно, что надо рыть в сторону model-checking, software/security verification и т.д., но думал, вдруг толковый линк бросят или какой сородич обнаружится...

[timur]

А у меня такой вопрос: зачем нужны в блок-схеме модели проверки типа "topic == 0", " в подфоруме" и "posts > 1" ? Я вижу тут только бесполезное усложенение модели, приводящее к увеличению количества необходимых тестов. А в проверках типа "topic == 0" "posts > 1" я вообще вижу искусственное внесение методики тестирования доменов (по Бейзеру) в нашу модель. Мы вроде только пути собирались тестировать?

[barancev]

А у меня такой вопрос: зачем нужны в блок-схеме модели проверки типа "topic == 0", " в подфоруме" и "posts > 1" ? Я вижу тут только бесполезное усложенение модели, приводящее к увеличению количества необходимых тестов. А в проверках типа "topic == 0"  "posts > 1" я вообще вижу искусственное внесение методики тестирования доменов (по Бейзеру) в нашу модель. Мы вроде только пути собирались тестировать?

Да, Вы совершенно правильно заметили. Это некоторое усложнение, внесенное в модель искусственно и приводящее к появлению новых путей.

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

В результате так и получилось, что тестировали только пути

[idunin]

внесение методики тестирования доменов (по Бейзеру) в нашу модель. Мы вроде только пути собирались тестировать?

А можно для не понятливых объяснить? Что есть домены и что есть пути в данном контексте. Что я не очень понял! И где про это можно прочесть?

[Case]

Собственно у Бейзера и можно прочесть. "Тестирование черного ящика" Борис Бейзер. Описание есть у нас в Библиотеке.

PS
Я сейчас честно бьюсь над книгой. Зачем некоторым вещам давать свои названия, мне непонятно.

[barancev]

А можно для не понятливых объяснить? Что есть домены и что есть пути в данном контексте. Что я не очень понял! И где про это можно прочесть?

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

Домены: если есть некоторое разбиение всей области входных данных на части, то вот эти части и называются доменами, а разбиение называется разбиением данных на домены.

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

Прочитать можно, как Слава заметил, как раз в упомянутой книге Бейзера "Тестирование чёрного ящика", ее сейчас достать проще всего из тех книг, в которых можно про это прочитать.

PS: Слава, а каким вещам в этой книге даны нестандартные названия, если не секрет? Я, возможно, принадлежу к другой школе тестировщиков, так что мне как раз названия, употребляемые в этой книге, кажутся правильными и стандартными.

[DrVal]

Кстати, есть еще ошибка в блок-схеме.

http://software-test...ews/?topic=2411
В форуме существует тема с таким идентификатором, но она находится не непосредственно в ветке «Новости», а в одной из ее подветок.
Ожидается появление сообщения о том, что не существует новости с указанным идентификатором (см. также тесты 4 и 5).

Если посмотреть на блок-схему, то принадлежность к подветке проверяется для топика не в ветке Новости.

[barancev]

Кстати, есть еще ошибка в блок-схеме.

http://software-test...ews/?topic=2411
В форуме существует тема с таким идентификатором, но она находится не непосредственно в ветке «Новости», а в одной из ее подветок.
Ожидается появление сообщения о том, что не существует новости с указанным идентификатором (см. также тесты 4 и 5).

Если посмотреть на блок-схему, то принадлежность к подветке проверяется для топика не в ветке Новости.

Да, я, вероятно, недостаточно точно указал, что подразумевается под словами "тема находится в форуме Новости". У каждого форума есть идентификатор. У форума новостей этот идентификатор равен 31. Так вот, это должно означать "тема находится в форуме с идентификатором 31".

Можно придать этому другой смысл и трактовать слова "тема находится в форуме" как "тема находится в форуме с заданным идентификатором или в одном из его подфорумов". В этом случае, действительно, блок-схема неправильная. Но я предполагал ту трактовку, которая описана выше.

Мой респект за то, что заметили, спасибо!

[DrVal]

Еще немножко попридираюсь.

"Идентификатор — положительное целое число". Это не совсем точное определение.

Тип идентификатора - SQL_INDEX.
Поэтому нет большого смысла отдельно проверять является ли оно числом. Отрицательное число и нечисловое значение - частные случаи несоотвествия типу SQL_INDEX.
И вопрос о форматах записи числа сразу же снимается, т.к. к SQL_INDEX они не применяются.

[barancev]

Еще немножко попридираюсь.

"Идентификатор — положительное целое число". Это не совсем точное определение.

Тип идентификатора - SQL_INDEX.
Поэтому нет большого смысла отдельно проверять является ли оно числом. Отрицательное число и нечисловое значение - частные случаи несоотвествия типу SQL_INDEX.
И вопрос о форматах записи числа сразу же снимается, т.к. к SQL_INDEX они не применяются.

А вот с этим замечанием я категорически не согласен. Как по существу, так и в технических деталях.

Сначала по существу. "Идентификатор — положительное целое число" -- это абсолютно точное, прямо таки идеальное, математически корректное, и в данном случае правильное определение. Если кто-то может показать его двусмысленность -- пусть попробует. Что касается "идеальности" этого определения и его несоответствия "реальному" миру компьютеров, где "целые числа" -- это не все целые числа, а находящиеся в некотором диапазоне, так вот -- в качестве идентификатора можно использовать числа, выходящие за пределы всех мыслимых диапазонов всех существующих в SQL типов. И скрипт будет вести себя как ни в чем не бывало.

Теперь технические детали. Я не знаю, есть ли такой числовой тип SQL_INDEX в стандарте SQL, сильно в этом сомневаюсь. Но я точно знаю, что в MySQL такого типа нет, а насколько мне известно, позади форума прячется именно MySQL. И скорее всего для идентификаторов использован тип INT. А потому допустимые с точки зрения БД значения идентификаторов лежат в диапазоне от -2147483648 до 2147483647. То есть отрицательные среди них встречаются. И даже если бы там был модификатор UNSIGNED (а я уверен почти на 100%, что его там нет) (кстати, модификатор нестандартный), то и в этом случае диапазон был бы от 0 до 4294967295. То есть 0 в него бы все равно попал. А это нехорошо, потому что "положительное целое число" -- не то же самое, что "неотрицательное целое число".

Ну, теперь сами понимаете, что "не число" -- это действительно несоотвествие типу INT, а "отрицательное число" и 0 типу соответствуют, но не соотвествуют логическим ограничениям. Поэтому и проверены отдельно.

Почему проверены и некоторое отрицательное число и 0? Потому что опыт говорит, что ошибки чаще всего находятся на границах или вблизи границ.

[Pulsar]

Статья безусловно неплохая, но возникает вопрос по тест-плану. Тест-план ли это?

Я нашел эту статью, когда искал информацию по тест-планам, тест-кэйсам и тп., их формальные особенности ...
А также нашел вот этот пост от barancev, описывающий тест-план
Давайте, чтобы не изобретать велосипед, посмотрим, скажем, на стандарт IEEE 829
Пост мне очень понравился. Однако там сказано, цитирую:
1) "При этом test plan отностится к организационной документации (кто, что, когда)"
2) "Для test plan не хватает некоторых организационных моментов. Например, ... на каждую отводим не более одного месяца на разработку тестов и затем по 2 дня в месяц для выполнения ... "
Т.е.
должно присутствовать
"кто" и "когда"
А в тест-плане из статьи этого нет. Там сказано что многое выкинуто, но если выкинуть сроки, останется ли это планом?

[Clauster]

конечно :)

[Pulsar]

конечно :)

Кратко однако ;)
Аргументация?

[Clauster]

Кратко однако ;)
Аргументация?

А что тут аргументировать? У меня, например, все тест планы без указания сроков.

[Pulsar]

Кратко однако ;)
Аргументация?

А что тут аргументировать? У меня, например, все тест планы без указания сроков.

Так может это и не тест планы.
Вот же цитаты:
1) "... test plan отностится к организационной документации (кто, что, когда)"
2) "Для test plan не хватает некоторых организационных моментов. Например, ... на каждую отводим не более одного месяца на разработку тестов и затем по 2 дня в месяц для выполнения ... "

[Clauster]

Не смешите меня. Вы видели мои тест планы? Да и что мне цитаты. У меня своя голова на плечах.

[Pulsar]

Не смешите меня. Вы видели мои тест планы? Да и что мне цитаты. У меня своя голова на плечах.

Смеяться полезно :)
А что до остального, не видел конечно. Они могут быть просто замечательными в разделе "что", но если там нет "когда", то почему это называть тест планом?