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

[barancev]

Подсказка -- вот это тоже тесты:

dfglkjfg вапдловаып (*№%%;
123 кпедлfgd лавпав п() вадпоа ()

[lambda]

Хммм... Интересно... Подскажите, а будет ли возможен такой вариант, верен ли он?
procedure void Name(int i, long l, long l, ... long l)
Т.к. {, <param type> <param name>}, а вики утверждает, что "{A} — ноль или более элементов"

[Freiman]

Хммм... Интересно... Подскажите, а будет ли возможен такой вариант, верен ли он?
procedure void Name(int i, long l, long l, ... long l)

будет. да.

[Fine_girl]

Добрый день! возник такой вопрос:
на курсах нас учили, что когда вводишь неверные входные данные, не надо делать ошибки сразу в нескольких местах, иначе не поймешь, на чем именно программа ошибается.
например: procedure Na*me() - и void пропущен, и в названии идентификатора недопустимый символ (http://java.sun.com/...ical.html#40625 - это,кстати, про требования Java)
так вот, а можно ли в положительных тестовых входных данных объединять такие вещи, например, проверять и на правильность структуры и на правильность написания идентификатора (чтобы уменьшить кол-во):
procedure void NaMe()
procedure void n(int i)
procedure void N2(long l2)
procedure void _Na_me_(int _i_ii_)

Или правильнее проверять эти:
Procedure void Name()
procedure void Name(int i)
procedure void Name(long l)
procedure void Name(int i, long l) +

procedure void n1a2m3e9()
procedure void _na_me_() и т.д.?

[stmark]

Добрый день! возник такой вопрос:
на курсах нас учили, что когда вводишь неверные входные данные, не надо делать ошибки сразу в нескольких местах, иначе не поймешь, на чем именно программа ошибается.
например: procedure Na*me() - и void пропущен, и в названии идентификатора недопустимый символ (http://java.sun.com/...ical.html#40625 - это,кстати, про требования Java)
так вот, а можно ли в положительных тестовых входных данных объединять такие вещи, например, проверять и на правильность структуры и на правильность написания идентификатора (чтобы уменьшить кол-во):

1. Неверные входные данные.
Делать ли ошибки в нескольких местах или нет, нужно решать в контексте. Иногда в смоук тестах я использую сложные входные данные со множеством ошибок, что бы проверить всё ли правильно работает. Т.к. участок ранее тестировался, то вероятность, что тест провалится мала, а мы в сою очередь экономим время. Если же тест провалился, то прогоняется тест-комплект, состоящий из тестов с одной ошибкой во входных данных и баг локализуется. Однако тут есть ещё больший подводный камень, который проще объяснить на примере:
Допустим, в адресной строке имеем: http://example.com\a...tegory=3&id=123 . Весьма часто, когда идёт запрос по этому URL, в начале проверяется наличие данной категории, а затем уже статья. Следовательно, если мы перейдём по ссылке http://example.com\a...e?category=&id=' , нам отобразиться 404 страница и фильтрация параметра id проверена не будет.

2. Верные входные данные
Сужу по своему опыту, почти во всех ситуациях сложные позитивные входные данные оказываются равносильны множеству входных данных, проверяющих лишь один элемент. Однако и тут может статься так, что минус на минус даст плюс и мы пропустим ошибку. Поэтому, лучше всё-таки проверять каждое требование\элемент отдельно и только в смоук тестах и хорошенько всё обдумав использовать лишь сложные входные данные.

3. Связи между элементами
Ещё не стоит забывать о том, что некоторые элементы могут зависеть друг от друга и в тестах стоит использовать так же и различные комбинации ( как пример pairwise testing )

[navigatort]

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

[stmark]

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

1. Это вроде как задачка, а не настоящее техническое задание:

Наткнулась на тестовое задание яндекса.

2. А чем в точности тестирование компилятора отличается от тестирования обычного ПО?

P.S. http://web.me.com/fl...bliography.html

[navigatort]

2. А чем в точности тестирование компилятора отличается от тестирования обычного ПО?

ИМХО. В том же, в чем отличается сам компилятор от обычного ПО. Жесткими требованиями к качеству и практически абсолютно формализованной постановкой задачи (грамматика языка).

[stmark]

ИМХО. В том же, в чем отличается сам компилятор от обычного ПО. Жесткими требованиями к качеству и практически абсолютно формализованной постановкой задачи (грамматика языка).

Существует множество ПО, обладающее теми же характеристиками: банковское, медицинское, аэрокосмическое, etc.

[Natalya Rukol]

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

То, о чём Вы говорите, корректно для позитивных проверок, но не для негативных.

Что-то мне подсказывает, что комбинировать негативные проверки без ущерба покрытию невозможно (и в smoke-тестах Вы получите не просто нелокализованную проблему, а риск пропуска дефекта за корректной ошибкой).

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

[Clauster]

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

То, о чём Вы говорите, корректно для позитивных проверок, но не для негативных.

Что-то мне подсказывает, что комбинировать негативные проверки без ущерба покрытию невозможно (и в smoke-тестах Вы получите не просто нелокализованную проблему, а риск пропуска дефекта за корректной ошибкой).

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

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

[stmark]

То, о чём Вы говорите, корректно для позитивных проверок, но не для негативных.

Что-то мне подсказывает, что комбинировать негативные проверки без ущерба покрытию невозможно (и в smoke-тестах Вы получите не просто нелокализованную проблему, а риск пропуска дефекта за корректной ошибкой).

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

Пример: форма с валидаторами. Каждый пункт обрабатывается отдельно от остальных (в данном случае просто примем как должное). Этих пунктов за сотню, будем считать, что их 100 штук. При нажатии на сабмит, проверяется каждое поле и если значение не валидное, выдаётся сообщение рядом с самим полем.
Тест-кейс:
1. Вбиваем во все поля невалидные значения
2. Сабмитим
3. Анализируем сообщения об ошибках

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

Если абстрагироваться, то я с Вами согласен. Однако случаи бывают разные и иногда важность реакции на негативные кейсы очень велика.

[navigatort]

Существует множество ПО, обладающее теми же характеристиками: банковское, медицинское, аэрокосмическое, etc.

Но компиляторы - самое "рафинированное" ПО из перечисленных.

[honey]

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

я это задание тоже когда-то делал, и, по всей видимости, успешно, т.к. получил следующее :)

А что за классы эквивалентности?
Например для этого примера какой класс эквивалентности будет?

[miig]

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

я это задание тоже когда-то делал, и, по всей видимости, успешно, т.к. получил следующее :)

Насколько я понял, почитав о классах эквивалентности, в данном случае входные данные можно поделить на сл. классы:
1) Если на вх.:

procedure <return type> <name> ()

(соотв. с ошибкой (ошибками) в этом классе или без)
2) Если на вх.:

procedure <return type> <name> (<param type> <param name>)

(соотв. с ошибкой (ошибками) в этом классе или без)
3) Если на вх.:

procedure <return type> <name> (<param type> <param name>, <param type> <param name>)

(соотв. с ошибкой (ошибками) в этом классе или без)
(Класс для 3 и более "param type> <param name>", правда не знаю, нужен ли он):
4) Если на вх.:

procedure <return type> <name> (<param type> <param name>, <param type> <param name>)

(соотв. с ошибкой (ошибками) в этом классе или без)

Соотв. далее для этих 4 классов составляются тесты. Как уже было упомянто выше:

тесты, на которых должно проходить:
procedure void Name()
procedure void Name(int i)
procedure void Name(long l)
procedure void Name(int i, long l)
+ аналогично для <return type> = int

тесты, на которых должно выдавать ошибку:
procedure void ()
procedure Name()
procedure long Name()
procedure int Name(string s)
procedure int Name(int i long l)
...

также проверить "<name>, <param name> - идентификаторы, соответствующие требованиям java" - попробовать начать с цифры, например. я требования java уже точно не помню.

Т.е. помимо этих вариантов, надо, как я понимаю, ещё добавить 3-4 теста на проверку есть ли ошибки в написании или орфографии.

[miig]

Тест сдал успешно. Пригласили на собеседование. Завтра еду к ним. Надеюсь устроюсь. ))

[stmark]

Тест сдал успешно. Пригласили на собеседование. Завтра еду к ним. Надеюсь устроюсь. ))

Удачи! :)

[miig]

Сходил на собеседование. Сначала, как говорится, поговорили по душам: что было в универе, что на последней работе и тд и тп.
Потом дали: "Нужно протестировать консольное приложение, которое на вход принимает 3 целых числа, интерпретируемые как длины сторон треугольника, а на выходе выводит на экран является ли введенный треугольник равнобедренным или равносторонним. Предложите конкретные значения тестовых данных, которые Вы будете использовать для тестирования такого приложения."
Не до конца понял как в данном случае разделить тесты на классы эквивалентности, граничные значения и прочее, прочее.
Попытался вначале на классы: на выходе - ответ: равноб. треуг., ответ: равностор. треуг., ответ: ошибка, причина ошибки.
Потом попробовал разделить по типу вводимых данных: только целые (>0), только целые (<0) и тд...
В общем так или иначе выдал пачку тестов. Но забыл про случаи, когда пользователь может либо ничего подать на вход, либо забыть один или два значения указать, ввести не цифры или буквы и тд. Когда меня спросили, ничего ли я не забыл, сразу про эти варианты сообразил и сразу упомянул их. Дальше попросили показать, как бы я написал такую программку на пёрле (не тестирование, саму программку). Тут у меня то ли от нервов, то ли ещё что баш с пёрлом "переплелись" и я в пёрловском скрипте воспользовался башовскими функциями, меня поправили, вообщем в с грехом пополам с этой задачкой справился, вроде как.
Дальше дали задание "развернуть односвязный список". Тут я и сел в лужу, потому, как подзабыл как это делается. Попытался сам придумать как это сделать. Выдал им свою теорию, попросили показать, как я бы это реализовал на c/c++, чего сделать не смог, ибо уже давно с сями не работал, опять же многое подзабыл. В итоге, после всех моих мытарств сказали: "позвоним в течение недели,сообщим о своём решении".
ps. В целом собеседование было очень неплохое, они где-то меня пытались направить в верном направлении ответа и тд и тп.
В очередной раз убедился, перед тестированием даже на тестера надо не забыть и быть готовым к написанию любой программы.

[redfoks]

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

я это задание тоже когда-то делал, и, по всей видимости, успешно, т.к. получил следующее :)

Насколько я понял, почитав о классах эквивалентности, в данном случае входные данные можно поделить на сл. классы:
1) Если на вх.:

procedure <return type> <name> ()

(соотв. с ошибкой (ошибками) в этом классе или без)
2) Если на вх.:

procedure <return type> <name> (<param type> <param name>)

(соотв. с ошибкой (ошибками) в этом классе или без)
3) Если на вх.:

procedure <return type> <name> (<param type> <param name>, <param type> <param name>)

(соотв. с ошибкой (ошибками) в этом классе или без)
(Класс для 3 и более "param type> <param name>", правда не знаю, нужен ли он):
4) Если на вх.:

procedure <return type> <name> (<param type> <param name>, <param type> <param name>)

(соотв. с ошибкой (ошибками) в этом классе или без)

Соотв. далее для этих 4 классов составляются тесты. Как уже было упомянто выше:

тесты, на которых должно проходить:
procedure void Name()
procedure void Name(int i)
procedure void Name(long l)
procedure void Name(int i, long l)
+ аналогично для <return type> = int

тесты, на которых должно выдавать ошибку:
procedure void ()
procedure Name()
procedure long Name()
procedure int Name(string s)
procedure int Name(int i long l)
...

также проверить "<name>, <param name> - идентификаторы, соответствующие требованиям java" - попробовать начать с цифры, например. я требования java уже точно не помню.

Т.е. помимо этих вариантов, надо, как я понимаю, ещё добавить 3-4 теста на проверку есть ли ошибки в написании или орфографии.

Хмм, а если переменные все независимы, то зачем повторять все положительные тесты для int?

[Moretti]

Скажите, а такая задачка считается простой или уже не очень? 8-)